Zero Trust arxitekturasi

Qisqacha xulosa

Zero Trust (ZT) - bu xavfsizlik modeli bo’lib, unda tarmoq perimetri endi ishonchli hudud hisoblanmaydi. Har bir so’rov (user → app, service → service, device → network) kontekstli signallarni (identifikatsiya, qurilmaning holati, joylashuvi, xavfi, xulq-atvori) hisobga olgan holda aniq autentifikatsiya, avtorizatsiya va shifrlashdan o’tadi. Maqsad blast radiusni minimallashtirish, lateral harakat xavfini kamaytirish va komplayensni soddalashtirishdir.

Zero Trustning bazaviy prinsiplari

1. Aniq ishonch yo’q: ishonch/VPN/ASN tarmog’idan meros qilib olinmaydi.
2. Kirish minimal darajada zarur: «faqat hozir kerak bo’lgan narsalarni taqdim etish» siyosati.
3. Uzluksiz tekshirish: sessiyalar va tokenlarni xavf va kontekstga qarab muntazam ravishda ortiqcha baholash.
4. Kompromsatsiya taxminlari: segmentatsiya, kuzatish, tezkor kontainment va kalitlar rotatsiyasi.
5. Hamma joyda shifrlash: TLS 1. 2+/1. 3 va mTLS data-planes ichida, DNS himoyalangan, KMS/HSM sirlari.

Maqsadli landshaft va nazorat domenlari

Identifikatsiyasi: odamlar (IdP: SSO, MFA, passkeys/FIDO2), mashinalar (SPIFFE/SVID, x509/mTLS).
Qurilmalar: siyosatga muvofiqlik (MDM/EDR, disk shifrlangan, patchlar, jailbreak/root - taqiqlangan).
Tarmoq: mikrosegmentatsiya L3/L7, ZTNA/SDP-shlyuzlar, servis-mesh (Envoy/Istio/Linkerd).
Ilovalar/API: mTLS, OIDC/JWT, soʻrov imzolari (HMAC), rate limits, DLP/niqoblash.
Maʼlumotlar: (Public/Confidential/Restricted) tasnifi, tokenlash/shifrlash.
Kuzatish darajasi: markazlashtirilgan autentifikatsiya/avtorizatsiya loglari, xulq-atvor tahlili, SLO/SLA.

Referens arxitektura (tekisliklar kesimida)

Control Plane: IdP/CIAM, PDP/PEP (OPA/Envoy), siyosatchilar kataloglari, PKI/CA, qurilmalarni attestatsiyadan o’tkazish.
Data Plane: proksi-kirish (ZTNA), mTLS uchun sidecar-proksi (Envoy) va L7 siyosati, servis shlyuzlari/GW API.
Management Plane: Services katalogi, CMDB, CI/CD, maxfiy menejment (Vault/KMS), markazlashtirilgan audit.

Soʻrov oqimi (user → app):

1. Identifikatsiya (SSO + phishing-resistant MFA) → 2) Qurilmani baholash (MDM posture) → 3) ZTNA-proksi ilovaga mTLS o’rnatadi → 4) PDP (siyosatlar) atributlar asosida qaror qabul qiladi (ABAC/RBAC) → 5) uzluksiz tavakkalchilikni qayta baholash (vaqt, geo, anomaliyalar).

Identifikatsiya va avtorizatsiya

IdP/SSO: OIDC/SAML, MFA andoza, afzal FIDO2 (passkeys).
RBAC/ABAC: rollar + kontekst atributlari (qurilma maqomi, bo’lim, xavf-profil).
Just-In-Time (JIT) kirish: avtomatik chaqirib olish bilan vaqtinchalik imtiyozlar; break-glass - qat’iy tartibga solingan.
mTLS mashinalar uchun: SPIFFE/SVID yoki ichki PKI qisqa yashovchi sertifikatlar bilan; avtomatik rotatsion ishlab chiqarish.

Qurilmalar va kontekst

Moslikni tekshirish (posture): OS/EDR versiyasi, disk-enkript yoqilgan, firewall; non-compliant → minimal yoki blok.
Attestatsiya: device identity + signed attestations (MDM/Endpoint).
Tarmoq cheklovlari: uchinchi tomon tunnellari bloki, majburiy korporativ DNS, DNS/WebRTC sizib chiqishlaridan himoya qilish.

