Learn about Amazon's procedures for securing your data in their facilities.
Key to insuring your organization's security and compliance in the cloud is what AWS calls the Shared Responsibility Model. The way AWS puts it is Shared Responsibility Model means that AWS handles security of the cloud while the AWS customer handles security in the cloud. What this means it that AWS provides assurances about the security and capabilities of their services, and about the physical security of their hardware on which your resources live. Meanwhile you are responsible for understanding how to use these services in an appropriate way to satisfy your obligations.
Let's start with security of the cloud. How can we be assured that AWS is doing all they can and should be doing on their side of the Shared Responsibility Model? This might be a good time to look at some AWS' security protocols. AWS states that their data centers are housed in nondescript buildings. They're secured at both a perimeter and at the facility itself. This security includes video cameras, security personnel, and more. Amazon also states that people wishing to access the data center floor must present multi-factor authentication at least twice.
This ensures that the people entering the facility are guaranteed to be who they say they are. Anyone who gets this far is also accompanied constantly by security staff. Not only that, but AWS background checks on their employees, limits access to only those people with a legitimate business need for such access, and logs every visit to a remote location. All this should give you some assurance that no unauthorized person is going to tamper with the hardware running your EC2 instance, or storing your S3 data. But what about other threats? AWS goes to extreme measures to protect against fire and flood.
They build their own power supplies and back everything up with onsite generators. And of course their data centers themselves are redundant and geographically separated. The multiple facilities that make up an availability zone are close enough to provide minimal latency for load balanced or distributed workloads, but far enough away that a threat to one does not put the other at risk. This is of course why AWS always recommends replicating data and compute across multiple AZs. That's another part of the Shared Responsibility Model. Shared Responsibility extends not only to security, but to redundancy and availability as well.
While some services, like EFS, handle replication for you, other AWS services leave it to you. If you don't architect your applications and data storage to take advantage of the high availability options AWS offers, you may end up putting your business at risk. That's just the tip of the iceberg as far as AWS' security of the cloud. Within the data centers of AWS, you'll find state of the art advanced networking monitoring, world-class intrusion detection, strict change management practices, and regular third-party audits to ensure the solidity of all of the above.
If you're interested in the details, just search of the AWS security white paper and you can read pages upon pages of detailed assurances about the security of AWS. So what about security in the cloud? What's your responsibility? Well, it comes down to understanding your requirements, the capabilities of AWS, and how to properly configure each AWS service to match those requirements. For instance, RDS, the Relational Database Service, provides an option for replicating across availability zones. But you must enable it yourself.
If you don't and the single instance of the RDS database is lost or compromised, AWS will not be able to do anything about it. Similarly, Elastic Block Storage, or EBS, allows your data volumes to persist after a host terminates, and to be snapshotted and backed up at will. However, if you don't enable settings to take advantage of these features, their usefulness will be nil in a disaster scenario. S3 is a perfectly safe place to store data, but AWS will not stop you if you choose to set a security policy that makes it public.
And encryption works the same way. EBS, S3, and now EFS all offer seamless server-side encryption, but you have to opt in. Now in some cases, your responsibilities may go beyond what AWS provides. When that happens, you'll need to take additional steps. For instance, if you must meet stricter encryption standards than what is satisfied by the available AWS options, you'll need to perform your own encryption prior to sending data to the cloud. As long as you do this, just like you would on premises, you'll be able to meet your requirements and still enjoy the benefits of AWS storage and compute.
Join AWS architect Brandon Rich and learn how to configure object storage solutions and lifecycle management in Simple Storage Service (S3), a web service offered by AWS, and migrate, back up, and replicate relational data in RDS. Find out how to leverage flexible network storage with Elastic File System (EFS), and use the new AWS Glue service to move and transform data. Plus, learn how Snowball can help you transfer truckloads of data in and out of the cloud.
- What is data management?
- AWS S3 basics
- S3 bucket creation
- S3 upload and logging
- S3 event notifications
- S3 data lifecycle configuration
- Working with Amazon Elastic Block Store volumes
- Creating and mounting an EFS
- Creating an AWS RDS instance
- RDS backup and recovery
- Moving data with AWS Database Migration Service
- Moving data with Data Pipeline and Glue