Securing Privileged Access in the cloud, due to its ephemeral nature, is quite challenging; it requires a different approach than securing a traditional on-premises environment. It requires an understanding of the various conduits or channels through which Privileged Access can be gained, as well as the challenges in securing each of those conduits.
Let’s go through these conduits and understand the security challenges while using them:
Conduit #1 – Management Consoles are a primary conduit where users gain Privileged Access to native cloud services.
- The access model is typically complex and comprises of roles, policies, permissions that are often stored inside a JSON (e.g. AWS) or similar construct. In addition to this, inheritance, federation rules and unique permission scenarios (e.g. Azure RBAC model, SharePoint Online security model), makes it difficult to gain visibility into “who has access to what?” at any given point in time. To gain this visibility, one has to perform significant amount of data sifting, crunching and enumerating over these access objects on a regular basis.
- To reduce operational overhead, Identities are often assigned a lifetime Administrator role to these consoles directly, defeating the principle of least privilege. In some organizations with no/less effective Identity Lifecycle Management, these users continue to have access even after termination and this could eventually lead to data breaches or bringing down the entire datacenter.
Conduit #2 – Native Command Line Interfaces (CLI) and API Calls represent the conduit with which applications, service accounts and both human and non-human Identities consume cloud services. Access assignments to these types of accounts are often static and the monitoring of usage is difficult due to lack of session uniqueness.
Conduit #3 – Serverless Functions available through Lambda/Azure functions are heavily used by organizations to automate and operate their cloud functions without human intervention, which often requires these functions to execute underprivileged context. Monitoring serverless functions can be challenging, due to the sheer volume and velocity of their activities. Determining and ensuring serverless functions follow the principle of least privileged access is extremely complex, time-consuming and expensive.
Conduit #4 – Local Workloads including Virtual Machines, Containers and Managed Databases
The need to manage the lifecycle of access on workloads such as virtual machines, databases (AWS RDS or Azure DB), Docker containers etc. is essential, but difficult to achieve.
- It is possible to grant Privileged Access to workloads and the users using those services by associating an elevated role. Therefore, any code running locally will now have privileged access to perform administrative actions.
- Managing local service accounts with Least Privileged Access is expensive and requires operational costs, in terms of defining and enforcing additional checks and processes. Organizations tend to use root or default privileged accounts on workloads to reduce costs, considering the workloads are transient in nature.
- How can the code’s privileged access be controlled in an ephemeral environment across hundreds and thousands of workloads? How can governance be defined to entities like IAM roles in an ever-changing cloud environment?
- Conduit #5 – DevOps and CI/CD Processes
Enterprises mostly use devOps or CI/CD tools viz. Chef, Ansible, Jenkins, GitHub etc. to interact, consume cloud services or orchestrate workloads to run on Cloud. Often it requires having or assigning privileged access to these tools/processes. Identities with privileged access on these tools can create a vulnerable workload or even create workloads with local privileged identities.
Stay tuned for the second part of my blog that goes into design/architecture principles for addressing the above discussed issues and how Saviynt enables organizations to manage and monitor privileged access in the cloud. If you have any questions, please reach out to me at Vibhuti.firstname.lastname@example.org.