Cloud Security Controls: Encryption, Compliance, and Shared Responsibility

Cloud Security Controls: Encryption, Compliance, and Shared Responsibility

The Shared Responsibility Model

When a company moves workloads to the cloud, security does not move entirely to the cloud provider. Instead, responsibility is divided between the provider and the customer. This division is called the shared responsibility model, and every major cloud provider publishes documentation describing it.

The split depends on which service model is in use:

• IaaS (Infrastructure as a Service): The provider secures the physical data center, networking hardware, hypervisors, and storage hardware. The customer is responsible for the operating system, middleware, applications, data, identity and access management, and network controls such as firewall rules and security groups.
• PaaS (Platform as a Service): The provider adds the operating system and runtime environment to its side of the line. The customer still owns the application code, data, and user access management.
• SaaS (Software as a Service): The provider manages almost everything through the application layer. The customer is responsible for user accounts, access privileges, and the data users put into the system.

A common mistake is assuming the cloud provider handles all security. That assumption has led to real breaches. Misconfigured storage buckets left open to the public internet, weak passwords on cloud accounts, and unencrypted databases are all customer-side failures, regardless of how secure the provider's infrastructure is.

Encryption at Rest

Data at rest means data stored on disk, in a database, or in object storage—data that is not actively moving across a network. Encrypting data at rest protects it if storage media is accessed without authorization.

Cloud providers offer several mechanisms:

• Provider-managed keys (e.g., SSE-S3 on Amazon S3): The provider generates, stores, and rotates encryption keys automatically. This is the easiest option and protects against unauthorized physical access to storage hardware.
• Customer-managed keys (e.g., SSE-KMS): Keys are stored in a key management service but the customer controls rotation schedules and access policies. This gives more auditability.
• Customer-provided keys (SSE-C): The customer supplies the key with each request. The provider never stores the key.

For virtual machines, the operating system disk and data disks can be encrypted at the hypervisor level (transparent disk encryption) or within the OS itself. Both protect data if a disk image is copied or a snapshot is accessed improperly.

Encryption in Transit

Data in transit means data moving over a network—between a user and a cloud service, between services within a cloud, or between a cloud and an on-premises network.

The primary control for data in transit is TLS (Transport Layer Security). Cloud storage services can be configured to require HTTPS, which uses TLS, and to reject plain HTTP requests. This is commonly enforced through a bucket or storage policy that includes a condition denying any request that does not use a secure transport.

For virtual machine traffic that travels inside a cloud virtual network, encryption is not automatic at every layer. Traffic between VMs in the same virtual network may not be encrypted unless the application layer or a VPN tunnel provides it. Customers configuring IaaS environments should consider this when handling sensitive data.

Common Compliance Frameworks

Many industries require organizations to follow specific security standards, and those requirements extend to cloud environments.

• HIPAA (Health Insurance Portability and Accountability Act): Applies to organizations handling protected health information (PHI). Cloud customers storing health data must ensure PHI is encrypted, access is logged, and they have a Business Associate Agreement (BAA) with the cloud provider.
• PCI DSS (Payment Card Industry Data Security Standard): Applies to any organization processing, storing, or transmitting payment card data. Requires encryption of cardholder data at rest and in transit, access controls, and regular vulnerability assessments.
• FedRAMP (Federal Risk and Authorization Management Program): A US government program that standardizes security assessment for cloud services used by federal agencies. Cloud providers offering services to federal customers must achieve FedRAMP authorization.
• SOC 2 (Service Organization Control 2): An auditing framework from the American Institute of CPAs. Cloud providers often obtain SOC 2 reports to demonstrate their controls to enterprise customers.
• GDPR (General Data Protection Regulation): A European Union regulation that affects any organization handling data of EU residents, including US-based cloud customers.

Compliance does not equal security, but frameworks provide a documented baseline that auditors and regulators can verify.

Safety and Professional Practices

Cloud configuration errors can expose sensitive data to the public internet immediately. Treat cloud credentials—API keys, access key IDs, and secret access keys—like passwords: never hard-code them in scripts or commit them to version control. Use identity and access management roles instead of long-lived credentials wherever possible. Apply the principle of least privilege: grant only the permissions a user or service actually needs. Review storage bucket and container permissions before putting any data into them, and enable logging so that access to sensitive resources can be audited.