AWS Applying Encryption in Cloud Services - cloud computing security - summary CH7

Applying Encryption in Cloud Services

• Encryption is a widely used security measure for ensuring data confidentiality.
• Cloud services often provide built-in support for encryption, simplifying key management compared to on-premises environments.
• Understanding the workings and implementation of encryption in various cloud services is crucial.
• Failure to encrypt sensitive data (e.g., credit card information, healthcare data, PII) poses risks of data exposure and potential legal consequences.
• Cloud encryption addresses concerns related to multi-tenancy (encryption at rest) and public APIs (encryption in transit).

Introduction to encryption

• Payment Card Industry Data Security Standard (PCI DSS) → a standard for storing and processing credit card information - requires the encryption of credit card information both in transit and at rest.
• A common three-tier architecture is illustrated
1. front web servers (behind a load balancer for high availability)
2. an application server (for business logic processing)
3. backend database (for storing purchase information).
• Web servers (Apache, Nginx) handle user requests, while load balancers distribute traffic among multiple servers to enhance performance and prevent overloads.
• SSL (Secure Sockets Layer) is a security protocol that encrypts data transmitted between a user's browser and a website's server. The use of SSL is denoted by "https://" in URLs, signifying a secure connection.
• To protect credit card information, we need to do the following:
1. Configure the SSL certificate on the load balancer → (for encryption in transit).
2. Configure the SSL certificate on the web servers → (for encryption in transit).
3. Configure the SSL certificate between the web servers and the application server → (for encryption in transit).
4. If the application server stores credit card information (even for a short period) in its local hard drive → we must configure full disk encryption (for encryption at rest).
5. Configure full database encryption on the backend database (for encryption at rest).
6. To make sure all the encryption keys are stored securely, we need to store them in a secured location (KMS).
• terminology we need to understand:
1. Plaintext: Original human-readable information.
2. Ciphertext: Non-human readable information resulting from encrypting plaintext.
3. Encryption: Process of converting plaintext into ciphertext.
4. Decryption: Process of converting ciphertext back into its original plaintext form.
5. Encryption Key: String used with an encryption algorithm to encode or decode ciphertext.
6. Encryption Algorithm: Mathematical algorithm in cryptography, combined with a key, for encrypting or decrypting a message.
• encoding → The process of converting information or data into a particular format.
• decoding → The process of converting encoded or encrypted data back into its original format.
• the encryption key is the specific parameter that guides the encryption and decryption processes, while the encryption algorithm is the set of rules or mathematical method that dictates how the transformation occurs. Encoding and decoding, in the context of encryption, refer to the processes of transforming data between its original and encrypted forms.

Symmetric encryption

• Symmetric encryption involves using a single key for both encryption and decryption.
• Common applications of symmetric encryption include :
• encrypting data at rest (PII, credit card info, healthcare data)
• validating message senders → who they claim to be
• generating random numbers in cryptography process

• Pros of Symmetric Encryption:
• Small ciphertext size
• Suitable for transferring large amounts of data
• Low CPU resources required
• Small encryption key size
• Faster encryption time compared to asymmetric encryption
• Cons of Symmetric Encryption:
• Considered less secure than asymmetric encryption as both parties use the same encryption key
• Considered less confidential than asymmetric encryption due to the shared encryption key

Advanced Encryption Standard (AES)

• AES for Encryption at Rest:
• Considered the de facto standard.
• Used in on-premises and public cloud environments.
• encryption at rest.
• AES Development:
• Developed by NIST in 2001.
• AES Key Sizes:
• Supports variable key sizes.
• Most commonly used key size is 256-bit.

Asymmetric encryption

• Asymmetric Encryption Basics:
• Involves two different keys: private and public.
• Keys are mathematically linked.
• Public and Private Keys:
• Public key: Shared openly for encrypting messages.
• Private key: Safely guarded, used for decrypting and signing messages for integrity → the message was no tampered with in the process
• Common Uses of Asymmetric Encryption:
• Creating digital signatures.
• Distributing session keys, as seen in use cases like the TLS protocol.

