In this video, Jeff Winesett introduces the shared security model employed by AWS. Understanding the differences between the security responsibilities shared between the customer and the cloud provider is important to eliminate cloud security risks/
- [Instructor] When it comes to entrusting a Cloud service provider with hosting and storing business data, security is at the forefront of that consideration. Not fully understanding the differences between the security responsibilities of the Cloud provider versus those placed on the Cloud customer can result in unnecessary security risks of Cloud-based systems. Cloud architects must familiarize themselves with Cloud security practices, as well as be aware of exactly how the security responsibilities are shared between the Cloud provider and the Cloud customer.
When Cloud-based services first became available several years ago, they got a rather undeserved reputation for lacking security. Many of the perceived security issues with the Cloud stemmed from a lack of understanding that the customer is still responsible for a lot of the security implementation. The responsibility of security is shared between the Cloud provider and the Cloud customer. In general, the Cloud provider is responsible for the physical security of the buildings, the infrastructure, the equipment, and keeping different customers secure from each other.
On the other hand, the Cloud customer has to provide security at the network and at the application level, especially as it pertains to the application data. Data in motion needs to be protected as well. For example, when transmitting confidential information on the internet, a secure communication protocol, such as HTTP over SSL, should be used. A nice feature of Amazon's elastic load balancer service is that security certificates can be managed directly on the load balancer.
This makes taking advantage of HTTPS even easier across a distributed fleet of web servers. Data must also be protected when it rests. AWS provides options to encrypt data before storing on Cloud storage devices. Entire file systems can also be encrypted on AWS. File system storage comes in two general varieties, elastic block storage, which persists beyond the lifetime of the underlying instance, and local storage, which will not survive termination of the instance on which it resides.
Both elastic block storage and local storage can be encrypted. AWS provides other storage options allowing encrypted data as well. Another security practice that can often be overlooked is protecting and managing account excess credentials. Almost all AWS services have an available API. To use the APIs, security credentials called access keys are needed. The AWS access key has two parts to it, a public access key ID and a secret access key.
When using the API, the secret key is used in the request for authentication. Therefore, all API requests sent from the public internet should be sent over HTTPS. Rather than storing the secret key as part of an application code bundle, the application should be configured such that this value could be passed in as input during the launch of the application. Encrypting this information before sending should also be considered. Another approach would be to make use of roles within the identity and access management service.
Instances can be launched in an IAM role, and as such, the instance will have access to the credentials and permissions associated with that role. If a secret access key becomes compromised, a new access key should be created. It's recommended to rotate keys often to ensure an unknown or undetected compromised key will not live forever. IAMs should also be used to manage access control. IAM is the service used in AWS to create users and manage their permissions.
Rather than handing out root account information to everyone that needs access, it is recommended to create separate users for each person needing access and only providing the access to the services explicitly needed. Securing the business application itself is also the responsibility of the Cloud customer. AWS provides security groups which act as firewalls to AWS resources. Resources must be locked down and restricted only to the specific users, applications, and other resources that really require access.
Also, all application code installed by the customer must be updated and patched by the customer as well. Basically, all of the pre-Cloud application security practices still apply in the Cloud. This was just a brief security overview. I'll be taking a deeper dive into the tools AWS provides to help secure Cloud-based systems later in the course.
- Benefits of cloud services
- Making architectures scalable
- Examining cloud constraints
- Virtual servers, EC2, and Elastic IP
- Using the Amazon machine image
- Elastic load balancing
- Using CloudWatch for monitoring
- Security Models
- Elastic block storage
- S3, CloudFront, and Elastic Beanstalk
- Handling queues, workflows, and notifications
- Caching options and services
- Identity and access management
- Creating a custom server image
- Application deployment strategies
- Serverless architectures