Mitigation for a Lack of Identity Federation
Implementing a modern identity service or platform helps mitigate the risk of password compromise with multiple identities. AWS’s native IAM Identity Center allows you to connect with your existing SAML identity provider or create and manage your users and groups directly from the IAM service itself.
This helps prevent password reuse. This is especially important in the case of an account compromise in which a single account has been compromised and the username and password combination is used to access multiple accounts if the password is the same across those accounts.
There are many examples of documentation wherein IAM policies have been scoped with wide-open permissions. This is done by design, for as you are learning about a new service or a new feature of a service in AWS, it can be frustrating to not have it work due to a permission issue. Having these wide-open roles in systems that will be used to communicate with production-level services and data can leave things in a vulnerable state.
As AWS users assume roles, the permissions passed on to them are taken on by the entity that uses that role. A Principal element is a necessary element in an IAM policy that specifies who is allowed (or denied) access to the resource. A wildcard, a character or symbol, used as a placeholder to match or represent one or more other characters in a string or filename, is often used when crafting the policy, especially when modeling IAM policies after example policies. This wildcard – designated by an asterisk (*) – allows everyone to assume the role.
A vulnerable policy, with the Principal of the policy having a wildcard, (*) is shown in the following example:
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Principal”: { “AWS”: “*” },
“Action”: “sts: AssumeRole”
}
]
}
The same can be said for IAM policies that use a wildcard with the Resource element of an IAM policy. The Resource element in the policy defines the specific object or objects that the preceding statement covers. Leaving the resource as a wildcard allows access to all items spun up in your account.
Mitigation of Vulnerable IAM Policies
Helping prevent vulnerable IAM policies comes back down to the principle of least privilege and taking the time to craft the permissions in the policies for the people and groups who are going to be assigned to those policies, along with the resources that they will be expected to manage with those policies.
Using only wildcards can leave your IAM policies vulnerable. However, this does not mean that a wildcard cannot be a valuable tool when crafting a policy to provide your users with the exact privilege that they will need. Another powerful tool when crafting policies is the use of policy variables.
The JSON policy variables are a way to identify a specific resource, but that resource does not have to be hardcoded into the JSON policy document itself.
The following example shows that a user with the previous policy attached can access any CloudWatch log group in US East 2 (Ohio) that matches the current user’s name:
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: “cloudwatch:*”,
“Resource”: “arn:aws:cloudwatch:us-east-2:log-group:${aws:username}”
}
]
}
The previous sections demonstrated how making some minor adjustments to your policies can help stave off attacks on your AWS account. You can also shift left your security practices by ensuring proper credential rotation and scanning for credentials and secrets in your code base before they ever make it to public or private repositories. This is discussed in the next section.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
