Sıfır Güven Güvenlik Modeli: Uygulama Rehberi

Klasik güvenlik modeli bir çevre çizer ve içeride olan her şeye güvenir. Mikroservisler, bulut ve hibrit altyapı bu varsayımı geçersiz kıldı: servisler birden fazla bölgeye ve sağlayıcıya dağıldığında “içerisi” diye bir yer kalmıyor. Sıfır güven (zero trust) modeli tam buradan başlar: ihlalin olduğunu varsayar ve her erişim isteğini ayrı ayrı doğrular.

Bu rehber sıfır güvenin ne olduğunu, neden önemli olduğunu ve kurumunuzda nasıl adım adım uygulanacağını anlatıyor. Kavramın en çok başvurulan tanımı ABD Ulusal Standartlar ve Teknoloji Enstitüsü’nün NIST SP 800-207 belgesidir.

Sıfır güven nedir

Sıfır güvenin ilkesi kısadır: “Asla güvenme, her zaman doğrula.” Kullanıcıdan, servisten ya da cihazdan gelen her istek, nereden gelirse gelsin, kimliği doğrulanarak, yetkisi kontrol edilerek ve şifreli kanal üzerinden işlenir.

Temel ilkeler:

• Her kullanıcıyı ve cihazı doğrula: güçlü kimlik doğrulama, mümkünse çok faktörlü
• İhlali varsay: sistemi bir parçası ele geçirilmiş gibi tasarla
• En az yetki: her işlem için gereken en küçük yetki
• Her şeyi şifrele: iletimde ve depoda
• Sürekli izle: erişimleri kaydet, anormalliği yakala
• Mikro bölümleme: ağı küçük, birbirinden yalıtılmış parçalara ayır

Neden şimdi

Servisler bölgeler, kıtalar ve bulut sağlayıcıları arasında konuştuğunda klasik güvenlik duvarı yetmez. Sık görülen senaryolar:

1. İçeriden tehdit: ele geçirilmiş tek bir çalışan hesabı hassas veriye ulaşabilir
2. Tedarik zinciri saldırısı: zafiyetli bir bağımlılık tüm altyapıyı açabilir
3. API yüzeyi: her mikroservis ayrı korunması gereken uçlar açar
4. Yanal hareket: saldırgan tek bir servise girdiğinde güvenlik olmayan iç ağda serbestçe dolaşır

Sıfır güven bunların hepsine aynı cevabı verir: ağdaki konum bir yetki değildir, her etkileşim ayrıca doğrulanır.

Temel bileşenler

Kimlik ve erişim yönetimi

Sıfır güvenin temeli güçlü kimliktir. Kullanıcı adı ve parolanın yanına çok faktörlü doğrulama (MFA) eklenir; yönetim hesaplarında ise donanım anahtarı ya da passkey gibi oltalamaya dayanıklı yöntemler tercih edilir. Kimlik tek bir sağlayıcıda (Keycloak, Microsoft Entra ID, Okta gibi) toplanır, uygulamalar OpenID Connect ile bu sağlayıcıya bağlanır.

Servisler arası kimlik doğrulama

Mikroservislerde servisler de birbirine kimliğini kanıtlamalıdır. En yaygın yol karşılıklı TLS’tir (mTLS): iki taraf da sertifika sunar. Servis ağı (service mesh) bunu uygulama kodu değişmeden sağlar:

# Istio: ad alanında yalnız mTLS'e izin ver
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: payments
spec:
  mtls:
    mode: STRICT
---
# Ödeme servisine yalnız sipariş servisi, yalnız bu uçtan erişebilir
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-order-to-payment
  namespace: payments
spec:
  selector:
    matchLabels:
      app: payment-service
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/orders/sa/order-service"]
    to:
    - operation:
        methods: ["POST"]
        paths: ["/api/v1/payments"]

Ağ bölümleme

Ağın içindeki her şeye güvenmek yerine altyapıyı küçük parçalara ayırın ve her parçaya kendi kuralını verin. Kubernetes’te bunun aracı NetworkPolicy’dir. Önce her şeyi kapatıp sonra gerekeni açmak en güvenli başlangıçtır:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database-ingress
spec:
  podSelector:
    matchLabels:
      role: database
  policyTypes: ["Ingress"]
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: api
    ports:
    - protocol: TCP
      port: 5432

NetworkPolicy’nin uygulanması kümenin ağ eklentisine bağlıdır; politikayı yazmak yetmez, eklentinin onu gerçekten zorladığını test edin.

Sürekli doğrulama

Girişte bir kez doğrulamak yetmez; oturum boyunca kimlik ve cihaz durumu yeniden değerlendirilir:

