Mikroservis Mimarisinde Servisler Arası Kimlik Doğrulama: mTLS ve OAuth 2.0 Client Credentials Karar Rehberi

Giriş

Dağıtık mimarilerde servislerin birbirleriyle iletişim kurarken kimliklerini doğrulamaları, Zero Trust (Sıfır Güven) prensiplerinin temelini oluşturur. Geleneksel ağ mimarilerinde bir güvenlik duvarının (firewall) arkasında yer alan tüm trafiğe güvenilmesi ilkesi, yerini her bir ağ isteğinin kaynağının doğrulanması gerektiği anlayışına bırakmıştır. Bir mikroservis ağında “Servis A”nın “Servis B”ye yaptığı bir HTTP isteğinde, B servisinin bu isteğin gerçekten A’dan geldiğini ve ağda araya giren kötü niyetli bir aktör olmadığını matematiksel olarak doğrulaması gerekir.

Makineden makineye (M2M) kimlik doğrulama senaryolarında endüstri standardı haline gelmiş iki temel yaklaşım bulunmaktadır: Ağ taşıma katmanında (L4) kimlik doğrulama sağlayan Mutual TLS (mTLS) ve uygulama katmanında (L7) yetkilendirme sağlayan OAuth 2.0 Client Credentials Grant. Bu iki teknoloji genellikle birbirine rakip olarak görülse de, taşıdıkları mimari prensipler, operasyonel yükler ve çözdükleri spesifik problemler birbirinden farklıdır. Karar aşamasında altyapı olgunluğu, gecikme (latency) bütçeleri ve ince ayarlı yetkilendirme (fine-grained authorization) ihtiyaçları belirleyici rol oynar.

İçindekiler

• Kavramsal Temeller: mTLS ve OAuth 2.0
• Karşılaştırma Kriterleri ve Trade-off Analizi
• Karar Rehberi: Ne Zaman Hangisi Kullanılmalı?
• Örnek Konfigürasyonlar ve Mimari Desenler
• Pratik Öneriler / Production Notları
• Sık Sorulan Sorular
• Sonuç

Kavramsal Temeller: mTLS ve OAuth 2.0

Mutual TLS (mTLS) Nedir?

Standart TLS (Transport Layer Security) protokolünde, yalnızca sunucu (server) istemciye (client) bir X.509 sertifikası sunarak kimliğini kanıtlar. Mutual TLS’te ise bu süreç çift yönlüdür. İstemci de sunucuya kendi sertifikasını sunar ve her iki taraf da birbirinin kimliğini, güvendikleri bir Certificate Authority (CA) üzerinden doğrular.

mTLS, OSI modelinin Taşıma (Transport) katmanında gerçekleşir. Şifreli tünel kurulmadan önce kimlik doğrulama tamamlanır. Bu durum, yetkisiz isteklerin uygulama katmanına (HTTP işleyicisine) hiç ulaşmadan TCP/TLS el sıkışma (handshake) aşamasında reddedilmesini sağlar.

OAuth 2.0 Client Credentials Grant Nedir?

OAuth 2.0, spesifik olarak M2M iletişim için “Client Credentials” akışını (grant type) tanımlar. Bu modelde, iletişim kurmak isteyen Servis A (Client), bir Kimlik Sağlayıcıya (Identity Provider / Authorization Server) kendi client_id ve client_secret bilgilerini göndererek bir Access Token (genellikle JWT formatında) talep eder. Servis A, bu token’ı HTTP isteğinin Authorization: Bearer <token> başlığı (header) üzerinden Servis B’ye (Resource Server) iletir. Servis B, token’ın imzasını ve geçerliliğini kontrol ederek isteği işler.

Bu yaklaşım OSI modelinin Uygulama (Application) katmanında çalışır ve taşıma güvenliği için ağ katmanında tek yönlü TLS’e (sadece sunucu doğrulaması) bağımlıdır.

Karşılaştırma Kriterleri ve Trade-off Analizi

İki yaklaşım arasındaki seçim, çeşitli operasyonel ve mimari ödünleşimler (trade-off) barındırır.

