Geleneksel çevre tabanlı güvenlik modeli, bulut-native mimariler çağında çökmüştür. Kurumlar mikro servislere geçiş yaptıkça saldırı yüzeyi katlanarak genişler. Bir zamanlar özel ağ içinde güvenli olduğu varsayılan servisler arası iletişim, artık kritik bir zafiyet vektörüdür. Sıfır Güvenlik (Zero Trust) mimarisi uygulamak artık bir tercih değil, bir zorunluluktur. Bu yazı, kimlik doğrulama için Karşılıklı TLS (mTLS) ve ince ayarlı erişim kontrolü için dinamik yetkilendirme politikaları uygulayarak mikro servislerde Sıfır Güvenlik'in nasıl uygulanacağını incelemektedir.
Mikro Servisler İçin Sıfır Güvenlik Neden Önemlidir?
Mikro servis ortamında servisler birden fazla düğümde dağıtılmıştır ve genellikle farklı küme veya bulutları kapsar. "Ağ içinde olmak güvenli demektir" varsayımı ölümcüldür. Bir saldırgan tek bir pod'u ele geçirdiğinde, hassas veritabanlarına veya diğer kritik servislere erişmek için yatay olarak hareket etmeyi (pivot) deneyebilir. Sıfır Güvenlik, "asla güvenme, her zaman doğrula" ilkesi üzerine çalışır. Kaynağı ne olursa olsun, erişim sağlanmadan önce her istek kimlik doğrulamasından ve yetkilendirmeden geçmelidir.
Bu stratejinin bir servis örgüsü (service mesh) bağlamındaki iki temel direği kimliktir (mTLS ile kanıtlanır) ve politika (dinamik kurallar ile uygulanır). mTLS olmadan servisler, kiminle konuştuğunu kriptografik olarak doğrulayamaz. Dinamik yetkilendirme olmadan, doğrulanmış servisler bile aşırı ayrıcalıklara sahip olabilir.
Karşılıklı TLS (mTLS) Uygulaması
mTLS, standart TLS el sıkışmasını, hem istemcinin hem de sunucunun sertifikaları sunmasını gerektirerek genişletir. Bu, her iki tarafın da kimliğinin güvenilir bir Sertifika Otoritesi (CA) kullanılarak doğrulanmasını sağlar. Kubernetes ortamında bu genellikle otomatik sertifika döngüsü ve enjeksiyonunu yöneten Istio veya Linkerd gibi bir servis örgüsü tarafından yönetilir.
Istio'da mTLS yapılandırması, bir PeerAuthentication politikası tanımlamayı içerir. Bu, yalnızca geçerli sertifikalara sahip isteklerin kabul edilmesini sağlar.
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: "default"
namespace: "prod-ns"
spec:
mtls:
mode: STRICT
# Bu, bu adım alanına giren tüm trafiğin şifreli olmasını
# ve her iki tarafın da mTLS ile kimlik doğrulamasını zorlar.
mTLS uygulandığında, servis kimliği doğrudan istemci sertifikasındaki Ortak Ad (CN) veya Alternatif Konu Adı (SAN) alanından türetilir. Örneğin, payment-service'ten gelen bir istek, kimliğin açıkça belirtildiği bir sertifika taşıyacaktır; bu da IP sahteciliği riskini ortadan kaldırır.
Dinamik Yetkilendirme Politikaları
mTLS, isteği yapanın "kim" olduğunu doğrular, ancak "ne yapabileceğini" tanımlamaz. Bir payment-service, inventory-service'i çağırabilir ancak asla admin-service'e erişmemelidir. İşte Yetkilendirme politikaları devreye girer. Statik izin listeleri yerine, dinamik politikalar servis kimliği, kaynak ad alanları ve hatta istek bağlamı içindeki belirli özniteliklere dayalı ince ayarlı kontrol sağlar.
AuthorizationPolicy kullanarak, trafiği sıkı bir şekilde sınırlayan kurallar tanımlayabilirsiniz. Örneğin, api-gateway'i yalnızca belirli HTTP yöntemlerine ve yollarına izin verecek şekilde kısıtlayabilirsiniz.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: "allow-payment-to-inventory"
namespace: "prod-ns"
spec:
selector:
matchLabels:
app: inventory-service
action: ALLOW
rules:
- from:
- source:
principals:
- "cluster.local/ns/prod-ns/ sa/payment-service"
to:
- operation:
methods: ["GET", "POST"]
paths: ["/api/v1/inventory/*"]
Bu yapılandırma, payment-service ele geçirilse bile, saldırganın inventory-service'in diğer kısımlarına veya açık bir izin kuralına sahip olmayan herhangi bir başka servise erişemeyeceğini garanti eder. Politika, trafik uygulama koduna ulaşmadan önce giriş geçidi veya yan taraftaki proxy'de değerlendirilir.
Pratik Dikkat Edilmesi Gerekenler ve Zorluklar
Bu mimariyi uygulamak dikkatli planlama gerektirir. İlk zorluk sertifika yaşam döngüsü yönetimidir. Sertifika döngüsü otomatik değilse, servisler çevrimdışı kalacaktır. İkinci olarak, her şey şifrelendiğinde bağlantı sorunlarını gidermek zor olabilir; loglama pipeline'ınızın servis örgüsü meta verilerini yakından emin olun. Son olarak, dinamik politikalar karmaşık hale gelebilir. Kazara kesintileri önlemek için varsayılan olarak "her şeyi engelle" ile başlayın ve bilinen iyi trafik yollarını kademeli olarak izin listesine ekleyin.
Sonuç
Mikro servisleri güvence altına almak, çevre savunmasından kimlik odaklı güvenliğe bir geçişi gerektirir. Sağlam servis kimlik doğrulaması için Karşılıklı TLS'i, ince ayarlı erişim kontrolü için dinamik yetkilendirme politikalarıyla birleştirerek, kurumlar etkili bir şekilde Sıfır Güvenlik mimarisi uygulayabilirler. Bu yaklaşım, potansiyel ihlallerin patlama yarıçapını önemli ölçüde azaltır ve giderek düşmanlaşan dijital bir ortamda servisler arası iletişimin güvenli kalmasını sağlar. Altyapınız büyüdükçe, bu politikaları güncel tutmak, dirençli bir güvenlik duruşunu sürdürmenin anahtarıdır.