Sıfır güven mimarisi
Kısa Özet
Zero Trust (ZT), ağ çevresinin artık güvenilir bir bölge olarak kabul edilmediği bir güvenlik modelidir. Her bir istek (kullanıcı - uygulama, hizmet - servis, cihaz - ağ) bağlamsal sinyaller (kimlik, cihaz durumu, konum, risk, davranış) dikkate alınarak açıkça doğrulanır, yetkilendirilir ve şifrelenir. Amaç, patlama yarıçapını en aza indirmek, yanal hareket riskini azaltmak ve uyumu basitleştirmektir.
Sıfır Güven temelleri
1. Açık bir güven yok -/VPN/ASN ağından güven miras alınmaz.
2. Erişim, gerekli olan minimumdur: "Yalnızca şu anda ihtiyaç duyulanı sağlama" politikası.
3. Sürekli doğrulama: Oturumlar ve belirteçler risk ve bağlam için düzenli olarak yeniden değerlendirilir.
4. Uzlaşma varsayımı: segmentasyon, gözlemlenebilirlik, hızlı çevreleme ve anahtar rotasyonlar.
5. Her yerde şifreleme: TLS 1. 2+/1. Veri planları içindeki 3 ve mTLS, korumalı DNS, KMS/HSM'deki sırlar.
Hedef manzara ve kontrol alanları
Kimlik: insanlar (IdP: SSO, MFA, passkeys/FIDO2), makineler (SPIFFE/SVID, x509/mTLS).
Cihazlar: Politikalara uygunluk (MDM/EDR, disk şifreli, yamalar, jailbreak/root - yasaktır).
Ağ: L3/L7 mikrosegmentasyon, ZTNA/SDP ağ geçitleri, servis ağı (Envoy/Istio/Linkerd).
Uygulamalar/API'ler: mTLS, OIDC/JWT, istek imzaları (HMAC), oran limitleri, DLP/maskeleme.
Veri: sınıflandırma (Public/Confidential/Restricted), alan düzeyinde tokenizasyon/şifreleme.
Gözlemlenebilirlik: merkezi kimlik doğrulama/yetkilendirme günlükleri, davranışsal analitik, SLO/SLA.
Referans mimarisi (düzlemler tarafından parçalanır)
Kontrol Düzlemi: IdP/CIAM, PDP/PEP (OPA/Envoy), politika katalogları, PKI/CA, cihaz kalifikasyonu.
Veri Düzlemi: proxy erişimi (ZTNA), mTLS ve L7 politikası için sidecar proxy (Envoy), GW servis ağ geçitleri/API'leri.
Yönetim Düzlemi: servis kataloğu, CMDB, CI/CD, gizli yönetim (Vault/KMS), merkezi denetim.
1. Tanımlama (SSO + phishing dirençli MFA) - 2) Cihaz değerlendirmesi (MDM duruşu) - 3) ZTNA proxy, uygulamaya mTLS kurar - 4) PDP (politikalar) niteliklere göre karar verir (ABAC/RBAC) - 5) sürekli risk yeniden değerlendirmesi (zaman, coğrafi, anomaliler).
Kimlik ve yetkilendirme
IdP/SSO: OIDC/SAML, varsayılan MFA, tercihen FIDO2 (geçiş anahtarları).
RBAC/ABAC: roller + bağlam özellikleri (cihaz durumu, departman, risk profili).
Just-In-Time (JIT) erişimi: otomatik iptal ile geçici ayrıcalıklar; Kırık cam - kesinlikle düzenlenmiş.
Makineler için mTLS: Kısa ömürlü sertifikalara sahip SPIFFE/SVID veya dahili PKI; Otomatik döner salınım.
Cihazlar ve Bağlam
Duruş: OS/EDR sürümü, disk şifreleme, güvenlik duvarı dahil; Uyumsuz - minimum erişim veya blok.
Doğrulama: aygıt kimliği + imzalı onaylar (MDM/Endpoint).
Ağ kısıtlamaları: üçüncü taraf tünellerinin engellenmesi, zorunlu kurumsal DNS, DNS/WebRTC sızıntılarına karşı koruma.
Ağ ve mikrosegmentasyon
"Düz" VLAN'ların atılması: bunun yerine L7'de segmentler/VRF ve ilke.
Servis Mesh: Sidecar proxy'leri mTLS, politika yetkilendirme (OPA/EnvoyFilter), telemetri sağlar.
ZTNA/SDP: ağa değil, belirli bir uygulamaya erişim; kliyent↔broker↔app, PDP'de politika.
Uzaktan Erişim: "Kalın" VPN'i bir uygulama proxy'si ile değiştirmek; Geri dönüş tünelleri güzergahlar/limanlar ile sınırlıdır.
Politikalar ve çözüm motoru
PDP/PEP: Politika Karar Noktası (OPA/Styra, Cedar и пр.) + Politika Uygulama Noktası (Elçi/İstio/Ağ Geçidi).
Politika modeli: bildirimsel kurallar (Rego/Cedar), statik ve bağlamsal nitelikler, risk değerlendirmesi.
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
}İzleme çözümleri: denetim için log 'input'/' result'/' explain'.
Varsayılan şifreleme ve güven
TLS 1. 2+/1. 3 her yerde, sıkı şifre süitleri, HSTS, OCSP zımbalama.
mTLS içeride: Sadece karşılıklı sertifikalarla servis↔servis; Kısa süreli anahtarlar (saat/gün).
Sırlar: KMS/HSM, dinamik sırlar (Vault), kısa TTL, uygulamalar için en az ayrıcalık.
Gözlemlenebilirlik, SLO ve yanıt
Metrikler (minimum set):- Kimlik doğrulama ve yetkilendirme başarısı (%), p95 PDP karar süresi, p95 TLS el sıkışma.
- Politika tarafından engellenen isteklerin yüzdesi (anomaliler/false).
- ZTNA brokerlerinin ve Mesh denetleyicisinin kullanılabilirliği.
- Uyumlu cihazların ve trendlerin oranı.
- "ZTNA ≥ 99 kullanılabilirlik. %95/ay; P95 authZ kararı ≤ 50 мс"
- "mTLS ile yapılan isteklerin yüzdesi 99 ≥. 9%».
- "0'dan fazla değil. %1 yanlış erişim hatası/gün"
Alarm: inkar patlamaları, p95 el sıkışmalarının bozulması, geçersiz zincirler, uyumlu cihazların oranında düşüş, coğrafya anomalileri/ASN.
Çevreden Zero Trust'a geçiş: bir yol haritası
1. Envanter: uygulamalar, veri akışları, tüketiciler, duyarlılık (PII/kart/ödemeler).
2. Kimlik ve MFA: Herkes için SSO ve kimlik avı dirençli MFA.
3. Cihaz içeriği: MDM/EDR, temel uyumluluk politikaları, uyumlu olmayan blok.
4. Öncelikli yolların mikrosegmentasyonu: ödemeler, arka ofis, yönetici; mTLS girin.
5. Kullanıcı erişimi için ZTNA: uygulamaları bir proxy aracılığıyla yayınlamak, "geniş VPN'yi kaldırın.
6. ABAC politikaları: merkezi PDP, bildirimsel kurallar, denetim.
7. Servis ağı uzantısı: S2S mTLS, L7 politikası, telemetri.
8. Otomasyon ve SLO: uyarı, politika testleri (politik CI), oyun günleri "IdP mevcut değilse? ».
İGaming/fintech için Özgüllük
Katı alan segmentasyonu: ödemeler/PII/dolandırıcılıkla mücadele/içerik - ayrı çevreler ve politikalar; Sadece ZTNA üzerinden erişim.
PSP/bankalarla etkileşim: ASN/aralıklarına göre izin listesi, PSP-uç noktalarına mTLS, Time-to-Wallet izleme ve authZ arızaları.
İçerik sağlayıcılar ve ortaklar: geçici JIT API erişimleri, kısa TTL belirteçleri, entegrasyon denetimleri.
Uyumluluk: PCI DSS/GDPR - veri minimizasyonu, DLP/takma ad, hassas tablolara erişimlerin kaydedilmesi.
Tedarik Zinciri Güvenliği ve CI/CD
Yapay imzalar (SLSA/Provenance): konteyner imzaları (cosign), K8s kabul politikası.
SBOM ve güvenlik açıkları: SBOM üretimi (CycloneDX), boru hattında politika kapısı.
CI Sırları: Bulut KMS için OIDC Federasyonu; Statik anahtarların yasaklanması.
Rotasyonlar: sık, otomatik; olaylarda zorla iptal.
Ortak hatalar ve anti-desenler
"ZTNA = yeni VPN": Uygulamalar yerine bir ağ yayınlamak Zero Trust değildir.
Cihaz kontrolü yok: MFA var, ancak virüslü/köklü cihazlar erişim kazanıyor.
Tek süper kullanıcı: JIT eksikliği ve ayrı roller.
Hizmet kodundaki politikalar: merkezi denetim/güncelleme mümkün değildir.
mTLS kısmi: mTLS olmayan hizmetlerin bir parçası - "sızdıran'bir döngü.
Sıfır UX: yedekli MFA istekleri, SSO yok; Sonuç - komutlara direnç.
Teknolojileri seçmek için mini kılavuz
Kullanıcı erişimi: ZTNA/SDP broker + IdP (OIDC, FIDO2 MFA).
Hizmet içi güvenlik: service-mesh (Istio/Linkerd) + OPA/Envoy authZ.
PKI: Kısa TTL ile SPIFFE/SVID veya Vault PKI.
Politikacılar: OPA/Rego veya Cedar; Git'te mağaza, CI'da check-in yapın (politika testleri).
Günlükler ve telemetri: OpenTelemetry - merkezi analiz, anomali tespiti.
Örnek konfigürasyonlar (parçalar)
Elçi (hizmetler arasında karşılıklı 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: trueOPA/Rego: Raporlara yalnızca "finans'tan, uyumlu cihazlardan, çalışma saatleri içinde erişim
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
}Sıfır Güven Uygulama Kontrol Listesi
1. Tüm kullanıcılar ve yöneticiler için SSO ve FIDO2 MFA'yı etkinleştirin.
2. Uyumlu olmayan kilitle cihaz duruşunu (MDM/EDR) girin.
3. Kullanıcı erişimini ZTNA'ya (uygulama başına) aktarın, VPN'i yalnızca dar S2S kanalları için bırakın.
4. Inside - varsayılan olarak mTLS + kısa ömürlü sertifikalar.
5. Politikaları (PDP/OPA) merkezileştirin, Git'te saklayın, CI'da test edin.
6. Hassas etki alanlarını segmentlere ayırın (ödemeler/PII/arka ofis) ve doğu-batı'yı kısıtlayın.
7. Auth/authZ, mTLS paylaşımı, duruş sinyalleri üzerinde telemetri, SLO ve uyarı ayarlayın.
8. "Oyun günleri" (IdP hatası, anahtar sızıntısı, broker düşüşü) yapın ve SOP'ları/geri dönüşleri düzeltin.
SSS
Zero Trust VPN'i tamamen değiştiriyor mu?
Kullanıcı erişimi için - evet, ZTNA lehine. S2S gövdeler için, VPN/IPsec kalabilir, ancak mTLS ve katı politikalar ile.
ZT UX'i daha da kötüleştirebilir mi?
Düşüncesizce. SSO + FIDO2, uyarlanabilir MFA ve uygulama başına erişim ile UX tipik olarak gelişir.
Bir servis ağı tanıtmak gerekli midir?
Her zaman değil. Ancak büyük bir mikro hizmet ortamı için mesh, mTLS/politika/telemetriyi radikal olarak basitleştirir.
Toplam
Zero Trust bir ürün değil, bir mimari disiplindir: yeni bir çevre olarak kimlik, cihaz bağlamı, uygulama erişimi (ZTNA), her yerde mikrosegmentasyon ve mTLS, merkezi politikalar ve ölçülebilir güvenilirlik. Yol haritasını ve kontrol listesini izleyerek, saldırı yüzeyini azaltacak, denetimi hızlandıracak ve "varsayılan güven" olmadan sürdürülebilir güvenlik kazanacaksınız.