Technical Tutorials

Geleneksel çevre tabanlı güvenlik modeli artık geçerli değil. Dağıtık bir mikroservis mimarisinde, hizmetler artık aynı veri merkezinde veya bulut VPC'sinde bulundukları için "güvenilir" kabul edilen iç ağlar üzerinden iletişim kurar. Saldırganların yanal hareketi ve iç tehditler de dahil olmak üzere gelişmiş tehditlerin yükselişi, hizmetler arası iletişimi güvence altına alma şeklinizde temel bir değişimi zorunlu kılar. İşte bu noktada Sıfır Güven Mimarisi (ZTA), sadece bir moda kelime olmaktan çıkıp kritik bir mühendislik gerekliliğine dönüşür.

Sıfır Güven, şu ilkeye dayanır: "Asla güvenme, her zaman doğrula." Mikroservisler için bu, kökeni ne olursa olsun her isteğin doğrulanması, yetkilendirilmesi ve şifrelenmesi gerektiği anlamına gelir. Bu yazıda, bu paradigmayı karşılıklı Taşıma Katmanı Güvenliği (mTLS) ve SPIFFE (Uç Federasyonlu İşletmeler için SPIFFE Kimliği) gibi kimlik çerçeveleri kullanarak nasıl uygulayacağımızı keşfedeceğiz.

İmplicit Güvenin Sorunu

Tarihsel olarak geliştiriciler, küme içindeki hizmetler arasındaki trafiğin güvenli olduğunu varsayardı. Bu örtük güven, bir hizmeti zayıflatan bir saldırganın, minimum sürtünme ile diğer hizmetlere yanal olarak hareket etmesine olanak tanır. ZTA olmadan, temeli sağlam ama iç odalarında kilit olmayan bir ev inşa etmektesiniz.

Sıfır Güven uygulamak, ağ tabanlı kontrollerden kimlik tabanlı kontrollere geçişi gerektirir. Her hizmetin benzersiz, kriptografik olarak doğrulanabilir bir kimliği olmalı ve her iletişim kanalı, bu kimliklere dayalı sıkı erişim politikalarını zorunlu kılmaldır.

Temel Bileşenler: SPIFFE ve mTLS

Sıfır Güven'i operasyonel hale getirmek için iki temel teknolojiye dayanırız:

SPIFFE/SPIRE: SPIFFE, kimliklerin belirtilmesi için bir standart sağlar ve SPIRE, bu kimlikleri X.509 sertifikaları aracılığıyla veren çalışma zamanı sistemidir.
mTLS: Standart TLS'te yalnızca sunucunun kimliğini kanıtlamasının aksine, mTLS hem istemcinin hem de sunucunun sertifika sunmasını gerektirir; bu da her iki tarafın da meşru varlıklar olduğundan emin olunmasını sağlar.

SPIRE'yi Istio veya Linkerd gibi bir hizmet ağı ile entegre ederek, sertifika yayımlama ve döndürme işlemlerini otomatikleştirebiliriz. Bu, SSL/TLS sertifikalarını yönetmenin manuel yükünü ortadan kaldırırken, hizmet kimliklerinin kısa ömürlü ve iptal edilebilir olduğundan emin olur.

Pratik Uygulama: Kimlik Sağlayıcılarının Yapılandırılması

Bir hizmetin kimliğine kefil olması için temel bir SPIRE ajanının nasıl yapılandırılacağına dair pratik bir örneğe bakalım. Bu yapılandırma, SPIRE ajanına hangi yükün (hizmetin) güvenilmesi gerektiğini ve resulting kimliğin hangi kitleye (hizmet ağı) sahip olması gerektiğini söyler.

# spire-server.conf
server {
  bind_address = "0.0.0.0"
  bind_port = "8081"
  data_dir = "/run/spire/data"
  log_level = "DEBUG"
  trust_domain = "example.org"
}

# Yük için eklentiyi tanımla
plugins {
  NodeAttestor "k8s_psat" {
    plugin_data {
      cluster = "my-k8s-cluster"
    }
  }

  KeyManager "disk" {
    plugin_data {
      keys_path = "/run/spire/data/keys.json"
    }
  }

  WorkloadAttestor "k8s" {
    plugin_data {
      # Geliştirme ortamında basitlik için Kubernetes token doğrulamasını atla
      skip_k8s_server_tls_verify = true
    }
  }
}

# Belirli mikroservis için politikayı tanımla
authority {
  # "payment-service" ifadesinin kefil olmasına izin ver
  selector "k8s:pod-ns:payment"
  selector "k8s:pod-name:payment-service"
}

Bu yapılandırmada, selector ifadeleri SPIRE sunucusuna kayıt olmasına izin verilen Kubernetes pod'larını tanımlar. Bu, yalnızca orijinal payment-service pod'unun diğer hizmetlerle iletişim kurmak için gerekli olan kriptografik kimliği alabilmesini sağlar.

Yetkilendirme Politikalarının Zorlanması

Kimlikler kurulduktan sonra sonraki adım yetkilendirmedir. Sıfır Güven sadece kim olduğunuzu doğrulamakla kalmaz; ne yapmanıza izin verildiğini de doğrular. Bu genellikle hizmet ağındaki sidecar proxy'leri (Envoy gibi) tarafından yönetilir.

Örneğin, bir Istio hizmet ağında erişimi kısıtlamak için bir AuthorizationPolicy tanımlayabilirsiniz. frontend-service'nin internal-logging-service'e doğrudan çağrı yapmasına izin verilmediğini varsayalım. Aşağıdaki YAML politikasını yazarak bunu zorlayabilirsiniz:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-frontend-to-logging
  namespace: default
spec:
  selector:
    matchLabels:
      app: internal-logging-service
  action: DENY
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/frontend-service"]

Bu politika, ağ yolu açık olsa bile, frontend-service kimliğinden kaynaklanan herhangi bir isteği internal-logging-service'e açıkça reddeder. Bu ince taneli kontrol, bir Sıfır Güven uygulamasının belirgin özelliğidir.

Sonuç

Mikroservis iletişimine Sıfır Güven uygulamak tek seferlik bir proje değil, güvenlik durumunuzu güçlendirmenin sürekli bir sürecidir. SPIFFE gibi standartları benimseyerek ve karşılıklı TLS'ten yararlanarak, kuruluşlar örtük güven varsayımlarını ortadan kaldırabilir ve potansiyel ihlallerin patlama yarıçapını önemli ölçüde azaltabilir.

Orta ve ileri düzey geliştiriciler için meydan okuma, güvenliği gözlemlenebilirlik ve performansla dengelemektir. Ancak, dağıtık sistemlerdeki dayanıklılık, uyumluluk ve güvenin uzun vadeli faydaları, başlangıç uygulama maliyetlerinden çok daha fazladır. Küçük başlayın, kimlik yönetimini otomatikleştirin ve gerçekten güvenli bir mikroservis ekosistemi oluşturmak için yetkilendirme politikalarınızı titizlikle test edin.