• Pros of Asymmetric Encryption:
• Large ciphertext size compared to symmetric encryption.
• Large encryption key size (RSA 2,048-bit or higher).
• Considered much safer than symmetric encryption due → to the involvement of two keys, you cannot reveal the private key from the public key
• Considered more confidential than symmetric encryption → to the involvement of two keys, as the private key is required for decryption.
• Cons of Symmetric Encryption:
• Suitable for transferring small amounts of data.
• High CPU resources required.
• Slow encryption time compared to asymmetric encryption.

Rivest Shamir Adleman (RSA)

• RSA Protocol Overview:
• Widely used for encryption in transit, key establishment, and digital signatures.
• Relies on factoring two large prime numbers, known as the factoring problem.
• RSA Key Recommendations:
• Recommended key size starts at 2,048-bit or higher.

Elliptical Curve Cryptography (ECC)

• ECC Usage:
• Mainly employed for key agreements, digital signatures, and pseudo-random generators.
• ECC Characteristics:
• Small key size compared to the RSA algorithm.
• Based on the algebraic structure of elliptic curves over finite fields.
• Recommended ECC Key Sizes:
• 256-bit for NSA secret message classifications.
• 384-bit for NSA top-secret message classifications.

AWS Key Management Service (KMS)

• AWS KMS → is Amazon's key management service.
• Allows generation and storage of cryptographic keys in FIPS 140-2 standard.
• Generates AES256 symmetric encryption keys for encryption at rest.
• Generates RSA 2,048-bit (up to 4,096-bit) and ECC 256-bit (up to 512-bit) for encryption, digital signing, and signature verification.
• Common services using AWS KMS:
• Amazon S3 (object storage): Protects against unauthorized access.
• Amazon EBS (block storage): Protects against unauthorized access to block storage or snapshots.
• Amazon RDS (managed relational database): Protects against unauthorized access to managed databases.

Best practices for deploying KMSes

• KMS → a secured location (or a vault) for generating, storing, and retrieving encryption keys
• The following are some important concepts in the key management field:
1. Key Encryption Key (KEK):
• Used for generating other encryption keys.
• Stored inside the KMS and doesn't leave it, as it encrypts keys in the hierarchy below.
2. Data Encryption Key (DEK):
• Used for encrypting the data.
• Stored near the data, with KMS keep a history of DEKs in metadata. → which allows the encrypted service to know which DEK version to use.
3. Master Encryption Key (MEK):
• Used for encrypting and decrypting the DEK in transit.
4. Key Generation:
• Involves regenerating new encryption keys.
• A precaution against potential exposure by an external third party → of a static encryption key → a key that has not been replaced and used in a very long time

The following are some best practices regarding AWS KMS:

1. Use IAM policies to grant access to a specific encryption key through an API, allowing fine-grained control (tagging resource but not reading the encryption key).
2. Specify the key's ARN in IAM policies for enhanced control over encryption keys.
3. Detect external entities with access to AWS KMS keys using the AWS IAM Access Analyzer API.
4. Utilize Amazon S3 bucket keys to create unique data keys for objects inside an S3 bucket, optimizing performance and reducing requests between S3 and AWS KMS.
5. Secure VPC access with AWS Private Link → secure channel.
6. Log API calls with AWS Cloud Trail → tracking of AWS KMS activity.
7. Log CMK events with Cloud Watch events → rotation, or deletion.
8. Set Cloud Watch alarms for impending CMK deletions.
9. Enforce MFA for AWS KMS access → by console or APIs.
10. Use AWS managed keys in KMS for services supporting encryption at rest.

• DEK (Data Encryption Key) is used to encrypt and decrypt data. CMK (Customer Master Key) in AWS Key Management Service (KMS) is used to protect and manage DEKs

AWS Cloud HSM

• FIPS → Federal Information Processing Standard is a US government standard for cryptographic modules, encompassing both hardware and software.
• AWS Cloud HSM → is a FIPS 140-2 Level 3 validated Hardware Security Module (HSM) managed by Amazon.
• Designed for regulated environments like banks or government agencies, it provides a single-tenant key for storage and serves as dedicated hardware for a single customer.
• The HSM device is tamper-resistant and tamper-proof, erasing all keys in case of a physical breach.
• AWS Cloud HSM generates
• AES256 symmetric encryption keys for encryption at rest
• RSA 2,048-bit (up to 4,096-bit), and ECC 256-bit (up to 512-bit) for encryption, digital signing, and signature verification.
• Being a hardware-based module, it includes TLS/SSL acceleration and Oracle Transparent Database Encryption (TDE) acceleration.

