What we learned about cloud security running a SaaS in AWS for 5 years - Part 3 - Identity and Access Management
This is Part 3 of a multi-part series of posts on how we securely ran ThreatSim in AWS for 5 years and never lost a customer (that we know of) due to any cloud security concerns.
When we set up shop in AWS we ran through different risk models to understand what we gained and lost, from a security perspective, by being in AWS. There were several technologies or facilities within AWS that we concluded we had to either trust -- or not. One of those was IAM. IAM is Amazon's black box identity and access management service. If anything related to IAM was compromised we were done. So we were honest with ourselves that IAM was something we had to trust Amazon to get right, and something we had to closely protect. Here's what we did:
IAM vs Root Account Use
Description: Ensure that IAM is used for the primary authentication and authorization method into the AWS environment.
Why it's important: Use AIM users, as opposed to the root account. IAM offers robust authentication and authorization controls including groups and policies that impact how users interact with the array of AWS services. The root account should only be used in emergencies.
Key Rotation
Description: Rotate access keys on a regular interval that is appropriate for the level of risk the keys are exposed to.
Why it's important: Individual access keys used by personnel (e.g. developers, ops, devops, etc.) should be rotated on a more frequent basis than server account keys. The rationale is that keys assigned to users are exposed to a greater risk of compromise given that they are stored on portable devices (e.g. laptops) and likely used across a wide array of software and communications channels. Service account API keys used within the organization are more likely to be used in the same way on a continual basis via established, fairly static, programmatic means.
Password Expiration
Description: Set a password expiration policy of 90 days.
Why it's important: 90 days is a sufficient balance between security and convenience.
Password Complexity
Description: Set a password complexity policy that prevents password attacks.
Why it's important: Configure a password policy for operations personnel as follows: Min length: 32, 1 upper, 1 lower, 1 number, 1 special character. Do not allow users to reset their own passwords. Personnel with administrative access should use a password manager (developed by a known, reputable developer) making the long length of the password a moot point.
MFA In Use
Description: All accounts with access to the AWS console should use MFA.
Why it's important: Ensure all accounts assigned to a user are configured with MFA, even those accounts that do not have privileged access as compromise of even a non-privileged account may allow an attacker to construct a more effective social engineering attack against the organization.
Use Service Accounts
Description: Use service account for IAM credentials that are for automated processes, 3rd party services, etc.
Why it's important: Create separate IAM users for any 3rd party credentials. For example, if the organization uses a 3rd party cloud optimization service, create a separate IAM account for that service, and then create keys for that service. If this 3rd party service is compromised, it is easier to revoke the keys for that one service rather than having to determine which keys were exposed.
No Service Account Passwords
Description: Do not configure service accounts with an IAM password.
Why it's important: Service accounts do not access the AWS web console. As such, they do not need a password configured for their account.
Service Account IAM Policies
Description: For some service accounts, create dedicated IAM policies.
Why it's important: If a 3rd party service requires read-only access to only a subset of AWS services, create an IAM policy that only requires access to those services. Many 3rd party services will provide a template that can be used.
IAM Policy - Least Privilege
Description: Whenever possible, follow the principle of least privilege.
Why it's important: Configure IAM policies that provide access to only those resources that are used to satisfy a valid business requirement.
IAM Policy - User Account IP Restrictions
Description: Configure IAM policies so that API keys can only be used from approved IP addresses.
Why it's important: IAM API keys (especially privileged keys) by default allow access from any IP address on the internet. To mitigate this risk, configure IAM policies so that keys can only be used from approved IP addresses or ranges. For example, a purpose-built VPN device that is protected with MFA. Where possible, restrict service accounts to approved IPs or ranges. Note: This is not always possible given that many 3rd party services do not originate from the same static IP address when connecting to AWS API.
Note: We found that there are some AWS services that will (it's rare) deny certain actions with IP-restrictive policies. To date we have noticed this behavior in certain VPC actions, Athena, and WAF. In these cases we created a specific user that did not have the IP-restriction policy applied. We then performed the operation, logged out, and disabled the account.
Use Groups to Assign Permissions to Users
Description: Do not assign permissions to users. Rather, assign permissions to groups.
Why it's important: Create a group that has a given policy applied to it. This way, the organization can manage user permissions at the group level (e.g. Security Operations, Support, Accounting, DevOps, etc.)
IAM Predefined Policies
Description: Use AWS predefined policies whenever possible.
Why it's important: Use AWS's predefined IAM policy templates when possible and refrain from creating IAM templates from scratch.
Use Roles for Applications When Possible
Description: If possible, avoid the use of API keys for AWS services in favor of IAM Roles.
Why it's important: When using AWS services (e.g. Lambda, EC2, etc.) try to use Roles versus API keys. Roles are more secure in that they do not use traditional keys that are more static and more vulnerable to compromise.
Regular IAM Review
Description: Review IAM users and permissions on a regular basis.
Why it's important: Conduct a regular IAM account review to ensure that users and permissions present are still appropriate.
Rotate Encryption Key
Description: Enable IAM Encryption Key rotation.
Why it's important: IAM key rotation should be enabled for KMS-backed encryption keys.
IAM Access Key Use Documentation
Description: Document where IAM access keys are used within your application and associated services.
Why it's important: Document when and where AWS API keys are used within the application or with a third party service. In the event of a security incident, it is helpful to have documentation that explains where each key lives within the organization.
Use Descriptive IAM Usernames
Description: Use a standard IAM username format that is descriptive.
Why it's important: When investigating security incidents or troubleshooting, responders will often have a large amount of information from different systems, from different environments, in different regions. As such, naming accounts according to a standard is helpful. For example, John Doe's US Production account might be named "jdoe-us-prod". This format communicates who it is, how the account is used, and where it is used. This format is also conducive to searching logs and correlating events.
Password Manager
Description: Provide personnel with a password manager.
Why it's important: Provide operations personnel with access to a secure password manager from a reputable developer. If the password manager supports group or team access, be mindful of how the password manager performs synchronization or password sharing.
Next post: Part 4 - Network Security