Prerequisites

To understand all further references in this document, the Azure Hierarchy as well as basic principles of Azure Entra ID (and its permissions) have to be understood.

Risk based approach

Most of the actions in this architecture target some key risks that are relevant for our clients, namely:

Data exfiltration in general (someone or Unique extracting/stealing data of any classification but naturally mostly classified data)
Data exfiltration via the Kubernetes Data Plane
Data exfiltration via Privileged Roles
Misconfiguration of Cloud Resources
Over-Provisioning or cost escalations
Security vulnerabilities in third-party application which could also result in data exfiltration

This list is not conclusive but many decisions taken target one of these risks.

PIM

Unique themselves and advises all clients to leverage Privileged Identity Management (PIM) access (also called JIT or Just in Time) at all times.

Unique always uses and means to advice to use PIM and does not repeat that statement in every chapter and section. PIM and PIM only!

Reference

Overall concept

Uniques reference architecture bases mainly on two key concepts from Microsoft:

It is crucial to understand, that most of the landing zone setup itself can and is only done by the client themselves. Learn in https://unique-ch.atlassian.net/wiki/spaces/PUB/pages/445776026/Customer+Managed+Tenant#Responsibilities which tasks these are.

Automation first

Unique strongly advises to delegate as much work as possible to automation, which gives the client

More control over incoming changes
Fewer if not minimal lateral movement risks
A tight grip on principle of least privilege as no human needs privileged access anymore except in escalations
An easy to get audit trail
A modern-day approach of collaboration

Note that the more the client automates, the less of the roles and permissions outlined below are needed. How much of the setup is automated from the client side also has a pricing and timeline impact as human actions always take longer than those of machines.

This automation grade is top-notch and a dream to many 🫧 Unique although works on providing the best risk mitigations possible. The more of this automation is implemented, the securer the solution all-in-all gets.

Again, remember that depending on the https://unique-ch.atlassian.net/wiki/spaces/PUB/pages/445776026/Customer+Managed+Tenant#Responsibilities it is up to one of the parties to mitigate this risk.

Resource Groups

This separation targets primarily https://unique-ch.atlassian.net/wiki/spaces/PUB/pages/445972604/Reference+Architecture+CMT#Risk-based-approach and is not only decoration.

Unique advises to segregate resources at a resource group level using the following groups:

Group	Content	High-level permissions
Main	Primary resources needed to run but no resources that contain data	The responsible party (can be Unique or the client, see Responsibilities) mostly works within this resource group if ever.
Sensitive	All customer data which mainly consists of prompts and files, all the embedding of uploaded files, encryption keys	Unique should have the least possible privilege (and only JIT) of to this group. Actually, no human should have too much access to this, see Automation.
Audit	Centralised, tamper-safe audit logs of	Unique and their workloads can only one-way emit into this resource group, there is no way to read. Modifications to this resource group should preferably only be made by the client or via Automation.
Vnet	Networking setup, whereof some limited internet access is needed to pull the content of https://unique-ch.atlassian.net/wiki/spaces/PUB/pages/436536544	Naturally most clients prefer to administer this part of the infrastructure themselves as it has a colossal security impact, if Unique should take care of it, the Automation approach is recommended above all manual actions
Terraform	Store terraform states	Few individuals with a specific role or the Automation should have access to this group as here the state of the whole infrastructure gets saved.