The Untold Risk of Automatic Remediation of Cloud Access

Authored by: Lori Robinson

It’s inevitable that you will run across a situation where the cloud access configured in your environments is misconfigured or over provisioned. This is to be expected due to the high velocity, large volume, and wide variety of changes that are constantly taking place in cloud environments. Even with the most carefully crafted governance framework, access can be directly provisioned in the target cloud environment bypassing processes and procedures and finding its way into your cloud environments.

Employing digital sentinels that stand watch night and day over vast cloud landscapes is a good first step. Automated monitoring can help you quickly uncover inappropriate, unused and risky access. The challenge then becomes to understand how this access came to be, and should it remain in place? The remediation of access is where many organizations get into trouble. A knee-jerk reaction may be to just revoke cloud access on the spot that appears incorrect or out of place.  However, this approach ends up bypassing the governance policies and procedures that your organization has spent so much time and effort implementing and refining.

It may seem ironic to bypass established process and procedures, but many cloud management solutions support and emphasize the ability to directly remediate cloud access and configuration violations in the target cloud environments. While this automatic remediation is swift, it could lead to inadvertently denying access that has been approved or is required for automated cloud workload scenarios. Let me present you with just a couple of real-world scenarios of why remediation-in-place is not a good approach when it comes to governing cloud access.

Cloud workloads and deployments are rapidly “shifting left” with the adoption of cloud infrastructure-as-code. That is to say, manual tasks that used to require human efforts are now becoming more automated, and also moving upstream. Coded templates leveraging re-usable patterns encapsulate much of the work necessary for rapid configuration and execution.  Without context, someone may not realize that particular cloud access to say a database, storage, or network resource is part of a carefully automated and orchestrated workflow or “pipeline”. Making automatic changes to such cloud access without the correct visibility into how and why that access was granted can disrupt existing pipeline executions, causing critical application builds and deployments to fail. By not understanding the origin of that access, chances are the automated processes will simply override any local changes made the next time the automated deployment happens again. So, the work you did to revoke that access is futile because that access will soon magically appear again upon the next cloud workload deployment.

Another reason automatic remediation can be risky is that it can bypass the established process and procedures set up as a part of an identity management program or solution. Because identity is a critical component of securing access, most organizations make use of a centralized solution for granting access across the enterprise.   Such access may be abstracted and automated in several ways, ranging from pre-defined access assignments based on identity attributes, group membership that maps to effective or federated cloud access, and even bundles of access represented as roles.  Without this context, you are essentially operating blind when trying to assess whether a particular piece of cloud access should be removed. You would not want to incorrectly revoke cloud access that is needed for say the cloud operations team to do their job, or a new project that recently spun up.

Automating the monitoring of cloud access is a good first step- that provides you the “what”.  But you also need to know the “how” and “why” to fully understand how such access is being granted in order to effectively govern. That is why integrating your cloud governance into an identity framework is a critical part maintaining consistent visibility and control across all your points of access. This integration enables you to leverage your existing investments to provide the context you need to correctly remediate cloud access. By taking this identity-centric approach to cloud governance your existing identity processes, workflows, signoffs and reporting can be extended to your cloud environments simplifying administration, enhancing security and easing compliance.


Discussion