Geleneksel çevre tabanlı güvenlik modeli, genellikle kale ve hendek mimarisi olarak görselleştirilen bu yaklaşım, artık eskimiştir. Modern bulut-native ortamlarda, yükler geçicidir, ağ sınırları bulanıklaşmıştır ve tehditler ağın hem dışından hem de içinden gelmektedir. Bu değişim, Sıfır Güven Mimarisi'ne (ZTA) geçişi zorunlu kılmaktadır. Bu bağlamda "asla güvenme, her zaman doğrula" sadece bir slogan değil, temel bir mühendislik gerekliliğidir.
Ağ Odaklıdan Kimlik Odaklıya Geçiş
Tarihsel olarak erişim kontrolü IP adreslerine ve ağ bölgelerine dayanıyordu. Bir istek kurumsal LAN'dan geliyorsa, buna güveniliyordu. Mikroservis ortamında bu yaklaşım başarısız olur. Konteynerler yatay olarak ölçeklenir, geçici podlar IP adreslerini sürekli değiştirir ve hizmetler halka açık ve özel ağlar arasında iletişim kurar.
Sıfır Güven, odağı istekte bulunan varlığın kimliğine kaydırır. Bu varlık bir kullanıcı, bir uygulama veya başka bir hizmet olsun, herhangi bir veriye erişilmeden önce kimlik doğrulaması yapılmalı, yetkilendirilmeli ve sürekli olarak doğrulanmalıdır. Bu kavram, genellikle "Kimlik Bilinçli Vekil Sunuculuk" veya "Karşılıklı TLS (mTLS)" olarak adlandırılır ve bir hizmetin ele geçirilmesi durumunda bile saldırganın uygun kimlik bilgilerine sahip olmadığı için diğer hizmetlere kolayca geçiş yapmasını engeller.
Servis Mesh'in Rolü
Sıfır Güven'i her bir mikroservis için manuel olarak uygulamak hata yapmaya açıktır ve ölçeklenemez. İşte burada Istio veya Linkerd gibi servis mesh'leri kritik altyapı bileşenleri haline gelir. Bir servis mesh, hizmetler arası iletişim için şifreleme, kimlik doğrulama ve yetkilendirmeyi uygulama mantığında kod değişikliği gerektirmeden şeffaf bir şekilde ele alan özel bir altyapı katmanı sağlar.
Bir servis mesh'te kimlik odaklı güvenliğin temel mekanizması karşılıklı TLS (mTLS)'dir. Standart TLS'te yalnızca sunucunun istemciye kimliğini kanıtlamasının aksine, mTLS her iki tarafın da sertifikaları sunmasını gerektirir. Mikroservis ekosisteminde bu sertifikalar genellikle servis mesh'in kontrol düzlemi tarafından yönetilen bir Sertifika Otoritesi (CA) tarafından verilir.
Istio ile Pratik Uygulama
Bir Istio servis mesh'inde sıkı bir mTLS politikasını nasıl uygulayacağınıza bakalım. Varsayılan olarak, birçok küme hem düz metin hem de TLS trafiğine izin veren "PERMISSIVE" (İzin Verilen) modunda çalışır. Gerçek bir Sıfır Güven duruşu için "STRICT" (Sıkı) modu zorunlu kılmamız gerekir.
Aşağıdaki YAML yapılandırması, tüm ad alanına uygulanacak ve gelen ve giden tüm trafiğin şifreli ve kimlik doğrulaması yapılmış olmasını gerektirecek bir PeerAuthentication politikasını tanımlar:
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: production
spec:
mtls:
mode: STRICT
Ayrıca, hizmetlerin yalnızca yetkili eşlerle iletişim kurmasını sağlamak için bir AuthorizationPolicy (Yetkilendirme Politikası) uygularız. Bu, tanımlanan kurallarla açıkça eşleşmeyen tüm trafiği reddederek yanal hareketi engeller.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: require-jwt
namespace: production
spec:
selector:
matchLabels:
app: frontend-service
action: ALLOW
rules:
- from:
- source:
requestPrincipals: ["cluster.local/ns/default/sa/backend-service"]
Bu örnekte, frontend-service yalnızca istekler backend-service hesabından, imzalı bir JWT ile doğrulanarak geliyorsa bu istekleri kabul edecektir. Aynı Kubernetes kümesi içinde olsa bile, diğer tüm kaynaklar reddedilir.
Sürekli Doğrulama ve Kısa Ömürlü Kimlikler
Güçlü bir Sıfır Güven uygulaması, başlangıç el sıkışma kimlik doğrulamasının ötesine geçer. Güvenin sürekli olarak doğrulanmasını içerir. Modern kimlik odaklı mimariler, dağıtılmış bir CA tarafından verilen kısa ömürlü sertifikaları (örneğin, 1-2 saat geçerli) kullanır. Bu, ele geçirilen bir sertifikadan kaynaklanan hasarın yayılma çapını minimize eder. Bir özel anahtar sızdırılırsa, hızla sona erer ve saldırgan için fırsat penceresini sınırlar.
Ayrıca, harici kimlik sağlayıcılarıyla (IdP) entegrasyon, kullanıcı özelliklerine, rollerine ve bağlamına dayalı ince taneli erişim kontrolüne olanak tanır. Bu, iç mikroservisleri harici tüketicilere açan API ağ geçitleri için özellikle önemlidir.
Sonuç
Mikroservislerde Sıfır Güven uygulamak bir varış noktası değil, bir yolculuktur. Derinlemesine savunma kültürüne geçişi ve servis mesh'leri gibi kimlik odaklı araçların benimsenmesini gerektirir. Karşılıklı TLS, sıkı yetkilendirme politikaları ve kısa ömürlü kimlik bilgilerini zorlayarak kuruluşlar saldırı yüzeylerini önemli ölçüde azaltabilir ve yanal hareketi önleyebilir. Dağıtık bilişim çağına daha da ilerledikçe, kimliği yeni çevre yapmak artık bir seçenek değil; dayanıklı yazılım mimarisi için gerekliliktir.