This course is focused on the details you need to know for the 20% of the Solutions Architect – Associate for AWS exam that covers data security. You will learn to recognize and explain platform compliance for AWS, and be able to both recognize and implement secure procedures for optimum cloud deployment and maintenance, including understanding the shared responsibility security model, and knowing what that looks like in practice.
- Recognize and explain the AWS shared security responsibility model
- Recognise and implement IAM users, policies and roles
- Recognize and explain how AWS enables you to protect data and rest and in transit
This course is for anyone preparing for the Solutions Architect–Associate for AWS certification exam. We assume you have some existing knowledge and familiarity with AWS, and are specifically looking to get ready to take the certification exam.
Basic knowledge of core AWS functionality. If you haven't already completed it, we recommend our Fundamentals of AWS Learning Path.
This Course Includes:
- 7 Video Lectures
- Everything you need to know about data security to prepare for the Solutions Architect–Associate for AWS certification exam
What You'll Learn
|Lecture||What you'll learn|
|Shared Responsibility Model||What's managed by AWS vs. customers|
|Identity and Access Management||How to use IAM to keep your data secure|
|Platform Compliance||Best practices for platform compliance|
|Data at Rest and in Transit||How to secure your data at rest and in transit|
|Identity Federation||Web identity federation|
|CloudFront Security||How to secure Amazon CloudFront|
If you have thoughts or suggestions for this course, please contact Cloud Academy at firstname.lastname@example.org.
Having a information security management system is an important part of maintaining a secure environment. An ISMS strategy will include a threat model, risk management use cases, and having clearly defined criteria is an important part of an ISMS strategy. Now AWS provides tools to help organizations define an information security management system. The well architected framework and the AWS security center provide templates for defining an ISMS. Platform compliance, data encryption at rest and in transit, and the auditing tools such as Amazon CloudWatch, Amazon CloudTrail, and AWS Config enable really detail hit detective controls.
AWS Cloudwatch is the cornerstone monitoring tool for AWS. Data is captured in five minute intervals for basic monitoring and one minute intervals where detailed monitoring is enabled. Cloudwatch is very useful if, say both, the dev and security teams need a common way to monitor and be a alerted to changes in the environment. You can include third party data as a custom metric. All integrate third party tools and services.
With Amazon CloudTrail, you have a web service that logs API calls and in those logs we're including the identity of the call, the time of the call, the source IP address, the parameters and the response elements. So it's a really good way of being able to order what's been coming and going from your environment. A very good detective tool.
AWS Config is an inventory and configuration history service that provides information about the configurations and more importantly the changes to the configurations in your infrastructure over time.
Okay, let's talk about tools and services we have in IWMS to help us and if we just look at some examples of inline threat protection technologies, generally we're talking about third party firewall devices that we can install on Amazon EC2 instances, we're talking about unified threat management gateways, we can think of intrusion prevention systems, data loss management gateways, anomaly detection gateways, and advance persistent threat detection gateways. Now all of these are appliances that we can add on top of network access controllers we have on our perimeter or our summits and our security groups that we have on our resources.
If we just look at some of the techniques and how those can be used to help us with this additional layer of protection. With firewalls like security groups, network access controllers. We're looking to manage the list of allowed destination servers and services and we can limit the IP addresses and restrict TCP and UDP ports. We're ideally looking to manage the list of allowed sources of traffic so were traffic is coming from, we want to limit that as much as possible and certainly to manage the list of allowed protocols. With WAFS, we're looking at limiting the platform and applications specific attacks and certainly looking to limit unauthorized user access. With host based or inline IDS IPS systems, that's one way of removing trojans and network attacks. For traffic shaping and rate limiting, your often DDoS attacks deplete network and system resources so right limiting is a good technique for protecting scarce resources from over consumption and common things we want to trap is ICMP flooding, an application request flooding, where we can detect considerable deviations from the normal traffic we're seeing and stopping any TCP sent flooding into us.
Alright, so inside this model, the most important thing with security is that we do test it out to ensure that, you know, it's working in a way that we want and every information security management system needs to ensure this regular of use of the effectiveness of our security controls in their policies. That's the only real way we can guarantee that the efficiency of the controls against new threats and vulnerabilities will work. Customers do need to ensure that their infrastructure is protected against attacks.
Going back to our shared security responsibility model a lot of the controls that need to be put in place are the responsibility of the customer. So, verifying our existing controls does require regular testing and it's best practice for ISWS customers to undertake a number of test approaches.
One is external vulnerability assessments, and that's where a third party evaluates system vulnerabilities with little or no knowledge of the infrastructure in its components. So, really looking to try and break in. We have external penetration tests and that's where a third with little or no knowledge of a system actively tries to break into it in a controlled fashion.
With our internal gray white box review of applications and platforms, a tester who has some or full knowledge of the system validates the efficiencies of controls in place or ideally evaluates applications in platforms for known vulnerabilities.
Those three controls that need to be run within the confines of the AWS acceptable use policy and that acceptable use policy outlines permitted and prohibited behavior in the AWS cloud and it certainly defines security violations and network abuse. So AWS supports both inbound and outbound penetration testing in the cloud, although you must request permission to conduct a penetration test.
About the Author
Head of Content
Andrew is an AWS certified professional who is passionate about helping others learn how to use and gain benefit from AWS technologies. Andrew has worked for AWS and for AWS technology partners Ooyala and Adobe. His favorite Amazon leadership principle is "Customer Obsession" as everything AWS starts with the customer. Passions around work are cycling and surfing, and having a laugh about the lessons learnt trying to launch two daughters and a few start ups.