Tarmoq va mikrosegmentatsiya

«Yassi» VLAN dan voz kechish: uning o’rniga - segmentlar/VRF va L7 siyosati.
Service Mesh: sidecar-proksi mTLS, siyosat bo’yicha avtorizatsiya (OPA/EnvoyFilter), telemetriyani ta’minlaydi.
ZTNA/SDP: tarmoqqa emas, aniq dasturga kirish; mijoz broker, PDPdagi siyosat.
Remote Access: «qalin» VPNni app-proksi bilan almashtirish; fallback-tunnellar yo’nalishlar/portlar bo’yicha cheklangan.

Siyosat va yechimlar dvigateli

PDP/PEP: Policy Decision Point (OPA/Styra, Cedar и пр.) + Policy Enforcement Point (Envoy/Istio/Gateway).
Siyosat modeli: deklarativ qoidalar (Rego/Cedar), statik va kontekst atributlar, tavakkalchilikni baholash.

Rego misoli (soddalashtirilgan):

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
}

Yechimlarning izlanishi: audit uchun’input ’/’ result ’/’ explain’logini kiriting.

Shifrlash va andoza ishonch

TLS 1. 2+/1. 3 hamma joyda, qat’iy shifrlangan, HSTS, OCSP stapling.
mTLS ichida: faqat o’zaro sertifikatlar bo’yicha xizmat; qisqa yashaydigan kalitlar (soat/kun).
Sirlar: KMS/HSM, dynamic secrets (Vault), qisqa TTL, ilovalar uchun least-privilege.

Kuzatish, SLO va javob berish

Metrika (minimal):

Autentifikatsiya va avtorizatsiya muvaffaqiyati (%), PDP qarorini qabul qilish vaqti p95, TLS-handshake p95.
Siyosat tomonidan bloklangan soʻrovlar foizi (anomaliyalar/soxta).
ZTNA brokerlari va Mesh-kontrollerning mavjudligi.
Kompliant qurilmalar va trendlar ulushi.

SLO (misollar):

"ZTNA ≥ 99. 95 %/oy; p95 authZ decision ≤ 50 мс».
"mTLS bilan so’rovlar ulushi ≥ 99. 9%».
"0 dan ortiq emas. 1 %/sutka foydalanishda yolg’on rad etish".

Alarting: deny portlashlari, qo’l siqish p95 tanazzullari, nevalid zanjirlari, compliant qurilmalar ulushining pasayishi, geografiya anomaliyalari/ASN.

Perimetrdan Zero Trustga oʻtish: yoʻl xaritasi

1. Inventarizatsiya: ilovalar, ma’lumotlar oqimi, iste’molchilar, sezgirlik (PII/kartochka/to’lovlar).
2. Identifikatsiya va MFA: SSO va phishing-resistant MFA hamma uchun.
3. Moslamalar konteksti: MDM/EDR, asosiy muvofiqlik siyosati, non-compliant bloki.
4. Ustuvor yo’llar mikrosegmentatsiyasi: to’lovlar, bek-ofis, ma’muriyat; mTLSni kiritish.
5. Foydalanuvchilar uchun ZTNA: ilovalarni proksi orqali chop etish, «keng VPN» ni olib tashlash.
6. ABAC siyosati: markazlashtirilgan PDP, deklarativ qoidalar, audit.
7. Servis-meshga kengaytirish: S2S mTLS, L7 siyosati, telemetriya.
8. Avtomatlashtirish va SLO: alerting, siyosat testlari (CI), o’yin kunlari "agar IdP mavjud bo’lmasa nima bo’ladi? ».

iGaming/fintech uchun xususiyatlar

Domenlarning qatʼiy segmentlanishi: toʻlovlar/PII/antifrod/kontent - alohida perimetrlar va siyosatlar; faqat ZTNA orqali kirish.
PSP/banklar bilan o’zaro hamkorlik: ASN/diapazonlar bo’yicha allow-list, PSP-endpointlarga mTLS, Time-to-Wallet monitoringi va authZ-dagi nosozliklar.
Kontent yetkazib beruvchilar va hamkorlar: vaqtinchalik JIT kirish, qisqa TTL tokenlari, integratsiya auditi.
Komplayens: PCI DSS/GDPR - ma’lumotlarni minimallashtirish, DLP/taxalluslashtirish, sezgir jadvallarga kirishni jurnallash.

