Users Should Use Work Email For Access
User should have access via their official corporate email id and not their personal id.
User should have access via their official corporate email id and not their personal id.
Ensure that no users have the KMS admin role and any one of the CryptoKey roles follows separation of duties, where no user have access to resources out of the scope of duty.
Ensure that user managed service accounts do not have any admin, owner, or write privileges. Service accounts are primarily used for API access to Google. It is recommended to not use admin access for service accounts.
Service account keys should be rotated periodically.
Service account keys should be managed by Google to ensure that they are as secure as possible, including key rotations and restrictions to the accessibility of the keys.
Ensuring that no service accounts have admin privileges.
Ensures that no users have the Service Account User role. The Service Account User role gives users the access to all service accounts of a project. This can result in an elevation of privileges and is not recommended.
Ensure that Cloud KMS cryptokeys are not anonymously or publicly accessible.
Ensure KMS encryption keys are rotated within a period of 90 days.
Rotate cryptographic keys on a regular schedule. Thus, key rotation should be enabled on all cryptographic keys. Google will handle the rotation of the encryption key itself, so previous data does not need to be re-encrypted before the rotation occurs.
Security risks involved in using API-Keys appear below: • API keys are simple encrypted strings • API keys do not identify the user or the application making the API request • API keys are typically accessible to clients, making it easy to discover and steal an API key To avoid the security risk in using API keys, it is recommended to use standard authentication flow instead.
Security risks involved in using API-Keys appear below: • API keys are simple encrypted strings • API keys do not identify the user or the application making the API request • API keys are typically accessible to clients, making it easy to discover and steal an API key In light of these potential risks, Google recommends using the standard authentication flow instead of API keys. However, there are limited cases where API keys are more appropriate. For example, if there is a mobile application that needs to use the Google Cloud Translation API, but doesn't otherwise need a backend server, API keys are the simplest way to authenticate to that API. In order to reduce attack vectors, API-Keys can be restricted only to trusted hosts, HTTP referrers and applications.
Security risks involved in using API-Keys are below: • API keys are simple encrypted strings • API keys do not identify the user or the application making the API request • API keys are typically accessible to clients, making it easy to discover and steal an API key In light of these potential risks, Google recommends using the standard authentication flow instead of API-Keys. However, there are limited cases where API keys are more appropriate. For example, if there is a mobile application that needs to use the Google Cloud Translation API, but doesn't otherwise need a backend server, API keys are the simplest way to authenticate to that API. In order to reduce attack surfaces by providing least privileges, API-Keys can be restricted to use (call) only APIs required by an application.
Security risks involved in using API-Keys are listed below: • API keys are simple encrypted strings • API keys do not identify the user or the application making the API request • API keys are typically accessible to clients, making it easy to discover and steal an API key Because of these potential risks, Google recommends using the standard authentication flow instead of API Keys. However, there are limited cases where API keys are more appropriate. For example, if there is a mobile application that needs to use the Google Cloud Translation API, but doesn't otherwise need a backend server, API keys are the simplest way to authenticate to that API. Once a key is stolen, it has no expiration, meaning it may be used indefinitely unless the project owner revokes or regenerates the key. Rotating API keys will reduce the window of opportunity for an access key that is associated with a compromised or terminated account to be used. API keys should be rotated to ensure that data cannot be accessed with an old key that might have been lost, cracked, or stolen.
Many Google Cloud services, such as Cloud Billing, send out notifications to share important information with Google Cloud users. By default, these notifications are sent to members with certain Identity and Access Management (IAM) roles. With Essential Contacts, you can customize who receives notifications by providing your own list of contacts.
Cloud services offer the ability to protect data related to those services using encryption keys managed by the customer within Cloud KMS. These encryption keys are called customer-managed encryption keys (CMEK). When you protect data in Google Cloud services with CMEK, the CMEK key is within your control.