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 email@example.com.
AWS provides a number of ways to protect your data at rest. Let's keep in mind that setting up data at rest is generally the responsibility of us the customer, so we need to select the method and to actually implement it. That isn't something that's done automatically for us by AWS.
AWS provides three options for encrypting data at rest. And these options are quite different and allow you to choose the approach that works best for you and your organization. The first option is you control the encryption method and the entire key management infrastructure. So you basically do all of the encryption yourself. The second option is you control the encryption method and AWS provides the storage component of the key management infrastructure while you continue to provide the management layer of that key management infrastructure. And the third option is that AWS controls the encryption method and the entire key management infrastructure. So AWS does it all for you, basically.
Let's just delve into a couple of these options, the most common ones. The second option where AWS stores keys using CloudHSM. This model is quite similar to Model A, where you do it all yourself, in that you manage the encryption method, but it differs in that the keys are stored in an AWS CloudHSM appliance rather than in a key storage system you manage on premise. So while the keys are stored in the AWS environment, they are inaccessible to any employee at AWS. So when determining if using AWS CloudHSM is appropriate for your deployment, it's important to understand the role that CloudHSM plays in encrypting data. So an HSM can be used to generate and store key material, and it can perform encryption and decryption operations, but it does not perform any key life cycle management functions. So it doesn't look after axis control policies, and it doesn't look after key rotation. So this means you may also need a compatible KMI in addition to the AWS CloudHSM appliance before deploying your encryption solution. The KMI you provide can be deployed either on premise or within Amazon EC2, and that can communicate with the AWS CloudHSM instance securely over SSL to help protect data and the encryption keys. Because the AWS CloudHSM service uses SafeNet Luna appliances, any key management server that supports the SafeNet Luna platform can also be used with AWS CloudHSM. So you might use that solution when you need to put an extra layer of key management and axis control in as well as using Amazon CloudHSM.
The third option is where AWS controls the encryption method and the entire key management infrastructure. So in this model, AWS provides server side encryption of your data, transparently managing the encryption method and also the keys. Now to do that, they use envelope encryption. How that works is first, a data key is generated by the AWS service at the time you request your data to be encrypted. Second, data key is used to encrypt your data. And then third, that data key is then encrypted with a key encrypting key that is unique to the service storing your data. And then fourth, the encrypted data key and the encrypted data are being stored by the AWS storage service on your behalf.
Let's look at the encryption options per AWS storage type. Amazon EBS encryption provides an encryption solution for your EBS volumes without the need for you to build, maintain and secure your own key management infrastructure. When you create an encrypted EBS volume and attach it to a supported instance type, you can encrypt data inside the volume and all snapshots created from that volume. Also noting here, all traffic in transit between the volume and the instance is encrypted using SSL. That encryption occurs on the service that hosts EC2 instances, providing encryption of data in transit from EC2 instances to EBS storage.
Anyway, back to data at rest. Amazon EBS encryption uses AWS key management service or KMS and custom master keys, or CMK. Encryption is supported with all EBS volume types, which is good to remember. And you can expect the same IOPS performance on encrypted volumes as you would with unencrypted volumes. You can access encrypted volumes the same way that you access existing volumes, and encryption and decryption is handled transparently. You can also leverage most standard file system level or block level encryption tools. An important point to remember with both block level and file system level encryption tools is that they can only be used to encrypt data volumes that are not Amazon EBS boot volumes. This is because these tools don't allow you to automatically make a trusted key available to the boot volume at startup. Encrypting Amazon EBS volumes attached to Windows instances can be done using BitLocker or encrypted file system, or EFS as well as open source applications like TrueCrypt.
For Amazon S3, server side encryption uses 256 bit advanced encryption standard, or AES, keys for both object and master keys. Each object is encrypted with a unique key.
For Amazon Glacier, data is always automatically encrypted before it's written to disk, using 256 bit AES keys unique to the Amazon Glacier service, and they're securely stored in separate systems under AWS's control.
For Redshift, when creating an Amazon Redshift cluster, you can optionally choose to encrypt all data in user created tables.
For Microsoft SQL Server, you can provision transparent data encryption. The SQL Server encryption module creates data in key-encrypting keys to encrypt the database.
For running Oracle on RDS, you can enable the Oracle advanced security option for Oracle, to leverage the native transparent data encryption and native network encryption features.
You can encrypt transport between your instances and databases using SSL connections. HTTPS uses the SSL TLS protocol. For MySQL and SQL Server, RDS creates an SSL certificate and installs the certificate on the DB instance when the instance is provisioned. Once an encrypted connection is established, data transferred between the DB instance and your application will be encrypted during transfer. You can also require your DB instance to only accept encrypted connections. The AWS Storage Gateway securely transfers your data to AWS over SSL.
Okay, so how about inbound connections from the public domain? You can also protect data in transit originating from outside connections using SSL connections. All AWS services provide secure customer access points, also called API endpoints, that allow you to establish secure HTTPS communications sessions. So all AWS services support SSL.
Amazon Elastic Load Balancers can terminate or pass through HTTPS or SSL. An Elastic Load Balancer Listener is a process that checks for connection requests. It is configured with a protocol and port for front end, which is client to load balancer, and a protocol and port for backend, which is load balancer to backend connections. If you use HTTPS or SSL for your front end listener, you must deploy an SSL TLS certificate on your load balancer. The load balancer uses the certificate to terminate the connection and then decrypt requests from clients before sending them to the backend instances.
The SSL protocol uses an X509 Certificate. The X509 Certificate is issued by a certification authority, or CA, and it contains identification information. You can create a certificate using AWS Certificate Manager or a tool that supports the SSL and TLS protocols, such as OpenSSL. You need to specify the certificate when you create or update an HTTPS listener for your load balancer. You can select the cipher key of your choice, and AWS provides support for most common ciphers. The best option is to use the latest pre-defined security policy.
About the Author
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.