1 Prerequisites
- 1.1 Risk based approach
- 1.2 PIM
2 Reference
- 2.1 Overall concept
- 2.2 Automation first
- 2.3 Resource Groups
  - 2.3.1 Main
- 2.4 Roles

Prerequisites

Azure Hierarchy

To understand all further references in this document, the Azure Hierarchy as well as the 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 applications 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

Unique's reference architecture is based mainly on two key concepts from Microsoft:

To keep in mind 👆🏽

It is crucial to understand, that most of the landing zone setup itself can and is only done by the client themselves. Learn in 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 the principle of least privilege as no human needs privileged access anymore except in escalations
An easy to get audit trail
A modern-day approach to collaboration

Note that the more the client automates, the fewer 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 it is up to one of the parties to mitigate this risk.

Resource Groups

This separation targets primarily and is not only decoration.

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

Group	Content	High-level permissions

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, and encryption keys.	Unique should have the least possible privilege (and only JIT) of this group. Actually, no human should have too much access to this, see Automation.
Audit	Centralized, 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, where some limited internet access is needed to pull the content of	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.

Main

The content of the main group, primarily based on . Besides the Infrastructure requirements, some more resources are recommended to be deployed in order to run .

Roles

To understand the content of this section, must be read and understood.

Author	See Parent

Public Documentation

Reference Architecture CMT