GCP Security · Domain 3
Ensuring Data Protection
About 23% of the exam
Key management options
- Default encryption
- everything encrypted at rest already
- Customer managed key
- your key in the key service
- Customer supplied key
- you send it with each request
- External key manager
- key held by a third party
- Hardware protection
- key material inside validated hardware
- Software protection
- key material managed in software
- Autokey
- creates keys following recommended practice
- Key ring
- container binding keys to a location
Default encryption is always on, so the real question is who holds the key and who can be compelled to use it
Key lifecycle
- Create
- Rotate
- Disable
- Schedule destroy
- Destroyed
- Versions rotate while the name stays
- Disable a version to stop decryption
- Destruction waits for a scheduled period
- The destroy delay is fixed at creation
- Import jobs use a time limited wrapper
- Symmetric material cannot be exported
- Rotation schedule configured per key
External keys and justification
- An external manager holds the material
- Reached over the internet or privately
- Justification codes accompany each access
- The external system can refuse a reason
- Availability of that system now matters
- Strongest separation from the provider
Where customer keys apply
- Bucket default key for new objects
- Warehouse datasets and their tables
- Disks through an encryption reference
- Messaging topics encrypt stored messages
- Managed environments encrypt their databases
- Secret payloads can use your key
Key access roles
- Encrypter and decrypter
- uses the key, cannot manage
- Decrypter only
- can read, cannot write
- Key administrator
- manages keys without using them
- Service agent
- the service identity needing key use
- Separation
- administrators should not be users
- Key project
- keys held in their own project
- Perimeter
- keys inside the same boundary
- Audit
- every key use is logged
Sensitive data protection
Inspect
- Built in detectors for common types
- Custom detectors from your own patterns
- Scan storage, warehouses and streams
Transform
- Redaction removes the value
- Masking keeps part of it
- Bucketing generalizes while keeping utility
- Tokenization allows reversible replacement
Operate
- Templates make the jobs repeatable
- Inline transformation inside a pipeline
- Findings feed the security console
Object storage protections
- Public access prevention blocks any exposure
- Uniform access removes per object lists
- Retention policy locks the deletion date
- Object versioning recovers from overwrites
- Signed links expire at a chosen time
- Bucket key applies to new objects
Warehouse level controls
- Policy tags drive column level access
- Authorized views expose derived results only
- Row level policies filter by identity
- Data access logs are on here
- Snapshots and time travel aid recovery
- Export controls limit where results go
Secret management
- A central store with versioned secrets
- Access granted per secret, not project
- Rotation reminders and a replication policy
- A customer managed key protects the payload
- Every access recorded in audit logs
- Never place secrets in environment variables
Data in use
- Confidential machines encrypt memory in hardware
- Confidential nodes extend it to clusters
- Attestation evidence proves the environment
- Cost falls only on the sensitive pool
- Combine with external keys for separation
- Protects against infrastructure level access
Residency and locality
- A location constraint limits where resources exist
- Single region storage keeps data local
- Key ring location should match the data
- Regulated workload programs add further controls
- Support personnel access can be restricted
- Replication choices change the geography
Data protection mistakes
- Bucket public through a legacy list
- Key in a different region entirely
- Key project outside the service perimeter
- Discovery run once and never repeated
- Masked column still exported in full
- Destroy delay shorter than the recovery need
Rapid recall: protection choice
- Provider must not decrypt alone
- an external key manager
- Reason recorded per access
- key access justifications
- Hide a salary column
- policy tag access
- Redact names in documents
- a de-identification transform
- Keep some analytic value
- bucketing generalization
- Stop any public exposure
- public access prevention
- Memory protected in hardware
- confidential computing
- Keys stay in country
- an in-country key ring
Reference strip: keys, lifecycle, discovery, storage, analytics
Keys
- Default encryption always on
- Customer managed and supplied
- External manager for separation
- Hardware protection level
Lifecycle
- Versions rotate under one name
- Disable before destroy
- Destroy delay set at creation
- Import wrappers expire quickly
Discovery
- Built in and custom detectors
- Redact, mask, bucket, tokenize
- Templates and repeatable jobs
- Findings into the console
Storage
- Public access prevention
- Uniform bucket access
- Retention and versioning
- Signed links with expiry
Analytics
- Policy tags on columns
- Authorized views for sharing
- Row filters by identity
- Access logs enabled
Quick exam traps
- Trap: Data sits unencrypted at rest until you configure a key
- Trap: The destroy delay on a key version can be changed later
- Trap: Masking a column also protects it in an export
- Trap: A customer supplied key is stored by the provider for you
- Trap: Uniform bucket access and public access prevention are one setting
- Trap: Confidential computing removes the need for encryption at rest
- Trap: Keys can sit in any region without affecting residency
cybercertprep.com · original revision sheet written from the public body of knowledge