IAM is allowing the right users to the right access at the right time. In today’s enterprise there are many ways to manage IAM and moving to the cloud has required additional controls to mitigate risk. An organization may deal with uniformed admins not applying the principle of least privileged. There can even be roles explosion making IAM a nightmare to manage. After using Google’s Cloud for a few years, I have watched it grow tremendously in the IAM space. In the beginning there were so few roles I never really felt comfortable granting users to projects to perform their duties. Now days there are a few products and features I hope to see from Google in the future. I’ve listed out my 10 ideas on how to further improve Google’s or any other cloud provider’s IAM offerings. While many of these can be achieved through heavy customization with programming or vendor tools it would be nice to have the ability to configure them also in the console.
1. A common problem I see at organizations is the lifecycle of employees and contractors. Missing from Google is the ability to add and remove users from groups and resources depending on their support need. This might even go along with their Access Transparency product by adding in the approval step for a cloud provider to access client data. An interesting concept would be the ability to add and remove users at certain times. This could resolve the issue of overprivileged users and forgotten access. Even some kind of approval system built in would limit access to resources. The user would have access to a role for limited time. If an engineer needs further access to debug an issue. I.e. contractor brought in to fix a bug for 1 month. It requires group owner approval through an approval form to access the system for the role.
2. 2FA is more important than ever and I have discussed some of the risks of it in other posts. There should be the ability to customize a policy to enforce 2FA for anyone assigned highly privileged roles. I believe this was a new feature added recently but only applies to groups. If we could restrict by role then it provides further protection against someone accidentally granting a new group a privileged role. Another idea is to restrict user accounts from even being assigned a role depending on their job function.
3. A useful policy configuration I have seen in AWS is the ability to limit access to a bucket to a certain IP. This gave me the idea of limiting service accounts to specific IPs too. This would add another layer of security to make sure an account is making requests from only whitelisted ranges. Attackers can compromise an account credentials but in addition they would have to have figure out how to spoof the IP or compromise the host too.
4. Add security alerts if a user is granted a role then starts doing abnormal actions. Google is clearly ahead in the machine learning space so it would be great to leverage it in the GCP for security. We can apply machine learning to get baseline activity of users already in a specific role. Afterwards security teams can detect account takeovers and be proactive. Even better is adding automated remediation to lock the account.
5. There seems to be a lack of enterprise security integrations for key tools such as Cyberark and Sailpoint. Being able to manage access through existing IAM tools with out of the box connectors will be key to managing GCP in a complex environment. It can lead to many of the features being automated such as provisioning/deprovisioning and approvals. It seems the framework is in place with the multiple GCP API endpoints to make it possible but it needs to be a joint partnership between companies to make it official.
6. Another IAM concept is segregation of duties. I want to set a global policy that states user cannot be assigned a network admin role and also the instance admin role. I don’t want users to be able to have multiple roles that could conflict and cause inside threats.
7. Adding in additional authentication/authorization check with IAP is a great way to improve security for a public app. It would be also useful to allow identity aware proxy to apply by url path. Cloudflare has a similar product called Access which is extremely simple to enable and apply to existing webapps using url routes. I don’t think this is possible with the current load balancer if the webapp is not decoupled. For example, I may want to only apply IAP to the order fulfilment portal of an app.
8. Having the ability to disable an account is useful for leave of absence scenarios. Even investigating issues or locking an account for forensics may be required. Another item to view would be last login or last access time. There should be an easy UI view of unused user and service accounts. (Again this is something similar AWS does well with their last access timestamp of tokens).
9. A reporting dashboard view of IAM is not in place. A quick health view of an entire orgs IAM access may be useful for management and security. It could provide insight into role populations and access to resources. Maybe even a network diagram web showing a user’s access to all different resources.
10. Unstructured data is difficult to keep track of and once in the cloud it becomes even more important to manage. A feature to add should be automatic remediation of access to data based on DLP classification scans. Google could integrate with their Cloud DLP or other scanning tools like Varonis which then triggers lockdown and alerts. I.e a policy could be in place to restrict access to any servers with PII data. This way users can’t accidentally misconfigure systems. There could be an alert if a user in specific roles or groups access sensitive data.
In the end most of my thoughts are trying to solve the human element. GCP provides great ways to secure resources technically but sometimes fails to provide additional safeguards against user error. Many companies aren’t able to justify the immense costs to build fort knox in the cloud and I believe the winner of the cloud market will be the one with the most simple and robust options for security.