Misuse of privileged access is becoming one of the primary culprits behind cloud data breaches. Despite significant efforts from leading cloud providers in creating awareness of the shared responsibility model, the leaks continue to grow both in numbers and size. This warrants the relooking and crafting a focused strategy for privileged access management (PAM) on cloud data repositories, cloud databases as services, elasticsearch databases and cloud file systems.
This article aims to explain the design principles and germane solutions for an effective and scalable PAM strategy to secure data on cloud data stores.
Design principle No. 1: Identity is the new threat vector
Employees, contractors and collaborators represent human identities, while VMs (virtual machines), database services, Kubernetes clusters and serverless functions represent silicon identities. Privileged roles and permissions can be assigned to any and all of these identities. Therefore, the principles of PAM and governance apply to both. Discovering identities with privileged access on cloud data stores is paramount to an effective PAM strategy for cloud data stores.
Solution: Human identities can very well be determined from directories, databases or HR systems. continuous integration (CI) and continuous delivery (CD) systems, DevOps tools, cloud workloads, and cloud data stores are the conduits/interfaces to which silicon identities are assigned. Continuous scanning and parsing of role or permission assignment objects provide detailed information on silicon identities.
Design principle No. 2: Identify all viable privileged access patterns
Assignment of privileged access via policies, roles and access control lists (ACLs) can be done in various ways:
• Native identity and access management (IAM) assignments: Roles and permissions offered by native cloud security frameworks (AWS IAM, Azure RBAC, etc.) can invariably be attached/assigned to multiple cloud services, including VMs (pattern used in a large-scale breach), serverless functions, or local and federated user accounts (major cause of failed audits due to missing visibility).
Solution: Continuously scan these security objects (roles, policies, ACLs, etc.), and deduce the permissions these objects grant on human service accounts as well as on cloud workloads. The scans provide insights on all possible privileged paths to cloud data stores, both point in time as well as continuously. Further, real-time alerting/remediation should also be added to prevent privileged access elevations on extremely sensitive data stores
• Resource policies: Resource policies, as the name suggests, are defined at individual data stores. These policy assignments enable access to cross-cloud subscriptions or tenants, both anonymous and authenticated users.
Solution: Continuously scan the resource policies, which entails parsing large sets of policy documents and creating a permissions matrix. The matrix provides deep access visibility on the data stores for any and all types of identities. The matrix should further be augmented with real-time monitoring.
• Access control lists (ACLs): Legacy security models on few data store types (e.g., S3 buckets) support the use of ACLs. Misconfigurations on ACLs can expose data in such buckets and often make them susceptible to data leaks/breaches.
Solution: It is strongly recommended to avoid using ACLs, and if needed, they should be continuously monitored and automatically remediated for misconfigurations.
Design principle No. 3: Discard rudimentary access assignment methods — they won’t scale
Static access assignments with elevated permissions to humans lead to residual access or long-term privileged access on cloud data stores. Alternative approaches of distinct user accounts with nonprivileged and privileged access still result in long-term access with account sprawl and increased risk exposure.
Solution: An effective measure is to elevate the access just in time for a predefined duration. Using roles and just-in-time user accounts are some unique approaches to solve this. Privileged roles can be achieved by collating fine-grained policies/permissions from native cloud providers.
• Just-in-time role assignment to cloud services requiring privileged access on cloud data stores: Static assignment of privileged roles to cloud workloads vis-a-vis VMs, containers, serverless functions, etc. gives such services unfettered access to data stores for the long term and is open for exploits.
Solution: Initiation of services with read-only permissions and assignment of privileged access can reduce risk exposure drastically. Services should check out privileged permissions, and the same needs to be checked in after the execution or completion of a job, at which point permissions should be switched back to read-only.
• Just-in-time access assignment using "roles layering" approach to custom services/applications: Privileged access is primarily provided by long-term keys, often embedded in application code or custom scripts. These long-term keys precariously make their way to public code repositories and become available for unauthorized usage.
Solution: Using a "roles layering" approach allows short-term API keys to be assigned to calling services/applications. Roles layering provides the ability to scale, with one single role becoming the conduit to assume multiple roles across various cloud services or tenants.
Design principle No. 4: Consolidate risk
Organizations have disparate views of user risk, security misconfigurations of cloud workloads and vulnerabilities. Point solutions give a fragmented view of risk exposure and have failed in preventing data leaks or breaches.
Solution: Consolidate events from various sources to a centralized risk hub, and use it to create a risk model. Use the same to provide necessary intelligence and insights to privileged access workflows. Aggregation can be done from user entity and behavior analytics (UEBA) platforms, which build a user’s baseline profile, as well as cloud workloads and risky misconfigurations (e.g., a virtual machine or a Kubernetes cluster with open ports to the internet, an old software version and elevated permissions to cloud databases).
Cloud data leaks and breaches will continue to be an issue. Securing data requires a concerted effort with a nonfungible and focused PAM strategy. Cloud’s ephemeral nature demands a scalable solution in which risk awareness and governance cannot be an afterthought.
