Software ArchitectureAtlas

Software Architecture Atlas

Gain an overview. Understand the connections.

Chapter III · Area 10 of 12

Security & risks

The Question for Our ShopMay a shipping carrier change the status of any order?

Here you will learn how to build trust limits, accesses and protections into your design.

7 Building blocks

Starting hereTrust Boundaries

Three questions for every access

  1. Where does trust change?

    Boundaries & threats

    The tracking message from the shipping carrier comes from outside; the shop checks the signature before processing it.

  2. Who may do what?

    Identity & permissions

    The payment module receives its provider token at runtime; the invoice worker writes R-882 but cannot change prices.

  3. Where does the structure weaken protection?

    Structural risks

    If the order and shipping services share a table, there is no clear owner, and every change has to be made together.

Known names – and where they are

Can a shipping carrier change the status of any order? No. The shop checks the message signature and then whether the carrier may update exactly this order, for example B-1042.Authentication & authorisation

This is how the building blocks hang together

Trust boundaries mark where protection is needed and where trust changes. Threat modelling derives measures for permissions, identities and secrets from them; shared data and tightly coupled services show structural risks that weaken these boundaries.

ActivityThreat ModelingThreat Modeling examines threats, attack paths and safeguards in the system design.ConceptTrust Boundariesshow where threat modelling examines inputs, identities and data flowsPrincipleLeast Privilegelimits the impact of compromised identities and faulty componentsConceptAuthentication & authorisationimplement identity and permission checks on protected actionsConceptSecretsdenote confidential credentials whose misuse is assessed in the threat modelRiskShared Databaseblurs data ownership and widens the possible access pathsAnti-patternDistributed Monolithcouples services tightly; an attack or fault therefore hits several parts
Relations: Trust Boundaries show where threat modelling examines inputs, identities and data flows; Least Privilege limits the impact of compromised identities and faulty components; Authentication & authorisation implement identity and permission checks on protected actions; Secrets denote confidential credentials whose misuse is assessed in the threat model; Shared Database blurs data ownership and widens the possible access paths; Distributed Monolith couples services tightly; an attack or fault therefore hits several parts.

Your learning path through the area

Here you clarify whether a shipping carrier may change the status of any order. From this you derive trust boundaries, permissions, identity checks and the handling of credentials. Each building block shows its theme at our shop.

  1. Trust Boundaries

    Boundaries

    This is what you learnYou can assign data across trust boundaries to a technical and business audit.

    In the shopA shipping partner sends a tracking message to the shop. The shop verifies the signature and then checks whether the partner is allowed to update this order.

    Trust Boundaries Open

  2. Threat Modeling

    Boundaries

    This is what you learnYou can traceably link threat, attack path, impact and appropriate protection measures for a specific shop flow.

    In the shopThe team looks at an incoming shipment message and asks if a compromised partner could change third-party order status.

    Threat Modeling Open

  3. Least Privilege

    Permissions

    This is what you learnYou can limit a service’s access to the data and actions that its specific task requires.

    In the shopThe invoice worker reads order data and writes invoice files. He does not need permission to change prices or accounts in the shop.

    Least Privilege Open

  4. Authentication & authorisation

    Permissions

    This is what you learnYou can separately track identity verification and permission verification on a shop access.

    In the shopA registered customer opens an order page. The shop checks the session token and then compares the customer identity with the order owner.

    Authentication & authorisation Open

  5. Secrets

    Permissions

    This is what you learnYou can manage access data via provision, use, rotation and revocation in a controlled manner.

    In the shopThe shop uses a provider access token for payment requests. A central runtime service provides it to the payment module and supports the change to a new key.

    Secrets Open

  6. Shared Database

    Coupling

    This is what you learnYou can explicitly assign data sovereignty and writing responsibility to a shared database.

    In the shopIn the shop, several modules read order data; the order module remains the sole scribe of the order status. Shipping reports changes through a module contract.

    Shared Database Open

  7. Distributed Monolith

    Coupling

    This is what you learnYou can detect symptoms of tight coupling across service boundaries and name a suitable structural correction.

    In the shopVariant: Order and shipping services share a table and must be published together. A modular monolith structure remains the starting variant of the shop.

    Distributed Monolith Open
Afterwards in the learning path · area 11Evolution & assessment

Thinking ahead

These areas are technically directly related to Security & risks together.

Chapter II · Area 07Communication & APIsInterfaces and messages cross trust boundaries and need suitable checks.Open area Chapter III · Area 09Runtime & operationsPermissions and secrets must stay effective in deployment, rotation and monitoring during operation.Open area From practiceOne order, two systemsHow a business change connects data, messages and error handling.Opening up the scenario