If you would like to be notified when Ricky & Monique Magalhaes release the next part in this article series please sign up to our InsideAWS.com Real-Time Article Update newsletter.
If you would like to read the first part in this article series please go to AWS, Security Based on a Shared Responsibility Model (Part 1).
Introduction
To ensure security requirements are met and compliance maintained the customer must have a clear understanding of his/her responsibilities and ensure that these are met appropriately. The security outcome and security benchmarks attainable are dependant on parties, both the customer and AWS, playing their part.
Although AWS services is designed to be easy to utilise and the infrastructure designed and run very well (as noted in part one of the series), there are a substantial number of obligations that the customer must understand and shoulder if they are to ensure the environment and services utilised provide security; privacy, reliability and accessibility.
Depending on the service type utilised and also depending on customer data sensitivity and risk acceptance levels, the customer’s responsibilities will change accordingly. AWS managed services also involve a different set of responsibilities.
For security realisation, when responsibility is shared between provider and customer (as it is here), an in-depth knowledge is key.
Amazon Web Services are responsible for securing the underlying global infrastructure and foundation services that support the cloud, and you, the customer, are responsible for everything else you position on top of the cloud or attach to the cloud.
Different services equate to different responsibilities
The customer responsibilities vary from one AWS service to the next, across the broad range of services offered. Some services offer more control than others and thus more responsibility is incurred.
IaaS
Infrastructure-as-a-service services allow the customer more control over the service but also more responsibility is placed on the customer. Types of IaaS AWS services include Amazon EC2 and Amazon S3.
EC2 responsibilities include:
- Patching OS on the instances and software installed on them
- Configuring the firewall for access control of instances
- Setting up VPC subnets
S3 responsibilities include:
- Access control policies
- Encryption for stored data
- Backup and archiving procedures
PaaS
Platform-as-a-service AWS services involve less customer responsibility (Amazon RDS, Redshift, Workspaces), as this falls under the managed services umbrella and AWS shoulder a large section of the responsibilities for these. Many of the responsibilities you encounter with IaaS services you don’t with PaaS.
There are certain security features that you should always configure no matter the service being utilised. It’s in your best interest to secure your credentials, manage access to user accounts and log activity appropriately.
These are only a few examples to show how different AWS services require different customer input nevertheless, display that careful consideration should be given to individual services when determining your security responsibilities.
The customer (YOU)
The customer part of the responsibility is to ensure that the security chain is completed and upheld when they utilise AWS services. You must be responsible for anything you manipulate on the AWS platform, and everything related to utilisation and management of the virtualised servers you create
AWS does not have control over the customer virtual instances, beyond them assuring that they are isolated, and thus the virtual server becomes the responsibility of the customer. All customers’ content (accounts and data) is under complete control of the customer and thus it is in their best interest to ensure it is secured and that ownership of data continuously upheld.
AWS offers a sizeable collection of security tools and controls for the customer to apply and use. There are tools available for every service you choose to employ in AWS but it is the customers responsibility to decide which tools to use or controls to implement and to utilise them and ensure that they are being applied accurately and without fail.
The security measures you chose to implement will depend on the nature of your data and how vulnerable you presume your data to be. The best approach to follow is to treat your virtual server in the same manner you would your on premise server, with the benefit of not having to concern about the physical intricacies (AWS looks after this – its their share of the Responsibility Model).
The customer also needs to carefully consider the following:
- What data they choose to store on AWS
- Under which jurisdiction (in which country) the content is stored
- The format of their data on AWS (is it encrypted) and how to uphold integrity of that data
- How access to their data is controlled and managed
- What should and should not be undertaken to ensure compliance with regulation and laws of the country they reside in
The customer’s responsibilities include:
- Client side data encryption and authentication
- Server side encryption
- Network traffic protection
- OS, Network and firewall configuration
- Platform and application management
- Customer data
- Customer IAM
Security best practices for the customer to consider
The following security best practices are advisable to ensure that your customer security responsibilities are appropriately met and the security chain upheld.
- Managing your account and access
Your route account is imperative as it gives boundless access to your AWS resources. This must be managed effectively to ensure it stays secure. It is advised that use of this account is limited and that groups be created and used to access resources instead.
Groups can be created on per-requirement policy basis and in doing this; levels of access can be controlled and monitored.
Multifactor authentication is also recommended for further attainable security.
- Patch Management
Keeping your systems and software running in your virtual environment patched and updated is essential. Tools are available to help automate the necessary procedures. Customers must ensure that they remain on top of this and ensure that it stays a priority practice.
- Secure data, Encryption
Amazon offers encryption features for server side encryption, thus data can be encrypted before it enters the data centre.
It is recommended that you also encrypt data at rest and in transit to keep it secure when stored and traveling within the network, always ensuring that you are using the best encryption solutions available.
- Managing Encryption keys
Encryption key management is a fundamental component of securing your data. It’s important that your encryption keys remain under your sole control – this means that they should be managed by you and you alone. This is the only way to guarantee that you have sole access to your encrypted data (even when in the cloud) and that you remain compliant. Neither AWS nor other third parties should have access to your encryption keys.
- Access management
Controlling access to your content is important and this could cause potentially devastating impact if not approached securely. By default everything is set to‘private mode’. How you decide to share your data is your prerogative, if you choose to do so, it’s very important you take the right precautionary measures and make sure it is done in a secure manner.
- VPN/Security Gateway from your Site
You can decide to further improve your security by utilising a VPN to relate your virtual instances to your cooperate site.
Conclusion
The AWS shared responsibility model is effective in that jointly the provider and the customer can achieve levels of security that would likely be unachievable if approached alone.
To achieve success with this approach, clear customer awareness of responsibilities is key, along with an in-depth understanding of your unique security and risk posture.
Always consider each service autonomously with regards to how best to secure them and to achieve success through completing the shared responsibility chain of security.
If you would like to be notified when Ricky & Monique Magalhaes release the next part in this article series please sign up to our InsideAWS.com Real-Time Article Update newsletter.
If you would like to read the first part in this article series please go to AWS, Security Based on a Shared Responsibility Model (Part 1).