Yetkazib berish zanjirlari va CI/CD xavfsizligi

Artefaktlar imzosi (SLSA/Provenance): konteyner imzosi (cosign), K8s Admission siyosati.
SBOM va zaifliklar: payplaynda SBOM (CycloneDX), policy-gate generatsiyasi.
CI sirlari: OIDC - bulutli KMS uchun federatsiya; statik kalitlarni taqiqlash.
Rotatsiyalar: tez-tez, avtomatik; hodisalarda majburiy revoke.

Tipik xatolar va anti-patternlar

«ZTNA = yangi VPN»: ilovalar o’rniga tarmoqni nashr etish - Zero Trust emas.
Moslamalar tekshirilmadi: MFA mavjud, ammo zararlangan/rutlangan moslamalar kirish huquqiga ega.
Yagona super foydalanuvchi: JIT va alohida rollarning yo’qligi.
Servislar kodidagi siyosat: markazlashtirilgan audit/yangilanishning imkoni yo’qligi.
mTLS qisman: mTLS’siz xizmatlarning bir qismi → «teshik» kontur.
Nol UX: MFAning ortiqcha so’rovlari, SSO yo’qligi; natija - jamoalarga qarshilik.

Texnologiyalarni tanlash bo’yicha mini-gidlar

Foydalanuvchilar: ZTNA/SDP brokeri + IdP (OIDC, FIDO2 MFA).
Xizmat ichidagi xavfsizlik: servis-mesh (Istio/Linkerd) + OPA/Envoy authZ.
PKI: SPIFFE/SVID yoki Vault PKI qisqa TTL bilan.
Siyosati: OPA/Rego yoki Cedar; Gitda saqlash, CI (policy-tests) da tekshirish.
Logi va telemetriya: OpenTelemetry → markazlashtirilgan tahlil, anomaliyalar detekti.

Konfiguratsiya namunalari (parchalar)

Envoy (servislar o’rtasida myutal-TLS)

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: true

OPA/Rego: hisobotlarga faqat «finance» dan, compliant-qurilmalardan, ish soatlarida kirish

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 joriy etish chek-varaqasi

1. Barcha foydalanuvchilar va boshqaruvchilar uchun SSO va MFA FIDO2 yoqish.
2. Non-compliant bloklangan device posture (MDM/EDR) ni kiritish.
3. Foydalanuvchini ZTNA (per-app) ga oʻtkazish, VPNni faqat tor S2S kanallari uchun qoldirish.
4. Ichida - mTLS andoza + qisqa umr koʻradigan sertifikatlar.
5. Siyosatni markazlashtirish (PDP/OPA), Git’da saqlash, CI’da sinash.
6. Sezgir domenlarni segmentlash (to’lovlar/PII/back-ofis) va east-west-ni cheklash.
7. Telemetriya, SLO va alertingni auth/authZ, mTLS ulushiga, posture-signallarga moslash.
8. «game days» ni amalga oshirish (IdP muvaffaqiyatsiz tugadi, kalitlar sizib chiqadi, broker yiqilib tushadi) va SOP/qaytishlarni qayd qilish.

FAQ

Zero Trust VPNni butunlay almashtiradimi?
Foydalanuvchilar uchun - ha, ZTNA foydasiga. S2S-magistrallar uchun VPN/IPsec qolishi mumkin, ammo mTLS va qat’iy siyosatlar.

ZT UXni yomonlashtira oladimi?
O’ylamasdan. SSO + FIDO2, moslashuvchan MFA va per-app UX bilan odatda yaxshilanadi.

Servis-mesh joriy etish majburiymi?
Har doim ham emas. Ammo katta mikroservis muhiti uchun mesh mTLS/siyosat/telemetriyani tubdan soddalashtiradi.

Jami

Zero Trust - bu mahsulot emas, balki arxitektura intizomi: o’ziga xoslik yangi perimetr, qurilmalar konteksti, ilova qilish imkoniyati (ZTNA), mikrosegmentatsiya va mTLS hamma joyda, markazlashtirilgan siyosat va o’lchanadigan ishonchlilik. Yo’l xaritasi va chek varaqasiga amal qilib, siz hujum yuzasini kamaytirasiz, auditni tezlashtirasiz va barqaror xavfsizlikka ega bo’lasiz.