[Cloud Architect] 9. Securing Access to Cloud Services
Overview of Access to Cloud Services
In this lesson we will focus on:
- AWS Control Plane and Access Model
- The Importance of Identity and Access Management Best Practices
- Using IAM roles and Identity Federation to Provide Secure Access to Users or Applications
- Least Privilege Permissions and Policies
Securing Access
Identity and Access Management in the cloud is the cornerstone of a secure environment.
Securing access to the control plane will determine security on a network, data, and resource consumption level.
Identity and Access Management in AWS
Key Concerns Related to Access Management when Designing for Security:
-
How will users and permissions be provisioned in your AWS environment?
-
Can we avoid the use of API credentials and passwords and push for temporary credentials, one-time password/multi-factor authentication, and identity federation?
-
Are permissions least privilege access and reviewed so that they are fine tuned to only what a user requires?
-
What's the worst case scenario if credentials were stolen?
Leveraging IAM Roles
Understanding and leveraging capabilities provided by IAM roles is key to providing segmented and secure role based access control to the AWS control plane.
Imagine a situation where keys in a config file or code were accidently pushed to a repository which is viewable by unauthorized parties, such as a public GitbHub repo. Or, imagine a situation where a user's laptop or server were compromised and keys were stolen. This could be disastrous depending on how users are given access to information and services.
A much better alternative to managing sensitive keys all together is to provide access using Identity Access Management (IAM) roles. The key benefit to IAM roles is that all credentials are temporary once assumed and there is no need to store API keys permanently.
A Few Common Use Cases
Assuming Roles
Applications running on containers and servers can simply assume roles which are assigned to the server infrastructure without the need to handle API keys within code or config files.
Additionally, IAM roles can be used to provide access to a multi AWS account structure without the need for managing users across many accounts - which is a common challenge.
Another benefit is that IAM roles pave the way for devising an elevated privilege model or complete identity federation. This removes the risk associated with managing users and identities in AWS.
Identity federation involves trusting a centralized identity provider that your organization is using to effectively shift user management and authorization from your AWS account to the identity provider.
Assuming Appropriates Roles for the Appropriate Task
IAM Roles for Applications
Applications running on instances or containers should use instance profile roles and not user api keys.
Instance profile role is a special role that is assigned to EC2 instances which allow applications running on those instances to obtain temporary credentials aligned with that role.
IAM Roles for Users
All users should be using multi-factor authentication (MFA) protected role escalation or identity federation.
An Application can Leverage an IAM Role to Access AWS Services without Needing Permanent API Keys
Key Terms
IAM Users
An IAM User is a resource that represents a person or application and allows that person to interact with AWS. It consists of a name, console login credentials, and API keys.
IAM Roles
An IAM Role is an identity in AWS that has permission policies to interact with AWS. A role can be assumed by anyone who needs it, such as, users, applications, or other AWS services and accounts.
Instance Profile Roles
Instance profile role is a special role that is assigned to EC2 instances which allow application running on those instances to obtain temporary credentials aligned with that role.
Identity Federation
Identity federation involves trusting a centralized identity provider that your organization is using to effectively shift user management and authorization from your AWS account to the identity provider.
Assume Role
When I say a server can "assume a role", I mean the application can obtain temporary credentials that are aligned to a role from AWS.
IAM Best Practices
We will explore additional best practices related to identity and access management within AWS.
Root User
The root user of the AWS account is the email address that was used to create the account. This user has full control of the account and its credentials should be treated with the highest sensitivity.
Root User Multi-Factor Authentication
Multi-factor authentication (MFA) should be set up and in the hands of a trusted member of your organization.
Root User Password
The password should be stored in your organization's secrets management store with the highest sensitivity.
Root User API Keys
Never create API credentials for the root user.
Limit Usage
Avoid using the root user for anything once the account is created and initial setup has been performed. The root user has full admin access to the AWS account and can even close the account. Due to the unrestricted nature of the root user, the risk of using and sharing root credentials increases significantly.
IAM Users & Roles
IAM User Best Practices
- Enforce strong password policies in your AWS account.
- Enforce MFA for all IAM users.
- As discussed earlier, IAM user API keys should be avoided as much as possible.
- Ensure that keys are rotated regularly if they have to be used.
Audit IAM Users, Roles, and Policies Periodically
- Ensure IAM users and roles are reviewed and audited on a regular basis.
- Audit IAM policy permissions granted versus actions executed based on CloudTrail audit logs.
- Remove IAM users and roles which have not been used recently and no longer needed.
- If IAM users are being used, do not assign IAM policies to users. Instead use IAM groups to designate permissions based on a user’s group.
Further Research on IAM Best Practices
Identity Federation
Using IAM roles is more secure than provisioning IAM users and managing API keys.
Identity federation allows an organization to manage identities using an external identity provider instead of attempting to provision and manage user identities from within the AWS environment.
If a mobile or web application requires access to the AWS API, the user of that application can authenticate with a web identity provider such as facebook, google, or amazon to obtain temporary API credentials.
Examples of External Identity Providers
- SAML 2.0 Identity Providers
- Corporate active directory
- Cloud-based identity providers such as Okta, OneLogin, Ping, Centrify, AWS SSO, etc.
- Web Identity Providers
- Facebook, Google, Amazon, etc.
Identity providers can provide role based access control mapped to IAM roles and AWS accounts.
Two Primary Security Benefits of Incorporating Identity Federation
- Organizations can centrally manage users, their identities and authentication, and their various roles with respect to access to various applications and platforms. This will allow onboarding and offboarding of an employee's access to entities such as AWS seamless and compliant with an organizations approval and off boarding processes. An example of this would be an employee that has access to multiple AWS accounts, Azure, windows servers, corporate VPN etc, If the employee leaves the organization, this access can be revoke centrally.
- Identity federation removes the need to use AWS IAM users and user api keys. Access to the API is then always dependent on IAM roles via federation.
Identity Federation for Users
Identity Federation for Applications
Additional Resources
Students can read more on identity federation in the AWS Documentation.
-
DevOps engineers and those setting up and managing AWS accounts should be familiar with the material related to setting up SAML 2.0 federation.
-
Application developers who need to invoke AWS API operations from their frontend web or mobile applications can learn more about web identity federation here.
Least Privilege Access
When creating IAM policies that provide permissions to users and roles, we want to follow the common security practice of granting least privilege. Least Privilege means we grant only the permissions required to perform the necessary tasks.
When creating IAM policies that provide permissions to users and roles, we want to follow the common security practice of granting least privilege. Remember, least privilege grants only the permissions required to perform necessary tasks.
It is a very common practice to allow more permissions than necessary. Usually this is for reasons such as convenience or not knowing what permissions are required. Some of the noteworthy recent cloud data breaches were partly related to users or roles which were compromised. These users and rules had expansive enough permissions to ultimately gain access to sensitive data.
A few of the noteworthy breaches were:
- Capital One breach from 2019: An intruder was able to exploit vulnerabilities on an EC2 instance to obtain API keys, and use those keys to perform other malicious activity, including exfiltrating millions of customer records.
- Imperva breach from 2018: Hackers were able to retrieve a set of AWS API from compromised cloud instances. The keys were used to access other data.
- OneLogin 2017: AWS API keys were compromised and used to access customer data.
For that reason it is critical to fine-tune IAM policies to restrict and limit, at minimum:
- What Can be Done (Actions)
- To What (Resources)
- By Who (Principals, Trust Policies)
Build A Least Privilege Policy
Let’s take a look at a simple example of taking an IAM policy and making it least privilege.
Say you have a microservice that is designed to read and write data to a recipes table in DynamoDB.
Our environment also contains other tables to store user profile information that is accessed by other microservices that are deployed.
A simple IAM policy allowing our recipe microservice to use DynamoDB might look like this:
{
"Sid": "DDBTableAccess",
"Effect": "Allow",
"Action": [
"dynamodb:*"
],
"Resource": "*"
}The problem here is that the policy will allow the application full access to perform all operations on DynamoDB. This could include access data in other tables such as the user profile table or even deleting tables!
In the event that the role was compromised, the threat posed to our environment would be very high.
A better solution would be to fine tune the access policy so that the application only gets permission to perform the actions it needs.
In the below example, we have an IAM policy that allows specific actions and limits those actions to a specific resource - in this case, the recipes table.
{
"Sid": "DDBTableAccessLeastPrivilege",
"Effect": "Allow",
"Action": [
"dynamodb:BatchGet*",
"dynamodb:DescribeStream",
"dynamodb:DescribeTable",
"dynamodb:Get*",
"dynamodb:Query",
"dynamodb:Scan",
"dynamodb:BatchWrite*",
"dynamodb:Delete*",
"dynamodb:Update*",
"dynamodb:PutItem"
],
"Resource": "arn:aws:dynamodb:*:*:table/recipes"
}Premisson bundary can also be used to restrict the premission granted to the role in case some other policy grant full access to the same user.
