When implementing different AWS services and architecting them within your environments, whether it be production, test or dev, do you know your security responsibilities for these services?
It is very likely that you are using services from three different classifications, which each have very different boundaries for enforcing security between the customer and AWS.
These classifications are:
- Infrastructure services
- Container services
- Abstract services
The level of responsibility around these services are defined within three different AWS Shared Responsibility Models, and it’s essential when using AWS you understand your level of responsibility when it comes to applying security.
This course focuses on Container and Abstract services. The primary Container services we look at are: RDS, EMR and Elastic Beanstalk and the primary Abstract services include: S3, DynamoDB, SQS and Glacier.
The lectures within this course will define and guide you through the following areas to help you apply the correct level of security to your Container and Abstract services.
What are AWS Abstract & Container Services?: This lecture provides you with a clear understanding of what abstract and container services are within AWS. There is a clear divide between the two which must be understood as responsibilities around security is a key difference between them
Security Controls: Data at Rest and In Transit: Here we will take a look some of the available options and best practises to help you maintain integrity and protection around your data when at rest, in transit and held within a number of container and abstract services
Security Controls: Network Segmentation: In this lecture we look at how we can use the network infrastructure and architecture to connect and restrict access to our container and abstract services to increase security through a number of different controls
Identity & Access Management: IAM is heavily used for both container and abstract services and plays a key part in authorisation and authentication for access and management, this lecture looks at how IAM can be used to help protect access across your services
Built-in Service Security Controls: This lecture will briefly look at some of the service specific security controls that may not have been covered in the previous lectures that you can leverage to help secure you data and environment
If you have thoughts or suggestions for this course, please contact Cloud Academy at firstname.lastname@example.org.
Hello and welcome to this lecture, where we shall briefly summarize what we have covered.
By now, you should understand that there are clear differences between AWS container services and Abstract services. These two classifications fall under two different shared responsibility models that offer various levels of AWS and customer management roles. It's important to understand which model your service falls under, whether that be infrastructure, container or Abstract, as this dictates how much of a responsibility you have to manage and architect the correct level of security for your environment.
As a general rule, when using container based services you will have more control and operational management of the service then those of Abstract services. You'll also have greater manipulation as to where the container service physically resides, such as within the private or public subnet, enabling you to utilize network security controls. Whereas your Abstract services will be abstracted from this environment and will be accessed over a service endpoint instead, such as S3, SQS, Glacier and DynamoDB.
With these Abstract services, you'll not need to maintain the underlying network architecture, as this is a shared multi-tenancy infrastructure that AWS maintains where they enforce their own network security controls on their own managed AWS network.
Throughout both container and Abstract services, there are multiple ways, depending on the service, to apply security at numerous different levels. For example, ensuring security exists for data at rest, in transit, via access controls, at a network level, for data durability and reliability and many more. Much of this access can be implemented at a deep and granular level depending on the sensitivity required on the data you're using. Some of this may be dictated by security governance and controls that may be required in your environment.
So to reiterate some key points:
- Container services provide you with more control, operational management and security responsibility than that of Abstract services
- Abstract services are managed and maintained by AWS more so than that of any other service classification, container or infrastructure
- Roles and responsibilities for customer differ when implementing security controls between the two classifications
- Understand the services that your are using and ensure that you are implementing its own security features as an additional layer within your security policies
- Whenever necessary and possible implement encryption when data is at rest and in transit
- Use the network security features offered by the VPCs, such as NACLs, Security Groups, Route Tables, NATs, Bastion Hosts, to restrict traffic between your different network segments and to enhance the security around your container services
- Implement a structured and managed IAM process using groups and roles to manage permissions across your AWS infrastructure ensuring access for users is restricted to only what is necessary
If you have any feedback on this course, positive or negative, please do leave a comment on the course landing page. We do look at the comments in our list and your feedback is greatly appreciated.
So that brings us to the end of this lecture and the end of the course. I hope it has given you a better understanding of AWS, Abstract and container services and that you have found it useful. Thank you for your time and good luck with your continued learning of cloud computing. Thank you.
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.
Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.