Cloudanix
GCP IAM Compliance
User should have access via their official corporate email id and not their personal id.
Users Should Use Work Email For Access
User should have access via their official corporate email id and not their personal id.
KMS Admin Roles Should Not Have CryptoKey Role
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.
User Managed Service Account Should Not Have Admin Priviledges
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
Service account keys should be rotated periodically.
Keys Should Be Managed By Google
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.
Service Accounts Admin And User Permissions Should Not Be Assigned At The Same Time
Ensuring that no service accounts have admin privileges.
Service Account User Should Not Have Service Account Token Creator Role
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.
KMS Cryptokeys Should Not Be Public
Ensure that Cloud KMS cryptokeys are not anonymously or publicly accessible.
KMS Encryption Keys Should Be Rotated
Ensure KMS encryption keys are rotated within a period of 90 days.
Cryptographic Keys Should Be Rotated
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.
Ensure API Keys Are Not Created For A Project
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.
Ensure API Keys Are Restricted To Specific Hosts And Apps
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.
Ensure API Keys Are Restricted To Necessary APIs
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.
Ensure API Keys Are Rotated Periodically
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.
Ensure Essential Contacts Configured For Organization
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.
Ensure Dataproc Clusters Encrypted Using CMEK
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.
Security for your Code, Cloud and Data
Cloudanix replaces your 5-6 disjointed security tools within 30 minutes.
Get StartedCLOUDANIX
Insights from Cloudanix
Explore guides, checklists, and blogs that simplify cloud security and help you secure your infrastructure.
Case Studies
Real-world success stories where Cloudanix helped organizations secure their cloud infrastructure. Watch how we made a d...
What is CSPM?
Understand what Cloud Security Posture Management (CSPM) is and how it automates security and compliance across cloud en...
CASB, CSPM, SIEM: Cloud Security Essentials
Understand how CASB, CSPM, and SIEM work together to enhance your cloud security posture and ensure better governance.
What is Cloud Audit?
In-depth assessment of cloud environment for security, compliance, and optimization. Identify vulnerabilities, ensure da...
Top 10 Challenges of CSPM
Cloud environments are getting more complex and dynamic day by day, making it difficult to gain complete visibility into...
Cloudanix docs
Cloudanix offers you a single dashboard to secure your workloads. Learn how to set up Cloudanix for your cloud platform ...
Changelog
A complete history of changes, improvements, and fixes for Cloudanix. Subscribe to get notified about the latest updates...