• Cihaz uyumu: işletim sistemi güncel mi, disk şifreli mi
• Kullanıcı davranışı: alışılmadık saat, konum ya da hacim
• Erişim örüntüleri: kim hangi veriye ne sıklıkla erişiyor

def evaluate_access(user, device, request) -> str:
    signals = {
        "os_patched": device.os_patched,
        "disk_encrypted": device.disk_encrypted,
        "known_location": request.country in user.usual_countries,
        "mfa_recent": user.mfa_age_minutes < 60,
    }
    if all(signals.values()):
        return "allow"
    if signals["os_patched"] and signals["disk_encrypted"]:
        return "step_up"   # yeniden MFA iste
    return "deny"

Kararlar ve gerekçeleri denetim kaydına yazılmalı; “neden reddedildim” sorusunun cevabı kayıtta bulunmalı.

Her yerde şifreleme

İletimde TLS 1.2 ve üstü (tercihen 1.3), depoda AES-256. Uygulama düzeyinde hassas alan şifrelerken anahtarı ortam değişkeninde değil bir sır yönetim servisinde (HashiCorp Vault, bulut KMS) tutun ve anahtar dönüşümünü baştan planlayın.

Aşamalı geçiş planı

Sıfır güven bir ürün değil, bir dönüşümdür. Tek seferde değil, aşamalarla yapılır. Süreler kurumun büyüklüğüne göre değişir; aşağıdaki sıra yön verir.

1. Değerlendirme

1. Kullanıcıların, cihazların, uygulamaların ve verilerin envanterini çıkarın
2. Erişim yollarını ve bağımlılıkları haritalayın
3. Hassas veriyi ve kritik sistemleri belirleyin
4. Mevcut güvenlik durumunu yazıya dökün
5. Hedef politikaları tanımlayın

2. Pilot

1. Kritik olmayan bir uygulama ya da ekip seçin
2. Merkezi kimlik ve MFA’yı devreye alın
3. Ağ bölümlemeyi uygulayın
4. Kayıt ve izlemeyi açın
5. Geri bildirimle politikaları düzeltin

3. Kademeli yayılım

1. Uygulamaları sırayla taşıyın
2. Servisler arası kimlik doğrulamayı yaygınlaştırın
3. Sürekli doğrulamayı devreye alın
4. Olay müdahale sürecini yazın ve prova edin
5. Ekipleri eğitin

4. Sürekli iyileştirme

1. Erişim örüntülerini izleyin
2. Politikaları yeni tehditlere göre güncelleyin
3. Düzenli güvenlik denetimi yapın
4. Tespit ve müdahale yeteneğini geliştirin

Örnek: bir fintech platformu

Ödeme işleyen bir platformda sıfır güven olmadan, ele geçirilen tek bir servis müşterinin finansal verisine ulaşabilir. Sıfır güvenle:

1. Her mikroservis sertifikasıyla kimliğini kanıtlar
2. Ödeme servisi yalnız tanımlı servislerle konuşabilir
3. Üretim veritabanına insan erişimi ek doğrulama ve süreli yetki ister
4. Her API çağrısı kaydedilir
5. Şüpheli davranış otomatik incelemeye düşer

Sonuç, olası bir ihlalin etki alanının (blast radius) küçülmesidir.

Sık karşılaşılan zorluklar

İşletme yükü artar. Otomasyon şart: sertifika dağıtımını ve dönüşümünü servis ağına ya da cert-manager gibi araçlara bırakın.

Şifreleme ve doğrulama gecikme ekler. Yetki kararlarını kısa süreli önbelleğe alın, bağlantıları yeniden kullanın.

Eski sistemler uymaz. Önlerine kimlik doğrulayan bir vekil (proxy) koyarak politikayı dışarıdan uygulayın.

Kullanıcı sürtünmesi artar. Riske dayalı erişim kullanın: düşük riskli işlemde ek adım istemeyin, yüksek riskte isteyin.

Araçlar

• Servis ağı: Istio, Linkerd, Consul
• Kimlik: Keycloak, Microsoft Entra ID, Okta, Auth0
• Ayrıcalıklı erişim: HashiCorp Boundary, Teleport
• Konteyner güvenliği: Falco, Trivy
• Sır yönetimi: HashiCorp Vault, bulut KMS servisleri

Sonuç

Bulutta ve mikroservislerle çalışan kurumlar için sıfır güven artık temel beklenti. Envanterle başlayın, tek bir pilotla deneyin, sonra kademeli yayın. Her adım ihlalin etki alanını biraz daha daraltır.

Sıfır güvene geçiş planınızı birlikte değerlendirmek isterseniz bize yazın.