The Security pillar of the Well-Architected Framework focuses on improving the security posture of your infrastructure and application workloads. In previous chapters, we discussed the concept of the AWS Shared Responsibility Model, which emphasizes the point that AWS, as a cloud provider, is responsible for the security of the cloud, and the customers are responsible for security in the cloud. The Security pillar identifies steps that can be taken by customers to improve the security of users and workloads in the cloud. Let’s go through some of those.
Best practices for enhancing your cloud security posture
Starting from how your users gain access to AWS accounts and applications, to protecting data in transit and at rest, there are quite a few areas that need to be addressed to ensure a good security posture on AWS.
Centralizing identity and access management
Avoid creating static identity and access management (IAM) credentials in any AWS account and federate all human access through a centralized identity provider (IdP) that you might already be using in your organization. It’s a common practice to use solutions such as Azure AD, OneLogin, and others for centrally authenticating and authorizing human users. AWS services such as IAM Identity Center make it easy to leverage the same IdP to federate users into AWS accounts with different levelsof access rights. For technical use cases, where applications or automation tools need access to AWS services, always leverage IAM roles without any static provisioning of user credentials. IAM roles give you dynamically generated temporary credentials, which greatly improves your security posture.
However, there are exceptions where you might have to create a pair of IAM credentials in the management account, as per the best practices for break-glass access patterns. These patterns advocate the creation of a limited number of static credentials in the management account to handle scenarios such as outages of the IdP or security incidents that require manual intervention procedures to be invoked. However, it’s important to note that there should be adequate monitoring around the usage of these credentials, and all activity should be audited. Toward the end of this section, we will discuss an implementation using the AWS User Notifications service, which can be used to send out notifications through commonly used communication platforms and channels.
Implementing security-in-depth principles
Security should be applied at multiple layers, starting from the edge of the network to the perimeter of VPCs and subnets, and moving down to the instance level, securing the application and operating system itself. It’s a good practice to implement security controls, both preventive and detective, to allow healthy communication patterns.
With a combination of AWS service control policies (SCPs ), AWS Config Rules, and networking controls such as subnet network access control lists (NACLs), security groups, and so on, appropriate measures can be taken to implement security in depth.
Protecting data in transit and at rest
Many AWS services offer out-of-the-box data encryption at rest. At the bare minimum, this provides security coverage for your data, but the ownership and management of the encryption key resides with AWS. Customers operating in more sensitive domains such as financial services might use their own encryption keys that can be managed using AWS Key Management Service (KMS).
Automating security measures as code
Utilize automated software-based security mechanisms to enhance scalability while ensuring cost-effectiveness. Develop secure architectures with version-controlled templates defining and managing security controls as code.
Reducing direct human data access patterns
Utilize mechanisms and tools that minimize or eliminate the need for direct access or manual handling of data, reducing the risk of mishandling and human errors involving sensitive data.
Preparing for security incidents
Every organization operates in the cloud in a slightly different way when it comes to incident management. It is therefore necessary to have a well-defined incident management procedure that is tested and tailored to your unique needs and team structures.
Up next, let’s look into a common security monitoring requirement for break-glass user access, which we discussed a while ago.