Security Principles

Security Principles

Well-Architected Framework

Key Security Principles

Three important principles for securing AWS architectures:

• AWS Shared Responsibility Model: Consider this model when determining how to apply security to cloud architectures
• Security Pillar of Well-Architected Framework: Use this to identify design principles that apply to your architectures
• Principle of Least Privilege: Always apply this when securing AWS resources

AWS Shared Responsibility Model

Note

Customer Responsibility: Security IN the cloud AWS Responsibility: Security OF the cloud

Customer Responsibilities (Security IN the Cloud)

• Customer data
• Platform, applications, identity and access management
• Operating system, network and firewall configurations
• Client-side data encryption and data integrity, authentication
• Server-side encryption (file system and/or data)
• Networking traffic protection (encryption, integrity, identity)

AWS Responsibilities (Security OF the Cloud)

• AWS foundation services
  • Compute
  • Storage
  • Database
  • Networking
• AWS Global Infrastructure
  • Regions
  • Availability Zones
  • Edge locations

“Security and compliance are shared responsibilities between AWS and our customers. AWS operates, manages, and controls security of the cloud.” Customer responsibilities include “selecting and securing operating systems that run on Amazon Elastic Compute Cloud (Amazon EC2) instances, and securing the applications that are launched on AWS resources.”

Security as a Well-Architected Framework Pillar

Security is one of the six pillars of the Well-Architected Framework. The other pillars are:

• Operational excellence
• Reliability
• Performance efficiency
• Cost optimization
• Sustainability

The framework provides best practices and design guidance across each pillar to help make choices and review existing architectures. You can use the AWS Well-Architected Tool to implement best practices and access current AWS best practices on-demand.

Design Principles for the Security Pillar

Strong Identity Foundation

Implement the principle of least privilege and enforce separation of duties with appropriate authorization for each interaction with AWS resources. Centralize identity management, and aim to eliminate reliance on long-term, static credentials.

Data Protection

Protect data in transit and at rest. Classify your data into sensitivity levels, and use mechanisms, such as encryption, tokenization, and access control, where appropriate.

Defense in Depth

Apply security at all layers. Apply a defense-in-depth approach with multiple security controls to all layers (edge of network, VPC, load balancing, every instance and compute service, operating system, application, and code).

Additional Design Principles

• Keep people away from data: Use mechanisms and tools to reduce or eliminate the need for direct access or manual processing of data
• Maintain traceability: Monitor, alert, and audit actions and changes to your environment in real time
• Prepare for security events: Have incident management and investigation policies and processes that align to organizational requirements
• Automate security best practices: Create secure architectures with controls defined and managed as code in version-controlled templates

User Permissions and Access Control

Implementing a strong identity foundation involves using policies to grant or deny access to AWS resources. For example:

• John can read, write, and delete objects in S3 bucket 1
• John can only read objects in S3 bucket 2
• John is explicitly denied access to a specific Amazon DynamoDB table

Principle of Least Privilege

Tip

Best Practices for Least Privilege

• Grant only the permissions that are required to perform a task
• Start with a minimum set of permissions
• Grant additional permissions as necessary
• Revoke unnecessary permissions

“This means granting only the permissions that are needed to perform a task. It’s more secure to start with a minimum set of permissions and grant additional permissions as needed.”

When creating access policies:

• Determine what users need to do
• Craft policies that allow them to perform only those tasks
• Create policies for individual resources that identify precisely who is allowed to access the resource
• Allow only the minimal permissions for those users

Data Protection Through Encryption

Protecting Data in Transit

“Data in transit is data that is actively moving from one location to another, such as across the internet or through a private network.” Use cryptographic protocols like TLS to protect data while it’s traveling between networks or being transferred from local storage to cloud storage.

Example: Encrypting pictures as they are uploaded to a cloud service using TLS to ensure privacy of the transfer.

Protecting Data at Rest

Client-Side Encryption

“Client-side encryption provides end-to-end protection for your object, in transit and at rest, from its source to storage.” The client encrypts data before sending it and retrieves encrypted data to decrypt for use.

Example: Encrypting data on a mobile device to ensure data is scrambled and isn’t accessible to unintended users if the device is lost or stolen.

Server-Side Encryption

“With server-side encryption, data is encrypted before it’s stored.” The server encrypts data when storing it and decrypts data when requested.

Example: Amazon S3 provides server-side encryption, encrypting data at the object level as it writes to disks in AWS data centers.

This section established the fundamental security principles for AWS cloud architectures, emphasizing the shared responsibility model, Well-Architected Framework security pillar, and the critical importance of implementing least privilege access controls with proper data encryption strategies.