From 7ff4fad9534be322c45c3a8f45c66a9bc92ddfa7 Mon Sep 17 00:00:00 2001 From: Tomas Kracmar Date: Tue, 9 Jun 2026 14:40:34 +0200 Subject: [PATCH] feat: Add management overlay pattern (Nebula T0 / Tailscale T1) and cloud admin VM guidance --- .../engagement-checklist.md | 25 +++-- .../books/02-privileged-access.md | 9 +- .../books/field-guide-2026.md | 60 ++++++++++- .../privileged-access-architecture.md | 99 +++++++++++++++++-- 4 files changed, 173 insertions(+), 20 deletions(-) diff --git a/antifragile-consulting/assessment-templates/engagement-checklist.md b/antifragile-consulting/assessment-templates/engagement-checklist.md index 6c0082a..dbca20c 100644 --- a/antifragile-consulting/assessment-templates/engagement-checklist.md +++ b/antifragile-consulting/assessment-templates/engagement-checklist.md @@ -96,7 +96,18 @@ Nothing here replaces the governing question from Book I: - `[LOOK AT]` How many Domain Admins and Enterprise Admins exist, and are they all justified with named owners? - `[ASK]` When was the privileged account list last reviewed, and by whom? -### B2. PIM / JIT +### B2. Admin workstations and management plane + +- `[ASK]` What do admins use to reach a domain controller remotely? Is that path independent of the AD it manages, or does it depend on AD for authentication? +- `[LOOK AT]` Do admins use the same device for privileged work (DC management, PIM activation) and daily tasks (email, browsing)? +- `[ASK]` Is there a dedicated admin workstation — physical PAW or cloud admin VM (Windows 365 / AVD) — that is used only for privileged tasks? +- `[LOOK AT]` If a cloud admin VM exists: is it enrolled in Intune with a hardened profile? Is it excluded from email and general browsing? Is it the device scoped in the CA policy restricting privileged role access? +- `[LOOK AT]` Is there a management overlay (Nebula, Tailscale, Headscale) providing the admin access path to on-prem Tier 0 systems? +- `[ASK]` If a Nebula T0 overlay exists: where is the CA key stored? Who can sign new node certificates? When was the last signing ceremony? +- `[ASK]` If a Tailscale T1 overlay exists: is key expiry configured? Does re-authentication require phishing-resistant MFA via Entra? +- `[LOOK AT]` For multi-cloud clients without a physical data centre: is the management plane explicitly designed, or is access to cloud management consoles and on-prem servers done ad hoc (VPN, direct RDP, per-cloud bastion, no unified plane)? + +### B3. PIM / JIT - `[LOOK AT]` Is Entra PIM deployed and enforced for Entra administrative roles? - `[LOOK AT]` Are Entra roles set to eligible (not active) by default? @@ -106,7 +117,7 @@ Nothing here replaces the governing question from Book I: - `[LOOK AT]` Is PIM alert configuration enabled (Roles activated without MFA, Redundant assignments, etc.)? - `[ASK]` For on-prem DA/EA: is there any JIT or time-limited elevation mechanism in place? -### B3. Service Accounts (On-Prem) +### B4. Service Accounts (On-Prem) - `[LOOK AT]` Are there service accounts with SPNs and static passwords older than 12 months? (Kerberoastable) - `[LOOK AT]` Which service accounts are over-permissioned (e.g., Domain Admin, local admin on all servers)? @@ -114,7 +125,7 @@ Nothing here replaces the governing question from Book I: - `[LOOK AT]` Are there service accounts nobody can identify a current owner for? - `[TEST]` Run a Kerberoast simulation: do ticket requests for service account SPNs generate any detection? -### B4. Service Principals & App Registrations (Cloud) +### B5. Service Principals & App Registrations (Cloud) - `[LOOK AT]` Which app registrations hold escalation-grade Graph permissions (application permissions): `RoleManagement.ReadWrite.Directory`, `AppRoleAssignment.ReadWrite.All`, `Application.ReadWrite.All`, `Directory.ReadWrite.All`? - `[LOOK AT]` Which app registrations have non-expiring client secrets? @@ -122,14 +133,14 @@ Nothing here replaces the governing question from Book I: - `[LOOK AT]` Which apps have tenant-wide admin consent, and is each justified and reviewed? - `[LOOK AT]` Which Azure workloads use client secrets instead of managed identities where managed identities are available? -### B5. Tier Model / Clean Source +### B6. Tier Model / Clean Source - `[LOOK AT]` Do Domain Admins / Enterprise Admins authenticate from standard workstations used for email and browsing? - `[LOOK AT]` Is ADCS (Active Directory Certificate Services) deployed? If so, is it on a Tier 0 or hardened host, or on a standard server? - `[LOOK AT]` Are there shared administrative jump boxes that cross tier boundaries (used for both Tier 0 and Tier 1 work)? - `[LOOK AT]` Do cloud admins use the same device for privileged Entra work as for daily activity? -### B6. Escalation Paths +### B7. Escalation Paths - `[LOOK AT]` Are there accounts with `GenericAll`, `WriteDACL`, or `WriteOwner` on high-value AD objects (domain root, DCs, admin groups) that are not themselves Tier 0? - `[LOOK AT]` Are there computers with unconstrained delegation enabled (excluding DCs)? @@ -137,7 +148,7 @@ Nothing here replaces the governing question from Book I: - `[LOOK AT]` Is LAPS (Windows LAPS preferred) deployed across all workstations and servers? What is the coverage percentage? - `[TEST]` Run BloodHound (or equivalent) and count attack paths to Domain Admin. Note the number as a baseline. Is it going up or down over time? -### B7. Break-Glass +### B8. Break-Glass - `[LOOK AT]` Do cloud-only break-glass Global Admin accounts exist? - `[LOOK AT]` Is phishing-resistant authentication (FIDO2 or certificate) configured on break-glass accounts? @@ -146,7 +157,7 @@ Nothing here replaces the governing question from Book I: - `[TEST]` Sign in to the break-glass account in a controlled drill. Does it work? Does the alert fire? Does someone respond? - `[ASK]` Where are the break-glass credentials stored, and can they be retrieved without the systems they recover? -### B8. Phishing-Resistant MFA for Admins +### B9. Phishing-Resistant MFA for Admins - `[LOOK AT]` What MFA method is enforced for Global Admins: FIDO2, certificate-based auth, or push/SMS? - `[LOOK AT]` Push-approve and SMS are not acceptable for administrative accounts. If they are in use, that is a P0. diff --git a/antifragile-consulting/books/02-privileged-access.md b/antifragile-consulting/books/02-privileged-access.md index a0850dd..ef77c9e 100644 --- a/antifragile-consulting/books/02-privileged-access.md +++ b/antifragile-consulting/books/02-privileged-access.md @@ -77,8 +77,9 @@ Privilege is the domain where deletion is the entire strategy. Adding "privilege **Paranoid protection for privileged work means, non-negotiably:** -- **PAWs** — privileged access workstations. All Tier 0 / Global Admin work happens from a clean, hardened, single-purpose device that never reads email or browses the web. The admin's normal laptop is Tier 2 and stays there. -- **Phishing-resistant MFA only** for admins — FIDO2 / passkeys / certificate- based. SMS and push-approve are not admin-grade; they're phishable, and admins are the phishing prize. +- **PAWs — the principle and the practical reality.** The principle: all Tier 0 / Global Admin work from a clean, hardened, single-purpose device that never reads email or browses the web. The admin's normal laptop is Tier 2. This is right. The practical reality: physical PAWs almost never get deployed. The hardware procurement, the second device on the desk, the behaviour change — all of it defeats the project before it starts. The deployable alternative that preserves the essential properties is a **cloud-hosted admin workstation** — a Windows 365 or Azure Virtual Desktop VM provisioned from a hardened template, enrolled in the management overlay, used only for privileged tasks. The admin connects from their normal device via browser or RDP. Privileged credentials live in the cloud VM, not on the admin's local device. If the VM is compromised: wipe it, reprovision from template in 20 minutes. The security property is the same — credentials isolated from the daily-use device — without the hardware problem. This is the practical PAW. Recommend it before recommending a dedicated physical device; it will actually get deployed. +- **The management overlay** connects the admin workstation (cloud VM or physical PAW) to the systems it manages without exposing those systems to the general network. The T0/T1 split matters here and maps directly to the tier model: T0 systems (DCs, ADCS, sync server) get an overlay with no external runtime dependency (Nebula with pre-distributed certificates); T1 systems (member servers, cloud workloads, multi-cloud resources) get an overlay with identity-aware access and per-session MFA (Tailscale with Entra OIDC). The realistic T0 node count for a 5,000-person organisation is 15–25 nodes — small enough to manage with a documented certificate ceremony and a spreadsheet, not a full PKI team. The management overlay is what makes remote and hybrid admin work possible without either a traditional VPN's flat-network problem or physical-presence-only access. +- **Phishing-resistant MFA only** for admins — FIDO2 / passkeys / certificate-based. SMS and push-approve are not admin-grade; they're phishable, and admins are the phishing prize. For the management overlay, this means Tailscale configured with key expiry and an Entra OIDC IdP enforcing FIDO2 — so the WireGuard device trust and a per-session identity assertion are both present, not just the device key. - **Separate, cloud-only privileged identities** for cloud admin (the Book II firebreak, enforced here). On-prem admin identity must not be the cloud admin identity. - **JIT for everything** via PIM: eligible-not-active, time-boxed, MFA on activation, justification logged, and **approval workflow on the crown roles**. - **Conditional Access scoped to admins** — privileged roles usable only from PAWs / compliant devices / named locations. @@ -116,6 +117,8 @@ Stable and Lindy (teach with confidence): standing privilege is the core risk; t What moves, and what you must verify against current Microsoft documentation: +- **The management overlay pattern** (covered in §3 above) is stable in principle — the T0/T1 split, the clean-source reasoning for isolating the management plane, the cloud admin VM as the deployable PAW substitute. What moves: the specific tooling. Nebula's CA and ACL model, Tailscale's per-session MFA configuration and OIDC integration, and the Windows 365 / AVD provisioning model all evolve. Verify current implementation guidance before deploying, and confirm Tailscale's key-expiry and IdP enforcement behaviour is still available as described. + - **PIM capabilities, role definitions, and the risk classification of specific Graph permissions** evolve continually. Confirm which scopes are escalation-grade *today* rather than trusting a 2026 list. - **On-prem JIT/PAM tooling is genuinely weaker and more fragmented than the cloud story.** Native time-bound group membership, MIM PAM, and third-party PAM all have trade-offs that shift. Don't promise a client a clean AD-native JIT experience without checking current reality — and be honest that on-prem eligibility is harder than PIM makes cloud look. - **gMSA vs dMSA.** gMSA is the established, Lindy answer for managed service accounts. **dMSA** (delegated managed service accounts, introduced with the Windows Server 2025 generation) targets the real gap — migrating a standing service account and disabling the original — but newer mechanisms carry newer attack surface, and there has been published privilege-escalation research against the dMSA migration path. **Verify current patch and hardening guidance before you recommend dMSA**; this is exactly the kind of new-and-shiny that Book I principle 8 warns about. gMSA until you've checked dMSA's current state. @@ -136,6 +139,8 @@ If a client's safety hinges on a current specific, look it up and cite it. "I ne - Is ADCS treated as Tier 0? When was KRBTGT last rotated? Is LAPS deployed? - Break-glass: does it exist, is it monitored to scream on use, and when was it last *tested* — not created, tested? - How many paths to Domain Admin / Global Admin exist right now, and is that number going up or down? +- What does an admin use to reach a domain controller remotely — and if that path is compromised, what does the attacker get? Is the management access path independent of the estate it manages? +- Are privileged credentials ever typed into or stored on a device that is also used for email and browsing? If yes, the session isolation that PAWs are meant to provide does not exist, regardless of what the policy says. --- diff --git a/antifragile-consulting/books/field-guide-2026.md b/antifragile-consulting/books/field-guide-2026.md index b03658e..c82beeb 100644 --- a/antifragile-consulting/books/field-guide-2026.md +++ b/antifragile-consulting/books/field-guide-2026.md @@ -221,11 +221,65 @@ ADCS is Tier 0. It sits on whatever server it runs on, and that server should ha --- -### Privileged Access Workstations — scope the conversation honestly +### Admin workstations — the cloud VM is the deployable PAW -PAWs are right in principle. In 2026, the practical conversation with most mid-market clients is: **dedicated devices for Tier 0 administration** (Global Admins and Domain Admins use a separate machine for those tasks, even if that machine is just a hardened Windows device or a VM they launch for admin work). +Physical PAWs are right in principle and almost never get deployed. Hardware procurement, second device, behaviour change — the project does not survive contact with a real IT budget. Do not open the conversation with "you need a dedicated PAW laptop." Open it with the cloud admin VM. -The minimum viable version: a dedicated Intune-enrolled, Entra-joined device with no email, no browser for general use, and a Conditional Access policy that restricts Global Admin and Domain Admin-equivalent activity to that device only. Not perfect PAW architecture but a massive improvement over "I use my laptop for everything." +**The cloud admin VM:** a Windows 365 or Azure Virtual Desktop instance provisioned from a hardened template. The admin connects from their normal device via browser or RDP. Privileged credentials — including WireGuard keys for the management overlay — live in the cloud VM, not on the admin's local device. Compromise response: wipe it, reprovision from template in under 20 minutes. + +**Provisioning the cloud admin VM:** +1. Create a Windows 365 or AVD instance from a hardened base image (CIS L2 baseline or equivalent) +2. Enrol in Intune, apply a configuration profile: no internet browsing, no personal email, no Microsoft Store apps, screen lock on idle, BitLocker enforced +3. Scope a CA policy restricting Global Admin and privileged role activation to this device (device compliance + named Intune group) +4. Install the Nebula client (if deploying T0 overlay) and distribute the pre-signed node certificate +5. Install the Tailscale client (if deploying T1 overlay) and enrol with the Entra OIDC identity + +**Minimum viable without the overlay:** a dedicated Intune-enrolled, Entra-joined cloud VM with no email and no general browsing, and a CA policy restricting GA activation to it. Not perfect, but it will actually get deployed and maintained. + +--- + +### Management overlay — Nebula for T0, Tailscale for T1 + +**When a client needs this:** SME and mid-market clients with multi-cloud resources, DevOps workloads, or remote admins — and no physical data centre with a proper management VLAN. The overlay builds the management plane that the physical network cannot provide. + +**When a client does not need this:** organisations with their own data centres and physical network infrastructure already in place. Traditional management VLAN segmentation plus jump boxes is the right answer there. Adding an overlay creates a new Tier 0 component without proportional benefit. + +**The T0 overlay — Nebula:** + +Nebula has no coordinator in the runtime path. Once certificates are distributed, the overlay runs with zero external dependencies. This is the right property for T0: a compromised or unavailable external service cannot affect access to your domain controllers. + +Deployment steps: +1. Provision the Nebula CA on a dedicated air-gapped machine (a dedicated laptop that is never networked, or a cheap PC kept in a drawer) +2. Generate and sign node certificates for each T0 node (DCs, sync server, ADCS, cloud admin VMs/PAWs) +3. Distribute the signed certificates and the CA certificate to each node +4. Configure the Nebula ACL policy: cloud admin VMs can reach DCs on port 3389 (RDP) and 5985/5986 (WinRM); nothing else. DCs do not reach each other through Nebula (they have their own replication channel) +5. Start the Nebula service on each node. Test connectivity from the cloud admin VM to a DC +6. Document the CA signing ceremony: who can sign new certs, what approval is needed, where the CA key is stored, how to revoke (distribute updated blocklist to all nodes) + +**Realistic T0 node count:** 15–25 nodes for a 5,000-person organisation. Certificate management is a documented ceremony run a few times a year, not an ongoing operational burden. + +**The T1 overlay — Tailscale:** + +Tailscale with Entra OIDC + key expiry gives you device trust (WireGuard node key) plus per-session identity assertion (Entra MFA on re-authentication). Configure key expiry to force re-authentication on a schedule aligned with the session risk tolerance (8–24 hours for admin access). + +Deployment steps: +1. Create a Tailscale account or deploy Headscale (for sovereign requirements) +2. Configure the OIDC integration with Entra ID. Set the MFA requirement to phishing-resistant (FIDO2) in the Entra Conditional Access policy that governs Tailscale authentication +3. Set key expiry: 8–24 hours for admin nodes, 24–72 hours for standard nodes +4. Define ACL policy: cloud admin VMs reach T1 servers on management ports only; standard user devices do not appear in the T1 ACL +5. Enrol cloud admin VMs as nodes. Enrol T1 servers (member servers, cloud management hosts, K8s API server endpoints) +6. Test: attempt to reach a T1 server from a non-enrolled device. Expected: no route. From an enrolled cloud admin VM: connected + +**What Tailscale carries for multi-cloud:** kubectl access to K8s clusters, SSH/RDP to member servers and cloud VMs, cloud CLI access where the management API is behind a private endpoint. It does not carry M365 admin traffic — that goes direct to Microsoft over the internet, gated by Conditional Access. + +**The Nebula CA — the one critical operation:** + +The CA key is the trust anchor for the entire T0 overlay. Its compromise means an attacker can enrol their own node and grant it access to every DC. Treat it accordingly: +- Air-gapped machine, never networked after initial setup +- CA key encrypted at rest on the machine and backed up separately +- Certificate lifetime: 180 days maximum, so non-renewal handles most revocation cases +- Revocation: generate and distribute an updated `blocklist.pem` to all nodes if a PAW is lost or an admin departs before cert expiry +- At least two named people who know the ceremony and can perform it --- diff --git a/antifragile-consulting/playbooks/privileged-access-architecture.md b/antifragile-consulting/playbooks/privileged-access-architecture.md index 78b334f..0cc23a2 100644 --- a/antifragile-consulting/playbooks/privileged-access-architecture.md +++ b/antifragile-consulting/playbooks/privileged-access-architecture.md @@ -17,6 +17,51 @@ The antifragile answer is a two-layer architecture: **network access** (Tailscal --- +## When overlay management networks help — and when they don't + +**Enterprises with their own data centres** already have the physical substrate for a proper management network: dedicated VLANs, hardware segmentation, jump boxes. Adding an overlay management network introduces a new Tier 0 component (the coordinator) on top of infrastructure that already solves the problem. The complexity cost outweighs the benefit. Traditional management VLAN segmentation, done properly, is the right answer. + +**SME clients with multi-cloud resources, containers, and DevOps workloads** have a different problem: there is no physical network to segment. Resources are scattered across Azure, AWS, a colo, and maybe on-prem. The management plane does not exist yet — you are building it. An overlay is how you build it, and it is the right answer for this context. + +**The T0/T1 split** — applying the tier model to the overlay itself: + +- **T0 systems** (domain controllers, ADCS, Entra Connect sync server — the identity control plane): use **Nebula**. No coordinator in the runtime path — once certificates are distributed, the overlay functions with zero external dependencies. The Nebula CA is the only Tier 0 component, and it can be kept offline. This means no coordinator to compromise, no external API call, no cloud service availability dependency for reaching your most critical systems. +- **T1 systems** (member servers, cloud workloads, Kubernetes clusters, multi-cloud management): use **Tailscale** (or Headscale for sovereign requirements). Per-node ACLs, Entra OIDC integration, per-session MFA via key expiry and IdP enforcement. The coordinator trust concern is more acceptable at T1 — a compromised coordinator affects T1 access, not T0. + +**The T0 node count is not scary.** For a 5,000-person organisation, the realistic T0 Nebula population is: + +| Component | Count | +|-----------|-------| +| Domain Controllers | 4–8 | +| Entra Connect / Cloud Sync server | 1–2 | +| ADCS issuing CA | 1–2 | +| AD FS servers (if not yet removed) | 0–4 | +| Cloud admin VMs / PAWs | 5–10 | +| **Total** | **~15–25 nodes** | + +Certificate management for 15–25 nodes is a documented procedure, not an operational burden. The CA signing ceremony happens a few times a year when a PAW is replaced or an admin leaves. This is tractable. + +--- + +## The PAW problem and the cloud admin VM + +Physical PAWs are the right principle. They almost never get deployed. Hardware procurement, second device on the desk, behaviour change — the project dies before it starts. + +The **cloud-hosted admin workstation** preserves the essential security properties without the hardware problem: + +- A Windows 365 or Azure Virtual Desktop VM provisioned from a hardened template +- Used only for privileged tasks (no email, no general browsing) +- Connected to the Nebula T0 overlay (for DC access) and Tailscale T1 overlay (for server/cloud access) +- Accessed by the admin from their normal device via browser or RDP client +- Privileged credentials live in the cloud VM, not on the admin's local device +- Compromise response: wipe the VM, reprovision from template in 20 minutes + +The security property that matters — privileged credentials do not touch the device used for email and browsing — is preserved. An attacker who compromises the admin's local device gets a browser session to a cloud VM that requires phishing-resistant MFA to reach. They do not get cached credentials, session tokens, or WireGuard keys for the management overlay. + +**When to use a physical PAW instead:** clients with a strong security culture and genuine appetite for the operational overhead, OT/ICS environments where the management workstation may need to be air-gapped, or engagements where the threat model includes a sophisticated attacker who would attempt to compromise the RDP session interactively. + +--- + ## The Two Layers ### Layer 1: Network Access — Tailscale / Headscale + WireGuard @@ -130,6 +175,30 @@ This catches more clients than it appears. A manufacturing company with 800 empl --- +### Nebula — T0 Management Overlay + +| Attribute | Detail | +|-----------|--------| +| **What it does** | WireGuard-based overlay mesh with no coordinator in the runtime path. Nodes authenticate via pre-distributed certificates signed by a local CA. Lighthouse nodes handle NAT traversal only — they are not in the authentication path. | +| **Why it is right for T0** | No external runtime dependency. A compromised or unavailable coordinator cannot affect T0 access. The CA (the actual trust anchor) can be kept offline and brought up only for certificate issuance. | +| **Trade-off vs Tailscale** | No dynamic node management (adding/removing a node requires a CA operation and cert redistribution); no cloud-managed control plane; higher initial setup complexity; certificate revocation requires distributing an updated blocklist | +| **Why the trade-off is acceptable for T0** | T0 node population is small (15–25 nodes) and stable. Revocation events (lost PAW, departing admin) are rare and known immediately. The operational overhead is a documented ceremony run a few times a year, not a recurring burden. | +| **Antifragile pillar** | Structural Decoupling, Sovereign Intelligence | +| **When to deploy** | T0 systems (DCs, sync server, ADCS) in any estate; air-gapped or restricted environments; clients where the management plane must have zero external runtime dependencies | + +**Nebula CA management — the one non-trivial operation:** + +The Nebula CA private key is the trust anchor for the entire T0 overlay. It must be treated accordingly: +- Air-gapped machine (a dedicated laptop that is never networked, or a hardware security module) +- Documented signing ceremony: who is authorised to sign a new certificate, what approval is required, what the procedure is +- Named individuals (minimum two) who know the procedure and can perform it +- CA key backup: encrypted, stored separately from the signing machine, tested +- Short certificate lifetimes (90–180 days) so revocation is handled implicitly by non-renewal as much as by explicit blocklist distribution + +This is the same discipline as an offline root CA — because that is functionally what it is. + +--- + ### Smallstep — Certificate-Based SSH Access | Attribute | Detail | @@ -145,20 +214,34 @@ This catches more clients than it appears. A manufacturing company with 800 empl ## The Decision Framework ``` -Does the client have legacy VPN sprawl or flat-network vendor access? -├── YES → Deploy Layer 1 (network access) first -│ ├── Wants managed service + commercial support → Tailscale (partnership) +Does the client have their own data centre with physical network infrastructure? +├── YES → Traditional management VLAN segmentation + jump box +│ Overlay adds complexity without proportional benefit here +└── NO / Multi-cloud / Scattered resources → Overlay is the right management plane + +Does the client need a T0 management overlay (DC, ADCS, sync server access)? +├── YES → Nebula (no external runtime dependency, CA offline) +│ └── Admin workstation: cloud admin VM (W365/AVD) or physical PAW, enrolled in Nebula +│ +Does the client need a T1 overlay (servers, cloud workloads, K8s, DevOps)? +├── YES → Layer 1 (network access) +│ ├── Wants managed service + commercial support → Tailscale + Entra OIDC + key expiry MFA │ └── Wants full sovereignty / data residency → Headscale + WireGuard │ Does the client need protocol-aware session recording / JIT / DB access? ├── YES → Add Layer 2 (PAM) │ ├── < 100 employees AND < $10M revenue → Teleport CE (free, self-hosted) -│ ├── Larger org / needs support → Teleport Enterprise (commercial) -│ └── SSH-only, budget-constrained → Smallstep (certificates only) +│ ├── Larger org / needs support → Teleport Enterprise (commercial, verify current pricing) +│ └── SSH-only, budget-constrained → Smallstep (certificates only, no session recording) │ -Does the client need both layers? -├── MOST CLIENTS → Tailscale (network) + Teleport CE/Enterprise (PAM) -└── OT/CRITICAL INFRA → Headscale (sovereign network) + Teleport (recorded vendor access) +Typical SME multi-cloud client: +├── T0: Nebula + cloud admin VMs +├── T1: Tailscale + Entra OIDC +└── Session recording: Teleport CE if eligible, otherwise accept the gap and compensate with + cloud VM audit logging and Tailscale connection logs + +OT / Critical infrastructure: +└── Headscale (sovereign T1) + Nebula (T0 where applicable) + Teleport (vendor session recording) ``` ---