Technical Tutorials

Yıllar boyunca dağıtık sistemler için hakim güvenlik modeli "kale ve hendek" yaklaşımıydı. Ağ perimetremizi güvenlik duvarları ve sızma tespit sistemleriyle güçlendirdik, kale surları içindekilerin güvende olduğuna güvendik. Ancak mikroservislerin ortaya çıkışı bu sınırları aşındırdı. Dinamik olarak iletişim kuran yüzlerce geçici hizmetle, güvenilir bir iç ağ kavartısı artık uygulanabilir değildir. Kompromise uğramış bir iç hizmet, harici bir ihlalle aynı derecede yıkıcı olabilir.

Burada Sıfır Güvenlik Mimarisi (ZGA) hayati hale gelir. Sıfır Güvenliğin temel ilkesi basit ancak derindir: asla güvenme, her zaman doğrula. Mikroservisler bağlamında bu, her hizmetten hizmete etkileşimi, güvenilmeyen bir ağdan geliyormuş gibi ele almayı gerektirir. Bu yazıda, karşılıklı TLS (mTLS) ve servis mesh teknolojilerine odaklanarak bu ilkelerin pratikte nasıl uygulanacağı incelenecektir.

Ağdan Kimliğe Geçiş

Geleneksel monolitik bir uygulamada kimlik doğrulama, çoğunlukla isteğin ağ konumuna dayanırdı. Mikroservis ortamında hizmetler farklı ad alanlarında, düğümlerde ve potansiyel olarak bulut sağlayıcılar arasında dağıtılır. IP adresleri geçicidir ve güven kararları için güvenilir değildir. Bu nedenle, Sıfır Güvenlik, güven sınırını ağdan kimlike kaydırır.

Her istek, gönderenin ve alıcının kimliğine dayanarak kimlik doğrulamasından ve yetkilendirmeden geçirilmelidir. Bu, iletişim katmanı ile sıkı entegre edilmiş sağlam bir Kimlik ve Erişim Yönetimi (IAM) sistemi gerektirir. "Kim soruyor?" (IP adresi) yerine "Bu belirli iş yükü nedir?" (Hesap Kimliği/Kimlik) yaklaşımına geçiş yaparız.

mTLS ile Şifrelemeyi Zorunlu Kılma

Mikroservislerde Sıfır Güvenliğin en kritik teknik bileşeni, tüm trafiğin, iç hizmetler arasındaki iletişim dahil olmak üzere transit halinde şifrelenmesini sağlamaktır. Bu, Karşılıklı TLS (mTLS) aracılığıyla gerçekleştirilir. Standart TLS'ten farklı olarak, istemcinin sunucunun kimliğini doğruladığı mTLS'te her iki taraf da sertifikalarını sunar. Bu, verinin şifrelenmesinin yanı sıra iletişim partnerinin de iddia ettiği kişi olduğundan emin olunmasını sağlar.

Yüzlerce hizmet için sertifikaları manuel olarak yönetmek operasyonel bir kabus yaratır. İşte burada Istio veya Linkerd gibi bir Servis Mesh, vazgeçilmez hale gelir. Kriptografik işlemleri bir sidecar vekil sunucusuna devrederek geliştiricilerin, sertifika yaşam döngüsü yönetimiyle uğraşmadan uygulama kodu yazmasına olanak tanır.

Pratik Uygulama: Istio Sidecar Enjeksiyonu

Başlıca servis mesh olan Istio kullanarak pratik bir örneğe bakalım. Otomatik sidecar enjeksiyonunu etkinleştirerek, ad alanında dağıtılan her pod'un otomatik olarak bir vekil sunucu kapsayıcısı aldığını garanti ederiz. Bu vekil sunucu, tüm gelen ve giden trafiği engeller, politikaları uygular ve mTLS'i yönetir.

İlk olarak, tüm mesh üzerinde karşılıklı TLS'i etkinleştiriyoruz. Bu yapılandırma, hizmetler arasında düz metin trafiğine izin verilmediğini sağlar.

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT

STRICT modu hayati önem taşır. Geçerli bir istemci sertifikası sunmayan her bağlantıyı reddeder. Yetkisiz bir hizmet, uygun kimlik bilgileri olmadan korunmuş bir hizmetle iletişim kurmaya çalışırsa, bağlantı hemen kesilir.

Yetkilendirme Politikalarıyla Granüler Erişim Kontrolü

Şifreleme tek başına yeterli değildir; kimin kiminle konuşabileceğini de kontrol etmeliyiz. Sıfır Güvenlik, en az ayrıcalık ilkesini savunur. Bir hizmetin başka bir hizmete bağlanabilmesi, varsayılan olarak bağlanabileceği anlamına gelmez.

Bunu YetkilendirmePolitikaları kaynaklarını kullanarak uygulayabiliriz. Örneğin, frontend-service'un yalnızca api-gateway'a erişmesine izin veren, diğer hizmetlerden doğrudan erişimi engelleyen bir politika tanımlayabiliriz.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-frontend-to-gateway
  namespace: production
spec:
  selector:
    matchLabels:
      app: api-gateway
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/frontend-service"]

Bu örnekte, principals alanı hesap kimliği kimliğini referans alır. Bu, bir saldırganın aynı IP adresine veya ana makine adına sahip bir pod'u kompromize etse bile, geçerli kimlik belirteçlerine sahip olmadıkları sürece ağ geçidine erişemeyeceğini garanti eder.

Sonuç

Mikroservis iletişiminde Sıfır Güvenlik uygulamak tek seferlik bir kurulum değil, kimliği doğrulama ve en az ayrıcalık politikalarını uygulama sürecinin sürekliliğidir. Servis mesh gibi araçlardan yararlanarak geliştiriciler, güvenlik karmaşıklığını uygulama kodundan altyapı katmanına taşıyabilir. Bu, ekiplerin hem harici saldırılara hem de iç ihlallere dayanabilen, dayanıklı ve güvenli uygulamalar geliştirmesini sağlar. Altyapınız büyüdükçe, unutmayın ki güven varsayılmaz; doğrulama ile her zaman kazanılır.