> ZERO-TRUST // zt-arch-03
Hardware-Bound FIDO2/WebAuthn Enterprise IdP
Ortadaki-saldırgan (AitM) oltalama saldırılarına karşı matematiksel olarak bağışık, WebAuthn ve donanım güvenlik anahtarları (YubiKey / Secure Enclave) ile çalışan parolasız kurumsal kimlik mimarisi.
Hedef Saldırgan Tehdit Modeli
Saldırganın ters vekil oltalama araçlarıyla kullanıcı adı, parola ve TOTP doğrulama kodlarını eşzamanlı olarak çalması.
Mimari Meta Verileri
NIST SP 800-207 Karşılanan Temel İlkeler
- ✓Access to individual enterprise resources is granted on a per-session basis.
- ✓Authentication and authorization are strictly dynamic and strictly enforced before access is allowed.
Engellenen MITRE ATT&CK Teknikleri
3 Olgunluk Seviyesi Konfigürasyonu
Başlangıç seviyesinden CISA Optimal tavizsiz savunmaya kadar evrimleşen teknik konfigürasyon parametreleri.
WebAuthn offered as an optional second factor for privileged admin accounts.
Password + Security Key (FIDO2) fallback to TOTP allowed.
Standard HTTPS TLS 1.3 edge termination.
Authentication success/failure logs retained for 90 days.
Mandatory FIDO2 WebAuthn across 100% of employees; all password inputs removed from UI.
Resident Discoverable Credentials (passkeys) with user presence PIN validation.
Origin validation enforced cryptographically at the browser-token boundary.
Real-time alert on credential registration from non-attested vendor AAGUIDs.
Enterprise-wide hardware-bound passkeys integrated with ephemeral SSH certificates and cloud IAM.
Strict AAGUID allowlisting restricted to FIPS 140-3 Level 3 validated hardware modules.
Cross-origin binding with strict Certificate Transparency monitoring.
Automated cryptographic attestation verification piped to SOC SIEM.
Altyapı Kodları: Terraform & Kubernetes Manifestoları
Doğrudan üretim ortamınıza uygulanabilir Helm/Terraform ve Kubernetes YAML şablonları.
resource "keycloak_realm" "realm" {
realm = "tinycto"
enabled = true
web_authn_policy_rp_entity_name = "TinyCTO Enterprise"
web_authn_policy_signature_algorithms = ["ES256", "EdDSA", "RS256"]
web_authn_policy_attestation_conveyance_preference = "direct"
web_authn_policy_authenticator_attachment = "cross-platform"
}apiVersion: v1 kind: ConfigMap metadata: name: webauthn-config namespace: auth data: rp-id: "tinycto.tv" rp-name: "TinyCTO Security Plane" origin: "https://auth.tinycto.tv" user-verification: "required"
Ortadaki-saldırgan (AitM) oltalama saldırılarına karşı matematiksel olarak bağışık, WebAuthn ve donanım güvenlik anahtarları (YubiKey / Secure Enclave) ile çalışan parolasız kurumsal kimlik mimarisi.
Mimarî Plan Sıkça Sorulan Sorular
Hardware-Bound FIDO2/WebAuthn Enterprise IdP mimarisi hangi birincil tehdit modellerini ve MITRE ATT&CK tekniklerini engeller?
Hardware-Bound FIDO2/WebAuthn Enterprise IdP, Saldırganın ters vekil oltalama araçlarıyla kullanıcı adı, parola ve TOTP doğrulama kodlarını eşzamanlı olarak çalması. Saldırganların yanlamasına ilerlemesini (lateral movement) ve yetki yükseltmesini engellemek için T1539, T1556, T1110, T1078 tekniklerini çekirdek seviyesinde (in-kernel) veya kriptografik kimlik kanıtlamasıyla etkisiz hale getirir.
Bu mimari NIST SP 800-207 Sıfır Güven ilkelerini nasıl karşılar?
Bu mimari, NIST SP 800-207 yönergelerine uygun olarak şu temel ilkeleri tavizsiz zorunlu kılar: Access to individual enterprise resources is granted on a per-session basis.; Authentication and authorization are strictly dynamic and strictly enforced before access is allowed.. Statik ağ çevresi güveni yerine her istekte dinamik kimlik kanıtlaması ve kriptografik doğrulama yürütülür.
INITIAL (Başlangıç) ile OPTIMAL (Tavizsiz Savunma) seviyeleri arasındaki operasyonel farklar nelerdir?
INITIAL seviyesi temel politika ve kimlik doğrulamasına odaklanırken (WebAuthn offered as an optional second factor for privileged admin accounts.), OPTIMAL seviyesi CISA ZTMM 2.0 tavizsiz savunma hedeflerini hayata geçirir (Enterprise-wide hardware-bound passkeys integrated with ephemeral SSH certificates and cloud IAM.). OPTIMAL seviye teknoloji yığını: step-ca, yubikey-fips, pam-u2f, aws-iam-identity-center.
Bu mimarideki temel hata riski (Failure Risk) nedir ve operasyonel dayanıklılık nasıl korunur?
Birincil operasyonel risk: Hardware security key physical obsolescence cycle management.. Bu risk, yedekli denetim düzlemi (control plane) dağıtımı, yerel önbellek yedekleri ve otomatik hata devri (failover) mekanizmalarıyla bertaraf edilir.
Bu mimari Altyapı Kodu (IaC) ile üretim ortamına nasıl uygulanır?
Bu sayfada sunulan ana Terraform/OpenTofu (main.tf) ve Kubernetes politika (policy.yaml) bildirimleri doğrudan GitOps boru hatlarına (ArgoCD, Flux) entegre edilebilir. Bildirimler, en az ayrıcalık ve kriptografik iş yükü kanıtlaması parametreleriyle önceden yapılandırılmıştır.