Kriter	mTLS	OAuth 2.0 Client Credentials
Çalışma Katmanı	Taşıma Katmanı (L4)	Uygulama Katmanı (L7)
Kimlik Kanıtı	X.509 Sertifikası	JSON Web Token (JWT) veya Opaque Token
Yetkilendirme Hassasiyeti	Sınırlı (Bağlantı bazlı erişim)	Yüksek (Scope, Audience, Claim bazlı yetkiler)
Operasyonel Yük (Altyapı)	Yüksek (PKI, sertifika dağıtımı ve rotasyonu)	Orta (Merkezi IdP yönetimi, secret yönetimi)
Ağ Gecikmesi (Latency)	Düşük (Bağlantı kurulduktan sonra ek yük yok)	Orta (Token doğrulama, JWKS çekme işlemleri)
İptal Etme (Revocation)	Zor (CRL veya OCSP altyapısı gerektirir)	Kolay (Kısa ömürlü token’lar ile doğal iptal)

Güvenlik ve Atak Yüzeyi Analizi

mTLS, ağ seviyesinde bir izolasyon sağlar. Bir uygulamanın HTTP parsing katmanında zafiyet (örneğin buffer overflow) olsa bile, mTLS sayesinde yetkisiz bir istemci bağlantı kuramayacağı için bu zafiyet sömürülemez. Buna karşılık OAuth 2.0 kullanımında, HTTP isteği uygulamanın web sunucusuna (Tomcat, Kestrel, Node.js vb.) kadar ulaşır ve token doğrulaması kod seviyesinde yapılır. Bu durum, ağ katmanında daha geniş bir atak yüzeyi anlamına gelir.

Diğer yandan OAuth 2.0, çalınan kimlik bilgileri senaryosunda farklı avantajlar sunar. Bir JWT token sızdırılırsa, token’ın sınırlı ömrü (örneğin 5 dakika) sayesinde hasar potansiyeli sınırlıdır. Ancak mTLS sertifikalarının rotasyon süreleri genellikle gün veya ay bazında olduğundan, ele geçirilen bir özel anahtar (private key) sertifika iptal edilene kadar tehlike yaratır.

Karar Rehberi: Ne Zaman Hangisi Kullanılmalı?

Aşağıdaki karar matrisi, mimari gereksinimlere göre en uygun yöntemi seçmeniz için “Eğer X ise -> Y” formatında tasarlanmıştır:

• Eğer altyapınız bir Service Mesh (Istio, Linkerd) üzerine kuruluysa veya servisler arası trafiği L4 katmanında izole etmek istiyorsanız -> mTLS kullanın. Mesh mimarilerinde kontrol düzlemi (control plane) sertifika rotasyonunu otomatikleştirerek PKI yükünü ortadan kaldırır.
• Eğer servislerin erişim haklarında ince ayarlı (fine-grained) kontrollere ihtiyacınız varsa (örneğin Servis A sadece okuma yapabilirken, Servis C yazma yapabilmeli) -> OAuth 2.0 Client Credentials kullanın. Token içindeki scopes bu gereksinimi native olarak çözer.
• Eğer iletişim kuracak olan servisler farklı domainlerde, farklı organizasyonlarda veya genel internet üzerinden haberleşiyorsa (Third-party API entegrasyonları) -> OAuth 2.0 Client Credentials kullanın. Karşı tarafa X.509 sertifikası dağıtmak operasyonel olarak yönetilemez hale gelir.
• Eğer uygulamanın gecikme (latency) toleransı çok düşükse ve mikrosaniyeler seviyesinde optimizasyon gerekiyorsa -> mTLS kullanın. TCP/TLS bağlantısı bir kez kurulduğunda Keep-Alive ile açık tutulur, her istekte ek bir token doğrulama kriptografisi (JWT imza kontrolü) çalıştırılmaz.
• Eğer Zero Trust mimarisinde maksimum güvenlik (“Defense in Depth”) hedefleniyorsa -> mTLS ve OAuth 2.0’ı birlikte kullanın. Taşıma katmanında güvenli kanal (mTLS) oluşturulur, uygulama katmanında spesifik yetkiler (OAuth 2.0 JWT) kontrol edilir.

Örnek Konfigürasyonlar ve Mimari Desenler

mTLS Örneği: Envoy Proxy L4 Konfigürasyonu

Modern dağıtık sistemlerde mTLS konfigürasyonu doğrudan uygulama koduna yazılmaz. Bunun yerine Envoy, Nginx veya HAProxy gibi ters vekil sunuculara (reverse proxy) veya sidecar container’lara devredilir (TLS Offloading). Aşağıdaki Envoy konfigürasyonu, hem istemci sertifikası talep eden hem de belirli bir CA (Certificate Authority) üzerinden doğrulama yapan temsilî bir dinleyici (listener) ayarını göstermektedir:

