Security 101
Following on from the foundational architecture post I thought I'd give a dive into security of the AWS cloud. For me this is the most important element to understand before even creating an AWS account as if you get this wrong it can be costly in more ways than one. There are a few items that need to be looked at when considering security. These include, but are not limited to:
- Shared Responsibility Model
- Identity and Access Management (IAM)
- Data Protection
- Governance and Compliance
Shared Responsibility Model
The shared security model is AWS' split of security responsibilities. While some of the lines have become slightly blurred with the newer services, it is a good way to understand what you are and are not responsible for.
As AWS puts it, in simplistic terms, you are responsible for security 'in the cloud' whilst they are responsible for security 'of the cloud'. This is often one of the drivers for moving to the cloud as management of infrastructure and facilities are part of the service offering. However this mean that you also lose control over the management of these. To combat this AWS certifies it's processes and standards against industry standards such as Sarbanes–Oxley and ISO 27001. All reports and certifications can be found in AWS Artifact.
Identity and Access Management (IAM)
IAM is the foundation of security in AWS. It determines who or what can perform actions on difference services and resources. While it can seem overly complicated to begin with it offers more flexibility and customization than a traditional security model.
As well as role-based access management (RBAC) AWS IAM also has the capability to apply attribute-based access control (ABAC). This is an authorization strategy that defines permissions based on attributes such as resource tag or source IP. This allows to apply further control to secure and manage the environment.
Data Protection
For me there are 3 elements to data protection. The first is covered under access management, and that is only allowing the right people to access the data they need, when they need it, and how they need it. My view is keep all users away from the data. While this can not always be achieved if it is the starting point it will ensure robust controls.
Second is about securing data that is being moved and how it is moved. Primarily this is about encryption for data in transit but it is also about ensuring data is only moved when and where it needs to go. Examples of this would be to restrict a S3 bucket to only be accessible via https and a VPC endpoint.
Finally data protection is about securing data being stored. This not only includes encryption at rest but also around ensuring data assurance and recovery. This could mean activating versioning on S3, snapshots for EBS or meta data and tags.
Governance and Compliance
How you manage security and report on compliance is just as critical as the security you implement. Often the hardest thing is proving solutions meet company, industry and country requirements.
Luckily AWS have a service for that, AWS Config. This allows accounts to report their compliance against a set of rules and standards. Whilst you can define your own rules there are also pre-defined conformation packs that can be deployed. Depending on the industry you might want to deploy PCI-DSS or HIPPA rules. If in a particular geography or serving a particular market you might have to comply with NCSC or FedRamp.
If you are unsure I would suggest to take a look at CIS Benchmarking as an over-view and also the category specific compliance packs based on pest practices.
For more details of security I would recommend taking a look at the Introduction to AWS Security whitepaper as well as the AWS Architecture Center which has a lot of resources on all aspects of security.
