--- type: tradeoffs pillar: security code: SEC title: "Security: tradeoffs" description: What security costs operations, performance and cost, and why costs left unnamed get paid anyway, through workarounds. status: draft sidebar: label: "Tradeoffs" order: 2 source_url: "https://framework.stackit.cloud/architecture/pillars/security/tradeoffs/" source_file: "docs/architecture/pillars/security/tradeoffs.mdx" --- Security has an unusual position in the framework: it is the pillar people are least willing to trade away explicitly, and the one most frequently traded away implicitly. Controls that impose friction get worked around rather than argued with, and the workaround is invisible until an incident exposes it. Which makes naming the costs more important here than anywhere else. A cost you acknowledge gets designed for. A cost you deny gets paid anyway, by someone improvising. --- ## Against Operational Excellence **The dominant tension, and the source of most silently abandoned controls.** Least privilege means engineers occasionally cannot do something they need to do, at an inconvenient time. Short-lived credentials mean re-authentication. Segmentation means requests must cross boundaries that someone configured. Change control means a fix waits for approval. Every one of these is correct, and every one produces pressure. That pressure resolves in one of two ways: an invested path around the friction, or a shared service account with broad permissions that everyone quietly uses. The second is the default outcome when the first is not funded. **How to resolve it:** invest in the path, not the exception. Self-service time-bound elevation beats a standing grant. Automated provisioning beats a ticket queue. A break-glass procedure that is fast, logged, and reviewed afterwards beats an unofficial one that is fast and invisible. Measure how often people work around a control, that number is the real assessment of it. ## Against Performance Efficiency Mostly small, occasionally structural: - **Encryption in transit** costs handshake latency and some throughput. Modern hardware makes this negligible for most workloads, and significant for very high-volume internal traffic. - **Per-request authorization** adds a lookup to every call. Caching helps and lengthens the window in which a revoked permission still works. - **Inspection points** (gateways, proxies, filters) add hops, and each is also a failure domain. - **Encrypted storage** is usually free at the hardware level and is not free when key operations hit an external service on a hot path. **How to resolve it:** measure rather than assume. Security overhead is routinely overestimated in design discussions and rarely appears in profiles. Where it is real, the answer is normally caching or a design change, not removing the control. ## Against Cost Optimization Security costs money in ways that are hard to attribute: dedicated tooling, log retention that grows without bound, key management operations, isolation that prevents efficient resource sharing, and time spent on review. Segmentation deserves specific mention. Separate projects and networks per environment and per sensitivity class means less consolidation, more idle capacity, and more things to manage. The containment is worth it, but it is a real cost, not a free organizational choice. Detection has a particular shape: log volume grows continuously, its cost is visible, and its value is invisible until the one time you need six-month-old data. Retention gets cut during cost reviews, quietly, and the consequence surfaces during an investigation. **How to resolve it:** tier by classification. [`SEC 3`](/architecture/pillars/security/sec-03-data-classification/) exists so that the expensive controls apply where they are warranted rather than everywhere. Set log retention from investigation and regulatory requirements, and record the reason next to the number so a future cost review argues with the reason rather than the number. ## Against Reliability Largely complementary, segmentation limits blast radius in both senses, with two real frictions: - **Every control is a component that can fail.** A misconfigured firewall rule and an expired certificate are outages. Security infrastructure on the critical path needs the same reliability treatment as anything else on it. - **Emergency access is a security liability and a reliability necessity.** Break-glass paths bypass the controls, which is what makes them useful during an incident and attractive to an attacker. They need to exist, be tightly bounded, be heavily logged, and be reviewed after every use. Backups appear on both sides: [`REL 8`](/architecture/pillars/reliability/rel-08-backup-and-restore/) requires copies, [`SEC 7`](/architecture/pillars/security/sec-07-encryption/) requires each copy to be protected to the classification of its contents. ## Against Sovereignty & Compliance Mostly aligned, and the alignment hides a real divergence. Security asks whether an attacker can reach the data. Sovereignty asks who can reach it *legitimately*, including the provider, its subprocessors, and anyone with legal authority over them. A workload can be excellently secured against attack while remaining fully exposed to a category of access that sovereignty is concerned with. Encryption is where this becomes concrete. [`SEC 7`](/architecture/pillars/security/sec-07-encryption/) is largely satisfied by encryption at rest with provider-managed keys. [`SOV 4`](/architecture/pillars/sovereignty/sov-04-key-ownership/) is not, because provider-managed keys leave the provider technically able to decrypt. Same mechanism, different question, different answer. **How to resolve it:** read the two pillars together for anything touching sensitive data, and do not assume that satisfying the security best practice satisfies the sovereignty one. ## Against Sustainability Minor. Encryption and inspection consume some additional compute; log retention consumes storage; segmentation reduces consolidation density. None of it is large enough to drive a security decision, and any argument that reaches for it is usually a cost argument wearing a different hat. --- ## Related - Design principles - [Overview](/architecture/pillars/security/): the questions this pillar asks - Sovereignty & Compliance tradeoffs