---
id: SEC07
pillar: security
title: SEC 7. How do you protect data in transit and at rest?
description: Encryption matters because access controls sometimes fail. Which traffic, which copies, and who holds the keys, decided per data set rather than once globally.
status: draft
services: [kms, object-storage]
sidebar:
  order: 16
  label: Encryption
source_url: "https://framework.stackit.cloud/architecture/pillars/security/sec-07-encryption/"
source_file: "docs/architecture/pillars/security/sec-07-encryption.mdx"
---

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`](/architecture/pillars/sovereignty/sov-04-key-ownership/).

## Best practices

- [`SEC 7.1`](/architecture/pillars/security/sec-07-encryption/#sec-71-encrypt-all-traffic-including-internal-service-to-service-calls) Encrypt all traffic, including internal service-to-service calls
- [`SEC 7.2`](/architecture/pillars/security/sec-07-encryption/#sec-72-encrypt-at-rest-including-every-copy) Encrypt at rest, including every copy
- [`SEC 7.3`](/architecture/pillars/security/sec-07-encryption/#sec-73-decide-who-is-technically-able-to-decrypt-per-data-set) Decide who is technically able to decrypt, per data set
- [`SEC 7.4`](/architecture/pillars/security/sec-07-encryption/#sec-74-manage-the-key-lifecycle-as-the-most-critical-state-you-hold) Manage the key lifecycle as the most critical state you hold

---

## 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`](/architecture/pillars/security/sec-03-data-classification/#sec-33-find-the-copies-telemetry-backups-caches-test-data-and-exports).

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`](/architecture/pillars/security/sec-01-security-baseline/#sec-11-derive-the-baseline-from-the-frameworks-you-are-actually-assessed-against) rather than being made per service.

**On STACKIT.** <LinkChip href="https://docs.stackit.cloud/products/security/cspm/">CSPM</LinkChip> 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
<LinkChip href="https://docs.stackit.cloud/products/databases/postgresql-flex/how-tos/connect-to-postgresql-flex/">connecting to PostgreSQL
Flex</LinkChip>.
Verifying rather than assuming is the practice, since the default varies by service.

Between your own services on
<LinkChip href="https://docs.stackit.cloud/products/runtime/kubernetes-engine/">Kubernetes Engine</LinkChip>, mutual TLS is
implemented in your applications or by a mesh you operate, as [`SEC 6.4`](/architecture/pillars/security/sec-06-network-controls/#sec-64-verify-inside-the-segment-rather-than-trusting-it) describes. The
<LinkChip href="https://docs.stackit.cloud/products/security/security-hardening/">security hardening guidance</LinkChip>
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

**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`](/architecture/pillars/security/sec-03-data-classification/#sec-33-find-the-copies-telemetry-backups-caches-test-data-and-exports) 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`](/architecture/pillars/security/sec-05-least-privilege/) and [`SEC 7.3`](/architecture/pillars/security/sec-07-encryption/#sec-73-decide-who-is-technically-able-to-decrypt-per-data-set) 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`](/architecture/pillars/security/sec-07-encryption/#sec-73-decide-who-is-technically-able-to-decrypt-per-data-set).

The places to check are the ones outside the primary store: <LinkChip href="https://docs.stackit.cloud/products/storage/object-storage/">Object
Storage</LinkChip> for exports and backup
destinations, <LinkChip href="https://docs.stackit.cloud/products/compute-engine/server-backup-management/">Server Backup
Management</LinkChip> for
virtual machine backups, and the telemetry stores under [`OPS 7.4`](/architecture/pillars/operational-excellence/ops-07-observability/#ops-74-set-retention-by-the-value-of-each-signal-rather-than-uniformly).

<LinkChip href="https://docs.stackit.cloud/products/storage/archiving/">Archiving</LinkChip> 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. <LinkChip href="https://docs.stackit.cloud/products/storage/object-storage/how-tos/manage-encryption/">Object Storage
encryption</LinkChip>
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`](/architecture/pillars/security/sec-07-encryption/#sec-73-decide-who-is-technically-able-to-decrypt-per-data-set) 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`](/architecture/pillars/security/sec-07-encryption/#sec-74-manage-the-key-lifecycle-as-the-most-critical-state-you-hold) 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

**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`](/architecture/pillars/security/sec-03-data-classification/#sec-32-let-the-classification-drive-the-controls-mechanically). 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`](/architecture/pillars/sovereignty/sov-04-key-ownership/), 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`](/architecture/pillars/sovereignty/sov-01-sovereignty-tier/) is what
decides.

**On STACKIT.** <LinkChip href="https://docs.stackit.cloud/products/security/kms/">KMS</LinkChip> is the customer-managed
key service. <LinkChip href="https://docs.stackit.cloud/products/security/kms/how-tos/create-and-manage-key-rings/">Key
rings</LinkChip>
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`](/architecture/pillars/security/sec-02-segmentation/#sec-22-structure-the-resource-hierarchy-so-it-can-carry-the-boundaries-you-need).

Where a compliance obligation mandates a specific algorithm or curve, check the supported set on
the <LinkChip href="https://docs.stackit.cloud/products/security/kms/basics/concepts/">concepts page</LinkChip> 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`](/architecture/pillars/security/sec-07-encryption/#sec-74-manage-the-key-lifecycle-as-the-most-critical-state-you-hold). **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

**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`](/architecture/pillars/reliability/rel-08-backup-and-restore/), 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
<LinkChip href="https://docs.stackit.cloud/products/security/kms/how-tos/create-and-manage-keys/">key management</LinkChip>
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`](/architecture/pillars/operational-excellence/ops-10-toil-elimination/#ops-102-automate-what-recurs-starting-with-the-riskiest-rather-than-the-most-frequent) 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`](/architecture/pillars/reliability/rel-08-backup-and-restore/#rel-85-protect-backups-to-the-classification-of-their-contents), 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`](/architecture/pillars/sovereignty/sov-04-key-ownership/) and it is
named in the [Sovereignty tradeoffs](/architecture/pillars/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

- [`SEC 3`](/architecture/pillars/security/sec-03-data-classification/) Data classification, which decides which data warrants which treatment
- [`SOV 4`](/architecture/pillars/sovereignty/sov-04-key-ownership/) Key ownership, the same mechanism answering a different question
- [`SOV 5`](/architecture/pillars/sovereignty/sov-05-operator-access/) Operator access, which extends this to data in use
- [`REL 8.5`](/architecture/pillars/reliability/rel-08-backup-and-restore/#rel-85-protect-backups-to-the-classification-of-their-contents) Backup protection, where key loss becomes data loss
- [`SEC 6.4`](/architecture/pillars/security/sec-06-network-controls/#sec-64-verify-inside-the-segment-rather-than-trusting-it) Internal verification, which encryption in transit accompanies