Security is one of the most important requirements for the smooth and efficient functioning of organizations, but many think cloud adoption is risky due to some long-standing confusion around cloud security. Organizations are often unclear about who is responsible for the security of data in the cloud. Is the service provider responsible for taking steps to safeguard the data? Or, does that responsibility fall to the organization's IT security teams?
To answer these questions, Amazon Web Services (AWS), one of the leading cloud providers, issued its Shared Responsibility Model to establish that implementation of security on the AWS cloud is not the sole responsibility of any one participant, but is shared between them and their customers. This webpage aims to break down the concepts in the AWS Shared Responsibility Model.
Responsibility of AWS vs responsibility of AWS cloud customers
While AWS claims full responsibility for the security "of" the cloud, it urges its customers to take care of the security "in" the cloud, and holds customers responsible for data security. In simple terms, imagine the AWS cloud as your office. Your proprietary security (i.e., Amazon) protects the building, mail boxes, parking, etc., and ensures that only authorized personnel enter the building. However, they do not take responsibility for letters in your mail box, or the audio system in your car, etc. The following image outlines the distribution of each participant's responsibilities in terms of cloud security.
Shared responsibility model: AWS' responsibility and the customer's responsibility.
Amazon's responsibilities
Security "of" the cloud entails protecting the infrastructure for all the services that run on the AWS cloud.
AWS hardware (global infrastructure):
The hardware platform includes regions, edge locations, and availability zones of the AWS cloud infrastructure. The security of this is achieved through constant IT maintenance and physical security protection, i.e., Amazon controls access to its data centres where the customer data resides. Providing strong physical security, AWS ensures that no one tampers with the hardware storage and, therefore, promises reduced downtime.
AWS software:
AWS helps in computation and storage by providing databases and other software needed for effective functioning of a network. AWS secures these software with the help of encryption keys, network monitoring tools, by implementing database protection principles, and more. AWS takes full responsibility for the security of the software platform across all of its services. This concept is also referred to as AWS Security Services. In addition to this, AWS is responsible for the security configuration of managed services such as Amazon DynamoDB, Amazon RDS, and Amazon Redshift. While these services provide the scalability and flexibility of cloud-based resources, they also provide an additional benefit of being able to be managed. Customers will just have to configure logical access controls and protect their account credentials for most of the managed services.
The customer's responsibilities
Security "in" the cloud encompasses the protection of customer data, platforms, applications, identity and access management (IAM), as well as network and firewall configuration. The amount of configuration work the customer needs to perform depends solely on the AWS cloud service that customers choose to use. If a customer chooses any of Amazon's Infrastructure as a Service (IaaS), for example Amazon Elastic Cloud Compute, Amazon Virtual Private Cloud (VPC), and AWS Simple Storage Service, the customer has to perform all the necessary security and management tasks. (See how to use Amazon VPC to add extra layers of security to your AWS cloud here). These tasks include:
Customer data protection
This includes securing data on the network side as it enters and exits the cloud service.
Client and server side data encryption
Amazon renders the customers responsible for the client and server side data encryption that uses the AWS managed encryption key, or a private key of their choice. Log360 Cloud employs the AES-256 algorithm for encryption at the application layer. This symmetric encryption algorithm uses 128-bit blocks and 256-bit keys. It utilizes the Data Encryption Key to transform data from plaintext to ciphertext, which is further safeguarded using the Key Encryption Key - offering another level of security. These keys are generated and managed by our in-house Key Management Service.
Network traffic protection
Customers are responsible for data going in and out of the server at all times. A SIEM solution that can track activities in cloud environments including AWS can help monitor traffic. It can also track activities of users, providing greater visibility into possible threats. The image below is the AWS dashboard from Log360 Cloud. It gives you an overview of all the security and network events that has occured in your AWS environment.
Monitor AWS activities from Log360 cloud dashboard.
Platforms, applications, and IAM
Customers are responsible for the protection and maintenance of the platform running in the cloud. They can use IAM tools to implement proper access control systems for data and resource. A SIEM solution like Log360 can leverage IAM reports to provide comprehensive insights into IAM users, roles, MFA devices, password changes, or unauthorized activities, and other IAM activities. These reports also delve deeper and provide information about the user responsible for an event, their source IP address, the AWS region in which the event took place, and other parameters.
File system encryption
File system encryption is also the responsibility of customers. You can utilize the file system protection provided by AWS, or an independent protection system to encrypt file systems. In Log360 Cloud, two types of data are encrypted using the AES-256 algorithm. These are:
- All the data in transit from service to agent is end-to-end encrypted. Further, the device data, network details, and domain details sent from agent to service is also end-to-end encrypted.
- Sensitive data, such as integration tokens, secret access tokens, and user authentication credentials are encrypted to maintain confidentiality and integrity.
As mentioned before, Log360 Cloud uses the AES-256 algorithm at the application layer. But apart from that, it also offers a full disk encryption in its data centres.
Shared responsibilities
Though AWS delivers the required infrastructure, customers have to provide their own control implementation for use within the service. Here are some of the shared controls implemented in the Shared Responsibility Model.
Patch management
AWS claims responsibility for patching and repairing damages to the infrastructure, but customers are held responsible for patching the guest operating system (guest OS), and applications.
Awareness and training
AWS trains employees in the use of its systems, but customers are responsible for the training and continued education of their own employees.
Configuration management
Similar to patch management, AWS takes responsibility for configuring devices within its infrastructure, but does not retain accountability for configuring the guest OS, databases, and applications. Customers must take sole responsibility for configuring those.
Through the Shared Responsibility Model, AWS delegates specific responsibilities to the customer, and to the AWS provider. This comes in handy when organizations want to ensure the smooth and secure functioning of their resources in the cloud.
Are you an AWS user? Do you monitor the logs generated in your AWS environment? Monitoring these logs can help you with performance optimization, resource utilization, and threat mitigation. But considering it is big data that we are talking about, manual work is out of the question. An effective approach involves adopting a robust AWS cloud monitoring solution capable of handling large volumes of event log data. ManageEngine Log360 centrally collects, analyzes, correlates, and archives log data from the AWS environment and that includes your AWS CloudTrail logs, Amazon S3 server logs, and AWS ELB. To learn more, read here.