listeners:
- name: service_b_listener
  address:
    socket_address:
      address: 0.0.0.0
      port_value: 8443
  filter_chains:
  - transport_socket:
      name: envoy.transport_sockets.tls
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
        require_client_certificate: true
        common_tls_context:
          tls_certificates:
          - certificate_chain: { filename: "/etc/certs/service-b.crt" }
            private_key: { filename: "/etc/certs/service-b.key" }
          validation_context:
            trusted_ca:
              filename: "/etc/certs/internal-ca.crt"
            match_typed_subject_alt_names:
            - san_type: URI
              matcher:
                exact: "spiffe://internal.domain/service-a"

Bu konfigürasyonda Envoy, bağlanan istemcinin sadece CA tarafından imzalanmış bir sertifika sunmasını yeterli bulmaz, aynı zamanda sertifikanın Subject Alternative Name (SAN) alanındaki SPIFFE ID’nin tam olarak spiffe://internal.domain/service-a olmasını şart koşar. Bu, kimlik ve erişim kontrolünün ağ katmanına indirilmiş halidir.

OAuth 2.0 Örneği: Token Talebi ve Doğrulama Yapısı

Bir uygulamanın IdP’den Client Credentials akışı ile token alması standart bir HTTP çağrısıdır. Aşağıdaki örnekte, Servis A’nın faturalandırma servisine (billing) erişim için token talep etmesi gösterilmiştir:

POST /auth/realms/internal/protocol/openid-connect/token HTTP/1.1
Host: idp.internal.system
Content-Type: application/x-www-form-urlencoded
Authorization: Basic c2VydmljZS1hLWlkOnNlY3JldC1rZXktdmFsdWU=

grant_type=client_credentials&scope=billing:write

Alınan JWT token’ın payload kısmı aşağıdaki temsili JSON formatına benzer. Servis B, token imzasını doğruladıktan sonra exp (expiration), aud (audience) ve scope alanlarını kontrol eder:

{
  "iss": "https://idp.internal.system/auth/realms/internal",
  "sub": "service-a-client-id",
  "aud": "service-b-billing",
  "exp": 1715690400,
  "scope": "billing:write"
}

Pratik Öneriler / Production Notları

Sistemleri canlı ortama (production) alırken teorik doğrular kadar operasyonel pratikler de kritiktir.

1. JWT Doğrulamada Bağımlılık (Bottleneck) Yönetimi

Eğer Servis B, aldığı her JWT token’ı doğrulamak için Kimlik Sağlayıcısına (IdP) bir ağ isteği (örneğin token introspection) yaparsa, IdP tek bir darboğaz (bottleneck) ve hata noktasına (SPOF) dönüşür. Bu nedenle JWT mimarisinin doğası gereği asimetrik şifreleme ve lokal doğrulama kullanılmalıdır. Servis B, IdP’nin JWKS (JSON Web Key Set) verisini belirli periyotlarla çekmeli ve memory üzerinde (cache) tutmalıdır. Böylece token doğrulama işlemleri sıfır ağ gecikmesi ile milisaniyenin altında tamamlanır.

2. Saat Sapmaları (Clock Skew)

Dağıtık sistemlerde sunucuların sistem saatleri arasında küçük farklılıklar olabilir. OAuth 2.0 tabanlı kimlik doğrulamada exp (bitiş zamanı) ve nbf (bu zamandan önce geçerli değil) claim’leri kontrol edilirken, kütüphanelerde genellikle 30 ile 60 saniye arasında bir clock skew margin (tolerans payı) bırakılmalıdır. Aksi takdirde, saat senkronizasyonu mükemmel olmayan sunucular arasında yeni alınmış token’lar anında reddedilebilir.

3. mTLS ve Sertifika Rotasyonu Stratejisi

Statik sertifikalar güvenlik zafiyeti yaratır. mTLS kullanılacaksa PKI (Public Key Infrastructure) yönetiminin otomatikleştirilmesi bir tercih değil zorunluluktur. SPIFFE (Secure Production Identity Framework for Everyone) ve SPIRE gibi projeler, konteyner tabanlı sistemlerde servis kimliklerinin (SVID) oluşturulmasını ve sertifikaların saatlik hatta dakikalık bazda, insan müdahalesi olmadan rotasyona tabi tutulmasını sağlar.

4. İzleme (Monitoring) ve Uyarı Sistemleri

