Security Principles

Least privilege means every identity, whether a person, service, pipeline or token, gets only the permissions it needs, on only the resources it needs, for only as long as it needs them. The goal is to limit blast radius: if a credential is stolen, the attacker can do very little with it. In practice that means one IAM role per service scoped to specific ARNs and conditions, OAuth scopes and audiences per API, database users that cannot run DDL, and no standing production admin access. Time matters as much as scope, so temporary credentials and just-in-time elevation that expires after an hour are part of the principle, not an extra.

Defense in depth means protecting an asset with several independent layers of control, so that the failure or bypass of one layer does not lead straight to compromise. A typical stack runs from the edge, with a WAF and DDoS protection, through network segmentation, strong identity with MFA, application-level authorization and input validation, to data encryption and finally monitoring that detects when a layer has failed. The key word is independent: layers should use different mechanisms, owners and failure modes. A WAF rule against SQL injection is useful, but the code must still use parameterised queries and the database user must still lack rights to drop tables.

Fail secure means that when a security control or one of its dependencies fails, the system defaults to the safe state, which is usually to deny. If the authorization service is unreachable, a token cannot be validated, or an exception is thrown during a permission check, the request is refused rather than allowed through. Feature flags for risky capabilities default to off, and cryptographic errors abort the operation. Error messages to users stay generic, with a correlation ID, while the detail goes to secure logs so failures do not leak internals. The classic bug it prevents is a catch block that returns true, which turns an ordinary outage into a security breach.

Zero trust is the principle that no request is trusted because of where it comes from. Being inside the corporate network or the VPC grants nothing; every request from a user, device or workload is authenticated, authorized and evaluated against context such as device posture, location and risk. Its three tenets are verify explicitly, use least privilege per request, and assume breach, which drives segmentation, encryption everywhere and monitoring to limit lateral movement. In practice that looks like mTLS between services with mesh authorization policies, short-lived scoped tokens, and replacing broad VPN access with per-application access such as AWS Verified Access. It applies to users, workloads, networks and data alike.

Secure by design means security is built into a system from its first design decision rather than bolted on before go-live. It starts with threat modeling during design, so risks shape the architecture while changes are cheap. It continues with secure defaults that need no extra effort, such as a service template with deny-all Spring Security, TLS, encryption and locked-down actuator endpoints, and paved roads where the platform provides these controls ready-made. Mature teams also eliminate whole classes of bugs, for example banning native Java deserialization or string-built SQL with ArchUnit rules, and put security acceptance criteria in stories. CISA's Secure by Design pledge pushes vendors in the same direction.

Privilege creep is prevented by making access expire and by measuring what is actually used. Grants for projects, incidents and vendors should be time-bound by default, through just-in-time elevation and expiring permission sets, so nothing accumulates silently. Unused-access analysis, such as IAM Access Analyzer's last-accessed data, shows which actions a role has never exercised, and those are removed; one review at NovaBank removed thirty-eight actions from a single role. Quarterly access reviews with named owners catch human accounts, and joiner, mover and leaver processes remove access when people change teams. Define roles in code, so every permission change goes through review and the policy history is auditable.

A common-mode failure is a single flaw that defeats several defensive layers at once because they share a mechanism, dependency or assumption. Defense in depth only works if layers fail independently. If the API gateway, the service and the admin console all validate tokens against one identity provider configuration, a mistake such as accepting an unsigned token or the wrong issuer breaks all three together. The same happens when several layers rely on one vendor library, one shared secret or one team's review. To avoid it, vary the mechanisms, separate ownership, keep controls such as database permissions that do not depend on the identity layer, and monitor each layer separately.

Separate the safety of a decision from the availability of the service. Fail secure applies to the decision itself: if the control cannot reach a trustworthy answer, the risky action is denied. Availability is then protected by designing degraded modes in advance rather than by failing open. If the fraud service is down, low-value transfers can proceed within strict limits while high-value ones are refused or queued. If the policy engine is unreachable, cached decisions may allow low-risk reads for a short period. The business, risk and security owners should agree each degraded mode explicitly, document it in an ADR, and test it in game days so it behaves as intended.

Turn each principle into concrete practices, and each practice into an automated check with a target. Least privilege becomes a CI policy, such as a Checkov rule, that fails the build on wildcard IAM actions, plus AWS Config rules for standing admin users. Fail secure becomes unit tests proving that an exception in the authorization path returns deny. Secure by design becomes ArchUnit rules banning native deserialization, and a template every new service must start from. Zero trust becomes mesh policies with default deny that are verified in tests. Then track the results as metrics on a dashboard, for example zero wildcard policies, zero standing admins and one hundred percent deny-all defaults.

Principles appear in documentation mainly through architecture decision records. Every significant ADR should include a short section stating which security principles the design upholds or weakens and how any residual risk is handled. For example, an ADR introducing cached authorization decisions would note that it relaxes fail secure for low-risk reads, set a cache lifetime, and record who accepted the risk. Principles also belong in the architecture principles page with their measurable practices, in threat models linked from the design, and in service templates' documentation. Writing the reasoning down makes trade-offs reviewable by security and risk owners and stops individual developers making them silently in code.