Encryption and Key Management

Overview

Encryption protects data confidentiality in cloud environments. Proper key management ensures encryption effectiveness.

Learning Objectives

• Implement cloud encryption strategies
• Manage encryption keys securely
• Apply encryption to different service models
• Understand key management options
• Apply ISO 27017 cryptographic controls

ISO 27017 Cryptographic Controls

A.10.1.1 - Policy on Use of Cryptographic Controls

Customer Requirements:

• Define encryption policy
• Specify encryption algorithms
• Define key management approach
• Document encryption usage
• Regular policy review

A.10.1.2 - Key Management

Key Management Requirements:

• Secure key generation
• Secure key storage (HSM preferred)
• Key access control
• Key rotation procedures
• Key backup and recovery
• Key destruction

Encryption Layers

Data Protection Spectrum

┌──────────────────────────────────────┐
│  Application-Level Encryption        │
│  - Full customer control             │
│  - Encrypt before cloud upload       │
│  - Customer-managed keys             │
│  - Highest security                  │
├──────────────────────────────────────┤
│  Client-Side Encryption              │
│  - Encrypt at client                 │
│  - Keys in customer environment      │
│  - Cloud sees encrypted data only    │
├──────────────────────────────────────┤
│  Server-Side Encryption (CMK)        │
│  - Cloud encrypts data               │
│  - Customer-provided keys (BYOK)     │
│  - Customer controls key lifecycle   │
├──────────────────────────────────────┤
│  Server-Side Encryption (PMK)        │
│  - Cloud encrypts data               │
│  - Provider-managed keys             │
│  - Transparent to customer           │
└──────────────────────────────────────┘

Encryption at Rest

Implementation by Service Model

IaaS:

Volume Encryption Options:

1. OS-Level Encryption
   ├─ dm-crypt/LUKS (Linux)
   ├─ BitLocker (Windows)
   ├─ Customer manages keys
   └─ Full control

2. Cloud-Native Encryption
   ├─ AWS EBS Encryption
   ├─ Azure Disk Encryption
   ├─ GCP Persistent Disk Encryption
   └─ Provider or customer-managed keys

3. Application-Level Encryption
   ├─ Encrypt in application code
   ├─ Field-level encryption
   ├─ Transparent to infrastructure
   └─ Maximum control

PaaS:

Database Encryption:

├─ Transparent Data Encryption (TDE)
│  ├─ Database-level encryption
│  ├─ Automatic encryption/decryption
│  └─ Provider or customer-managed keys
│
├─ Column-Level Encryption
│  ├─ Encrypt specific columns
│  ├─ Application-managed
│  └─ Granular control
│
└─ Application-Layer Encryption
   ├─ Encrypt before database write
   ├─ Customer-managed keys
   └─ Full application control

SaaS:

Encryption Configuration:

├─ Provider-Default Encryption
│  ├─ Automatic for all data
│  ├─ Transparent to users
│  └─ Provider-managed keys
│
├─ Customer Lockbox (if available)
│  ├─ Customer approval for provider access
│  ├─ Additional access control
│  └─ Audit trail
│
└─ Client-Side Encryption (advanced)
   ├─ Encrypt before upload
   ├─ Customer-managed keys
   └─ Limited functionality impact

Encryption in Transit

A.13.1.1 - Network Controls

TLS Requirements:

Implementation Example:

# Nginx TLS Configuration
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers on;
ssl_session_timeout 10m;
ssl_session_cache shared:SSL:10m;

# HSTS
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Key Management Strategies

Option 1: Provider-Managed Keys (PMK)

Characteristics:
├─ Easiest to implement
├─ No key management burden
├─ Provider controls key lifecycle
├─ Suitable for non-sensitive data
└─ Compliance limitations

Process:
1. Enable encryption
2. Provider generates keys
3. Provider manages rotation
4. Transparent to customer

Option 2: Customer-Managed Keys (CMK/BYOK)

Characteristics:
├─ Customer controls key lifecycle
├─ Keys stored in cloud KMS
├─ Customer-defined rotation
├─ Suitable for sensitive data
└─ Better compliance support

Process:
1. Create key in cloud KMS
2. Define key policy
3. Configure resource encryption
4. Implement rotation schedule
5. Monitor key usage

AWS KMS Example:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Enable IAM User Permissions",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "Allow use of the key for S3",
      "Effect": "Allow",
      "Principal": {
        "Service": "s3.amazonaws.com"
      },
      "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey"
      ],
      "Resource": "*"
    }
  ]
}

Option 3: Customer-Provided Keys (Hold Your Own Key)

Characteristics:
├─ Keys never leave customer environment
├─ Cloud provider requests decryption
├─ Maximum control
├─ Complex to implement
└─ Potential performance impact

Architecture:
┌──────────────┐      Encrypted    ┌──────────────┐
│ Cloud Service│◄─────────────────│  Customer    │
│              │                   │  Key Server  │
│              │──Request decrypt─►│  (on-prem/   │
│              │◄─Decrypted data──│   dedicated) │
└──────────────┘                   └──────────────┘

Key Rotation

Rotation Strategy

Key Rotation Schedule

┌─────────────────────────────────────┐
│ Symmetric Keys (AES)                │
│ ├─ Automatic: 365 days             │
│ ├─ High-risk data: 90 days         │
│ └─ Compliance-driven: Per regulation│
├─────────────────────────────────────┤
│ Asymmetric Keys (RSA)               │
│ ├─ Certificates: Per validity period│
│ ├─ SSH keys: 180 days              │
│ └─ API keys: 90 days               │
├─────────────────────────────────────┤
│ Master Keys                         │
│ ├─ Annual rotation minimum         │
│ ├─ Emergency rotation as needed    │
│ └─ Maintain old keys for decryption│
└─────────────────────────────────────┘

Automated Rotation Example:

# AWS KMS Key Rotation
import boto3

kms = boto3.client('kms')

# Enable automatic rotation
kms.enable_key_rotation(KeyId='key-id')

# Check rotation status
response = kms.get_key_rotation_status(KeyId='key-id')
print(f"Rotation enabled: {response['KeyRotationEnabled']}")

Envelope Encryption

Multi-Layer Key Architecture

┌───────────────────────────────────────┐
│  Master Key (in HSM)                  │
│  - Long-lived                         │
│  - Rarely used directly               │
│  - Highest protection                 │
└──────────┬────────────────────────────┘
           │ Encrypts
           ▼
┌───────────────────────────────────────┐
│  Data Encryption Keys (DEK)           │
│  - Per-object keys                    │
│  - Encrypted by master key            │
│  - Stored with encrypted data         │
└──────────┬────────────────────────────┘
           │ Encrypts
           ▼
┌───────────────────────────────────────┐
│  Data                                 │
│  - Encrypted with DEK                 │
│  - DEK rotates with each operation    │
└───────────────────────────────────────┘

Benefits:
├─ Master key rarely exposed
├─ Performance optimization
├─ Easy key rotation
└─ Granular access control

Key Takeaways

1. Encryption is essential for data protection
2. Multiple encryption layers provide defense in depth
3. Key management is critical to encryption effectiveness
4. Customer-managed keys provide more control
5. Regular key rotation reduces risk
6. TLS 1.2+ required for data in transit

Self-Assessment

1. What are the three key management options?
2. What is envelope encryption?
3. Why is key rotation important?
4. What TLS version should be used minimum?
5. How does client-side encryption work?