Geleneksel "kale ve hendek" güvenlik modeli, modern bulut-native mimariler karşısında uzun süredir çökmüş durumda. Monolitik bir uygulamada, tüm bileşenler güvenilir bir iç ağda bulunduğu için çevre güvenmesi yeterliydi. Ancak mikroservisler, hizmetlerin doğası gereği güvensiz ağlar üzerinden iletişim kurtuğu dağıtık, dinamik bir ortam sunar. Bu değişim, güvenlik duruşunda temel bir değişikliği zorunlu kılar: Sıfır Güvenlik Mimarisi'nin (ZTA) benimsenmesi.
Sıfır Güvenlik (Zero Trust) tek bir ürün veya teknoloji değildir; "asla güvenme, her zaman doğrula" ilkesine dayanan bir güvenlik paradigmasydır. Mikroservisler için bu, kökeni ne olursa olsun her isteğin kimliğinin doğrulanması, yetkilendirilmesi ve şifrelenmesi gerektiği anlamına gelir. Bu blog yazısı, karşılıklı TLS (mTLS) ve kimlik bilgilere erişim üzerine odaklanarak, bir mikroservis ekosisteminde Sıfır Güvenlik'in teknik uygulamasını incelemektedir.
Temel Direkler: Kimlik ve Şifreleme
Sıfır Güvenlik modelinde, güveni tesis etmek için ağ konumuna (örneğin, iç alt ağda bulunmak) güvenemeyiz. Bunun yerine, güven kimlikten türetilir. Her mikroservisin ayrı ve doğrulanabilir bir kimliği olmalıdır. Ayrıca, bu kimlikler arasındaki iletişim kanalı güvenli olmalıdır. Bunu başarmak için endüstri standardı Karşılıklı Taşıma Katmanı Güvenliği'dir (mTLS).
Service Mesh ile mTLS Uygulaması
Yüzlerce mikroservis için sertifikaları ve anahtarları manuel olarak yönetmek operasyonel bir kabus gibidir. İşte burada Istio veya Linkerd gibi service mesh'ler devreye girer. Altyapı düzeyinde mTLS yönetimini otomatikleştirerek, uygulama kodunda herhangi bir değişiklik gerektirmeden tüm doğu-batı trafiğinin şifrelenmesini ve kimlik doğrulamasını sağlarlar.
Aşağıda, belirli bir namespace için sıkı mTLS'yi zorlayan bir Istio PeerAuthentication ilkesinin kavramsal bir örneği yer almaktadır. Bu, bu namespace içinde iletişim kurmaya çalışan herhangi bir servisin geçerli bir sertifika sunmasını sağlar.
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: production
spec:
mtls:
mode: STRICT
Kipi STRICT olarak ayarlayarak, mesh düz metin trafiğini reddeder. Geçerli bir güven kökü tarafından verilmiş bir sertifika olmadan trafiği engellemeye çalışan kötü niyetli bir aktör veya zayıf düşmüş bir servis varsa, bağlantı kesilecektir. Bu durum, küme içindeki dinleme ve ortadaki adam (man-in-the-middle) saldırıları riskini ortadan kaldırır.
OAuth 2.0 ve OpenID Connect ile İnce Granüllü Yetkilendirme
mTLS taşıma katmanını güvence altına alırken, eylemi yetkilendirmez. Hizmet A'nın Hizmet B ile konuştuğunu bilmek yeterli değildir; Hizmet A'nın ne yapmasına izin verildiğini de bilmemiz gerekir. İşte burada kimlik bilgilere dayalı yetkilendirme devreye girer ve genellikle OAuth 2.0 ve OpenID Connect (OIDC) kullanılır.
Tipik bir akışta, bir istemci isteği bir API Geçidi üzerinden sisteme girer. Geçit, kullanıcının JSON Web Token'ını (JWT) doğrular. Doğrulandıktan sonra istek arka uç mikroservislerine iletilir. Kritik nokta, service mesh'in kullanıcının kimliğini (veya bir kullanıcıyı temsil eden bir hizmet hesabı kimliğini) istek başlıklarına enjekte etmesidir; bu da arka uç servislerin, ağ topolojisine değil politikalar bazında ince granüllü yetkilendirme kararları almasına olanak tanır.
Kullanıcının profilini görüntülemek istediği bir senaryoyu ele alalım. İstek şu şekilde görünebilir:
GET /api/v1/users/me/profile HTTP/1.1
Host: user-service
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
X-Forwarded-For: 192.168.1.5
user-service, ardından JWT ile ilişkili kullanıcının profil uç noktasına erişim izni olup olmadığını doğrulamalıdır. Bu mantık, iş mantığında kodlanmış if/else ifadeleri yerine, bir OPA (Open Policy Agent) kararı gibi bir yetkilendirme ilkesi aracılığıyla uygulanmalıdır.
Pratik Zorluklar ve En İyi Uygulamalar
Sıfır Güvenlik uygulamak kendi zorluklarıyla gelmez. Sertifika döndürme (rotation), kritik bir operasyonel endişedir. Büyük ölçekli dağıtımlarda, sertifika ömürleri genellikle günler veya hatta saatler olarak ayarlanır. Süre sonu nedeniyle oluşan kesintileri önlemek için otomatik döndürme mekanizmaları esastır.
Ayrıca, gözlemlenebilirlik daha da karmaşıklaşır. Her istek şifrelendiğinde ve kimliği doğrulandığında, geleneksel hata ayıklama zorlaşır. Gizliliği tehlikeye atmadan istekleri servis sınırları boyunca izlemek için service mesh ile sorunsuz çalışan dağıtık izleme (örneğin Jaeger veya Zipkin) uygulamak şarttır.
Sonuç
Hassas verilerle uğraşan veya bulut ortamlarında çalışan kuruluşlar için mikroservisler için Sıfır Güvenlik Mimarisi benimsemek artık bir seçenek değil, zorunluluktur. Şifreleme ve kimlik doğrulama için mTLS'yi, sağlam kimlik bilgilere dayalı yetkilendirme ile birleştirerek, potansiyel ihlallerin etki alanını sınırlayan derinlemesine bir savunma stratejisi oluşturursunuz. Başlangıçtaki kurulum karmaşıklığı, eski modellere göre daha yüksek olsa da, güvenlik duruşu, uyumluluk ve operasyonel direnç konusundaki uzun vadeli faydalar, onu modern uygulama geliştirme için vazgeçilmez bir yatırım haline getirir.