The following are some best practices regarding AWS Cloud HSM:

1. Utilize AWS Cloud HSM to relieve highly intensive web servers by offloading TLS processing.
2. Store your organizational PKI Certificate Authority (CA) private key using AWS Cloud HSM.
3. Ensure high availability by deploying a cluster of AWS Cloud HSM modules across different availability zones.
4. Increase Cloud HSM capacity for creating new keys by adding another Cloud HSM module.
5. Establish IAM group, add users, and grant necessary permissions on AWS Cloud HSM.
6. Enforce MFA for users accessing the AWS Cloud HSM console.

• PKI (Public Key Infrastructure) is a system that manages digital keys and certificates for secure communication. A CA (Certificate Authority) is a trusted entity within a PKI that issues and verifies digital certificates, ensuring the authenticity and integrity of cryptographic keys.

Best practices for deploying secrets management services

1. Major cloud providers provide secrets management services.
2. "Secrets" encompass sensitive data like database credentials, API keys, tokens, and usernames/passwords → sensitive information in a secured location
3. Secrets management ensures secure storage with access controls.
4. Centralized repository is recommended for dynamic cloud environments.
5. DevOps benefits by redirecting code to secrets management services, avoiding embedding sensitive information in code.

AWS Secrets Manager

• AWS Secrets Manager enables creation, storage, rotation, labeling, and versioning of secrets.
• Secrets managed by AWS Secrets Manager are encrypted and stored inside AWS KMS.
• AWS Secrets Manager → Amazon's managed secrets service
• services that support the use of secrets inside AWS services:
1. AWS Lambda functions contain secrets.
2. Passwords for connecting to various Amazon RDS databases (Aurora, MySQL, PostgreSQL, Oracle, MariaDB, and Microsoft SQL Server) are stored as secrets.
3. Secrets are present inside Amazon Document DB.
4. Amazon RedShift contains secrets.

The following are some best practices regarding AWS Secrets Manager:

1. Create IAM group, add service accounts, grant necessary AWS Secrets Manager permissions.
2. Control minimal access with IAM policies for users and applications.
3. Enable Replica Secret for central storage across AWS regions; update encryption key.
4. Use tagging for better organization of secrets related to AWS resources.
5. Ensure secret rotation is enabled for enhanced security.
6. Store sensitive information, including password hints, inside retrievable secret values.
7. Optimize performance with client-side caching in AWS Secrets Manager.
8. Avoid storing sensitive information, like secrets, in log files.
9. Run resources needing access inside your VPC.
10. services that operate outside your VPC, use AWS Code Build to access secrets from the AWS Secrets Manager service
11. Ensure secure access via AWS Private Link within your VPC.
12. Monitor API activities with AWS Cloud Trail.
13. Use Amazon Cloud Watch Logs for pending deletion or rotation alerts.
14. Employ AWS Config to track changes in your secrets.

• AWS Replica Secret is a feature allowing the replication of secrets (such as database credentials) across multiple AWS regions for enhanced availability and redundancy in AWS Secrets Manager.

Best practices for using encryption in transit

• Encryption in transit ensures secure communication over public networks while preserving confidentiality and integrity.
• IPSec → common protocol for site-to-site VPNs and VPN tunnels, operates on OSI model layer 3.
• Best practices for IPSec:
• Utilize IKEv2 protocol for security association (SA).
• Employ AES-GCM for encryption.
• Ensure integrity using HMAC-SHA256 or higher.

Transport Layer Security (TLS)

• TLS is a widely used protocol for encryption during data transit.
• It replaced SSL protocols due to security flaws, establishing itself as the de facto standard for internet encryption.
• TLS combines asymmetric encryption for session negotiation with symmetric encryption for secure message transfer between clients and servers.
• Despite relying on TCP, TLS is considered application layer encryption, specifically at layer 7 in the OSI model, exemplified by HTTPS in the HTTP protocol.

Best practices regarding TLS:

1. Private subnet or internal applications use certificates signed by a trusted internal CA.
2. Public-facing sites, APIs, or apps should use certificates from a reputable public CA.
3. Ensure certificate validity, matching domain name with DNS, and checking expiration or revocation status.
4. Avoid wildcard certificates; ensure certificate name matches server's FQDN.
5. Avoid short-validity certificates like Lets Encrypt.
6. Disable weak protocols (SSL and TLS versions lower than 1.2).
7. Disable weak cipher suites (3DES/DES/RC2/IDEA).
8. Use an RSA private key with a minimum size of 2,048-bit.
9. Employ SHA256 as the signature algorithm.
10. Enable Strict Transport Security (HSTS).
11. Implement Perfect Forward Secrecy (PFS).

Best practices for using encryption at rest

• Encryption at rest safeguards data stored in storage or databases, protecting it from unauthorized access.
• In object storage encryption → each file or object undergoes separate encryption.
• The process of extracting an encrypted object involves:
1. DEK is stored near the object, with metadata specifying the encryption key version.
2. Entire DEK is wrapped with a KEK.
3. KEK is stored in a key-managed service.
4. Authorized service requests KEK from the key-managed service to decrypt the specific DEK.
5. Decrypted DEK is transmitted via TLS/SSL to object storage, decrypting the object itself.
6. explanation in simpler way : In the computer world, keeping things safe is like having a secret diary. Imagine your secrets are in a diary, and you put it in a magic box (DEK) that only you and your friend can open. To make it super safe, you hide the magic box in a secret place (KEK). When you want to see your secrets, you go to the secret place, use your special key to open the magic box, and then you can read your diary.

AWS and object storage encryption

• AWS S3supports the following types of encryption keys:
1. Server-side encryption with Amazon S3 Managed Keys (SSE-S3):
• AES256-based encryption at rest.
• AWS generates, rotates, and maintains encryption keys.
• Recommended for all S3 bucket encryption.
2. Server-side encryption with CMKs stored in AWS KMS (SSE-KMS):
• AES256-based encryption at rest.
• Customers generate, rotate, and maintain encryption keys stored in AWS KMS.
• AWS KMS adds control with access configuration to encryption keys.
• AWS CloudTrail enables an additional audit trail.
3. Server-side encryption with customer-provided keys (SSE-C):
• Amazon S3 encrypts files using AES256 during upload.
• Customers encrypt files before uploading to S3.
• Amazon has no access to the encryption key.

Block storage encryption

• block storage encryption → a single DEK encrypts the entire block storage or disk volume, snapshots use a single encryption key for the entire snapshot.
• The DEK is wrapped by a KEK → stored in a secure vault (KMS).
• AWS block storage (EBS) supports different encryption key types:
• AWS-managed CMKs:
• AES256-based encryption at rest.
• AWS generates, rotates, and maintains keys.
• Recommended for all EBS volume encryption.
• Customer-managed CMKs:
• AES256-based encryption at rest.
• Customers generate, rotate, and maintain keys stored in AWS KMS.
• AWS KMS provides additional access control configuration.
• AWS Cloud Trail tracks CMK usage.
• Recommended for highly sensitive environments storing sensitive data in EBS volumes.

Full database encryption

• Full database encryption, also known as Transparent Data Encryption (TDE), uses a single DEK to encrypt the entire database, including logs, backups, and snapshots.
• The DEK is wrapped by the KEK, stored in a secured vault (KMS).

Amazon RDS encryption

• Amazon RDS supports the following types of encryption keys:
• AWS-managed CMKs:
• AES256-based encryption at rest.
• AWS generates, rotates, and maintains keys.
• Recommended for regular RDS database encryption.
• Customer-managed CMKs:
• AES256-based encryption at rest.
• Customers generate, rotate, and maintain keys stored in AWS KMS.
• AWS KMS provides additional access control configuration.
• AWS Cloud Trail tracks CMK usage.
• Recommended for highly sensitive environments storing sensitive data in RDS databases.

Encryption in use

• data is being used in the server's memory
• AWS Nitro Enclaves:
• AWS provides customers with an architecture isolating sensitive information (PII, credit card numbers, healthcare data).
• This design separates customer data from the EC2 instance and employs AWS KMS for data encryption.