• mTLS için İzlenecek Metrikler: tls_handshake_failure_total. Eğer bu metrikte ani bir artış varsa, yüksek ihtimalle süresi dolmuş bir sertifika veya CA yapılandırma hatası mevcuttur.
• OAuth 2.0 için İzlenecek Metrikler: HTTP 401 Unauthorized dönen isteklerin spesifik nedenleri (token_expired, invalid_signature). Eğer 403 Forbidden oranlarında artış varsa, scope tanımlarında veya yetkilendirme matrisinde yapılandırma uyumsuzluğu vardır.

Mimari Karar Notu: Güvenlik, katmanlı (layered) bir yaklaşımdır. Çoğu kurumsal ölçekli altyapı, veri merkezi içindeki iletişimi şifrelemek ve dışarıdan gelen tarama isteklerini kesmek için L4’te mTLS kullanır; sistem içindeki spesifik işlem yetkilerini sınırlandırmak için L7’de OAuth 2.0 token’larını taşır.

Sık Sorulan Sorular

mTLS kullanıyorsam neden OAuth 2.0 Client Credentials kullanmaya ihtiyacım olsun?

mTLS kimin bağlandığını garanti eder, ancak bağlanan servisin sistemin içinde ne yapabileceğini kontrol etmek için tasarlanmamıştır. Servis A’nın kimliğini mTLS ile doğrulayabilirsiniz, ancak Servis A’nın Servis B’deki “ödeme yapma” veya “kayıt silme” endpoint’lerine erişim yetkisi olup olmadığını yönetmek istiyorsanız, taşıma katmanı (L4) kavramları yetersiz kalır. OAuth 2.0’ın kapsam (scope) yönetimi bu noktada devreye girer.

Opaque Token ile JWT arasındaki tercih kriteri nedir?

M2M iletişimde JWT (JSON Web Token) neredeyse standarttır çünkü durumsuz (stateless) doğrulama sağlar. Opaque Token kullanıldığında, API her gelen token’ı doğrulamak için Kimlik Sağlayıcısına bir “introspection” isteği atmak zorundadır; bu da iç ağ trafiğini ve gecikmeyi artırır. Opaque Token’lar genellikle anlık iptal işleminin (immediate revocation) aşırı kritik olduğu, veri sızıntısının anında durdurulması gereken spesifik senaryolarda tercih edilir.

Geliştirici ortamlarında (Local Development) mTLS yönetimi zor değil mi?

Evet, oldukça zordur. Geliştiricilerin kendi makinelerinde mTLS sertifikaları oluşturması, dağıtması ve CA’leri sisteme tanıtması geliştirme süreçlerini yavaşlatır. Pratik yaklaşım, local ve test ortamlarında TLS doğrulamasını kapatıp, OAuth 2.0 mock mekanizmaları veya HTTP Basic Auth gibi basit yöntemler kullanmak, mTLS konfigürasyonunu ise yalnızca Staging ve Production ortamlarında (Service Mesh aracılığıyla saydam olarak) aktif etmektir.

Sertifika iptal (Revocation) mekanizması mTLS’te nasıl kurgulanmalı?

İdeal kurgu iptal mekanizması kurmak değil, çok kısa ömürlü (örneğin 1 saatlik) sertifikalar kullanmaktır. Kısa ömürlü sertifikalar, CRL (Certificate Revocation List) indirme veya OCSP (Online Certificate Status Protocol) sorgulama yüklerini ortadan kaldırır. Sertifikanın ele geçirilme durumu olursa, maksimum 1 saat içinde geçerliliği kendiliğinden biter.

Sonuç

Servisler arası kimlik doğrulama kararında mTLS ve OAuth 2.0 Client Credentials yaklaşımları birbirinin mutlak alternatifi değil, birbirini tamamlayan paradigma araçlarıdır. mTLS, ağ topolojisine güvenmemek ve taşıma düzeyinde şifrelenmiş kimlik onayı sağlamak (Zero Trust) için altyapısal bir çözüm sunarken; OAuth 2.0, spesifik izinlerin yönetimi, farklı etki alanları arası uyumluluk ve uygulama düzeyinde yetkilendirme esnekliği sağlar.

Action Item olarak: Mevcut altyapınızda bir Service Mesh kullanılıyorsa, öncelikle taşıma katmanı güvenliği için mTLS’i aktive edip otomatikleştirmeyi hedefleyin. Sonrasında, iş mantığı gereği ince ayarlı erişim haklarına (read/write izinleri, rol bazlı kısıtlamalar) ihtiyaç duyan kritik servis sınırlarında OAuth 2.0 Client Credentials modelini L7 yetkilendirme katmanı olarak ekleyerek derinlemesine savunma (Defense in Depth) stratejisini tamamlayın.