Zero Trust Architecture
Brief Summary
Zero Trust (ZT) is a security model in which the network perimeter is no longer considered a trusted zone. Each request (user→app, service→service, device→network) is explicitly authenticated, authorized and encrypted, taking into account contextual signals (identity, device state, location, risk, behavior). The goal is to minimize blast radius, reduce the risk of lateral movement and simplify compliance.
Zero Trust fundamentals
1. No explicit trust - trust is not inherited from the/VPN/ASN network.
2. Access is the minimum necessary: the policy "to provide only what is needed now."
3. Continuous verification: sessions and tokens are regularly reassessed for risk and context.
4. Assumption of compromise: segmentation, observability, rapid containment and key rotations.
5. Encryption everywhere: TLS 1. 2+/1. 3 and mTLS inside data plans, protected DNS, secrets in KMS/HSM.
Target landscape and control domains
Identity: humans (IdP: SSO, MFA, passkeys/FIDO2), machines (SPIFFE/SVID, x509/mTLS).
Devices: compliance with policies (MDM/EDR, disk encrypted, patches, jailbreak/root - prohibited).
Network: L3/L7 microsegmentation, ZTNA/SDP gateways, service mesh (Envoy/Istio/Linkerd).
Applications/APIs: mTLS, OIDC/JWT, request signatures (HMAC), rate limits, DLP/masking.
Data: classification (Public/Confidential/Restricted), tokenization/encryption at the field level.
Observability: centralized authentication/authorization logs, behavioral analytics, SLO/SLA.
Reference architecture (broken down by planes)
Control Plane: IdP/CIAM, PDP/PEP (OPA/Envoy), policy catalogs, PKI/CA, device qualification.
Data Plane: proxy access (ZTNA), sidecar proxy (Envoy) for mTLS and L7 policy, GW service gateways/APIs.
Management Plane: service catalog, CMDB, CI/CD, secret management (Vault/KMS), centralized audit.
1. Identification (SSO + phishing-resistant MFA) → 2) Device assessment (MDM posture) → 3) ZTNA proxy establishes mTLS to application → 4) PDP (policies) makes decision based on attributes (ABAC/RBAC) → 5) continuous risk reassessment (time, geo, anomalies).
Identity and authorization
IdP/SSO: OIDC/SAML, default MFA, preferably FIDO2 (passkeys).
RBAC/ABAC: roles + context attributes (device status, department, risk profile).
Just-In-Time (JIT) access: temporary privileges with automatic revocation; break-glass - strictly regulated.
mTLS for machines: SPIFFE/SVID or internal PKI with short-lived certificates; automatic rotary release.
Devices and Context
posture: OS/EDR version, included disk-encryption, firewall; non-compliant → minimum access or block.
Attestation: device identity + signed attestations (MDM/Endpoint).
Network restrictions: block of third-party tunnels, forced corporate DNS, protection against DNS/WebRTC leaks.
Networking and microsegmentation
Discarding "flat" VLANs: instead, segments/VRF and policy on L7.
Service Mesh: sidecar proxies provide mTLS, policy authorization (OPA/EnvoyFilter), telemetry.
ZTNA/SDP: access to a specific application, not to the network; kliyent↔broker↔app, policy in PDP.
Remote Access: replacing the "thick" VPN with an app proxy; fallback tunnels are restricted to routes/ports.
Policies and solution engine
PDP/PEP: Policy Decision Point (OPA/Styra, Cedar и пр.) + Policy Enforcement Point (Envoy/Istio/Gateway).
Policy model: declarative rules (Rego/Cedar), static and contextual attributes, risk assessment.
rego package access. http
default allow = false
allow {
input. user. role == "support"
input. request. path == "/admin/tickets"
input. device. compliant == true time. now_hh >= 8 time. now_hh <= 20
}Trace solutions: log 'input '/' result '/' explain' for audit.
Default encryption and trust
TLS 1. 2+/1. 3 everywhere, strict cipher suites, HSTS, OCSP stapling.
mTLS inside: servis↔servis only by mutual certificates; short-term keys (hours/days).
Secrets: KMS/HSM, dynamic secrets (Vault), short TTL, least-privilege for applications.
Observability, SLO and response
Metrics (minimum set):- Authentication and authorization success (%), p95 PDP decision time, p95 TLS-handshake.
- Percentage of requests blocked by policy (anomalies/false).
- Availability of ZTNA brokers and Mesh controller.
- Proportion of compliant devices and trends.
- "ZTNA ≥ 99 availability. 95 %/month; p95 authZ decision ≤ 50 мс».
- "The percentage of requests with mTLS ≥ 99. 9%».
- "Not more than 0. 1% false access failures/day."
Alarting: bursts of deny, degradation of p95 handshakes, invalid chains, drop in the proportion of compliant devices, geography anomalies/ASN.
Moving from perimeter to Zero Trust: a road map
1. Inventory: applications, data flows, consumers, sensitivity (PII/card/payouts).
2. Identity and MFA: SSO and phishing-resistant MFA for all.
3. Device context: MDM/EDR, basic compliance policies, non-compliant block.
4. Microsegmentation of priority paths: payments, back office, admin; Enter mTLS.
5. ZTNA for user access: publishing applications through a proxy, remove the "wide VPN."
6. ABAC policies: centralized PDP, declarative rules, audit.
7. Service mesh extension: S2S mTLS, L7 policy, telemetry.
8. Automation and SLO: alert, policy tests (political CI), game days "what if IdP is not available? ».
Specificity for iGaming/fintech
Rigid domain segmentation: payments/PII/anti-fraud/content - separate perimeters and policies; access only over ZTNA.
Interaction with PSP/banks: allow-list by ASN/ranges, mTLS to PSP-endpoints, Time-to-Wallet monitoring and authZ failures.
Content providers and partners: temporary JIT API accesses, short TTL tokens, integration audits.
Compliance: PCI DSS/GDPR - data minimization, DLP/pseudonymization, logging of accesses to sensitive tables.
Supply Chain Security and CI/CD
Artifact signatures (SLSA/Provenance): container signatures (cosign), Admission policy in K8s.
SBOM and vulnerabilities: SBOM generation (CycloneDX), policy-gate in pipeline.
Secrets in CI: OIDC Federation to Cloud KMS; prohibition on static keys.
Rotations: frequent, automatic; forced revoke on incidents.
Common bugs and anti-patterns
"ZTNA = new VPN": publishing a network instead of applications is not Zero Trust.
No device check: MFA is, but infected/rooted devices gain access.
Single super user: lack of JIT and separate roles.
Policies in service code: central audit/update not possible.
mTLS partial: part of services without mTLS → a "leaky" loop.
Zero UX: redundant MFA requests, no SSO; result - resistance to commands.
Mini-guide for choosing technologies
User access: ZTNA/SDP broker + IdP (OIDC, FIDO2 MFA).
In-service security: service-mesh (Istio/Linkerd) + OPA/Envoy authZ.
PKI: SPIFFE/SVID or Vault PKI with short TTL.
Politicians: OPA/Rego or Cedar; store in Git, check in CI (policy-tests).
Logs and telemetry: OpenTelemetry → centralized analysis, anomaly detection.
Sample configurations (fragments)
Envoy (mutual-TLS between services)
yaml static_resources:
listeners:
- name: listener_https filter_chains:
- filters:
- name: envoy. filters. network. http_connection_manager typed_config:
"@type": type. googleapis. com/envoy. extensions. filters. network. http_connection_manager. v3. HttpConnectionManager route_config: { name: local_route, virtual_hosts: [] }
transport_socket:
name: envoy. transport_sockets. tls typed_config:
"@type": type. googleapis. com/envoy. extensions. transport_sockets. tls. v3. DownstreamTlsContext common_tls_context:
tls_params: { tls_minimum_protocol_version: TLSv1_2 }
tls_certificates:
- certificate_chain: { filename: /certs/tls. crt }
private_key: { filename: /certs/tls. key }
validation_context:
trusted_ca: { filename: /certs/ca. crt }
require_signed_certificate: trueOPA/Rego: access to reports only from "finance," from compliant devices, during working hours
rego package policy. reports
default allow = false
allow {
input. user. dept == "finance"
input. device. compliant == true input. resource == "reports/profit"
time. now_hh >= 8 time. now_hh <= 21
}Zero Trust Implementation Checklist
1. Enable SSO and FIDO2 MFA for all users and admins.
2. Enter device posture (MDM/EDR) with non-compliant lock.
3. Transfer user access to ZTNA (per-app), leave VPN only for narrow S2S channels.
4. Inside - mTLS by default + short-lived certificates.
5. Centralize policies (PDP/OPA), store in Git, test in CI.
6. Segment sensitive domains (payments/PII/back office) and restrict east-west.
7. Set up telemetry, SLO and alert on auth/authZ, mTLS share, posture signals.
8. Conduct "game days" (IdP failure, key leak, broker drop) and fix SOPs/rollbacks.
FAQ
Is Zero Trust replacing VPN entirely?
For user access - yes, in favor of ZTNA. For S2S trunks, VPN/IPsec may remain, but with mTLS over and strict policies.
Could ZT make UX worse?
If thoughtlessly. With SSO + FIDO2, adaptive MFA, and per-app access, UX typically improves.
Is it necessary to introduce a service mesh?
Not always. But for a large microservice environment, mesh radically simplifies mTLS/policy/telemetry.
Total
Zero Trust is not a product but an architectural discipline: identity as a new perimeter, device context, application access (ZTNA), microsegmentation and mTLS everywhere, centralized policies and measurable reliability. By following the roadmap and checklist, you will reduce the attack surface, speed up auditing and gain sustainable security without "default trust."