Journey to a Successful AWS Deployment – Part 2 Cloud Security
Insight recently partnered with Amazon Web Services (AWS) to help customers with their cloud journey. Each customer’s requirements for the cloud can be different, from applications born in the cloud to a “lift and shift” migration of existing workloads to the cloud. A consultative approach is taken to ensure the migration to the cloud is efficient and fit for purpose.
What is common between each approach, is how the solution is architected to result in a successful deployment. Insight approach each design following the AWS Well-Architected Framework. The framework is a published set of best practices for deployment to AWS services. This framework provides consistency across deployments.
The AWS Well-Architected Framework consists of five pillars:
- Operational Excellence
- Performance Efficiency
- Cost Optimization
The following post is part 2 of a blog series covering each of the five pillars and how Insight use these whilst architecting in the cloud. AWS provide a whitepaper on this subject – AWS Well-Architected Framework.
The second pillar in the AWS Well-Architected Framework is Security. Security is a major consideration for any organisation looking to adopt cloud. Customers often ask, how can I control access to data and applications? Is the data protected? How can I control access and be able to trace previous access and changes?
This pillar of the framework covers those questions posed by covering the ability to protect information, data and applications. This pillar also covers risk assessments and mitigation strategies available, the design principles covered are as follows:
- Implement A Strong Identity Foundation: Adopting a least privileged model to the AWS environment such as deny by default and limit access to only the required amount of time. Enforce regular access credential rotation and enforce separate of duties.
- Enable Traceability: Covered in more detail in the first pillar – Operational Excellence. Enable monitoring from conception and centralise logging in real-time for auditing. Integrate logs and metrics with systems to automatically respond to events and take automated actions.
- Apply Security At All Layers: Traditional infrastructure focused security at the perimeter of the network that enforced security on north-south traffic. This design principle shifts that focus to a defence-in-depth approach, apply security at all levels such as the edge, subnet level, instance level, operating system and application.
- Automate Security Best Practice: Manage and apply security mechanisms as code. Secure architecture implemented as code ensures security compliance when deploying infrastructure and applications. Security can be baked into deployment cycles using version control between teams.
- Protect Data In Transit And At Rest: Protect data when in transit and when at rest using encryption and access control where required.
- Keep People Away from Data: Remove direct access to infrastructure and applications where it is not required. Eliminate the need of manual processing of data by automating and removing human error reducing the risk of data loss.
- Prepare For Security Events: Create well-documented incident management and procedures. Regularly run incident response simulations and develop tools that can automate detection and recovery.
Security is broken down into five focus areas of best practice:
- Identity and Access Management
- Detective Controls
- Infrastructure Protection
- Data Protection
- Incident Response
The following section highlights the key takeaways of each area.
Identity and Access Management
AWS Identity and Access Management (IAM) is fundamental to enabling security across the AWS environment. IAM is AWS’ tool for handling things such as users, groups, passwords, certificates and permissions. With IAM, principles can be defined such as users, groups, services and roles. Policies can then be applied to said principles.
IAM service can be used to implement a least privileged model, this starts as soon as the AWS account is created. When creating a new AWS account an initial account is created known as a root account, this root account has access to all AWS services and resources within that account. Additional users and groups should be configured using root but then the root account should be protected and only used when absolutely required.
The root account will come with access keys, these should be deleted to prevent programmable access to the account at this level and multi-factor authentication (MFA) should be enabled to prevent unauthorised access.
Additional user accounts should then be consumed for day to day operations with only the required permissions assigned to that account. Apply strict password policies and rotate access credentials regularly.
IAM service implements role-based access, roles can be created with a particular set of permissions assigned to it. IAM roles are a secure way to grant permissions to trusted entities. IAM roles can be used to allow trusted access for another AWS account and can be used in conjunction with 3rd part web providers and SAML providers to federate access. Application code running on an EC2 instance can use a role to perform actions on AWS resources as well as services such as AWS Lambda to call other AWS services and have the correct permission to do so.
Least privileged can be enabled by ensuring authenticated identities are provided the minimal set of permissions necessary for operations and for only the required amount of time. Insight can assist when architecting least privileged using IAM as well as other key services such as AWS Security Token Service (STS) and AWS Organisations.
Detective controls can be used to identify potential security threats and can be used for legal or compliance obligations. Inventory assets to create baselines along with internal audits to fully understand the environment and what changes that may occur.
AWS make it easier to manage assets within the environment by enabling the ability to programmatically describe services and applications without depending on agents. Reliable, real time gathering of asset information can be achieved by API calls.
AWS CloudTrail records a detailed history about each API call made in an AWS account, all actions to AWS, whether that is via the console or via CLI or SDK access, use API calls, this provides a great insight into all activity on the account.
Collecting logs centrally becomes a key part of detective controls, logs can be analysed in real time once logs are centralised using services such as AWS CloudWatch Logs or Amazon S3 object based store. Security teams can use the collection of logs and use search tools to discover potential events of interest, such as unauthorised access.
Changes in the environment can traditionally be hard to detect and revert, AWS Config provides an AWS resource inventory, configuration history and change notifications. All resources can be recorded or only specific ones, as well as resource set by tags. Once enabled, changes to resources can be easily detected.
Infrastructure encompasses an Apply security at all layer design principle, it ensures systems and services within the environment are protected against unauthorised access and potential vulnerabilities.
Protect network functions defined within a Amazon VPC, an isolated group of cloud resources. North-south traffic in and out of the VPC and east-west within the VPC can be controlled. Each subnet created within a VPC can be defined as public or private which has a direct implication on how the traffic is routed. Firewall policies can be defined to control traffic in and out of subnets and at an instance level using Security Groups.
Patching is still critical within the application whether the application is running in the cloud or on-premises. AWS Systems Manager Patch Manager can help deploy patches automatically across large groups of instances.
Additional services considered that can help protect infrastructure are AWS Shield, a managed DDoS protection service and AWS WAF, a web application firewall.
Data protection can be a complex, but important, subject to cover. Insight can assist with this subject closer, the following will highlight some of the key considerations.
Classify data types then map control and levels of protection based on the classification, for instance data that is publicly available and required to be accessed by anyone will have a different protection requirement to critical data only required to be accessed by the business. AWS KMS service can leverage tags to define levels of access to resources.
Encrypt data at rest, that is where the data persists such as Amazon EBS for block storage or Amazon S3 for object storage, both of which offer encryption. Consider data archives, services such as Amazon Glacier offers the ability to encrypt data at rest for archives.
Encrypt data in transit, that is data that gets transmitted from one system to another, protect data by using secure protocols that implement TLS. Consider traffic that might traverse AWS services and, if configured, different regions. Different AWS services offer different options around encryption, AWS KMS can be used to manage encryption keys.
Finally, incident response is about preparing for potential security incidents and having processes in place to mitigate the potential impact. Tags can be used to properly describe AWS resources that make up an application to fully evaluate the impact of an incident. Tags can also provide other information such as application owner so during an incident, the correct people or team can be accessed quickly.
AWS CloudFormation can be leveraged to spin up an isolated application using captured images or configuration following an incident, this isolated environment can be automated in deployment and removal providing isolated root cause analysis.
Security is the second pillar within the AWS Well-Architected Framework and with all of the framework, it represents an ongoing effort. By planning the AWS deployment up front and following this methodology, it ensures best practice is followed from the start and not bolted on as an afterthought.
The remaining pillars in the framework will be covered in this blog series.
If you are interested in finding out more, please contact your Insight Account Manager or get in touch via our contact form here.
Why not also read 'Journey to a Successful AWS Deployment – Part 3 Cloud Reliability'?