SEC 7. How do you protect data in transit and at rest?
Last updated on
Encryption is a layered defence, justified by the assumed failure of the layers around it. It matters precisely because access controls are sometimes misconfigured, network boundaries are sometimes crossed, and storage media sometimes leave a building.
The mechanism is largely solved and the decisions are not. What gets encrypted, which copies are
included, and who holds the keys are choices with real consequences, and the last one is where
this question meets SOV 4.
Best practices
Section titled “Best practices”SEC 7.1Encrypt all traffic, including internal service-to-service callsSEC 7.2Encrypt at rest, including every copySEC 7.3Decide who is technically able to decrypt, per data setSEC 7.4Manage the key lifecycle as the most critical state you hold
SEC 7.1 Encrypt all traffic, including internal service-to-service calls
Section titled “SEC 7.1 Encrypt all traffic, including internal service-to-service calls”Risk if not established: High
External traffic is encrypted almost everywhere. Internal traffic frequently is not, on the reasoning that the internal network is trusted, which is precisely the assumption assume breach removes.
Cover all of it: service to service, application to database, application to cache, and the
telemetry pipeline, which carries a copy of much of your data under SEC 3.3.
Two operational details decide whether it holds. Certificate lifecycle is the common failure: an expired internal certificate is an outage, and internal certificates get less attention than external ones. Automate issuance and renewal or it will happen to you. And verification is what makes encryption meaningful; a client that encrypts but does not validate the certificate is protected against passive observation and not against an active attacker.
Use current protocol versions and disable obsolete ones. This is a configuration decision that
belongs in the baseline under SEC 1.1 rather than being made per service.
On STACKIT. CSPM names missing TLS encryption as an example of the findings it produces, so the estate-wide check is available rather than something to build.
Managed services expose their own connection security settings, documented per service, such as connecting to PostgreSQL Flex . Verifying rather than assuming is the practice, since the default varies by service.
Between your own services on
Kubernetes Engine , mutual TLS is
implemented in your applications or by a mesh you operate, as SEC 6.4 describes. The
security hardening guidance
covers platform-level practice.
Tradeoffs. Performance Efficiency. Handshake latency and some throughput cost, negligible for most workloads on current hardware and measurable on very high-volume internal traffic. It is routinely overestimated in design discussions and rarely appears in a profile.
Verify. List the connections your workload makes. Which are encrypted, and which of those validate the certificate rather than merely encrypting?
SEC 7.2 Encrypt at rest, including every copy
Section titled “SEC 7.2 Encrypt at rest, including every copy”Risk if not established: High
Encryption at rest is largely a solved problem for primary storage and largely unexamined for
everything else. The copies from SEC 3.3 are where it is missed: backups, snapshots, replicas,
logs, exports and test data.
Ask per storage location rather than per system, since a single workload writes to several. The question is whether this specific location is encrypted, with which key, and whether that satisfies the classification of what is written there.
Understand what it protects against. Encryption at rest addresses physical media compromise and,
depending on key ownership, provider access. It does not protect against an attacker who has
compromised a workload authorized to read the data, because that workload decrypts legitimately.
That distinction is what makes SEC 5 and SEC 7.3 load-bearing rather than optional extras.
On STACKIT. Encryption at rest is provided by the storage services rather than being something
you add, so the practical work is establishing which key protects each store, which is SEC 7.3.
The places to check are the ones outside the primary store: Object
Storage for exports and backup
destinations, Server Backup
Management for
virtual machine backups, and the telemetry stores under OPS 7.4.
Archiving provides audit-proof immutable storage, which is a different property from encryption and complementary to it: immutability protects against alteration, encryption against reading.
What “customer-managed” means differs per service, so read each rather than assuming one
mechanism. Object Storage
encryption
is AES256 at rest by default, and beyond that offers server-side encryption with backend-managed
keys, or SSE-C, where you supply the key with the request and it is not stored on STACKIT systems.
SSE-C is the stronger answer to SEC 7.3 and the more demanding one, since the key has to reach
every request and losing it is unrecoverable.
Whether a given service accepts a KMS key at all is that service’s own business, and there is no central list of which ones do. Expect to establish it service by service for the services your workload actually uses, and to do it early: at the tiers where customer-held keys are mandatory it is usually the first thing the design turns on, and the answer can be no.
Tradeoffs. Little at rest, since it is generally transparent and hardware-accelerated. The
cost appears in key management under SEC 7.4 rather than in the encryption itself.
Verify. List every place your most sensitive data is written, including backups and telemetry. Which are encrypted at rest, and with whose key?
SEC 7.3 Decide who is technically able to decrypt, per data set
Section titled “SEC 7.3 Decide who is technically able to decrypt, per data set”Risk if not established: High
This is the decision that separates encryption as a checkbox from encryption as a control. With provider-managed keys, the provider is technically able to decrypt. With customer-managed keys, they are not, and you carry the consequences of holding the key.
Neither is universally correct. Provider-managed keys are simpler, more reliable and appropriate for most data. Customer-managed keys are what a classification requires when the point is to exclude the provider, and they bring a real operational burden with them.
Decide per data set using the mapping from SEC 3.2. Applying customer-managed keys uniformly is
expensive and applying them nowhere leaves the regulated data with a control it needed.
Be clear about which question you are answering. Encryption at rest with provider-managed keys
satisfies most of this best practice as a security control. It does not satisfy SOV 4, because
that question is about who legitimately has access rather than about whether an attacker can read
the disk. Same mechanism, different question, and the sovereignty tier from SOV 1 is what
decides.
On STACKIT. KMS is the customer-managed
key service. Key
rings
group keys logically and are also the access control boundary, which makes the ring structure
worth planning alongside the project structure from SEC 2.2.
Where a compliance obligation mandates a specific algorithm or curve, check the supported set on the concepts page before the design depends on KMS.
Key import is supported, so a key generated outside STACKIT can be brought in and used within KMS. Imported keys are bound to a version and wrapped during import. That matters where a classification requires the key to have originated outside the provider, which is a stricter requirement than customer-managed and is worth distinguishing when reading a compliance obligation.
Tradeoffs. Reliability. Holding your own keys means you can lose them, and losing a key
destroys the data as thoroughly as losing the data. Operational Excellence. Key lifecycle
becomes a practice rather than a setting, which is SEC 7.4. Performance Efficiency. Key
operations on a hot path cost a round trip unless cached.
Verify. For each data set, who is technically able to decrypt it? Where the answer includes the provider, is that consistent with its classification and its sovereignty tier?
SEC 7.4 Manage the key lifecycle as the most critical state you hold
Section titled “SEC 7.4 Manage the key lifecycle as the most critical state you hold”Risk if not established: High
Once you hold keys, they are the most critical state in the system. Everything they protect is inaccessible without them, which makes key loss equivalent to data loss and key compromise equivalent to data compromise.
Four things need a defined answer:
Generation. Where keys come from and with what strength. Import if the classification requires external origin.
Access. Which identities may use a key and which may manage it. These are different permissions and conflating them means anyone who can decrypt can also delete.
Rotation. How keys are replaced, on what cadence, and what happens to data encrypted under the previous version.
Recovery. What happens if a key is lost or deleted. This is the one teams discover they have
not answered, and it needs the same rigour as REL 8, since a key backup is a backup.
Deletion deserves particular care because it is irreversible in a way most operations are not. A deleted key with live data behind it is unrecoverable data.
On STACKIT. KMS supports key versions, which is the mechanism rotation is built on, and key management covers the operations. Key rings are the access boundary, so permissions are structured around rings rather than individual keys.
Three properties decide whether that is operable at your scale, and each of them constrains a design rather than merely informing it.
Rotation is manual. KMS performs a rotation when you ask it to and offers no schedule, so a
policy that says “every ninety days” is something you automate under OPS 10.2 or something that
quietly does not happen.
A new key version does not re-encrypt what exists. Creating a version rotates what is used next; data already written stays on the version that wrote it. Block Storage with a customer-managed key is the concrete case: a volume encrypted under version one stays there, and moving it to version two means creating a new volume and copying the data across. Where that matters, the rotation plan is a data-migration plan and belongs in the estimate rather than in a policy document.
Deletion has a thirty-day window. A deleted key or key version can be recovered within thirty days, after which it is gone and so is the data behind it. That is enough to survive a mistake and not enough to survive an unnoticed one, which is why the deletion path deserves the same approval treatment as any other irreversible operation.
Key material belongs in the backup analysis under REL 8.5, which states the same point from the
reliability side: if a key is lost, the backups it protects become unreadable.
Tradeoffs. Reliability, directly and seriously. This is the cost of SOV 4 and it is
named in the Sovereignty tradeoffs. A key management practice
that is under-resourced becomes an availability incident, which is a worse outcome than the
provider-managed key it replaced.
Verify. For your customer-managed keys: who can use them, who can delete them, when were they last rotated, and what is the recovery procedure if one is lost?
Related
Section titled “Related”SEC 3Data classification, which decides which data warrants which treatmentSOV 4Key ownership, the same mechanism answering a different questionSOV 5Operator access, which extends this to data in useREL 8.5Backup protection, where key loss becomes data lossSEC 6.4Internal verification, which encryption in transit accompanies