Practical Cases of Applying Secure Architecture
These examples demonstrate how to apply the secure architecture requirements in real contexts, according to the application's risk level (see Chapter 1).
🏥 Case 1 - Healthcare Application with Public Exposure (High Risk - L3)
- Web app in a public cloud with APIs for clinics and patients
- Clinical and personal data processed
- Integration with external services
Requirements applied:
| Requirement | Practical application |
|---|---|
| ARC-001 | Trust zones defined (public frontend, backend, database) |
| ARC-005 | STRIDE threat modelling applied to the flows between components (critical flows covered and mitigations recorded) |
| ARC-011 | Segmentation between dev/stage/prod environments with isolated permissions and identity |
| ARC-012 | Formal approval checklist completed by AppSec before the deploy to production |
| ARC-013 | Automatic validation of the topology via Cartography in CI/CD |
🧾 Case 2 - B2B Invoicing System (Medium Risk - L2)
- Internal web app with authenticated users
- Financial and customer data
Requirements applied:
| Requirement | Practical application |
|---|---|
| ARC-002 | Inventory of externally exposed APIs with the associated controls documented |
| ARC-003 | Architecture review with a formal record and an AppSec checklist |
| ARC-006 | Critical services with active isolation in dedicated subnets |
| ARC-010 | Architecture diagram versioned in the repository (.drawio) |
📝 Case 3 - Internal Task Management Platform (Low Risk - L1)
- Web application accessible only on the internal network
- No sensitive data or external APIs
Requirements applied:
| Requirement | Practical application |
|---|---|
| ARC-001 | Simple diagram with a single trust zone |
| ARC-008 | Basic validation of the internal data flows |
| ARC-010 | Diagram included in the project wiki |
🔗 These examples show how to apply the requirements according to the risk, promoting proportionality and effectiveness without overload.