GCP: About Encryption

Encryption at rest

GCP encrypts customer data by default
Key creation and rotation are managed by GCP
Data is broken into subfile chunks
Each chunk is encrypted at storage level with its unique encryption key
No two chunks will ever have the same encryption key
Each updated chunk is encrypted with a new key
Key used for encryption is called data encryption key (DES)
DEKs are generated by storage system using Google’s cryptographic library, keyczar
AES-128 and AEAS-256 are used for encryption
Implemented using BoringSSL(fork of OpenSSL)
Backups are encrypted using a separate key

Keep encryption keys on premises where required and use them to encrypt services in GCP
COntrol access to and use of data at the finest level of granularity, ensuring data security and privacy
Manage encryption of cloud-hosted data the same way as current oon-premises data- or better.
HAve a provable and auditable root of trust over resources
Be able to further separate and segregate customer data, beyond the use of ACLs

Encryption in transit protects your data if communications are intercepted while data moves between toye site and the cloud provider or between 2 service
It reduces the potential attach surgace
Prevents attacker from accessing data if communications are intercepted

Globally distributed system that GCP services accept requests from.

Terminating traffic for incoming HTTP(S), TCP and TLS proxy traffic
DDOS attack prevention
Routing and load balancing traffic to GCP services
Google implements the following security strategy within GFE:
- Authentication
- Integrity
- Encryption

Encryption is performed at the network layer (Layer 3)
AES-128
Session keys are established on hosts
- Protected by ALTS
Security tokens used for authentication
- Generated for every flow; consist of token key and host secret
Protects a compromised host from spoofing packets on the network

Layer 3 traffic
Traffic traveling between the two networks is encrypted by one VPN gateway and decrypted by the other VPN gateway
IKEv1 (AES-128), IKEv2 (AES-256)

TLS in the GFE is implemented with BoringSSL
Fork of OpenSSL
Automatically negotiates the highest version of the protocol to ensure the best possible security

Layer 7 traffic
Mutual authentication and transport encryption system developed by Google
Used for securing Remote Procedure Call (RPC) communications within Google’s infrastructure
Identities are bound to entities (user, machine, or service) instead of to a specific server name or host
Relies on both the Handshake Protocol and the Record Protocol
Governs how sessions are established, authenticated,encrypted, and resumed
GFE to service / service to service

Cloud Key Management Service (KMS) is a service that lets you manage cryptographic keys for every service within the Google Cloud Platform
Generate, use, rotate, and destroy symmetric encryption keys
Automatic or at-will key rotation
Asymmetric and symmetric key support
Used to encrypt all data on Google Cloud (default)
Integrated with Cloud IAM and Cloud Audit Logs
Tracked every time it is used and authenticated and logged
Permissions are handled by Access Control Lists (ACLs) on a per-key basis
- Per key policy
Used with Cloud HSM
DEKs are encrypted with a key encryption key (KEK).
Process known as envelope encryption - “Encrypting key with another key.”
A central repository for storing KEKs
KEKs not exportable from KMS
Automatically rotates KEKs at regular intervals
Standard rotation period is 90 days

Four types of locations:
- Regional (e.g., Iowa)
  - Zones in a specific geographical place
- Dual-regional (e.g., Iowa and South Carolina)
  - Zones in two specific geographical places
- Multi-regional (e.g., United States)
  - Zones spread across a general geographical area
- Global
  - KMS resources are available from zones spread around the world.
Users and services who are far away from the location will experience higher latency.
Read operations are served by a data center close to the requesting user or service.
Write operations must propagate to multiple data centers when performed on multi-region or global resources.
- Will be slower as a result.

Keys are stored in a hierarchical structure
- Project
- Location
- Key ring
- Key
- Key version
Project
- KMS belongs to a project
- Best practice is to run in a separate project to be able to lockdown permissions with regards to having access to KMS and the keys themselves
Geographical Location
- Where KMS keys are stored
- Where KMS receives requests
Key Ring
- Grouping of keys for organizational purposes
- Keys inherit permissions from the key ring
Key
- Cryptographic key
- Symmetric or asymmetric
Key Version
- The material that makes up the key (length, algorithm)
- Numbered sequentially
- States:
  - Pending generation
    - Being generated
    - Asymmetric keys only
  - Enabled
  - Disabled
    - Can be put back into the enabled state
  - Scheduled for destruction
    - Can be put back into the disabled state
  - Destroyed
  - Symmetric encryption
    - Primary key version to be enabled for encryption
  - Asymmetric encryption
    - Key version to be enabled for encryption or digital signing

Symmetric key rotation
- A new key version of a key is generated
- New key marked as primary
- Previous key not destroyed
- Old key available for decryption
- Automatic key rotation
Asymmetric key rotation
- A new key version of a key is generated
- Manual key rotation only

Ensuring that one individual does not have all necessary permissions to be able to complete a malicious action.
Users normally should not have access to decryption keys.
Helps prevent security or privacy incidents and errors.
Best practice: Move KMS to its own project.