In this article, we will take a look at Identity Access Management or IAM in GCP (the Google Cloud Platform). First off, let us understand what IAM is.
What is IAM?
Identity Access Management is a collective term that covers business policies, processes, technologies, and products that are used to manage user identities and regulate user access within an organization. These frameworks help IT, managers, to control user access to critical data within the organization. These systems can either be deployed on-premises or provided by a third-party vendor through a cloud-based subscription model or deployed in a hybrid model. IAM is a foundational security component, and its policies define:
- How users are identified in a system;
- How their roles are identified in a system and how they are assigned to the users;
- Adding, removing, and updating individuals and their roles in the Identity & Access management system;
- Systems, information, and other areas are protected by this recipe;
- Assigning levels of access to individuals or groups of individuals; and
- The correct levels of protection and access for sensitive data, systems, information, and locations.
To read more about the benefits of IAM, you can check out my article on Its importance of IAM.
How Can You Implement IAM in the Google Cloud Platform?
Not implementing IAM in your Google Cloud Platform account can expose you to many security threats and vulnerabilities. Below is a list of steps you can take to implement this and secure your cloud infrastructure.
Access via Official Email Only:
Employees should have access to your application via corporate email ids only and not personal email ids such as Gmail or Yahoo. This will prevent unauthorized access from outside of the organization.
KMS User Separation:
Ensure that no users have the KMS admin role, and any one of the CryptoKey roles follow separation of duties, where no user has access to resources out of the scope of duty.
Restrict Administrator Access for Service Accounts:
The user-managed service accounts should not have 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 to implement the principle of least privilege and prevent any accidental or intentional modifications that may lead to data leaks and/or data loss.
Multi-Factor Authentication (MFA) or 2-Step Verification is the process where one needs more than one mechanism to authenticate a user, thereby protecting the user login from attackers exploiting stolen or weak credentials. MFA should be enabled for all user accounts to help protect access to your Google Cloud Platform resources, applications, and data. It adds an extra layer of security on top of existing user account credentials (i.e., email address and password).
Building on the previous point, it is strongly recommended that Google Cloud Platform organization administrator accounts use Security Keys as a Multi-Factor Authentication (MFA) method. Security Keys are physical keys that send an encrypted signature rather than a code to protect login credentials against phishing attacks. Users simply tap the button on their security key instead of typing codes. Unlike other MFA methods that use one-time codes via text messages, security keys don’t require a phone number associated with the user account.
You should have default audit logging enabled on the Google Cloud Platform project. The default audit logs should be configured to log all admin activities and write and read access to data for all services. In addition, no exempted members should be added to the logs to ensure the proper delivery of all audit logs. This helps you keep track of user activity and take action whenever an anomaly in the logs is detected. Logging is also a necessity as per the PCI DSS and HIPAA compliance.
Logging Project Ownership:
Speaking of logging, you should enable logging, and log alerts exist for project ownership assignments and changes. Project Ownership is the highest level of privilege on a project. Any changes in project ownership should be heavily monitored to prevent unauthorized changes. Logging is also a necessity as per the PCI DSS and HIPAA compliance.
Delete User-managed Service Account Keys:
Google Cloud Platform user-managed service accounts should use GCP-managed keys instead of user-managed keys for authentication. For user-managed key pairs, critical management operations such as key storage, key distribution, key revocation, key recovery, and key rotation, as well as a key protection against unauthorized access, are your responsibilities. Anyone who has access to your user-managed keys will be able to access these resources through their associated service accounts. Deleting unwanted user-managed service account keys will significantly reduce the chances that a compromised set of keys can be used without your knowledge to access certain Google Cloud components and resources.
Insights from our Scale to Zero show
How Can Cloudanix Help?
Cloudanix audits your Cloud account and lets you know if you do not satisfy any of the above steps. In addition, we have an IAM recipe that checks if your GCP account follows the best practices for IAM regularly and notifies you if you have any above misconfigurations. To explore our audit recipe, you can start by signing up for a free trial here.
IAM is one of the most complex services in any cloud environment. Failure to adhere to the best IAM practices can lead to data breaches, data leaks, and malicious insider attacks. Having IAM vulnerabilities also violate many compliance standards like HIPAA, GDPR, PCI DSS, and CIS. Therefore, you should pay special attention to IAM in your GCP account.
Know more about:
- AWS IAM Permission Boundary and Why You Shouldn’t Ignore It.
- Why Understanding IAM (Identity and Access Management) Is Most Important For Better Cyber Security.
- A Complete List of AWS IAM Misconfigurations.