In the cloud, access control involves who has access (identities) and what kind of access each identity has. When it comes to human identities, we have several ways to manage them using 3rd party tools. We can avoid creating an account and depend on SAML Assertion or Open ID connection with MFA enabled to maintain access control. But when it comes to Machine IDs, Application IDs, or Service IDs,the IDs are created by applications. We still need to create access keys and set permissions, but these kinds of accounts exist in the cloud and have broader access to different resources than Human IDs. If these automated non-human IDs are not securely managed, bad actors can exploit enterprise infrastructure and data. A recent example of this is the Uber breach that occurred in 2021.
This doesn’t mean we don’t have a solution or tool to manage this situation, we do, but as cloud security owners we must understand this new complexity and implement needed controls. Thinking in traditional ways often defined by on-prem experiences could leave a large loophole in the infrastructure. The traditional way wasn’t wrong, but it was implemented for on-premises infrastructure where all the applications and systems were disconnected, and the only way to log in to the company was via a defined perimeter.
In the cloud, there are many ways users and systems can interact with each other. All systems/apps are interconnected. For example, in the cloud, users can log in to their account through the company network as well as out of the company network directly to the SaaS resource. Therefore, if the company does not have good control over those SaaS accounts, then a bad actor can log in through the internet and gain access to company cloud infrastructure and cause damage or steal data.
In solving this kind of challenge, cloud teams must follow cloud security practices, identity governance best practices, and data governance best practices, and all this needs to be viewed through a single pane of glass so that if anything is missing, then it can be detected.
Let’s look at each section and see how a small mistake can impact the security of cloud infrastructure.
1. Identity Control
In a cloud environment, permission to access your organization’s resources are tied to your identity. This makes identity incredibly valuable. It is a key to the kingdom, as it were. A specific user identity gets privileged access to do their job, such as create or delete certain buckets, upload bucket objects, or one of a dozen other tasks that require more expansive permissions than what a normal user should have.
AWS allows us to create AWS Roles with specific permissions but are not tied to any singular identity. Instead of granting and revoking said permissions to each individual on an ad hoc basis, we can give the Role the necessary entitlements and allow our users (with their identity) to utilize this Role to get their job done.
The Real Challenge: Controlling Assumed Roles
There is a feature in AWS called “Assume Role,” in which a role does not have their own permission but can assume other roles, which then can have some broader access.
Example: Role SuperUser might not have any permissions by itself, except the ability to assume two other roles: ReadOnly, and Writer
Now this has 2 challenges:
- It is very hard to find who has executed the command
- Who has what kind of access
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::999999999999:root "
},
]
},
"Action": "sts:AssumeRole"{
"Arn": "arn:aws:sts::111122223333:assumed-role/listuser
}
}
]
}
2. Resource Control
In the cloud, resources are where all the company code is deployed. Cloud resources including applications, services and databases are used to create products and deliver business value. These components or services of cloud resources can be controlled with resource policies. These resource policies are simply IAM policies, which can be as easily misconfigured as user permissions. As a result, users without credentials attempting to access cloud resources can expose corporate cloud resources to external cyber attackers.
Example: By configuring resources with the code below, we have roles for Approle and DataBaseRole and they are enabled to “allow” and “passrole”. These roles should be more granular and not be allowed blanket access as in the example below.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:GetRole",
"iam:PassRole"
],
"Resource": [
"arn:aws:iam:::role/EC2-AppRole",
"arn:aws:iam:::role/EC2-DatabaseRole"
]
}
]
}
3. Policy Control
A policy is an object in AWS that, when associated with an identity or resource, defines its permissions. AWS evaluates these policies when an IAM principal (user or role) makes a request. Permissions in the policies determine whether the request is allowed or denied. When you create a permissions policy to restrict access to a resource, you can choose an identity-based policy or a resource-based policy.
Identity-based policies are attached to an IAM user, group, or role. These policies allow you to specify what that identity can do (its permissions). For example, you can attach the policy to the IAM user named John, stating that he is allowed to perform the Amazon EC2 RunInstances action. The policy could further state that John is allowed to get items from an Amazon DynamoDB table named MyCompany. You can also allow John to manage his own IAM security credentials.
Resource-based policies let you grant usage permission to other AWS accounts or organizations on a per-resource basis. You also use a resource-based policy to allow an AWS service to invoke your function on your behalf. For Lambda functions, you can grant account permission to invoke or manage a function.
The permission “lambda: AddPermission” is used to add resource policies to Lambda functions, determining which services can access the function, trigger its code, or even update it. This permission is extremely powerful: In the wrong hands, it can allow an attacker to take over any existing lambda in the account and consume its privileges to become a supervillain.
4. Data Control
A data policy is a high-level collection of statements that describe expectations and intended results, intending to influence or direct data habits at the business level. Data policies are established through data governance initiatives such as Outbound data sharing, regulatory conformity, and other policies
Data access is one of the main outputs of effective data governance. Organizations should ideally have well thought out, structured means of granting data access to different users. This is reinforced by various permissions and levels of security required for data access. Frequently, these permissions are based on organizational roles or responsibilities.
Conclusion
Cloud teams that are innovating to create business value for their organizations are facing new security and identity governance challenges. Understanding the control challenges around cloud access, resource, policy and data is an important first step towards making the necessary security and IGA advancements to prevent cloud breaches and data theft.
