Servisler Arası Kimlik Doğrulama: Kurumsal Çözümler

Bir mikroservis başka bir servise istek gönderdiğinde ilk soru çoğu zaman “istek hangi kullanıcıdan geliyor?” oluyor. Oysa kurumsal sistemlerde bundan önce yanıtlanması gereken daha temel bir soru vardır: Bu isteği gerçekten hangi servis yapıyor ve o servisin bu işlemi gerçekleştirmesine izin veriliyor mu? Servisler Arası Kimlik Doğrulama: Kurumsal Çözümler yaklaşımı, uygulamalar arasında güven oluşturmayı IP adresi, ortak parola veya iç ağ varsayımı gibi zayıf yöntemlerden çıkarıp doğrulanabilir servis kimliklerine taşır. Yaklaşık on yıllık yazılım geliştirme deneyimimde mikroservis projelerinde en sık gördüğüm sorunlardan biri, authentication ile authorization kavramlarının birbirine karıştırılması ve kullanıcı token'larının servis kimliği yerine kullanılmaya çalışılmasıdır. Bu rehberde mikroservislerde servisler arası kimlik doğrulama nasıl yapılır sorusunu OAuth 2.0, mTLS, JWT, workload identity, SPIFFE, service mesh, token exchange ve Zero Trust yaklaşımı üzerinden uygulanabilir örneklerle ele alacağız.

Servisler Arası Kimlik Doğrulama Nedir?

Servisler arası kimlik doğrulama, bir uygulama bileşeninin başka bir bileşene bağlanırken kendi kimliğini güvenilir ve doğrulanabilir şekilde kanıtlamasıdır. Burada kimlik doğrulanan taraf çoğu zaman insan değil, çalışan bir workload, API, worker, scheduled job veya mikroservistir. Amaç yalnızca bağlantının şifreli olması değil, isteğin hangi servis örneğinden geldiğinin anlaşılmasıdır. Güvenilir servis kimliği daha sonra authorization kararının girdisi haline gelir. Kurumsal sistemlerde service-to-service authentication nasıl uygulanır sorusunun sağlıklı yanıtı da authentication, authorization ve delegation katmanlarını ayrı düşünmekle başlar.

Machine-to-Machine (M2M) Authentication

Machine-to-Machine authentication iki yazılım bileşeninin insan etkileşimi olmadan birbirinin kimliğini doğruladığı modeli ifade eder. Bir ödeme servisi fatura servisine, bir worker depolama API'sine veya bir cron görevi raporlama servisine bağlanabilir. Bu senaryolarda kullanıcı parolası veya interaktif giriş ekranı anlamlı değildir. Bunun yerine client credential, certificate, signed assertion veya workload identity gibi makineye uygun kimlik mekanizmaları kullanılır. Kimlik mümkün olduğunca kısa ömürlü ve çalıştığı workload ile ilişkilendirilebilir olmalıdır.

İnsan Kullanıcı Authentication'ından Farkı

İnsan kullanıcı authentication sürecinde parola, passkey, MFA veya kurumsal SSO gibi kullanıcı etkileşimi içeren mekanizmalar kullanılır. Servis authentication sürecinde ise sürekli çalışan yazılım bileşenlerinin otomatik şekilde kimlik kanıtlaması gerekir. Servisin secret kopyalaması veya manuel giriş yapması beklenemez. Kullanıcı kimliği ile servis kimliğinin aynı token veya credential içinde kontrolsüz biçimde birleştirilmesi de audit açısından sorun yaratabilir. Sağlıklı mimaride kullanıcı, workload ve varsa actor kimliği ayrı bağlamlar olarak korunur.

Microservice Mimarisinde Neden Gereklidir?

Microservice mimarisinde tek uygulama içindeki fonksiyon çağrıları ağ üzerinden yapılan servis çağrılarına dönüşür. Her servis farklı ekip tarafından geliştirilebilir, farklı ortamda çalışabilir ve farklı verilere erişebilir. Bu nedenle bir endpoint'e ulaşabiliyor olmak o endpoint üzerinde işlem yapmaya yetmemelidir. Her service call doğrulanabilir bir workload identity taşımalı ve hedef servis authorization politikasını uygulamalıdır. Bu yaklaşım bir servis ele geçirildiğinde saldırganın bütün iç API'lere otomatik erişmesini zorlaştırır.

“Internal Network Güvenlidir” Varsayımı Neden Yeterli Değildir?

Bir isteğin şirket ağı içinden gelmesi onun güvenilir olduğu anlamına gelmez. Ele geçirilmiş workload, yanlış yapılandırılmış container veya yetkisiz çalışan aynı internal network içinde trafik üretebilir. IP tabanlı allowlist uygulandığında dinamik altyapıda adres değişiklikleri ek risk oluşturur. Modern Zero Trust yaklaşımında ağ konumu tek başına güven sinyali sayılmaz. Kimlik, cihaz veya workload durumu, hedef kaynak ve istenen işlem birlikte değerlendirilir.

Önce Üç Problemi Birbirinden Ayırın

Servis güvenliğinde en önemli tasarım adımlarından biri workload authentication, service authorization ve user delegation problemlerini birbirinden ayırmaktır. Bu üç konu aynı HTTP isteğinde birlikte bulunabilir fakat farklı sorulara yanıt verir. Kimlik doğrulama çağrıyı yapan servisi belirler, authorization bu servisin ne yapabileceğine karar verir, delegation ise servis bir kullanıcı adına hareket ediyorsa bu bağı korur. Bu ayrım yapılmadığında kullanıcı token'ı service identity gibi kullanılabilir veya certificate sahipliği business permission olarak yorumlanabilir. İyi tasarlanmış mimari her katmanı ayrı doğrular ve audit kayıtlarında ayrı gösterir.

Workload Authentication

Workload authentication çalışan yazılım bileşeninin kimliğini doğrular. Bu kimlik service account, certificate, signed token veya platform tarafından verilen workload identity olabilir. Kimliğin yalnızca deployment adıyla değil, cryptographic proof ile desteklenmesi gerekir. Authentication başarılı olsa bile servis henüz herhangi bir işleme yetkili sayılmaz. Bir sonraki adım authorization policy'nin bu identity için izin verip vermediğini kontrol etmektir.

Çağrıyı Hangi Servis Yapıyor?

Bu soru service-to-service güvenliğinin en temel sorusudur. Kaynak IP veya HTTP header gibi kolay taklit edilebilir sinyaller yeterli değildir. Hedef servis doğrulanmış certificate subject, token subject veya workload identity claim üzerinden kaynak servisi belirlemelidir. Kimlik doğrudan deployment yaşam döngüsüne bağlanırsa manuel credential dağıtımı azalır. Audit kayıtları da çağrının hangi workload tarafından yapıldığını açık biçimde gösterebilir.

Service Authorization

Service authorization doğrulanmış servisin hangi operasyonları gerçekleştirebileceğini belirler. Örneğin raporlama servisi müşteri bilgisini okuyabilir ancak ödeme başlatamayabilir. Bu karar RBAC, ABAC veya policy-as-code modeliyle verilebilir. Network erişimi tek başına business authorization yerine geçmez. Minimum permission yaklaşımı servis ele geçirildiğinde oluşabilecek blast radius'u sınırlar.

Bu Servis Ne Yapabilir?

Authentication sonucunda “bu inventory-service” denebilir, ancak bundan sonra “inventory-service hangi endpoint'e hangi method ile erişebilir?” sorusu cevaplanmalıdır. İzinler service identity, environment, resource ve request context üzerinden değerlendirilebilir. Genel bir “internal-service” rolü çok geniş yetki oluşturabilir. Daha dar policy belirli servis çiftlerine ve operasyonlara izin verir. Kullanılmayan permission'ların düzenli olarak kaldırılması least privilege yaklaşımını korur.

User Delegation

User delegation bir servisin kendi kimliğini koruyarak kullanıcı adına başka serviste işlem yapmasıdır. Bu senaryoda yalnızca kullanıcı token'ını forwarding yapmak her zaman güvenli değildir. Downstream servis hem original user kimliğini hem de çağrıyı yapan workload'u bilmek isteyebilir. Token exchange veya actor claim modeli bu iki bağlamı ayırmaya yardımcı olur. Özellikle finansal ve hassas veri işlemlerinde audit açısından bu ayrım büyük önem taşır.

Servis Hangi Kullanıcı Adına Hareket Ediyor?

Bir API çağrısı doğrudan kullanıcının isteğinden kaynaklanıyorsa downstream servis kullanıcı bağlamını bilmek isteyebilir. Fakat servis kendi yetkisini kullanıcı token'ından türetmemelidir. Kullanıcı kimliği subject, servis kimliği ise actor veya workload identity olarak ayrı taşınabilir. Authorization policy hem kullanıcı hem servis bağlamını birlikte değerlendirebilir. Böylece “kim istedi” ve “hangi servis gerçekleştirdi” soruları audit kaydında ayrı cevaplanır.

Service Identity Nedir?

Service identity bir workload'un sistem içindeki doğrulanabilir kimliğidir. Bu kimlik yalnızca uygulama adı, host name veya IP adresi gibi metadata olmamalıdır. Kimliğin trusted issuer tarafından verilmesi ve cryptographic olarak doğrulanabilmesi daha güvenli bir model sağlar. Modern platformlarda service identity deployment sırasında otomatik üretilebilir ve kısa ömürlü credential ile temsil edilebilir. Bu yaklaşım mikroservislerde service identity token yönetimi ve zero trust güvenlik mimarisi kurmak isteyen ekipler için temel katmanı oluşturur.

Service Name ile Identity Aynı Şey Değildir

Bir servisin “orders-api” adını taşıması onun gerçekten orders-api olduğunu kanıtlamaz. DNS adı, container label veya HTTP header kolayca yanlış yapılandırılabilir veya taklit edilebilir. Identity doğrulanabilir bir credential veya certificate ile ilişkilendirilmelidir. Service name identity'nin okunabilir bir attribute'u olabilir. Güven kararı ise doğrulanmış issuer ve cryptographic proof üzerinden verilmelidir.

IP Adresine Dayalı Identity

IP adresi geleneksel ağlarda service identity yerine sık kullanılmıştır. Ancak container, autoscaling ve serverless ortamlarında IP adresleri dinamik olabilir. Aynı adres farklı zamanda başka workload tarafından kullanılabilir. NAT ve proxy katmanları gerçek kaynağı daha da belirsiz hale getirebilir. IP network policy için yararlı bir sinyal olsa da tek başına kimlik kanıtı olmamalıdır.

Service Account

Service account bir workload'a özel mantıksal kimlik sağlar. Kubernetes veya cloud IAM ortamlarında deployment belirli service account ile ilişkilendirilebilir. Ancak service account adının varlığı tek başına güvenli kimlik doğrulama anlamına gelmez. Workload'un gerçekten o service account adına hareket ettiğinin platform tarafından doğrulanması gerekir. Kısa ömürlü token ve audience kısıtlaması service account kullanımını daha güvenli hale getirir.

Cryptographic Workload Identity

Cryptographic workload identity certificate veya signed token üzerinden workload kimliğini kanıtlar. Credential trusted authority tarafından verilir ve hedef servis signature veya certificate chain doğrulaması yapar. Kimlik kısa ömürlü tutulduğunda çalınmış credential'ın kullanım süresi azalır. Workload attestation credential issuance öncesinde çalışan bileşenin gerçekten beklenen workload olduğunu doğrular. Bu model statik shared secret kullanımına göre daha güçlü bir temel sunar.

Identity'nin Environment'tan Bağımsız Olması

Service identity tasarımında uygulama adı ile environment bilgisi ayrı attribute olarak ele alınabilir. “payment-service” kimliği development, staging ve production ortamlarında farklı trust context ile kullanılabilir. Environment bilgisini identity path veya claim içinde taşımak policy yazımını kolaylaştırabilir. Ancak aynı logical service için her platformda tamamen farklı isim üretmek portability sorununa yol açabilir. Organization ortak naming ve trust domain standardı belirlemelidir.

Servisler Arası Authentication Yöntemleri

Servisler arası authentication için tek bir evrensel yöntem yoktur. Static API key basit entegrasyonlarda kolaydır ancak uzun ömürlü secret riski taşır. OAuth 2.0 Client Credentials uygulama seviyesinde token tabanlı authorization için güçlü bir model sunarken mTLS transport seviyesinde iki taraflı kimlik doğrulama sağlar. Cloud workload identity ve SPIFFE gibi yaklaşımlar credential dağıtımını runtime identity modeline taşır. OAuth 2.0 mTLS JWT ve API key ile servis kimlik doğrulama karşılaştırması yapılırken güvenlik hedefi, operasyon maliyeti, platform desteği ve portability birlikte değerlendirilmelidir.

Static API Key

Static API key servise önceden verilen sabit bir anahtarın her istekte gönderilmesiyle çalışır. Uygulaması kolay olduğu için küçük entegrasyonlarda sık görülür. Ancak anahtar uzun süre aynı kalırsa sızıntı durumunda risk büyür. Bir anahtarın birden fazla servis tarafından paylaşılması gerçek caller identity bilgisini ortadan kaldırır. Mümkün olduğunda unique, scoped ve kısa ömürlü credential modellerine geçmek daha güvenlidir.

Shared Secret

Shared secret iki tarafın bildiği ortak gizli değerdir. Basic authentication veya özel header mekanizmalarında kullanılabilir. Değer hem client hem server tarafında güvenli saklanmak zorundadır. Secret rotation birden fazla deployment arasında koordinasyon gerektirebilir. Büyük mikroservis ortamlarında shared secret sayısı arttıkça operasyon yükü ve sızıntı riski büyür.

HMAC

HMAC isteğin belirli alanlarının shared key ile imzalanmasına dayanır. Bu yaklaşım secret'ı doğrudan request içinde taşımadan request integrity doğrulaması sağlar. Timestamp ve nonce kullanımı replay riskini azaltabilir. Buna rağmen secret iki taraf arasında paylaşılır ve rotation problemi devam eder. HMAC belirli API protokollerinde uygun olabilir ancak workload identity yerine her zaman en iyi seçenek değildir.

OAuth 2.0 Client Credentials

OAuth 2.0 Client Credentials, bir uygulamanın kendi kimliğiyle authorization server'dan access token almasını sağlar. Kullanıcı etkileşimi bulunmaz. Token audience ve scope değerleriyle hedef servis ve permission sınırlandırılabilir. Client authentication secret, private key veya mTLS üzerinden yapılabilir. Kurumsal backend entegrasyonlarında merkezi token issuance ve policy yönetimi sunduğu için güçlü bir seçenektir.

JWT

JWT imzalı claim set'ini kompakt formatta taşıyan token yapısıdır. Service identity, issuer, audience, expiration ve permission bilgileri token içinde bulunabilir. Resource server token'ı local olarak doğrulayabildiği için her request'te authorization server'a çağrı yapmak zorunda değildir. Ancak signature kontrolü tek başına yeterli değildir. Issuer, audience, expiration ve algorithm doğrulaması da zorunludur.

Mutual TLS (mTLS)

mTLS normal TLS'in server authentication modeline client certificate doğrulamasını da ekler. Böylece iki servis TLS handshake sırasında birbirinin kimliğini cryptographic olarak doğrulayabilir. Trafik aynı zamanda şifrelenir ve integrity korunur. Certificate identity authorization policy'nin girdisi olarak kullanılabilir. Otomatik certificate issuance ve rotation olmadan büyük ölçekte yönetimi zorlaşabilir.

Cloud Workload Identity

Cloud workload identity, çalışan iş yükünün uzun ömürlü access key taşımadan cloud IAM kimliği almasını sağlar. Platform deployment metadata veya service account üzerinden workload'u doğrular. Kısa ömürlü token veya credential otomatik verilir. Bu model secret zero problemini önemli ölçüde azaltır. Tek cloud ortamında native entegrasyon güçlü avantaj sağlayabilir.

SPIFFE/SPIRE

SPIFFE workload identity için platformdan bağımsız bir standart tanımlar. SPIRE ise workload attestation, identity issuance ve rotation süreçlerini uygulayan yaygın runtime bileşenidir. X.509-SVID mTLS için, JWT-SVID ise token tabanlı senaryolar için kullanılabilir. Trust domain yapısı multi-cluster ve multi-cloud ortamlarında ortak identity plane sağlayabilir. Operasyon ekibinin CA, attestation ve federation modelini iyi tasarlaması gerekir.

Service Mesh

Service mesh service-to-service trafiği proxy veya veri düzlemi üzerinden yöneterek automatic mTLS ve policy enforcement sağlayabilir. Uygulama kodunun certificate handling yapması gerekmez. Workload identity proxy katmanına dağıtılabilir. Authorization policy ve observability merkezi olarak uygulanabilir. Ancak mesh kullanmak otomatik olarak Zero Trust sağlamaz, default-deny ve explicit policy yine tasarlanmalıdır.

Static API Key Kullanmanın Riskleri

API key basitliği nedeniyle hızlı çözüm gibi görünür ancak kurumsal ölçekte önemli güvenlik ve yönetim sorunları doğurabilir. Uzun ömürlü key'ler repository, log veya environment dump üzerinden sızabilir. Aynı key birden fazla workload tarafından kullanılırsa hangi servisin istek yaptığı ayırt edilemez. Rotation sırasında eski ve yeni credential'ın eş zamanlı desteklenmesi operasyon yükü getirir. Bu nedenle API key kullanımında unique identity, kısa kullanım süresi ve merkezi secret management en azından temel koruma olarak düşünülmelidir.

Long-Lived Credential

Aylarca veya yıllarca değişmeyen API key çalındığında saldırgan uzun süre erişim sağlayabilir. Sızıntı fark edilmediğinde risk daha da büyür. Credential TTL kavramının olmadığı yapılarda revocation manuel yapılır. Kısa ömürlü token modeli bu pencereyi doğal olarak küçültür. Uzun ömürlü credential yalnızca başka seçenek olmadığı ve güçlü rotation bulunduğu durumlarda değerlendirilmelidir.

Secret Leakage

API key source code, CI log, shell history veya monitoring çıktısına yanlışlıkla yazılabilir. Environment variable kullanılması da değerin hiçbir zaman görünmeyeceği anlamına gelmez. Secret scanning sızıntıyı erken yakalamaya yardımcı olabilir. Log masking ve minimum erişim politikası da uygulanmalıdır. Sızıntı durumunda credential derhal revoke edilmeli ve kullanım geçmişi incelenmelidir.

Credential Sharing

Aynı API key'i beş farklı servisin kullanması authentication anlamını zayıflatır. Hedef servis isteğin hangi workload'dan geldiğini ayırt edemez. Bir servis ele geçirildiğinde diğer servislerle aynı yetki kullanılabilir. Her workload için unique identity ve permission scope tanımlamak daha güvenlidir. Audit log ancak bu ayrım olduğunda anlamlı hale gelir.

Rotation Problemi

Static secret rotation client ve server deployment'larının koordinasyonunu gerektirebilir. Eski key hemen kapatılırsa güncellenmemiş workload'lar çalışmayı durdurabilir. Uzun overlap süresi ise güvenlik riskini artırır. Otomatik credential issuance ve kısa TTL bu problemi farklı biçimde çözer. Static key kullanılacaksa dual-key rotation mekanizması önceden tasarlanmalıdır.

Coarse-Grained Authorization

API key çoğu zaman “anahtar doğruysa erişime izin ver” mantığıyla uygulanır. Bu model endpoint veya resource bazında ince yetki kontrolünü zorlaştırabilir. Her operation için ayrı key üretmek ise yönetimi hızla ağırlaştırır. OAuth scope veya policy engine gibi mekanizmalar daha zengin context sunabilir. Identity ve authorization birbirinden ayrıldığında policy daha anlaşılır hale gelir.

Auditability Eksikliği

Shared API key kullanıldığında loglarda yalnızca aynı credential identifier görülür. Hangi deployment veya servis örneğinin işlem yaptığı bilinmeyebilir. Incident sırasında root cause analizi zorlaşır. Unique workload identity ve correlation ID daha güçlü audit trail sağlar. Finansal veya regüle sistemlerde bu görünürlük kritik olabilir.

Secret Zero Problemi

Secret manager kullanmak secret'ların merkezi saklanmasını sağlar ancak ilk authentication credential'ının nereden geldiği sorusu devam eder. Workload secret manager'a erişebilmek için yine bir kimlik kanıtlamak zorundadır. Bu ilk güven noktasına secret zero denir. Eğer secret manager'a erişim için uzun ömürlü başka bir secret kullanılıyorsa problem yalnızca başka yere taşınmış olur. Workload identity ve platform attestation bu ilk credential ihtiyacını azaltmak için geliştirilmiş yaklaşımlardır.

Secret Manager Kullanmak Neden Tek Başına Yeterli Değildir?

Secret manager credential storage ve rotation açısından önemli fayda sağlar. Ancak workload secret manager'a kim olduğunu nasıl kanıtlayacağı sorusuna tek başına cevap vermez. Kubernetes secret, environment variable veya dosya içine yerleştirilen bootstrap credential yine korunmalıdır. Saldırgan bu ilk credential'ı ele geçirirse merkezi secret'a ulaşabilir. Workload identity secret manager erişimini deployment kimliğiyle bağlayarak bu zinciri güçlendirebilir.

İlk Credential Nereden Geliyor?

Her authentication zincirinin bir başlangıç trust noktası vardır. VM metadata, Kubernetes service account token, hardware identity veya signed workload attestation bu rolü üstlenebilir. Bu başlangıç credential'ının manuel olarak image içine eklenmesi risklidir. Platform tarafından runtime sırasında verilmesi daha güvenli olabilir. Trust root ve issuance süreci organization security modelinin parçası olarak açıkça belgelenmelidir.

Environment Variable Secret'ları

Environment variable secret kullanımı kolay olduğu için yaygındır. Ancak process dump, debug output veya yanlış loglama nedeniyle değer görünür hale gelebilir. Ayrıca statik variable uzun süre yaşayan workload içinde rotation sorununa yol açabilir. Runtime injection ve kısa ömürlü credential daha iyi alternatif olabilir. Environment variable zorunluysa erişim scope'u dar ve lifetime kısa tutulmalıdır.

Kubernetes Secret

Kubernetes Secret API secret değerlerini cluster içinde yönetmek için temel mekanizma sağlar. Ancak secret nesnesinin varlığı otomatik olarak güçlü workload identity anlamına gelmez. RBAC, encryption at rest ve secret mount policy ayrıca yapılandırılmalıdır. Workload'un secret'a erişim permission'ı minimum tutulmalıdır. Mümkün olan cloud servislerinde projected service account token veya workload federation daha iyi seçenek olabilir.

CI/CD Secret

CI/CD pipeline'larında static cloud key saklamak geçmişte yaygın bir yöntemdi. Pipeline sistemi ele geçirildiğinde bu key uzun süre kullanılabilir. OIDC federation sayesinde pipeline job kendi kısa ömürlü identity token'ıyla cloud STS üzerinden credential alabilir. Böylece repository veya CI secret store içinde kalıcı access key tutulmaz. Deployment pipeline güvenliği service authentication mimarisinin önemli bir parçasıdır.

Secret Zero'yu Workload Identity ile Ortadan Kaldırmak

Workload identity çalışan bileşenin platform metadata'sı veya attestation bilgisi üzerinden kimliğini kanıtlamasını sağlar. Trusted identity service bu doğrulamadan sonra kısa ömürlü credential verir. Workload'a önceden sabit secret gömmek gerekmez. Credential otomatik rotate edilebilir ve workload sona erdiğinde geçerliliğini kaybeder. Bu model secret zero problemini tamamen sihirli biçimde yok etmez ancak trust root'u yönetilebilir platform katmanına taşır.

OAuth 2.0 Client Credentials ile Service-to-Service Authentication

OAuth 2.0 Client Credentials, kullanıcı bağlamı gerektirmeyen backend entegrasyonlarında sık kullanılan bir authorization modelidir. Client kendi kimliğiyle token endpoint'e bağlanır ve hedef resource için access token ister. Authorization server client authentication işlemini doğrular ve izin verilen scope kapsamında token üretir. Resource server token'ın issuer, audience, expiration ve permission bilgilerini doğrular. Kurumsal servisler arası kimlik doğrulama ve API güvenliği hizmeti tasarlanırken bu model özellikle merkezi IdP bulunan yapılarda güçlü bir başlangıç noktası sağlar.

Client Credentials Flow Nasıl Çalışır?

Flow client'ın authorization server ile kimlik doğrulaması yapmasıyla başlar. Client hedef API için belirli scope veya audience talep eder. Authorization server kayıtlı policy'ye göre access token üretir. Client bu token'ı resource server'a gönderir. Resource server token'ı doğruladıktan sonra request authorization kararını verir.

Client Authentication

Client authentication client secret, private key assertion veya mTLS ile yapılabilir. Basit client secret operasyon kolaylığı sağlar fakat uzun ömürlü shared secret riski taşır. Private key yaklaşımında private key client'ta kalır ve signed assertion gönderilir. mTLS client certificate ile cryptographic doğrulama sağlar. Kurumsal senaryoda mümkün olduğunda shared secret bağımlılığını azaltmak daha güçlü bir modeldir.

Token Endpoint

Token endpoint authorization server'ın access token verdiği endpoint'tir. Client bu noktada kendi kimliğini doğrular ve grant type olarak client credentials kullanır. Endpoint rate limit, audit ve strong TLS ile korunmalıdır. Başarısız authentication denemeleri güvenlik monitoring sistemine aktarılabilir. Token endpoint yüksek availability gerektirir çünkü yeni credential issuance bu servise bağlıdır.

Access Token

Access token client'ın hedef resource üzerinde belirli permission ile işlem yapabildiğini gösterir. Token opaque veya JWT formatında olabilir. Lifetime mümkün olduğunca kısa tutulmalıdır. Audience yalnızca hedef API'yi göstermelidir. Scope isteğin gerçekleştirebileceği operasyonları sınırlar.

Resource Server

Resource server access token'ı alan hedef API'dir. Server token formatına göre local signature validation veya introspection yapabilir. Issuer ve audience mutlaka doğrulanmalıdır. Token geçerli olsa bile endpoint bazlı authorization ayrıca uygulanmalıdır. Resource server'ın authentication failure ve authorization denial olaylarını ayrı loglaması faydalıdır.

Client ID

Client ID secret değildir ve kayıtlı uygulama kimliğini tanımlar. Bir client ID'nin birden fazla bağımsız workload tarafından kontrolsüz paylaşılması audit görünürlüğünü azaltabilir. Environment veya deployment modeline göre ayrı client registration gerekebilir. Client ID permission tanımının doğrudan kendisi değildir. Authorization server policy hangi client'ın hangi scope'ları alabileceğini ayrıca belirler.

Client Secret

Client secret client authentication için kullanılan paylaşılan gizli değerdir. Uzun ömürlü tutulduğunda API key'e benzer riskler taşır. Secret manager kullanımı storage riskini azaltabilir ancak rotation yine yönetilmelidir. Private key veya workload identity destekleniyorsa daha güçlü seçenekler değerlendirilebilir. Kullanılan secret hiçbir zaman source repository içine eklenmemelidir.

Audience

Audience access token'ın hangi resource server için üretildiğini belirtir. Service A için verilen token'ın Service B tarafından kabul edilmesi cross-service token misuse riskini artırır. Bu nedenle target API aud claim'i strict biçimde kontrol etmelidir. Generic “internal-api” audience çok geniş erişim oluşturabilir. Service-specific audience daha düşük blast radius sağlar.

Scope

Scope token'ın hangi işlemler için kullanılabileceğini ifade eder. “read:orders” veya “write:payments” gibi dar scope'lar broad admin permission'a göre daha güvenlidir. Client yalnızca ihtiyaç duyduğu scope'u istemelidir. Authorization server client'ın allowed scope listesini sınırlar. Resource server ise endpoint davranışını scope ile eşleştirir.

Token Lifetime

Kısa token lifetime çalınmış credential'ın kullanım süresini azaltır. Ancak çok kısa TTL authorization server yükünü artırabilir ve outage durumunda availability etkisi yaratabilir. Beş dakika ile bir saat arasında değişen süreler sistem gereksinimine göre değerlendirilebilir. Automatic refresh veya yeniden token alma mekanizması bulunmalıdır. TTL kararı risk seviyesi ve operasyon dayanıklılığı birlikte düşünülerek verilmelidir.

Client Credentials Ne Zaman Doğru Seçimdir?

Client Credentials kullanıcı bağlamı olmadan çalışan servislerin başka API'lere kontrollü erişmesi gerektiğinde uygun bir modeldir. Backend API, worker, cron, batch job ve third-party makine entegrasyonu sık görülen örneklerdir. Model merkezi authorization server üzerinden client permission yönetimini kolaylaştırır. Ancak kullanıcı adına işlem yapılıyorsa delegation veya token exchange gibi farklı akışlar gerekebilir. Ayrıca client authentication yönteminin kendisi shared secret yerine workload identity veya private key ile güçlendirilebilir.

Backend-to-Backend API

Bir backend servisinin başka backend API'ye kendi adına erişmesi Client Credentials için doğal bir senaryodur. Client authorization server'dan hedef API için token alır. Token service-specific audience ve dar scope içerir. Hedef API kullanıcı session'ına bağlı kalmadan caller service identity'sini görür. İki servis arasında mTLS de eklenerek transport kimliği güçlendirilebilir.

Background Worker

Background worker genellikle kullanıcı request'i olmadan queue mesajı işler. Worker kendi workload identity veya OAuth client kimliğiyle downstream API'ye erişebilir. Permission yalnızca yaptığı iş için gerekli endpoint'lerle sınırlandırılmalıdır. Token kısa ömürlü olarak runtime'da alınmalıdır. Worker sayısı autoscaling ile arttığında statik credential dağıtımı yerine workload identity daha kolay yönetilir.

Cron Job

Cron job belirli zamanlarda otomatik çalışan scheduled workload'dur. Kullanıcı hesabına bağlı token kullanması uygun değildir. Job kendi service identity'siyle kısa ömürlü access token alabilir. Schedule süresi kısa olduğu için credential yalnızca çalışma anında üretilebilir. Job tamamlandığında token'ın kalan ömrü de sınırlı tutulur.

Batch Processing

Batch processing saatler sürebilen ve büyük data set üzerinde çalışan workload olabilir. İlk alınan token'ın tüm batch süresi boyunca yaşayacak şekilde çok uzun TTL verilmesi doğru değildir. Worker düzenli token refresh yapmalıdır. Authorization policy batch job kimliğini ayrı olarak tanımalıdır. İş tamamlandığında credential otomatik geçersiz hale gelmelidir.

Third-Party Machine Integration

Harici bir şirket veya sistem API'ye makine kimliğiyle erişiyorsa Client Credentials uygun olabilir. Her partner için ayrı client registration oluşturmak audit ve revocation işlemlerini kolaylaştırır. Shared global key kullanımından kaçınılmalıdır. Private key veya mTLS client authentication daha güçlü güven sağlayabilir. Scope yalnızca partner sözleşmesinde gerekli operasyonlarla sınırlandırılmalıdır.

Kullanıcı Bağlamı Gerekmeyen İşlemler

Servis kendi business responsibility'si kapsamında işlem yapıyorsa user delegation gerekmeyebilir. Örneğin nightly report generation veya cache warm-up kullanıcı kimliği olmadan çalışabilir. Bu durumda service identity ve application permission yeterlidir. Kullanıcı token'ı eklemek gereksiz privilege ve audit belirsizliği yaratabilir. Authentication modeli işlemin gerçek actor yapısına göre seçilmelidir.

Client Secret Kullanmak Zorunlu mu?

OAuth Client Credentials adı nedeniyle client secret kullanmanın zorunlu olduğu düşünülebilir, ancak bu doğru değildir. Client authentication private key assertion, mTLS veya platform workload identity ile yapılabilir. Bu yöntemler shared secret saklama ve rotation yükünü azaltabilir. Özellikle cloud-native workload'larda identity federation OAuth token issuance ile birleştirilebilir. Kurumsal sistemlerde uzun ömürlü client secret yalnızca mevcut altyapının başka seçenek sunmadığı durumlarda tercih edilmelidir.

client_secret_basic

client_secret_basic client ID ve secret'ın HTTP Basic authentication üzerinden token endpoint'e gönderildiği yöntemdir. Basit ve geniş desteklidir. Ancak secret her client instance tarafından bilinmek zorundadır. Secret manager ve otomatik rotation olmadan operasyon riski büyür. Modern platformlarda private key veya workload identity seçenekleri değerlendirilebilir.

Private Key Tabanlı Client Authentication

Private key yaklaşımında client secret paylaşmak yerine kendi private key'iyle signed assertion üretir. Authorization server kayıtlı public key üzerinden assertion'ı doğrular. Private key network üzerinden gönderilmez. Key rotation yine yönetilmelidir ancak shared secret'a göre daha güçlü separation sağlar. Hardware-backed key storage bulunan ortamlarda güvenlik daha da artırılabilir.

mTLS Client Authentication

mTLS client authentication token endpoint'e bağlanan client'ın certificate ile doğrulanmasını sağlar. Authorization server certificate identity ile client registration'ı eşleştirir. Shared secret taşınmaz. Certificate issuance ve rotation otomatik yapılırsa operasyon daha güvenli hale gelir. Certificate-bound token ile aynı anahtar token kullanımına da bağlanabilir.

Workload Identity ile OAuth

Workload identity ile OAuth birleştirildiğinde servis platform kimliğiyle authorization server'a güvenilir assertion sunabilir. Authorization server bu assertion'ı doğrulayıp hedef API için access token üretir. Uzun ömürlü client secret gerekmez. Cloud STS ve federated identity modelleri bu yaklaşımı destekleyebilir. Böylece authentication platform identity'den, authorization ise OAuth token'dan gelir.

Long-Lived Shared Secret'tan Kaçınmak

Uzun ömürlü secret paylaşımı sızıntı ve rotation riskini büyütür. Workload identity, private key veya short-lived credential varsa bunlar tercih edilmelidir. Legacy sistem nedeniyle secret gerekiyorsa her client için unique değer kullanılmalıdır. Rotation otomatik ve düzenli olmalıdır. Kullanılmayan secret'lar inventory üzerinden tespit edilip kaldırılmalıdır.

JWT Service Authentication'da Nasıl Kullanılır?

JWT servis authentication ve authorization bağlamını imzalı claim set'i olarak taşımak için kullanılabilir. Token authorization server tarafından access token olarak verilebilir veya belirli protokollerde client assertion görevi görebilir. JWT'nin avantajı resource server'ın signature ve claim doğrulamasını lokal yapabilmesidir. Dezavantajı ise yanlış validation uygulamalarının ciddi güvenlik açığı oluşturabilmesidir. Token formatı ile güvenlik modeli birbirine karıştırılmamalıdır, çünkü JWT yalnızca bir taşıma ve imzalama formatıdır.

Signed JWT

Signed JWT header, payload ve cryptographic signature bölümlerinden oluşur. Signature token'ın trusted issuer tarafından üretildiğini ve içerik üzerinde değişiklik yapılmadığını doğrular. Confidentiality sağlamaz, payload çoğu durumda okunabilir. Bu nedenle hassas secret JWT claim içine yazılmamalıdır. Trust kararı issuer key ve claim validation sonucuna dayanmalıdır.

Self-Contained Access Token

Self-contained token permission ve identity bilgilerini kendi içinde taşır. Resource server her request'te IdP'ye introspection çağrısı yapmak zorunda değildir. Bu yapı performans ve availability avantajı sağlar. Ancak token revoke edildiğinde expiration süresine kadar geçerli kalabilir. Kısa TTL bu riski azaltır.

Issuer

Issuer token'ı hangi identity provider'ın verdiğini belirtir. Resource server yalnızca açıkça güvenilen issuer değerlerini kabul etmelidir. Signature valid olsa bile beklenmeyen issuer token'ı reddedilmelidir. Multi-tenant yapılarda issuer kontrolü tenant isolation için önemlidir. Issuer discovery config'in güvenilir kaynaktan yüklenmesi gerekir.

Subject

Subject token'ın adına üretildiği kimliği ifade eder. Service token'ında bu değer client veya workload identity olabilir. User delegation senaryosunda subject kullanıcıyı temsil edebilir ve actor ayrı claim'de taşınabilir. Subject tek başına permission anlamına gelmez. Authorization policy scope ve diğer context bilgilerini ayrıca değerlendirmelidir.

Audience

Audience token'ın hedef resource server'ını belirtir. Bir servise verilen token'ın başka serviste kabul edilmemesi gerekir. Resource server aud claim'i kendi beklenen identifier'ı ile eşleştirmelidir. Audience doğrulaması token replay ve cross-service misuse riskini azaltır. Generic audience yalnızca bilinçli tasarlanmış ortak gateway senaryolarında kullanılmalıdır.

Expiration

exp claim token'ın son geçerlilik zamanını belirtir. Resource server kendi saatini güvenilir NTP kaynağıyla senkron tutmalıdır. Küçük clock skew toleransı uygulanabilir. Expiration kontrolü atlanmamalıdır. Çok uzun token ömrü theft riskini büyütür.

Scope / Permissions

Scope token'ın kullanılabileceği operation set'ini ifade eder. Resource server endpoint bazında gerekli scope kontrolünü yapmalıdır. Token valid diye bütün API'ye erişim verilmemelidir. Service-specific permission isimleri anlaşılır audit sağlar. Çok geniş “admin” scope kullanımından kaçınılmalıdır.

JWT Doğrulamasında Kontrol Edilmesi Gerekenler

JWT doğrulamasında yalnızca signature kontrol etmek yeterli değildir. Token doğru issuer'dan gelmeli, hedef resource için üretilmiş olmalı ve halen geçerli zaman aralığında bulunmalıdır. Allowed algorithm listesi application config içinde sabitlenmelidir. Scope, token type ve gerekli claim'ler endpoint gereksinimine göre kontrol edilmelidir. Validation kütüphanesi güvenilir olsa bile güvenlik policy uygulama tarafından açık biçimde tanımlanmalıdır.

Signature

Signature token içeriğinin trusted signing key tarafından imzalandığını doğrular. Public key JWKS üzerinden alınabilir. Invalid signature token doğrudan reddedilmelidir. Signature doğrulaması devre dışı bırakılmış debug config production'a taşınmamalıdır. Key source mutlaka trusted issuer ile ilişkilendirilmelidir.

iss

iss claim beklenen identity provider identifier'ıyla tam eşleşmelidir. Başka tenant veya test IdP tarafından imzalanmış token kabul edilmemelidir. Multi-issuer destekleniyorsa allowlist açıkça tanımlanmalıdır. Dynamic issuer kabulü SSRF veya trust confusion riskine yol açabilir. Issuer validation authentication pipeline'ın temel parçasıdır.

aud

aud claim target API'nin token'ın gerçek hedefi olduğunu gösterir. Resource server yalnızca kendisine ait audience değerini kabul etmelidir. Aynı organization içindeki başka API için verilmiş token geçerli olsa bile reddedilmelidir. Bu kontrol blast radius'u azaltır. Token exchange service-specific audience üretmek için kullanılabilir.

exp

exp kontrolü token'ın süresi dolup dolmadığını belirler. Expired token hiçbir business işlemi için kabul edilmemelidir. Clock skew yalnızca birkaç dakika gibi sınırlı toleransla yönetilebilir. Çok geniş tolerans token lifetime politikasını anlamsızlaştırır. Expiration failure ayrı telemetry olarak izlenebilir.

nbf

nbf token'ın hangi zamandan itibaren geçerli olduğunu belirtir. Token gelecekte kullanılmak üzere üretildiyse erken kullanım engellenir. Saat farkı nedeniyle küçük tolerans gerekebilir. nbf claim varsa validation uygulanmalıdır. Kullanılmıyorsa uygulama library default davranışı açıkça bilinmelidir.

Allowed Algorithm

Token header içindeki alg değeri doğrudan güvenilir kabul edilmemelidir. Uygulama yalnızca beklenen güçlü algoritmaların allowlist'ini tutmalıdır. Public key ile symmetric algorithm karışıklığı gibi geçmiş JWT açıkları bu kontrolün önemini göstermiştir. Algorithm migration planlı yapılmalıdır. Eski ve yeni algoritma geçiş süresi kısa tutulmalıdır.

Scope / Claims

Token signature açısından geçerli olsa bile gerekli permission claim'i yoksa request reddedilmelidir. Claim formatı merkezi authorization standardıyla uyumlu olmalıdır. Resource server yalnızca gerçekten ihtiyaç duyduğu claim'leri kullanmalıdır. Kullanıcı tarafından kontrol edilebilir claim ile security decision verilmemelidir. Policy testleri farklı claim kombinasyonlarını kapsamalıdır.

Token Type

ID token ile access token farklı amaçlara hizmet eder. API'nin yanlışlıkla ID token kabul etmesi güvenlik problemi yaratabilir. typ, token endpoint metadata veya issuer policy token type ayrımına yardımcı olabilir. Resource server yalnızca kendi authentication kullanımına uygun token türünü kabul etmelidir. Token exchange çıktıları da açık token type ile işlenmelidir.

JWKS ve Signing Key Rotation

JWT kullanan sistemlerde signing key hiçbir zaman sonsuza kadar sabit kalmamalıdır. Identity provider yeni key yayınlayabilir ve eski key'i kontrollü geçiş sürecinde kaldırabilir. Resource server JWKS endpoint'ten public key set'i alarak signature doğrular. Local cache IdP'ye her request'te bağımlılığı azaltır. Unknown kid durumunda kontrollü refresh yapılması ve IdP outage sırasında mevcut cache davranışının önceden tasarlanması gerekir.

JWKS Endpoint

JWKS endpoint issuer'ın aktif public signing key'lerini yayınlar. Resource server bu endpoint'i trusted issuer config üzerinden öğrenmelidir. Endpoint TLS ile korunmalıdır. Her request'te yeniden çağırmak performans ve availability açısından doğru değildir. Local cache ve uygun refresh policy kullanılmalıdır.

kid

kid JWT header içinde hangi signing key'in kullanıldığını belirtir. Validator local cache içinden ilgili key'i seçebilir. Bilinmeyen kid yeni rotation anlamına gelebilir. Ancak her unknown kid için sınırsız network request yapmak DoS riskine yol açabilir. Refresh rate limit ve negative cache yaklaşımı değerlendirilebilir.

Local Key Cache

Local key cache JWT validation'ın IdP outage sırasında devam edebilmesini sağlar. Cache TTL çok kısa olursa gereksiz network bağımlılığı oluşur. Çok uzun olursa kaldırılmış key'in kabul süresi uzayabilir. Cache policy signing key rotation sıklığıyla uyumlu olmalıdır. Uygulama restart sonrasında cache warm-up davranışı da test edilmelidir.

Unknown Key Refresh

Yeni signing key devreye alındığında resource server unknown kid görebilir. Bu durumda bir kez JWKS refresh yapılması normaldir. Saldırgan rastgele kid değerleriyle sürekli refresh tetiklememelidir. Rate limit ve kısa negative cache bu riski azaltır. Refresh başarısız olduğunda token fail-closed biçimde reddedilmelidir.

Key Rotation

Key rotation yeni public key'in önceden JWKS set'e eklenmesiyle daha güvenli yapılabilir. Ardından yeni token'lar yeni key ile imzalanır. Eski token'ların lifetime süresi dolduktan sonra eski key kaldırılır. Bu overlap kesintisiz geçiş sağlar. Acil compromise durumunda normal overlap süresi uygulanmayabilir.

IdP Outage Sırasında Davranış

IdP erişilemiyorsa mevcut cache'teki signing key'lerle halen geçerli token doğrulaması devam edebilir. Yeni token issuance ise etkilenebilir. Resource server'ın cached key süresi ve fail behavior önceden belirlenmelidir. Kritik operasyonlar için fail-open tercih edilmesi ciddi risk yaratabilir. Outage senaryosu chaos testleriyle düzenli doğrulanmalıdır.

Bearer Token Riskleri

Bearer token'ı elinde bulunduran taraf token geçerli olduğu sürece onu kullanabilir. Bu nedenle token theft ve replay servisler arası authentication tasarımında önemli tehditlerdir. Kısa TTL riski azaltır ancak tamamen ortadan kaldırmaz. Audience validation token'ın başka serviste kullanılmasını sınırlar. Daha yüksek güvenlik gerektiren sistemlerde sender-constrained token kullanımı değerlendirilebilir.

Token Theft

Bearer token memory dump, log, proxy veya yanlış instrumentation üzerinden sızabilir. Token şifreli transport içinde gönderilse bile endpoint compromise riski devam eder. Kısa lifetime ve minimum scope theft etkisini sınırlar. Secret redaction ve secure observability pipeline uygulanmalıdır. Yüksek riskli API'lerde proof-of-possession yaklaşımı düşünülebilir.

Replay Attack

Saldırgan ele geçirdiği bearer token'ı expiration süresince başka bağlantıdan tekrar kullanabilir. Token'ın kendisi sender kimliğine bağlı değildir. mTLS-bound veya DPoP token bu sorunu azaltmayı hedefler. Nonce ve replay cache bazı protokollerde ek koruma sağlayabilir. Replay tehdidi özellikle ödeme ve privileged operation senaryolarında değerlendirilmelidir.

Token Log Leakage

Authorization header veya query parameter'ın loglanması token sızıntısının yaygın nedenidir. Application, reverse proxy ve tracing sistemleri header redaction uygulamalıdır. Token hiçbir zaman URL query içinde taşınmamalıdır. Incident sırasında log retention ve erişim kapsamı da değerlendirilmelidir. Token leakage testleri security test suite içine eklenebilir.

Cross-Service Token Misuse

Service A için verilen token Service B tarafından da kabul edilirse çalınmış token'ın etkisi büyür. Strict audience validation bu riski azaltır. Her resource server unique audience kullanmalıdır. Broad internal token yalnızca çok özel gateway tasarımında düşünülmelidir. Token exchange downstream için daha dar token üretmeye yardımcı olur.

Audience Kontrolünün Önemi

Audience claim token'ın hangi API için üretildiğini belirtir. Resource server bu kontrolü atladığında herhangi bir internal token'ı kabul edebilir. Bu durum lateral movement riskini artırır. Service-specific audience ve scope birlikte kullanılmalıdır. Automated security test wrong audience token'ın reddedildiğini doğrulamalıdır.

Sender-Constrained Access Token Nedir?

Sender-constrained access token, token kullanımını belirli cryptographic key veya client certificate sahipliğine bağlayan modeldir. Bearer token çalındığında tek başına yeterli olmaz. Kullanıcı veya servis token'a bağlı private key'i de kanıtlamak zorundadır. mTLS-bound access token ve DPoP bu yaklaşımın iki örneğidir. Yüksek değerli işlemler ve regulated API'lerde replay riskini azaltmak için değerlendirilebilir.

Bearer Token'dan Farkı

Bearer token “token kimdeyse kullanabilir” modeline dayanır. Sender-constrained token ise belirli sender'ın key sahipliğini doğrular. Bu nedenle network veya log üzerinden çalınan token başka client tarafından kolayca kullanılamaz. Ek cryptographic işlem ve key lifecycle yönetimi gerekir. Güvenlik kazanımı risk seviyesine göre değerlendirilmelidir.

Proof-of-Possession

Proof-of-Possession client'ın token ile ilişkilendirilmiş private key'e sahip olduğunu kanıtlamasıdır. Proof request'e özgü signature veya TLS client certificate üzerinden gösterilebilir. Token issuer public key veya certificate binding bilgisini token'a ekler. Resource server iki bilgiyi birlikte doğrular. Bu model replay riskini ciddi biçimde azaltabilir.

mTLS-Bound Access Token

mTLS-bound access token client certificate ile token arasında cryptographic binding kurar. Authorization server token'ı verirken kullanılan certificate bilgisini token içine yansıtır. Resource server request'teki mTLS certificate ile token binding bilgisini karşılaştırır. Token başka client'a kopyalansa bile certificate private key olmadan kullanılamaz. Kurumsal API'lerde güçlü authentication gerektiren işlemler için uygundur.

DPoP

DPoP client'ın HTTP request'e özel signed proof göndermesine dayanır. Proof method, URL ve unique identifier gibi bilgileri içerir. Access token client public key'iyle ilişkilendirilir. Resource server proof signature ve token binding kontrolünü yapar. Certificate altyapısı kurmadan application-layer proof gereken bazı senaryolarda değerlendirilebilir.

Hangi Kurumsal Senaryolarda Gereklidir?

Sender-constrained token her API için zorunlu değildir. Finansal işlem, yüksek değerli yönetim API'si veya hassas cross-organization entegrasyonunda ek koruma anlamlı olabilir. Basit internal read-only API'de operasyon maliyeti faydadan yüksek olabilir. Threat model token theft ve replay etkisini değerlendirmelidir. Teknoloji seçimi risk odaklı yapılmalıdır.

Mutual TLS (mTLS) Nedir?

Mutual TLS iki tarafın da TLS handshake sırasında certificate sunarak kimliğini doğruladığı iletişim modelidir. Normal TLS'te client server certificate'ını doğrular, mTLS'te server da client certificate'ını doğrular. Böylece encrypted channel ile workload authentication aynı transport katmanında birleştirilebilir. Certificate identity service authorization policy'nin girdisi olarak kullanılabilir. Otomatik PKI ve rotation mekanizması bulunduğunda mikroservis platformlarında güçlü bir temel sağlar.

Normal TLS ile mTLS Arasındaki Fark

Normal TLS web tarayıcısının sunucunun gerçek kimliğini doğrulaması için yaygın olarak kullanılır. Client genellikle kendi certificate'ını sunmaz. mTLS ise client'ın da trusted CA tarafından imzalanmış certificate sunmasını ister. Böylece server caller workload'u cryptographic olarak doğrulayabilir. İki model de encryption sağlar ancak authentication yönü farklıdır.

Server Authentication

Server authentication client'ın doğru server'a bağlandığını doğrulamasını sağlar. Server certificate hostname ve trusted CA chain üzerinden kontrol edilir. Expired veya invalid certificate kabul edilmemelidir. Internal servislerde de hostname veya service identity doğrulaması önemlidir. TLS inspection veya proxy kullanılıyorsa trust model açıkça tanımlanmalıdır.

Client Authentication

Client authentication server'ın bağlanan workload'un certificate'ını doğrulamasıdır. Certificate trusted CA tarafından verilmiş olmalıdır. Subject veya SAN içindeki service identity authorization için kullanılabilir. Certificate çalınmasını önlemek için private key workload scope'unda korunmalıdır. Kısa certificate lifetime ve otomatik rotation riski azaltır.

Mutual Authentication

Mutual authentication iki tarafın da karşı taraf kimliğine güven doğrulaması yapmasıdır. Client yanlış server'a, server da yetkisiz client'a bağlantı kurmaz. Bu yaklaşım east-west traffic için güçlü temel sağlar. Yine de business permission mTLS tarafından otomatik belirlenmez. Authorization policy ayrı katmanda uygulanmalıdır.

Encryption

mTLS transport üzerindeki veriyi symmetric session key ile şifreler. Network üzerinde paketleri gören saldırgan application payload'ı doğrudan okuyamaz. Modern cipher suite ve TLS version policy uygulanmalıdır. Encryption endpoint compromise riskini ortadan kaldırmaz. Application secret handling yine güvenli olmalıdır.

Integrity

TLS integrity mekanizmaları trafik üzerinde yetkisiz değişiklik yapılmasını tespit eder. Böylece man-in-the-middle saldırısının önemli bölümü engellenir. Certificate trust chain doğru doğrulanmalıdır. Invalid certificate bypass eden debug config production'da bulunmamalıdır. Service mesh kullanılıyorsa proxy'nin TLS policy'si merkezi olarak izlenmelidir.

mTLS Nasıl Çalışır?

mTLS bağlantısı standart TLS handshake üzerine client certificate doğrulamasını ekler. Client ve server destekledikleri protocol seçeneklerini paylaşır. Server certificate gönderir ve client trusted CA üzerinden doğrular. Server client certificate talep eder ve client kendi kimlik belgesini sunar. Başarılı doğrulama sonrasında taraflar ortak session key oluşturur ve application trafiği encrypted channel üzerinden akar.

TLS Handshake

TLS handshake tarafların protocol version, cipher ve cryptographic parametreler üzerinde anlaşmasını sağlar. Aynı süreç certificate doğrulamasını da içerir. Modern TLS sürümleri performans ve güvenlik açısından eski sürümlere göre avantaj sağlar. Handshake CPU maliyeti connection reuse ile azaltılabilir. Session resumption yoğun servis trafiğinde yararlı olabilir.

Client Hello

Client Hello client'ın desteklediği TLS sürümleri, cipher seçenekleri ve bağlantı parametrelerini server'a bildirir. Modern handshake ephemeral key exchange bilgilerini de taşır. Server ortak güvenli seçeneklerden birini seçer. Güvensiz eski protocol sürümleri policy ile kapatılmalıdır. Service mesh bu policy'yi merkezi olarak uygulayabilir.

Server Certificate

Server certificate server identity'sini ve public key bilgisini taşır. Client certificate chain'i trusted CA root'a kadar doğrular. Hostname veya service identity eşleşmesi kontrol edilir. Expiration ve gerektiğinde revocation bilgisi değerlendirilir. Validation başarısızsa bağlantı kurulmaz.

Client Certificate

mTLS'te server client'tan certificate ister. Client workload identity'sini temsil eden certificate'ı ve key ownership proof'unu sunar. Server certificate chain ve identity bilgisini doğrular. Certificate başka workload tarafından paylaşılmamalıdır. Otomatik issuance unique identity sağlamayı kolaylaştırır.

Certificate Verification

Certificate verification signature chain, validity period ve identity alanlarını kontrol eder. Trust bundle hangi CA'ların kabul edildiğini belirler. Expired veya unknown CA certificate reddedilir. Authorization için certificate identity policy engine'e aktarılabilir. Trust bundle güncellemeleri kontrollü ve otomatik dağıtılmalıdır.

Session Key

Handshake tamamlandığında taraflar application trafiğini şifrelemek için symmetric session key üzerinde anlaşır. Symmetric encryption performans açısından public key işlemlerinden daha verimlidir. Key yalnızca ilgili session için geçerlidir. Perfect forward secrecy destekleyen cipher tercih edilmelidir. Session lifetime security ve performance dengesine göre ayarlanır.

Encrypted Channel

Encrypted channel kurulduktan sonra HTTP, gRPC veya başka application protocol trafiği güvenli bağlantı üzerinden taşınır. Network üzerinde payload'ın okunması veya değiştirilmesi zorlaşır. Buna rağmen endpoint application logları hassas veriyi açığa çıkarabilir. TLS yalnızca transit protection sağlar. Veri güvenliği uygulama ve storage katmanında ayrıca düşünülmelidir.

mTLS'nin Service-to-Service Authentication Avantajları

mTLS servisler arasında network seviyesine yakın güçlü cryptographic identity sağlar. İki taraflı authentication ve encryption aynı handshake içinde gerçekleşir. Certificate identity service-level policy için kullanılabilir. Service mesh veya workload identity platformu certificate lifecycle'ını otomatik yönetirse geliştirici kodunun certificate operasyonuna girmesi gerekmez. Bu yaklaşım özellikle yüksek sayıda east-west servis çağrısı bulunan Kubernetes ve multi-cluster yapılarda güçlü bir güvenlik katmanı sunar.

Cryptographic Identity

Certificate identity kolay taklit edilen header veya IP bilgisinden farklı olarak private key sahipliğiyle doğrulanır. Workload trusted CA tarafından verilen certificate kullanır. Hedef servis certificate chain ve identity bilgisini kontrol eder. Private key workload dışına çıkarılmamalıdır. Kısa ömürlü certificate theft riskini azaltır.

Two-Way Authentication

mTLS hem client hem server kimliğinin doğrulanmasını sağlar. Client yalnızca doğru hedefe, server yalnızca trusted workload'a bağlantı kabul eder. Bu yapı internal API spoofing riskini azaltır. Federation varsa farklı trust domain'ler kontrollü biçimde birbirini tanıyabilir. Authorization yine ayrıca uygulanmalıdır.

Encryption in Transit

Tüm service traffic TLS ile şifrelenir. Internal network üzerinde packet capture yapan taraf application payload'ı doğrudan okuyamaz. Bu koruma database credential veya kişisel veri taşıyan isteklerde önemlidir. TLS policy eski cipher ve protocol'leri engellemelidir. Observability araçları encrypted traffic nedeniyle identity metadata üzerinden çalışmalıdır.

MITM Koruması

Doğru certificate validation man-in-the-middle saldırılarının önemli bölümünü engeller. Saldırgan trusted certificate ve private key olmadan geçerli taraf gibi davranamaz. Trust root compromise edilirse risk değişir. Bu nedenle CA güvenliği mTLS modelinin kritik parçasıdır. Emergency root rotation planı önceden hazırlanmalıdır.

Identity-Based Access Policy

mTLS certificate içindeki service identity authorization policy'nin girdisi olabilir. “payments-service yalnızca ledger-service'e POST yapabilir” gibi rule tanımlanabilir. Network IP değişse bile identity aynı kalabilir. Policy workload ve environment bilgisiyle zenginleştirilebilir. Bu yaklaşım dinamik infrastructure için IP allowlist'e göre daha sürdürülebilirdir.

mTLS Tek Başına Authorization Sağlar mı?

mTLS caller identity'yi doğrular fakat o caller'ın hangi business işlemi yapabileceğine otomatik karar vermez. Certificate sahibi olmak yalnızca kimlik kanıtıdır. Authorization endpoint, HTTP method, resource ve gerekiyorsa kullanıcı bağlamı üzerinden ayrıca uygulanmalıdır. Service mesh identity-level policy sağlayabilir ancak uygulama içindeki hassas resource kararları yine application veya merkezi policy engine tarafından verilmelidir. Authentication ile authorization ayrımı bu noktada özellikle önemlidir.

Authentication ve Authorization Ayrımı

Authentication “kimsin?” sorusuna cevap verir. Authorization ise “ne yapabilirsin?” sorusunu cevaplar. mTLS ilk soruya güçlü yanıt sağlar. İkinci soru için ACL, RBAC, ABAC veya policy engine gerekir. Bu ayrım tasarım ve audit belgelerinde açık tutulmalıdır.

Certificate Identity

Certificate identity service name veya SPIFFE ID gibi workload bilgisini taşıyabilir. Bu bilgi policy decision için güvenilir input olur. Ancak certificate'a business role eklemek her zaman iyi model değildir. Identity uzun ömürlü kavram, permission ise daha sık değişen policy olabilir. İki yaşam döngüsünü ayırmak operasyonu kolaylaştırır.

Service-Level Policy

Service-level policy hangi workload'un hangi servise bağlanabileceğini belirler. Mesh AuthorizationPolicy veya gateway policy bu kontrolü uygulayabilir. Default-deny modeli güvenli başlangıç sağlar. Yeni dependency açık allow rule ile eklenir. Kullanılmayan service edge'leri dependency graph üzerinden kaldırılabilir.

HTTP Method / Resource Yetkileri

Bir servisin hedef API'ye bağlanabilmesi tüm endpoint'lere erişmesi gerektiği anlamına gelmez. GET ve POST farklı risk seviyesine sahip olabilir. Resource path veya operation bazında policy tanımlanabilir. Çok ayrıntılı network policy uygulamak zorlaşırsa application authorization kullanılabilir. Policy seviyesi business riskine göre seçilmelidir.

User-Level Authorization

Servis bir kullanıcı adına işlem yapıyorsa mTLS yalnızca workload kimliğini doğrular. Kullanıcının ilgili resource üzerinde yetkili olup olmadığı ayrıca kontrol edilmelidir. User token veya exchanged token bu bağlamı taşıyabilir. Service B hem caller service hem user permission bilgisini değerlendirebilir. Bu yapı impersonation riskini azaltır.

mTLS + OAuth Birlikte Kullanılabilir mi?

mTLS ile OAuth birbirlerinin rakibi olmak zorunda değildir. mTLS transport seviyesinde workload identity ve encrypted channel sağlar. OAuth access token application seviyesinde audience, scope ve delegation context taşıyabilir. İki mekanizma birlikte kullanıldığında service identity ile business authorization ayrı katmanlarda güçlü biçimde temsil edilir. Yüksek güvenlikli API'lerde token certificate'a bağlanarak replay koruması da güçlendirilebilir.

mTLS → Workload Identity

mTLS connection'ın hangi workload tarafından açıldığını certificate üzerinden doğrular. Identity platformu certificate'ı deployment'a otomatik verebilir. Hedef servis source workload'u güvenilir biçimde belirler. Bu kimlik OAuth token içindeki actor bilgisiyle karşılaştırılabilir. Mismatch durumunda request reddedilebilir.

OAuth Token → Authorization Context

OAuth token target resource, scope ve varsa user delegation bilgisini taşır. Resource server access token'ın kendisi için üretildiğini doğrular. mTLS caller'ın gerçekten token'ı kullanmaya yetkili workload olup olmadığını destekleyebilir. Böylece network kimliği ile application permission birlikte değerlendirilir. Audit kaydı iki bağlamı da saklayabilir.

Defense in Depth

Defense in depth tek kontrolün hata vermesi durumunda diğer katmanın saldırıyı sınırlamasını hedefler. mTLS channel ve workload identity sağlar. Token dar audience ve scope sağlar. Network policy gereksiz bağlantıları engelleyebilir. Application authorization en son business rule'u uygular.

Certificate-Bound Access Token

Certificate-bound token token'ın belirli client certificate ile kullanılmasını zorunlu hale getirir. Authorization server token issuance sırasında certificate binding bilgisini ekler. Resource server aynı certificate'ın request'te kullanıldığını doğrular. Çalınmış token başka connection üzerinde çalışmaz. Bu model hassas service-to-service API'lerde güçlü replay koruması sağlar.

PKI Kurumsal Ölçekte Nasıl Tasarlanmalıdır?

mTLS'in başarısı yalnızca certificate kullanmakla değil, certificate lifecycle'ının güvenli ve otomatik yönetilmesiyle ilgilidir. Root CA mümkün olduğunca güçlü koruma altında tutulmalı ve günlük issuance doğrudan root üzerinden yapılmamalıdır. Intermediate CA operasyonel issuance görevini üstlenebilir. Trust bundle, certificate lifetime, rotation ve revocation süreçleri merkezi olarak yönetilmelidir. Büyük mikroservis ortamında manuel certificate üretmek yerine workload identity control plane tercih edilmelidir.

Root CA

Root CA trust zincirinin en yüksek güven noktasıdır. Compromise edilmesi bütün issued identity'lerin güvenilirliğini etkileyebilir. Root key mümkünse offline veya hardware-backed ortamda korunmalıdır. Günlük workload certificate issuance root üzerinden yapılmamalıdır. Recovery prosedürü düzenli olarak test edilmelidir.

Intermediate CA

Intermediate CA root tarafından imzalanır ve operasyonel certificate issuance görevini üstlenir. Farklı environment veya region için ayrı intermediate kullanılabilir. Bu ayrım compromise durumunda blast radius'u azaltabilir. Intermediate lifetime root'tan daha kısa tutulmalıdır. Rotation trust bundle güncellemesiyle koordineli yapılmalıdır.

Trust Bundle

Trust bundle workload'ların hangi CA chain'lerine güveneceğini belirler. Federation durumunda birden fazla trust root içerebilir. Bundle güncellemeleri bütün workload'lara güvenilir ve hızlı şekilde dağıtılmalıdır. Eski root kaldırılmadan önce yeni root'un yayılması gerekir. Emergency rotation sırasında propagation süresi kritik hale gelir.

Certificate Issuance

Certificate issuance workload attestation sonucuna bağlanmalıdır. Bir kullanıcı manuel form doldurarak production service certificate almamalıdır. Platform deployment kimliği doğrulandıktan sonra certificate otomatik üretilebilir. Subject identity standard naming convention kullanmalıdır. Issuance olayları audit log'a kaydedilmelidir.

Certificate Lifetime

Kısa certificate lifetime çalınmış credential'ın kullanım süresini sınırlar. Otomatik rotation varsa saatler veya günler düzeyinde lifetime uygulanabilir. Manuel süreç varsa çok kısa lifetime availability riski yaratabilir. En doğru süre platform yeteneğine göre belirlenmelidir. Expiration monitoring mutlaka bulunmalıdır.

Automatic Rotation

Automatic rotation certificate süresi dolmadan yeni credential üretir ve workload'a dağıtır. Uygulama mümkünse connection restart etmeden yeni certificate kullanabilmelidir. Eski certificate kısa grace period boyunca geçerli kalabilir. Rotation failure telemetry ile izlenmelidir. Bu süreç manuel operasyonu büyük ölçüde azaltır.

Revocation

Certificate compromise edildiğinde normal expiration beklenemeyebilir. Revocation list, OCSP veya kısa lifetime yaklaşımı kullanılabilir. Çok kısa certificate ömrü bazı yapılarda explicit revocation ihtiyacını azaltır. Critical incident durumunda trust root veya intermediate rotation gerekebilir. Revocation davranışı chaos testlerinde denenmelidir.

Manuel Certificate Yönetimi Neden Ölçeklenmez?

On veya yirmi servis için manuel certificate yönetimi yapılabilir görünse de yüzlerce workload ve autoscaling ortamında hızla sürdürülemez hale gelir. Yeni instance oluşturulduğunda certificate provisioning otomatik olmalıdır. Expiration tarihlerini spreadsheet üzerinden takip etmek outage riskini artırır. Trust store ve rotation işlemleri bütün fleet üzerinde koordinasyon gerektirir. Workload identity platformu certificate lifecycle'ını deployment yaşam döngüsüyle birleştirdiğinde operasyon daha güvenilir hale gelir.

Certificate Provisioning

Manuel provisioning geliştiricinin certificate talep etmesi ve dosyayı workload'a kopyalaması gibi adımlar içerir. Bu süreç hem yavaştır hem yanlış dağıtım riski taşır. Autoscaling workload için pratik değildir. Attestation sonrası otomatik issuance daha iyi modeldir. Certificate hiçbir zaman image içine sabit gömülmemelidir.

Expiration

Manuel certificate'lar çoğu zaman uzun lifetime ile verilir çünkü sık yenilemek zordur. Bu durum sızıntı etkisini büyütür. Expiration yaklaşınca unutulan certificate production outage oluşturabilir. Merkezi monitoring yaklaşan süresi dolumlarını göstermelidir. Otomatik rotation uzun lifetime ihtiyacını azaltır.

Rotation

Rotation eski ve yeni certificate'ın kontrollü geçişini gerektirir. Manuel süreçte deployment sırası ve trust store güncellemesi hata kaynağıdır. Otomatik agent veya mesh proxy yeni certificate'ı kesintisiz kullanabilir. Rotation düzenli yapılırsa emergency durumda süreç daha tanıdık olur. Yıllarca hiç rotate edilmeyen PKI incident anında ciddi risk taşır.

Distribution

Certificate ve private key'in workload'a güvenli dağıtılması gerekir. E-posta, shared file veya build artifact ile dağıtım yapılmamalıdır. Runtime API veya secure volume daha iyi yöntemdir. Private key mümkün olduğunda workload memory veya protected filesystem dışına çıkarılmamalıdır. Distribution kanalı da authentication gerektirir.

Trust Store Güncellemesi

Yeni CA veya intermediate eklendiğinde bütün workload trust store'larının güncellenmesi gerekir. Dağıtımın bir bölümü başarısız olursa servisler arası bağlantı kopabilir. Version-controlled trust bundle ve otomatik rollout kullanılmalıdır. Canary deployment update etkisini ölçebilir. Eski root ancak bütün fleet yeni root'a güvendikten sonra kaldırılmalıdır.

Emergency Rotation

CA veya key compromise durumunda normal rotation süreci yeterince hızlı olmayabilir. Yeni trust root kısa sürede bütün platforma dağıtılmalıdır. Compromised credential derhal kullanım dışı bırakılmalıdır. Emergency playbook ve yetki sorumluları önceden tanımlanmalıdır. Düzenli tabletop veya DR testi bu sürecin gerçekten çalışıp çalışmadığını gösterir.

Workload Identity Nedir?

Workload identity bir uygulama sürecinin veya deployment'ın çalıştığı ortam tarafından doğrulanmış kimliğidir. Amaç uzun ömürlü secret taşımak yerine runtime sırasında geçici credential almaktır. Platform workload'un hangi node, namespace, service account veya signed image olarak çalıştığını doğrulayabilir. Başarılı attestation sonrasında kısa ömürlü token veya certificate üretilir. Bu model cloud-native servis authentication tasarımının en önemli yapı taşlarından biridir.

Credential Yerine Runtime Identity

Static credential uygulamanın yanında taşınırken runtime identity çalıştığı ortamdan türetilir. Workload yeni instance olarak başladığında identity service tarafından yeniden doğrulanır. Önceden sabit password dağıtmaya gerek kalmaz. Autoscaling ve ephemeral deployment için daha uygundur. Credential compromise etkisi kısa lifetime ile sınırlandırılır.

Workload Attestation

Attestation workload'un iddia ettiği kimlikle eşleşip eşleşmediğini kontrol eder. Kubernetes namespace, service account, node identity veya image signature sinyal olarak kullanılabilir. Tek sinyale bağlı model bazı tehditlerde zayıf kalabilir. Risk seviyesine göre birden fazla attribute birlikte değerlendirilebilir. Attestation policy değişiklikleri code review üzerinden yönetilebilir.

Ephemeral Credentials

Ephemeral credential kısa süre için geçerlidir ve workload yaşam döngüsüyle ilişkilidir. Token veya certificate otomatik alınır. Deployment sonlandığında credential'ın kullanışlı ömrü kısa sürede biter. Uzun ömürlü secret inventory yükü azalır. Rotation background süreç tarafından sürekli yapılabilir.

Automatic Rotation

Workload identity sistemleri credential expiration yaklaşmadan yeni credential üretir. Application veya proxy yeni credential'a kesintisiz geçebilir. Rotation başarısızlığı platform telemetry'sinde görünür olmalıdır. Uzun süre rotate edilmemiş workload anomali olarak değerlendirilebilir. Bu otomasyon human error riskini azaltır.

Infrastructure-Aware Identity

Infrastructure-aware identity workload'un yalnızca uygulama adına değil çalıştığı güvenilir platform bağlamına da dayanır. Namespace, cluster, node veya cloud account identity claim'lere eklenebilir. Authorization policy environment sınırını bu bilgilerle belirleyebilir. Ancak identity isimleri altyapıya aşırı bağımlı tasarlanırsa portability düşebilir. Logical service identity ile infrastructure attribute'larını ayrı tutmak dengeli bir modeldir.

Cloud-Native Workload Identity

Büyük cloud platformları workload'ların static access key kullanmadan kendi servislerine erişebilmesi için native identity mekanizmaları sunar. Ortak fikir deployment ile IAM principal arasında güven ilişkisi kurmaktır. Workload metadata service veya federated token üzerinden kısa ömürlü credential alır. Böylece environment variable içinde yıllarca yaşayan access key ihtiyacı azalır. Tek cloud kullanan işletmelerde native entegrasyon operasyon açısından oldukça pratik olabilir.

AWS IAM Roles

AWS ortamında compute workload'ları IAM role üzerinden geçici credential alabilir. EC2 instance profile, ECS task role veya Kubernetes entegrasyonları farklı workload tiplerini destekler. Application static access key saklamak zorunda kalmaz. IAM policy yalnızca gerekli cloud API operation'larını açmalıdır. Credential otomatik refresh edilir.

Azure Managed Identity

Azure Managed Identity workload'un Azure resource kimliği üzerinden token almasını sağlar. Secret veya certificate'ın uygulama tarafından yönetilmesi gerekmez. Resource access Azure RBAC ile sınırlandırılabilir. System-assigned ve user-assigned identity modelleri farklı lifecycle ihtiyaçlarını karşılar. Application uygun SDK veya token endpoint üzerinden kısa ömürlü credential alır.

Google Cloud Workload Identity

Google Cloud workload identity modelleri workload'un service account yetkisini static key olmadan kullanmasını sağlar. Kubernetes veya external workload federation üzerinden short-lived token alınabilir. IAM policy target resource erişimini sınırlar. Service account key dosyası dağıtma ihtiyacı azalır. Multi-cloud federation senaryolarında external identity trust modeli ayrıca tasarlanmalıdır.

Kubernetes Service Accounts

Kubernetes service account pod'lara logical workload identity sağlar. Modern projected service account token'ları audience ve expiration ile sınırlandırılabilir. Legacy uzun ömürlü token kullanımından kaçınılmalıdır. External identity provider service account token'ını doğrulayarak cloud credential verebilir. Namespace ve service account kombinasyonu attestation için kullanılabilir.

CI/CD OIDC Federation

CI/CD platformu job için OIDC token üreterek cloud IAM'e federated authentication sağlayabilir. Pipeline içinde static cloud key tutulmaz. Trust policy repository, branch veya environment claim'leriyle sınırlandırılabilir. Token kısa ömürlüdür ve job tamamlandığında değerini kaybeder. Deployment güvenliği açısından güçlü bir iyileştirmedir.

Workload Identity Federation

Workload Identity Federation bir platform kimliğinin başka identity domain tarafından trusted assertion olarak kabul edilmesini sağlar. Böylece static cross-cloud credential paylaşmak gerekmez. Kaynak identity provider workload token'ı üretir, hedef STS bu token'ı doğrular ve kısa ömürlü local credential verir. Bu model multi-cloud ve partner entegrasyonlarında güçlüdür. Trust policy açık audience, issuer ve workload attribute kontrolüyle sınırlandırılmalıdır.

Static Credential Olmadan Authentication

Federation'ın temel avantajı uzun ömürlü shared key ihtiyacını azaltmasıdır. Workload kendi platform identity'sini kanıtlar. Hedef identity service bu proof üzerinden geçici token verir. Credential source repository veya CI secret store içinde bulunmaz. Revocation trust policy değişikliğiyle merkezi yapılabilir.

Identity Provider Trust

Federation hedef sistemin kaynak identity provider'a belirli koşullarda güvenmesini gerektirir. Tüm issuer token'larını kabul etmek yerine audience ve subject pattern sınırlandırılmalıdır. JWKS ve issuer metadata güvenilir kanaldan alınmalıdır. Trust relation code veya IAM policy olarak yönetilebilir. Audit log hangi federated identity'nin credential aldığını göstermelidir.

Short-Lived Credentials

Federation sonucu verilen credential genellikle kısa ömürlüdür. Bu durum static key sızıntısına göre riski azaltır. Workload gerektiğinde yeni credential alır. Süre çok kısa seçilirse STS availability kritik hale gelir. Local cache ve refresh stratejisi kontrollü uygulanmalıdır.

Cross-Cloud Federation

Bir cloud workload'un diğer cloud API'sine erişmesi için karşı tarafta static key saklamak yerine federation kullanılabilir. Kaynak cloud workload token'ı target cloud tarafından doğrulanır. Mapping policy yalnızca belirli workload'lara role verir. Multi-cloud secret rotation yükü azalır. Trust boundary ve incident response iki platformu kapsayacak şekilde tasarlanmalıdır.

Multi-Cloud Enterprise Architecture

Multi-cloud işletmede her platformun native identity sistemi bulunabilir. Ortak federation layer logical service identity ile cloud principal'ları eşleştirebilir. SPIFFE veya merkezi STS portability için ek seçenek sunar. Tüm identity'leri tek sistemde zorla birleştirmek yerine trust relation'ları açık tanımlamak daha sürdürülebilir olabilir. Identity inventory farklı cloud'larda aynı servisin hangi principal'ları kullandığını göstermelidir.

SPIFFE Nedir?

SPIFFE, heterojen altyapılarda workload'lara güvenilir ve platformdan bağımsız identity vermek için açık standartlar tanımlar. Identity URI formatındaki SPIFFE ID ile temsil edilir. X.509-SVID veya JWT-SVID workload'un bu identity'yi kanıtlamasını sağlar. Workload API credential'ı uygulamaya veya proxy'ye runtime sırasında iletir. Multi-cloud ve Kubernetes artı VM ortamlarında ortak identity semantics isteyen işletmeler için güçlü bir modeldir.

Platform-Independent Workload Identity

SPIFFE identity'yi belirli cloud IAM ürününe bağlamaz. Aynı logical workload Kubernetes, VM veya farklı cloud üzerinde benzer identity formatı kullanabilir. Bu portability multi-cloud yapıda avantaj sağlar. Ancak underlying attestation entegrasyonu her platform için yine kurulmalıdır. Organization naming ve trust domain tasarımını merkezi belirlemelidir.

SPIFFE ID

SPIFFE ID URI biçiminde workload identity tanımlar. Örnek olarak trust domain ve workload path birlikte logical kimliği ifade eder. Identity içinde secret bulunmaz. Authorization policy SPIFFE ID pattern üzerinden yazılabilir. Naming convention anlaşılır ve uzun vadede stabil olmalıdır.

Trust Domain

Trust domain ortak güven yönetimi sınırını ifade eder. Aynı trust domain içindeki workload'lar belirli CA ve policy set'i altında identity alır. Production ve development için ayrı trust domain kullanmak blast radius'u azaltabilir. Çok fazla domain federation yönetimini zorlaştırabilir. Tasarım organizasyon risk sınırlarına göre yapılmalıdır.

Workload Path

Workload path logical service, namespace veya application rolünü tanımlamak için kullanılabilir. Infrastructure detail'lerini gereğinden fazla path'e gömmek portability'yi azaltabilir. Path policy yazımını kolaylaştıracak kadar açıklayıcı olmalıdır. Naming convention değişikliği identity migration gerektirir. Bu nedenle erken dönemde açık standart belirlemek önemlidir.

SPIFFE Verifiable Identity Document (SVID)

SVID workload'un SPIFFE ID sahipliğini cryptographic olarak kanıtlayan belgedir. X.509 certificate veya JWT formatında olabilir. Credential kısa ömürlü ve otomatik rotate edilebilir. Application doğrudan veya proxy üzerinden kullanabilir. Trust bundle doğrulama için gerekli public trust bilgisini sağlar.

Workload API

Workload API workload'un disk üzerinde static key beklemeden identity credential almasını sağlar. Local agent workload'u attestation policy ile eşleştirir. Başarılı doğrulama sonrası SVID uygulamaya sunulur. Credential rotation aynı API üzerinden takip edilebilir. Bu model secret distribution ihtiyacını azaltır.

SPIRE Nedir?

SPIRE, SPIFFE standartlarını uygulayan workload identity platformudur. Server tarafı registration, attestation ve certificate authority görevlerini yönetir. Agent node üzerinde çalışarak workload'ları doğrular ve Workload API sunar. Identity issuance ve rotation otomatik hale gelir. Büyük kurumsal platformda SPIRE güvenilir bir identity control plane olarak kullanılabilir ancak yüksek availability ve operasyon planı gerektirir.

SPIFFE Runtime Environment

SPIRE workload'lara SPIFFE uyumlu runtime identity sağlar. Server ve agent bileşenleri birlikte çalışır. Application direct SVID kullanabilir veya mesh proxy üzerinden dolaylı faydalanabilir. Platformdan bağımsız identity hedeflenir. Configuration ve registration data version control ile yönetilmelidir.

Node Attestation

Node attestation agent'ın güvenilir infrastructure üzerinde çalıştığını doğrular. Cloud instance identity, Kubernetes node metadata veya başka platform proof'ları kullanılabilir. Güvenilmeyen node'un workload identity dağıtması engellenir. Attestation method threat model'e göre seçilmelidir. Node compromise durumunda revocation planı bulunmalıdır.

Workload Attestation

Agent aynı node üzerindeki process veya container'ın hangi workload olduğunu belirler. Kubernetes service account, namespace, process UID veya container metadata sinyal olabilir. Registration rule doğru SPIFFE ID ile workload attribute'larını eşleştirir. Çok geniş selector yanlış workload'a identity verilmesine yol açabilir. Policy review security sürecine dahil edilmelidir.

Identity Issuance

Başarılı attestation sonrasında SPIRE workload için SVID üretir. X.509-SVID mTLS bağlantısında kullanılabilir. JWT-SVID token tabanlı kimlik kanıtı sunabilir. Credential kısa lifetime ile verilir. Issuance olayı telemetry ve audit sisteminde izlenmelidir.

Automatic Rotation

SPIRE SVID süresi dolmadan yeni credential sağlar. Application Workload API üzerinden güncel belgeyi alabilir. Proxy veya mesh entegrasyonu rotation'ı uygulama kodundan gizleyebilir. Rotation failure güvenlik ve availability alarmı oluşturmalıdır. Kısa lifetime bu otomasyona güvenildiğinde pratik hale gelir.

Trust Bundle Management

SPIRE trust bundle ilgili trust domain'in doğrulama root'larını içerir. Federation varsa diğer trust domain bundle'ları da yönetilebilir. Bundle değişiklikleri agent'lara otomatik dağıtılır. Emergency root rotation senaryosu test edilmelidir. Yanlış bundle distribution geniş çaplı bağlantı hatası oluşturabilir.

X.509-SVID ve JWT-SVID

SPIFFE iki temel SVID biçimi sunar ve bunlar farklı iletişim modellerine hizmet eder. X.509-SVID TLS ve özellikle mTLS için doğal seçimdir. JWT-SVID transport bağlantısından bağımsız token tabanlı authentication gereken senaryolarda kullanılabilir. Birini diğerinin evrensel alternatifi gibi düşünmek doğru değildir. Synchronous service call, asynchronous message ve external protocol ihtiyaçları ayrı değerlendirilmelidir.

X.509-SVID

X.509-SVID SPIFFE ID'yi certificate SAN alanında taşıyan kısa ömürlü kimlik belgesidir. Private key workload veya proxy scope'unda korunur. TLS handshake sırasında karşı taraf identity'yi doğrular. Automatic rotation güçlü operasyon avantajı sağlar. East-west service traffic için yaygın ve doğal bir modeldir.

mTLS

X.509-SVID mTLS bağlantısında client ve server workload identity'sini doğrulamak için kullanılabilir. Trust bundle certificate chain verification sağlar. Identity policy SPIFFE ID üzerinden yazılabilir. Uygulama doğrudan certificate kullanabilir veya service mesh proxy bu işlemi üstlenebilir. Kısa certificate lifetime credential theft etkisini sınırlar.

Synchronous Service Communication

HTTP ve gRPC gibi synchronous bağlantılarda X.509-SVID transport katmanıyla doğal biçimde uyumludur. Connection kurulurken authentication tamamlanır. Aynı connection üzerinde birden fazla request taşınabilir. Connection pooling handshake maliyetini azaltır. User delegation gerekiyorsa ayrıca application token kullanılabilir.

JWT-SVID

JWT-SVID workload identity'yi signed token olarak taşır. Transport dışında bir servis veya sistem tarafından doğrulanabilir. Audience belirli target için sınırlandırılmalıdır. Token kısa lifetime ile kullanılmalıdır. Bearer token riskleri nedeniyle yüksek güvenlikli senaryolarda kullanım şekli dikkatle tasarlanmalıdır.

Token-Based Authentication

JWT-SVID target sistemin X.509 mTLS entegrasyonu bulunmadığında token tabanlı authentication sağlayabilir. Hedef trust bundle veya public key üzerinden signature doğrular. Audience target service'i göstermelidir. Token başka hedefte kabul edilmemelidir. Authorization permission bilgisi ayrı policy ile belirlenebilir.

Transport Dışındaki Identity Use Case'leri

Asynchronous message veya signed assertion gereken durumda transport connection identity'si yeterli olmayabilir. JWT-SVID belirli workload identity bilgisini application mesaj akışına taşıyabilir. Bununla birlikte original user veya message-specific integrity için ek claim ve signature gerekebilir. Replay riski ayrıca değerlendirilmelidir. Token'ın hedef audience ve expiration değeri dar tutulmalıdır.

Hangisi Ne Zaman Kullanılmalı?

Direct service connection ve mTLS gereken durumda X.509-SVID çoğu zaman daha uygundur. Transport dışı token tabanlı identity gerektiğinde JWT-SVID değerlendirilebilir. Aynı organizasyon iki formatı farklı use case'lerde birlikte kullanabilir. Seçim uygulama protokolü ve trust model'e göre yapılmalıdır. Tek tip credential zorlamak yerine doğru katmanda doğru format kullanılmalıdır.

Workload Attestation Nasıl Yapılır?

Workload attestation identity sisteminin “bu process gerçekten iddia ettiği servise mi ait?” sorusuna yanıt verir. Kubernetes namespace ve service account en yaygın sinyaller arasındadır. Daha yüksek güvenlikte node identity, container image signature veya hardware attestation gibi ek sinyaller kullanılabilir. Attestation rule çok geniş olursa yanlış workload identity alabilir. Çok dar ve infrastructure-specific rule ise operasyon esnekliğini azaltabilir.

Kubernetes Namespace

Namespace workload'ları logical gruplara ayırır ve attestation için yararlı attribute sunar. Ancak yalnızca namespace adı güçlü identity kanıtı değildir. Service account ile birlikte kullanılması daha anlamlıdır. Namespace creation permission güçlü şekilde kontrol edilmelidir. Production ve development namespace'leri aynı identity policy'yi otomatik paylaşmamalıdır.

Service Account

Service account pod'un logical workload kimliğini temsil edebilir. Attestation agent pod metadata üzerinden service account bilgisini doğrulayabilir. Aynı service account'un birçok farklı application tarafından paylaşılması identity separation'ı zayıflatır. Her önemli workload için ayrı account tercih edilmelidir. Permission minimum tutulmalıdır.

Node Identity

Node identity workload'un trusted cluster veya compute instance üzerinde çalıştığını doğrulamaya yardımcı olur. Cloud instance attestation veya node certificate kullanılabilir. Compromised node üzerinde çalışan workload'ların risk seviyesi ayrıca değerlendirilmelidir. Node identity tek başına application identity değildir. Workload-level selector ile birlikte kullanılmalıdır.

Process Identity

VM veya bare-metal ortamında process UID, executable path veya process metadata attestation sinyali olabilir. Bu bilgiler platform tarafından güvenilir biçimde alınmalıdır. Kullanıcı tarafından kolayca değiştirilebilen process name güvenilir kanıt değildir. OS isolation modeline göre ek kontroller gerekebilir. Signed binary bilgisi daha güçlü sinyal sağlayabilir.

Container Image

Container image digest workload'un hangi artifact'tan çalıştığını gösterebilir. Attestation policy yalnızca approved image digest'lerine identity verebilir. Mutable tag yerine immutable digest kullanmak önemlidir. Image signature ile birlikte kullanıldığında supply-chain güvenliği güçlenir. Runtime image değişirse identity issuance policy otomatik reddedebilir.

Signed Artifact

Signed artifact deployment edilen binary veya image'ın trusted build pipeline'dan geldiğini kanıtlamaya yardımcı olur. Workload identity issuance signing provenance sonucuna bağlanabilir. Böylece manuel üretilmiş veya değiştirilmiş artifact aynı identity'yi alamaz. Signature key güvenliği ayrıca önemlidir. Build provenance ve runtime identity birlikte güçlü bir zincir oluşturur.

Hardware Attestation

Hardware attestation TPM veya confidential computing özellikleri üzerinden workload'un belirli güvenli hardware üzerinde çalıştığını kanıtlayabilir. Yüksek riskli environment'larda ek güven sinyali sağlar. Operasyon ve platform desteği daha ağırdır. Her microservice için gerekli olmayabilir. Risk modeli gerçekten ihtiyaç olup olmadığını belirlemelidir.

Trust Domain Nasıl Tasarlanmalı?

Trust domain tasarımı hangi workload'ların ortak identity trust root altında bulunacağını belirler. Tek global domain yönetimi kolaylaştırabilir ancak compromise durumunda etki alanı büyüyebilir. Environment, business unit veya region bazlı domain separation blast radius'u azaltabilir. Buna karşılık federation sayısı ve policy yönetimi artar. En iyi yapı organization boundaries, compliance ve operasyon kapasitesi birlikte düşünülerek seçilmelidir.

Tek Global Trust Domain

Tek domain bütün workload'lar için ortak trust semantics sağlar. Service discovery ve policy yazımı daha basit olabilir. Multi-region communication ekstra federation gerektirmez. Ancak root compromise bütün organization'ı etkileyebilir. Çok büyük işletmede risk separation ihtiyacı değerlendirilebilir.

Environment Bazlı Trust Domain

Production ve non-production için ayrı trust domain kullanmak güçlü isolation sağlar. Development workload production identity ile doğrudan trust kuramaz. Federation gerektiğinde explicit rule tanımlanır. Trust bundle ve CA operasyonu iki domain için ayrı yürütülür. Bu model yanlış environment erişimini azaltır.

Business Unit Bazlı Trust Domain

Farklı business unit'ler bağımsız security governance kullanıyorsa ayrı trust domain mantıklı olabilir. Acquisition veya regulated department senaryolarında boundary daha belirgin hale gelir. Cross-unit çağrılar federation üzerinden explicit yapılır. Çok fazla domain operasyon yükünü artırabilir. Ortak naming ve policy standardı yine korunmalıdır.

Region Bazlı Trust Domain

Region bazlı domain data residency veya bağımsız operasyon ihtiyacına hizmet edebilir. Region outage diğer bölgenin identity issuance sistemini doğrudan etkilemeyebilir. Cross-region service call federation gerektirir. Network architecture ve trust domain tasarımı birlikte ele alınmalıdır. Sadece coğrafi isim uğruna gereksiz domain üretmekten kaçınılmalıdır.

Blast Radius Karşılaştırması

Az sayıda büyük trust domain operasyonu sadeleştirir fakat compromise etkisini büyütebilir. Çok sayıda küçük domain blast radius'u küçültür ancak federation ve trust bundle yönetimini ağırlaştırır. Organization risk tolerance bu dengeyi belirler. CA compromise tabletop exercise gerçek etkiyi anlamaya yardımcı olur. Domain tasarımı uzun ömürlü olduğu için erken dönemde planlı yapılmalıdır.

SPIFFE Federation

SPIFFE Federation farklı trust domain'lerin birbirinin workload identity'lerini kontrollü biçimde doğrulamasını sağlar. Her domain kendi CA ve issuance sürecini korur. Federation trust bundle exchange ve policy üzerinden belirli cross-domain çağrılara izin verir. Multi-cloud, multi-cluster, partner veya birleşme senaryolarında kullanışlıdır. Federation bütün domain'lere otomatik full trust vermek anlamına gelmemelidir.

Cross-Trust-Domain Authentication

Bir trust domain'deki workload diğer domain'deki servisle iletişim kurduğunda hedef karşı domain bundle'ını kullanarak identity doğrular. Identity doğrulandıktan sonra authorization policy ayrıca uygulanır. Federation yalnızca cryptographic trust sağlar. Service-level permission açık allow rule gerektirir. Audit log source trust domain bilgisini saklamalıdır.

Multi-Cloud

Farklı cloud platformlarında çalışan workload'lar SPIFFE identity ile ortak semantics kullanabilir. Her cloud native attestation yöntemini korur. Federation veya ortak trust domain üzerinden cross-cloud authentication yapılabilir. Cloud-specific IAM tamamen kaldırılmak zorunda değildir. Workload identity layer internal service communication için ortak abstraction sunabilir.

Multi-Cluster

Birden fazla Kubernetes cluster aynı veya ayrı trust domain kullanabilir. Aynı domain operasyon kolaylığı sağlar, ayrı domain daha güçlü isolation sunar. Cross-cluster mTLS için trust bundle ve service routing birlikte çalışmalıdır. Cluster identity de authorization context'e eklenebilir. Federation testleri cluster outage senaryolarını kapsamalıdır.

Partner Organization

Partner şirket workload'larına doğrudan internal trust domain identity vermek yerine federation kurulabilir. Her organization kendi identity lifecycle'ını yönetir. Cross-organization policy yalnızca gerekli servisleri açar. Contract sona erdiğinde federation relation veya permission kaldırılabilir. Bu model shared API key'e göre daha güçlü audit sağlar.

Acquisition / Merger Senaryoları

Birleşen iki organization'ın identity platformlarını hemen tek sisteme taşımak riskli olabilir. Federation geçiş döneminde iki trust domain'in kontrollü iletişim kurmasını sağlar. Service dependency'ler kademeli olarak migrate edilebilir. Ortak naming standardı zaman içinde oluşturulabilir. Final architecture business ve compliance kararına göre şekillenir.

Service Mesh ile Service Authentication

Service mesh uygulama trafiğini proxy veya veri düzlemi katmanında yöneterek workload authentication'ı uygulama kodundan ayırabilir. Automatic mTLS, certificate distribution ve service identity propagation temel özellikler arasındadır. Authorization policy source ve destination identity üzerinden uygulanabilir. Observability connection-level identity bilgisini görünür hale getirir. Bunun karşılığında control plane, proxy lifecycle ve debugging operasyonu organizasyona ek sorumluluk getirir.

Service Mesh Ne Sağlar?

Service mesh east-west traffic için ortak security ve observability layer sağlar. Uygulama takımlarının her dilde ayrı mTLS implementasyonu yazması gerekmez. Proxy certificate alır ve connection sırasında identity doğrular. Policy merkezi control plane tarafından dağıtılabilir. Ancak application-level business authorization yine uygulama sorumluluğu olabilir.

Automatic mTLS

Mesh proxy workload için certificate alır ve service call sırasında mTLS kurar. Developer certificate dosyası yönetmez. Rotation background olarak gerçekleşir. Strict policy plaintext bağlantıyı engelleyebilir. Mesh telemetry hangi bağlantının mTLS kullandığını gösterebilir.

Certificate Distribution

Control plane veya workload identity system certificate'ları proxy'lere dağıtır. Private key mümkün olduğunca workload scope'unda üretilmelidir. Certificate kısa lifetime ile rotate edilir. Distribution failure connection sorununa yol açabileceği için monitoring önemlidir. CA availability platform SLO'sunun parçasıdır.

Identity Propagation

Proxy source workload certificate'ından identity'yi çıkarabilir. Bu identity authorization policy ve telemetry sistemine aktarılır. Uygulamanın güvenilmeyen header'dan caller identity okumasına gerek kalmaz. Proxy-generated metadata yalnızca trusted local channel üzerinden application'a verilmelidir. Header spoofing riskine karşı ingress temizliği yapılmalıdır.

Authorization Policy

Mesh policy hangi source identity'nin hangi destination ve operation'a erişebileceğini belirleyebilir. Default-deny güvenli başlangıç sağlar. Policy code review ve automated test ile yönetilebilir. Çok ayrıntılı rule set'in debugging'i zorlaşabileceği için naming standardı önemlidir. Business object authorization application katmanında kalabilir.

Observability

Mesh proxy source ve destination identity, mTLS status ve policy decision gibi telemetry üretebilir. Bu veriler service dependency graph oluşturmak için değerlidir. Unexpected service call anomaly olarak işaretlenebilir. Tracing correlation ID ile application log'ları birleştirilebilir. Fazla telemetry maliyeti için sampling ve retention politikası uygulanmalıdır.

Istio ile Service-to-Service Authentication

Istio service mesh yaklaşımında workload identity ve mTLS'i veri düzlemi proxy'leri üzerinden uygulayabilir. Workload certificate'ları otomatik dağıtılabilir. PeerAuthentication connection authentication politikasını, AuthorizationPolicy ise erişim kurallarını tanımlar. STRICT mode plaintext trafiği engellemek için kullanılır. SPIFFE formatındaki identity bilgisi service policy'nin temel girdilerinden biri olabilir.

Workload Identity

Istio workload kimliğini Kubernetes service account ve trust domain bilgisiyle ilişkilendirebilir. Proxy certificate SPIFFE benzeri identity taşır. Aynı service account'u ilgisiz workload'larda paylaşmamak önemlidir. Authorization policy source principal üzerinden identity kontrol edebilir. Service account lifecycle security governance kapsamına alınmalıdır.

Automatic mTLS

Proxy'ler desteklenen service traffic için otomatik mTLS kurabilir. Uygulamanın TLS library yapılandırması gerekmeyebilir. Migration döneminde permissive davranış kullanılabilir. Final state olarak strict mode daha güvenli olur. Telemetry plaintext kalan trafiği tespit etmek için kullanılmalıdır.

PeerAuthentication

PeerAuthentication inbound traffic için mTLS modunu tanımlar. Namespace veya workload seviyesinde policy uygulanabilir. Migration sırasında farklı scope'lar kontrollü kullanılır. Global permissive policy uzun süre açık bırakılmamalıdır. Policy inheritance davranışı ekip tarafından iyi anlaşılmalıdır.

STRICT Mode

STRICT mode workload'un yalnızca mTLS ile doğrulanmış bağlantıları kabul etmesini sağlar. Plaintext bypass riskini azaltır. Legacy service henüz mesh'e hazır değilse migration planı gerekir. Önce telemetry ile remaining plaintext dependency'ler tespit edilebilir. Ardından servisler kademeli strict mode'a alınır.

AuthorizationPolicy

AuthorizationPolicy source identity, operation ve destination bilgisine göre izin veya red kararı tanımlayabilir. Default-deny yaklaşımı explicit allow policy'lerle birleştirilebilir. Policy değişiklikleri application deployment kadar dikkatli test edilmelidir. Yanlış rule production outage oluşturabilir. Audit log hangi policy'nin request'i reddettiğini göstermelidir.

SPIFFE Identity

Mesh workload identity URI formatında trust domain ve service account bilgisini taşıyabilir. Bu değer service-level policy yazımında kullanılabilir. Identity path'in uzun vadede stabil tutulması önemlidir. Namespace rename gibi operasyonlar policy etkisi yaratabilir. Naming strategy platform standardının parçası olmalıdır.

STRICT ve PERMISSIVE mTLS

Service mesh migration sırasında bütün workload'ları aynı anda mTLS'e geçirmek her zaman mümkün olmayabilir. PERMISSIVE mod hem plaintext hem mTLS bağlantıyı kabul ederek geçiş kolaylığı sağlar. Ancak bu durum saldırganın plaintext path üzerinden authentication bypass etmesine imkan verebilir. Bu nedenle permissive kullanım geçici ve ölçülebilir olmalıdır. Hedef state mümkün olduğunda STRICT mode olmalı ve exception'lar açıkça kayıt altına alınmalıdır.

Migration Dönemi

Migration sırasında önce mesh sidecar veya data plane rollout yapılabilir. Telemetry hangi service pair'lerin mTLS kullandığını gösterir. Plaintext dependency'ler tespit edilerek sırayla düzeltilir. Policy değişikliği canary uygulanabilir. Belirli tarih sonunda permissive mode kaldırılır.

Legacy Workloads

Legacy application proxy injection veya modern TLS stack ile uyumlu olmayabilir. Bu workload'lar için gateway veya dedicated adapter kullanılabilir. Exception sonsuza kadar bırakılmamalıdır. Modernization roadmap identity migration ile ilişkilendirilmelidir. Legacy erişimi dar network ve service policy ile sınırlandırılabilir.

Plaintext Bypass Riski

PERMISSIVE policy mTLS bağlantıyı desteklerken plaintext'i de kabul eder. Saldırgan network erişimi kazanırsa certificate olmadan service'e ulaşabilir. Authorization yalnızca mTLS identity'ye dayanıyorsa plaintext request'in nasıl işlendiği kritik hale gelir. Default deny veya source identity required policy uygulanmalıdır. Telemetry sıfır plaintext hedefine doğru ilerlemeyi göstermelidir.

STRICT Mode'a Geçiş Planı

İlk adım mevcut traffic inventory çıkarmaktır. Sonra mTLS desteklemeyen service'ler migrate edilir. Policy dry-run veya audit mode ile test edilebilir. Canary namespace strict mode'a geçirilerek etkiler ölçülür. Son aşamada organization baseline strict hale getirilebilir.

Service Mesh Zero Trust Sağlar mı?

Service mesh güçlü bir Zero Trust bileşeni olabilir ancak tek başına Zero Trust değildir. mTLS workload kimliğini doğrular fakat bütün authenticated servislerin birbirine erişmesine izin verilirse risk devam eder. Default-deny, least privilege ve explicit service policy gerekir. User authorization ve resource-level business kuralları application katmanında uygulanabilir. Continuous verification ise identity, policy, telemetry ve anomaly detection süreçlerinin birlikte çalışmasını gerektirir.

mTLS Yeterli Değildir

mTLS “kim bağlandı?” sorusunu cevaplar. “Bu identity bu kaynağa erişebilir mi?” sorusu ayrıca yanıtlanmalıdır. Tüm mTLS workload'lara full network erişimi vermek Zero Trust yaklaşımına aykırıdır. Service policy minimum dependency'yi tanımlamalıdır. User context gereken işlemlerde additional authorization zorunludur.

Default Deny

Default-deny policy yeni service identity'nin hiçbir hedefe otomatik erişmemesini sağlar. Gerekli dependency explicit allow rule ile eklenir. Bu model yanlış yapılandırmanın etkisini azaltır. Service onboarding süreci permission talebini içermelidir. Unused rule'lar telemetry ile zaman içinde temizlenebilir.

Least Privilege

Least privilege her workload'a yalnızca işini yapmak için gerekli izinleri vermeyi amaçlar. Network connectivity, API scope ve cloud IAM permission birlikte değerlendirilmelidir. Bir katmanda geniş izin diğer katmanların faydasını azaltabilir. Identity graph gerçek kullanım ile granted permission farkını gösterebilir. Düzenli review gereksiz permission'ları kaldırır.

Explicit Service Policy

Service dependency graph hangi servislerin iletişim kurması gerektiğini gösterir. Policy bu dependency'leri açık allow olarak tanımlayabilir. Yeni edge code review gerektirebilir. Acil exception süreli olmalıdır. Policy naming business ownership ile ilişkilendirilirse bakım kolaylaşır.

Continuous Verification

Zero Trust yalnızca connection başlangıcındaki certificate kontrolünden ibaret değildir. Token validity, workload state ve permission context sürekli değerlendirilebilir. Deprecated identity veya unexpected region anomaly olarak işaretlenebilir. Credential kısa ömürlü tutulur ve otomatik yenilenir. Policy değişiklikleri runtime'a hızlı dağıtılmalıdır.

API Gateway ve Service Mesh Arasındaki Fark

API Gateway çoğunlukla dış kullanıcı veya partner trafiğinin sisteme giriş noktasını yönetir. Service mesh ise internal east-west service traffic üzerinde workload identity ve policy uygular. İki katman farklı trust boundaries üzerinde çalışır. Kurumsal mimaride gateway external token doğrularken mesh internal mTLS sağlayabilir. User delegation gerektiğinde gateway ve internal STS birlikte token exchange akışı oluşturabilir.

North-South Authentication

North-south traffic kullanıcı, mobile application veya partner sistemin dışarıdan platforma bağlandığı trafiği ifade eder. API Gateway OAuth token, API key veya mTLS client certificate doğrulayabilir. Rate limit ve threat protection bu sınırda uygulanabilir. Gateway internal workload identity üretmek yerine external identity context'i güvenli şekilde içeri taşımalıdır. Downstream token kullanım modeli açıkça tanımlanmalıdır.

API Gateway

API Gateway external API'ler için authentication ve routing boundary görevi görür. OAuth access token validation, partner mTLS ve rate limit burada uygulanabilir. User identity ve token claims downstream policy için context oluşturur. Gateway tek başına bütün internal service call'ları yönetmek zorunda değildir. East-west communication mesh veya application authentication ile korunabilir.

East-West Authentication

East-west traffic internal servislerin birbirini çağırdığı trafiği ifade eder. Burada workload identity ve mTLS daha merkezi hale gelir. Service mesh automatic certificate handling sağlar. Authorization source service ve destination service ilişkisine göre uygulanabilir. External user token yalnızca gerçekten gerekli olduğunda taşınmalıdır.

Service Mesh

Service mesh internal traffic için identity-aware network katmanı sağlar. Proxy automatic mTLS ve policy enforcement yapabilir. Uygulama kodunda ortak transport security mantığı tekrar edilmez. Telemetry service graph oluşturur. Bunun karşılığında mesh operasyon yetkinliği gerekir.

İki Katmanın Birlikte Kullanılması

Gateway dış trust boundary'yi, mesh ise internal workload boundary'yi koruyabilir. External token gateway'de doğrulanır. Internal servis çağrıları mTLS ile yapılır. Kullanıcı bağlamı gerekiyorsa downstream'e audience-sınırlı token taşınabilir. Bu iki katman birlikte kullanıldığında görev ayrımı daha net hale gelir.

Kullanıcı Token'ını Downstream Servislere Forward Etmeli misiniz?

Kullanıcı access token'ını olduğu gibi bütün downstream servis zincirine göndermek basit görünür ancak ciddi güvenlik ve audit sorunları doğurabilir. Token ilk API için üretilmiş olabilir ve diğer servislerde audience mismatch oluşturur. Geniş scope bütün iç servislerde gereksiz privilege yaratabilir. Token birden fazla log ve process üzerinden geçtikçe leakage yüzeyi büyür. Kullanıcı bağlamı gerçekten gerekiyorsa token exchange ile service-specific ve daha dar token üretmek çoğu kurumsal mimaride daha güvenlidir.

Token Propagation

Token propagation gelen user token'ın downstream request'e aynen eklenmesidir. Teknik olarak kolaydır ve kullanıcı claim'lerini korur. Ancak her downstream servis external token formatına bağımlı hale gelir. Audience ve scope çoğu zaman hedef servise uygun değildir. Uzun call chain token leakage riskini artırır.

Audience Problemi

User token gateway veya Service A için üretilmiş olabilir. Service B'nin aynı token'ı kabul etmesi audience modelini zayıflatır. Generic audience bütün internal API'leri tek security domain'e çevirir. Token exchange Service B için yeni audience üretir. Bu yaklaşım blast radius'u azaltır.

Excessive Privilege

External token kullanıcıya geniş permission set'i taşıyabilir. Downstream servis yalnızca küçük bir operation'a ihtiyaç duyabilir. Raw forwarding gereksiz privilege taşır. Token exchange daha dar scope üretir. Service B yalnızca kendisine gerekli permission'ı görür.

Token Leakage

Token her yeni service hop'unda memory, log ve tracing sistemine temas eder. Zincir uzadıkça leakage yüzeyi büyür. Service-specific kısa token bu etkiyi azaltır. Sensitive header redaction her servis için yine uygulanmalıdır. Token forwarding mimarisi gözlemleme sistemleriyle birlikte değerlendirilmelidir.

Audit Problemi

Raw user token kullanıldığında downstream log yalnızca kullanıcı kimliğini görebilir. Çağrıyı gerçekte hangi upstream servisin yaptığı belirsiz kalabilir. Actor/service identity ayrıca kaydedilmelidir. Token exchange actor context taşıyabilir. Audit trail “user X, service A üzerinden service B operation yaptı” şeklinde bilgi sunmalıdır.

Ne Zaman Kabul Edilebilir?

Tek backend sınırı içinde kısa call chain ve tüm servislerin aynı audience modeli bilinçli tasarlanmışsa propagation kabul edilebilir. Risk düşük ve authorization merkezi olabilir. Buna rağmen service identity ayrı doğrulanmalıdır. Sensitive operation veya çok katmanlı enterprise API'de token exchange daha güvenli olur. Karar architecture simplicity ile blast radius arasında verilmelidir.

OAuth 2.0 Token Exchange

Token Exchange bir security token'ın hedef resource için yeni ve daha dar token'a dönüştürülmesini sağlar. Service A gelen user token'ı STS'e sunabilir. STS original subject, actor service ve target audience bilgilerini değerlendirir. Sonuç olarak Service B için sınırlı scope içeren downstream access token üretilir. Bu model delegation ve least privilege ihtiyacını bir arada çözmeye yardımcı olur.

Security Token Service (STS)

STS bir identity veya security token'ı başka credential'a dönüştüren güven hizmetidir. Kaynak token doğrulanır ve caller service kimliği kontrol edilir. Policy hedef resource için hangi scope'un verileceğine karar verir. Issuance olayı audit log'a kaydedilir. STS yüksek availability ve güçlü signing key yönetimi gerektirir.

Subject Token

Subject token original kullanıcı veya workload kimliğini temsil eder. STS issuer, audience ve expiration doğrulaması yapar. Token'ın exchange için kullanılmasına policy izin vermelidir. Raw token değerinin loglanmaması gerekir. Subject identity downstream token içinde uygun claim ile korunabilir.

Target Resource

Token exchange isteği yeni token'ın hangi resource için kullanılacağını belirtmelidir. Target resource Service B gibi specific API olabilir. Bu bilgi audience ve scope daraltmada kullanılır. Generic target blast radius'u artırır. STS yalnızca caller'ın erişmesine izin verilen resource için token üretmelidir.

Audience

Yeni token'ın audience değeri target service'i göstermelidir. Service B yalnızca kendi audience değerini kabul eder. Token Service C'de tekrar kullanılamaz. Bu separation lateral movement riskini azaltır. Audience naming organization standardıyla yönetilmelidir.

Narrower Scope

Exchange edilen token original token'dan daha geniş permission taşımamalıdır. Service A'nın Service B'de ihtiyaç duyduğu minimum operation scope seçilir. STS policy kullanıcı ve actor context'ini birlikte değerlendirir. Downstream service broad external permission set'ini görmez. Least privilege service chain boyunca korunur.

Downstream Access Token

STS sonucu üretilen token kısa ömürlü ve target-specific olmalıdır. Service A token'ı yalnızca Service B request'inde kullanır. Token actor identity ve original subject bilgisini taşıyabilir. Service B authorization kararını bu context üzerinden verir. Audit log tüm delegation chain'i görünür hale getirir.

Token Forwarding ve Token Exchange Karşılaştırması

Raw token forwarding operasyon açısından basit olsa da security boundary'leri genişletebilir. Token exchange ek STS altyapısı gerektirir ancak audience ve scope'u her downstream service için daraltabilir. Büyük microservice platformunda bu fark blast radius ve auditability açısından önemlidir. Basit sistemlerde forwarding yeterli olabilir. Karar kullanıcı delegation ihtiyacı ve servis zincirinin uzunluğuna göre verilmelidir.

Raw User Token Forwarding

Raw forwarding aynı token'ın service chain boyunca taşınmasıdır. Uygulaması kolay ve latency maliyeti düşüktür. Downstream her external token claim'ini anlamak zorunda kalabilir. Token theft etkisi daha geniş olur. Actor service identity ayrı mekanizmayla korunmalıdır.

Service-Specific Token

Service-specific token yalnızca belirli downstream API için üretilir. Audience target service ile sınırlıdır. Scope yalnızca gerekli operation'ları içerir. Token başka serviste reddedilir. Ek STS call ve token cache operasyonu gerekir.

Blast Radius

Raw token geniş audience taşıyorsa ele geçirilmesi birçok servisi etkileyebilir. Service-specific token etkisini tek resource ile sınırlar. Kısa TTL ek koruma sağlar. mTLS-bound token replay riskini daha da azaltabilir. Riskli business operation'larda dar blast radius tercih edilmelidir.

Least Privilege

Token exchange permission'ı her hop için azaltma imkanı sunar. Forwarding aynı broad scope'u zincir boyunca taşır. Service A yalnızca Service B'de ihtiyaç duyduğu permission'ı istemelidir. STS policy scope escalation engellemelidir. Downstream resource server dar token üzerinde daha basit authorization uygulayabilir.

Auditability

Token exchange original subject ve actor service bilgisini ayrı claim'lerde taşıyabilir. Audit kaydı delegation chain'i gösterir. Raw forwarding yalnızca original user'ı görünür bırakabilir. Service identity mesh veya mTLS logundan ayrı correlate edilmek zorunda kalır. Finansal işlem gibi alanlarda açık actor bilgisi daha değerlidir.

Operational Complexity

Token exchange STS, key management ve policy katmanı gerektirir. Token cache ve refresh davranışı doğru uygulanmalıdır. Küçük sistemde bu ek altyapı gereksiz olabilir. Büyük enterprise platformunda merkezi delegation modeli uzun vadede standardizasyon sağlar. Tasarım gerçek risk ve ekip kapasitesine göre seçilmelidir.

Delegation ve Impersonation

Delegation ile impersonation aynı kavram değildir. Impersonation servis veya admin bileşenin kullanıcıymış gibi işlem yapmasıdır. Delegation modelinde original user kimliği korunurken işlemi gerçekleştiren actor service de görünür kalır. Bu ayrım audit ve least privilege açısından önemlidir. Finansal veya regüle uygulamalarda kim adına kimin hangi işlemi gerçekleştirdiğinin açık kaydı gerekir.

Impersonation Nedir?

Impersonation bir aktörün başka kimlik gibi davranmasıdır. Downstream servis gerçek actor bilgisini göremeyebilir. Support veya admin araçlarında kontrollü senaryolar için kullanılabilir. Güçlü audit ve approval gerekir. Normal service-to-service communication için varsayılan model olmamalıdır.

Delegation Nedir?

Delegation user'ın belirli yetkisini başka service'e sınırlı biçimde aktarmasıdır. User identity korunur. Actor service de ayrı olarak belirtilir. Token exchange bu ilişkiyi temsil edebilir. Scope target operation ile sınırlandırılır.

User Identity

User identity işlemin kimin adına yapıldığını gösterir. Subject claim veya equivalent context içinde taşınabilir. Downstream service resource-level permission için bu bilgiyi kullanabilir. User identity service identity yerine geçmez. Her iki bağlam ayrı doğrulanmalıdır.

Actor/Service Identity

Actor identity kullanıcı adına request'i gerçekleştiren service'i gösterir. mTLS workload certificate veya token actor claim bu bilgiyi sağlayabilir. Audit trail actor ve user'ı birlikte kaydetmelidir. Service compromise durumunda hangi işlemlerin affected olduğunu anlamak kolaylaşır. Permission policy actor service'i de sınırlandırabilir.

Audit Trail

Sağlıklı audit kaydı user, actor, target resource ve action bilgisini birlikte saklar. Correlation ID distributed trace ile ilişki kurar. Token identifier veya credential metadata gerektiğinde eklenebilir ancak raw token saklanmamalıdır. Policy decision ve reason da loglanabilir. Bu kayıt incident ve compliance incelemesini kolaylaştırır.

Finansal İşlemlerde Delegation

Para transferi veya ödeme onayı gibi işlemlerde yalnızca service identity yeterli değildir. Kullanıcının kimliği ve transaction permission'ı açıkça doğrulanmalıdır. Actor service hangi adımı gerçekleştirdiğiyle birlikte loglanmalıdır. Downstream token mümkün olduğunca işlem ve resource scope ile sınırlandırılabilir. Yüksek riskte sender-constrained token ek koruma sağlayabilir.

Önerilen Kullanıcı + Workload Identity Modeli

Kurumsal microservice mimarisinde user identity ve workload identity ayrı fakat birlikte kullanılabilir. External user token gateway veya ilk servis tarafından doğrulanır. Service A kendi workload identity'sini mTLS veya federated credential ile kanıtlar. Downstream erişim gerekiyorsa STS user context ve actor service bilgisinden Service B'ye özel token üretir. Service B hem mTLS caller identity'yi hem internal token authorization context'ini doğrular.

External User Token

Kullanıcı IdP üzerinden external access token alır. Gateway issuer, audience ve expiration doğrulaması yapar. External token mümkün olduğunca internal servis zinciri boyunca ham şekilde taşınmaz. User identity ilk güven boundary'sinde çıkarılır. Downstream delegation gerekiyorsa STS kontrollü dönüşüm yapar.

Service A Workload Identity

Service A platform tarafından verilen workload identity kullanır. mTLS certificate veya signed workload token bunun örneğidir. Service B'nin Service A'yı user token üzerinden tanıması gerekmez. Workload identity deployment ile ilişkilidir. Credential kısa ömürlü ve otomatik rotate edilir.

Authorization Decision

Service A user request'ini alırken kendi endpoint authorization kararını verir. Kullanıcının requested operation'a yetkisi kontrol edilir. Downstream service çağrısı için gerekli permission ayrıca belirlenir. Bu decision central PDP üzerinden verilebilir. Denied request STS'e taşınmamalıdır.

Token Exchange

Service A user token veya trusted user context'i STS'e sunar. Aynı anda kendi workload identity'sini kanıtlar. STS Service B için daha dar access token üretir. Actor ve subject bilgileri ayrı korunabilir. Token kısa TTL ile sınırlandırılır.

Internal Access Token

Internal token yalnızca Service B için audience taşır. Scope downstream operation ile sınırlıdır. External token'daki gereksiz claim'ler çıkarılabilir. Token organization internal issuer tarafından imzalanabilir. Service B yalnızca bu issuer ve audience kombinasyonunu kabul eder.

Service A → Service B mTLS

Network bağlantısı mTLS üzerinden kurulur. Service B certificate identity'den caller'ın Service A olduğunu doğrular. Internal access token application authorization context sağlar. Token ve connection identity uyumu kontrol edilebilir. Böylece stolen token'ın başka workload tarafından kullanılması zorlaşır.

Service B Authorization

Service B önce workload identity ve token validity kontrolü yapar. Ardından user, actor, scope ve target resource bilgisine göre authorization kararı verir. Policy centralized PDP veya application içinde çalışabilir. Audit log bütün context'i correlation ID ile kaydeder. Bu model identity confusion riskini azaltır.

Service Authorization Nasıl Tasarlanmalıdır?

Service authorization basit allowlist'ten fine-grained policy modeline kadar farklı seviyelerde uygulanabilir. Service-to-service ACL başlangıç için anlaşılırdır. RBAC service role'leri, ABAC context attribute'larını, ReBAC ise resource ilişkilerini kullanır. Kurumsal ölçekte policy-as-code değişikliklerin review ve test edilmesini kolaylaştırır. En önemli prensip authenticated service'in otomatik olarak bütün internal kaynaklara yetkili sayılmamasıdır.

Service-to-Service ACL

ACL hangi source service'in hangi destination service'e erişebileceğini listeler. Küçük service graph'ta basit ve anlaşılırdır. Endpoint düzeyinde ek ayrıntı gerekiyorsa rule sayısı artabilir. Dependency graph'tan otomatik üretim veya validation yapılabilir. Kullanılmayan edge'ler düzenli kaldırılmalıdır.

RBAC

Role-Based Access Control service identity'leri belirli role'lerle ilişkilendirir. Örneğin reporting-reader rolü birkaç servise read access verebilir. Role sayısı kontrolsüz büyürse yönetim zorlaşır. Çok genel role'ler least privilege'i zayıflatır. Business capability odaklı role tasarımı daha anlaşılır olabilir.

ABAC

Attribute-Based Access Control identity, environment, resource ve request context attribute'larını değerlendirir. “production payment service yalnızca eu region customer resource okuyabilir” gibi kural yazılabilir. Esneklik yüksek olduğu için policy testleri önemlidir. Attribute source güvenilir olmalıdır. Kullanıcı tarafından gönderilen header doğrudan trusted attribute sayılmamalıdır.

ReBAC

Relationship-Based Access Control user veya service ile resource arasındaki ilişkileri kullanır. Özellikle çok tenant'lı ve hierarchical resource modellerinde yararlı olabilir. Service identity tek başına karar için yeterli olmayabilir. Graph relationship store operational dependency oluşturur. High-scale sistemde consistency ve latency gereksinimleri planlanmalıdır.

Fine-Grained Authorization

Fine-grained authorization resource instance, action ve context düzeyinde karar verir. Service-level network allowlist'ten daha ayrıntılıdır. Özellikle finansal veya tenant-isolated API'lerde önemlidir. Policy merkezi PDP üzerinden değerlendirilebilir. Cache kullanılırsa permission değişikliğinin yayılma süresi dikkate alınmalıdır.

Policy as Code

Policy-as-code authorization kurallarını version control altında tutar. Değişiklik pull request ile review edilebilir. Unit test ve integration test policy behavior'ı doğrular. Deployment pipeline policy'yi güvenli biçimde dağıtır. Rollback geçmiş version üzerinden yapılabilir.

Default-Deny Service Authorization

Default-deny yaklaşımı yeni bir workload identity'nin hiçbir service'e otomatik erişmemesini sağlar. Gerekli dependency explicit allow rule ile eklenir. Bu model network içine giren saldırganın serbest lateral movement yapmasını sınırlar. İlk rollout sırasında mevcut dependency graph çıkarılmalıdır. Policy kademeli uygulanarak production kesintisi riski azaltılabilir.

Her Servisi Başlangıçta Reddetmek

Default policy tüm service call'ları reddeder. Yeni workload ancak açık permission tanımlandığında hedefe erişebilir. Bu güvenli başlangıç principle of least privilege ile uyumludur. Brownfield sistemde bir anda uygulanırsa geniş outage oluşturabilir. Audit mode veya telemetry ile mevcut traffic önce gözlemlenmelidir.

Explicit Allow

Her gerekli service dependency explicit allow kuralıyla tanımlanır. Rule source identity, destination ve operation içerebilir. Business owner değişikliği review edebilir. Acil allow rule süreli yapılabilir. Kullanılmayan rule otomatik öneriyle kaldırılabilir.

Service Dependency Graph

Dependency graph runtime telemetry üzerinden hangi servislerin gerçekten iletişim kurduğunu gösterir. Bu bilgi initial policy generation için kullanılabilir. Ancak gözlenmemiş traffic otomatik gereksiz sayılmamalıdır. Seasonal veya failover path'leri ayrıca incelenmelidir. Graph security ve architecture review için değerli görünürlük sağlar.

Unused Permission Removal

Bir permission uzun süre kullanılmıyorsa kaldırılması değerlendirilebilir. Last-used telemetry bu kararı destekler. Critical DR path gibi nadiren kullanılan izinler yanlışlıkla silinmemelidir. Owner approval workflow uygulanabilir. Düzenli permission hygiene blast radius'u azaltır.

Policy Decision Point ve Policy Enforcement Point

Merkezi authorization mimarisinde karar verme ve uygulama sorumluluğu iki ayrı kavramla ifade edilir. PDP policy ve request context üzerinden allow veya deny kararı üretir. PEP bu kararı API gateway, mesh proxy veya application boundary üzerinde uygular. Merkezi decision tutarlı policy sağlar fakat latency ve availability bağımlılığı oluşturabilir. Distributed enforcement ile local cache bu dengeyi yönetmeye yardımcı olur.

PDP Nedir?

Policy Decision Point authorization kararının hesaplandığı bileşendir. User, workload, resource ve action attribute'larını değerlendirir. Policy-as-code burada çalışabilir. Karar reason veya policy ID ile birlikte döndürülebilir. PDP logları audit ve debugging için önemlidir.

PEP Nedir?

Policy Enforcement Point request'i durdurup PDP kararını uygular. API Gateway, service mesh proxy veya application middleware PEP olabilir. Deny kararında business operation'a geçilmez. PEP trusted context'i PDP'ye doğru aktarmalıdır. Bypass path olmaması gerekir.

Centralized Decision

Centralized PDP policy tutarlılığını artırır. Ekipler her serviste farklı authorization library yazmak zorunda kalmaz. Policy update merkezi uygulanır. Bunun karşılığında latency ve HA gereksinimi yükselir. Cache ve regional replica değerlendirilebilir.

Distributed Enforcement

Enforcement service veya proxy'lere dağıtılabilir. Request local PEP üzerinden kontrol edilir. Merkezi policy bundle belirli aralıklarla dağıtılabilir. Network outage sırasında local decision devam edebilir. Policy freshness ve revocation süresi açıkça yönetilmelidir.

Policy Cache

Policy cache yüksek request hacminde PDP round-trip maliyetini azaltabilir. Cache key tüm security-relevant attribute'ları içermelidir. Permission revoke edildiğinde stale allow kararı risk oluşturabilir. TTL risk seviyesine göre kısa tutulabilir. Deny result cache davranışı da ayrı değerlendirilmelidir.

OPA veya Cedar ile Merkezi Authorization

Policy engine kullanımı authorization logic'ini application kodundan ayırmaya yardımcı olabilir. OPA veya Cedar gibi policy yaklaşımları identity, user, resource ve context attribute'ları üzerinden karar üretebilir. Kurum tek bir policy modelini bütün servislere zorunlu kılmak yerine en yüksek değer sağlayan use case'lerden başlayabilir. Policy unit test ve simulation rollout güvenliğini artırır. Authorization platformunun availability ve governance modeli application kadar önemli hale gelir.

Policy-as-Code

Policy dosyaları source control içinde tutulabilir. Değişiklikler code review'dan geçer. Test case'leri beklenen allow ve deny davranışını doğrular. CI invalid policy'yi production'a çıkarmamalıdır. Version bilgisi runtime decision log'una eklenebilir.

Service Identity Attributes

Source workload identity, environment ve service owner gibi attribute'lar policy input olabilir. Bu değerler trusted identity system'den gelmelidir. User header içinden alınan service name güvenilir sayılmamalıdır. Policy exact identity veya controlled group üzerinden karar verebilir. Identity rename migration etkisi önceden planlanmalıdır.

User Attributes

User role, tenant veya authentication strength gibi bilgiler authorization kararına eklenebilir. Claim source trusted IdP olmalıdır. Token içindeki her claim otomatik policy input yapılmamalıdır. Hassas permission için current user state merkezi directory'den doğrulanabilir. Privacy gereksinimleri loglanan attribute set'ini sınırlandırabilir.

Resource Attributes

Resource owner, tenant, sensitivity veya region bilgisi fine-grained authorization için kullanılabilir. Service-level role tek başına yeterli olmayabilir. Policy resource attribute ile user ve actor context'i eşleştirebilir. Attribute stale olursa yanlış karar riski oluşur. Source-of-truth ve cache strategy açık olmalıdır.

Context-Aware Decisions

Request time, region, device veya risk signal gibi context attribute'ları policy'yi güçlendirebilir. Çok fazla dinamik context debugging'i zorlaştırabilir. Kritik ve güvenilir sinyaller seçilmelidir. Policy decision log hangi attribute'ların karara etki ettiğini göstermelidir. High-risk operation için ek verification uygulanabilir.

Kubernetes NetworkPolicy Authentication'ın Yerini Alır mı?

Kubernetes NetworkPolicy hangi pod veya namespace'in hangi network trafiğini yapabileceğini sınırlar. Bu önemli bir segmentation kontrolüdür ancak cryptographic workload authentication değildir. IP ve label tabanlı network identity ile application identity aynı şey değildir. mTLS veya signed token caller identity'yi doğrular. NetworkPolicy ve workload authentication birlikte kullanıldığında defense in depth elde edilir.

Network Segmentation

Network segmentation gereksiz connection path'lerini kapatır. Database'e yalnızca ilgili backend namespace erişebilir. Bu durum attack surface'i azaltır. Ancak izin verilen connection'daki caller kimliğini application-level olarak doğrulamaz. Network policy identity layer'ın tamamlayıcısıdır.

Workload Authentication

Workload authentication connection'ın arkasındaki service identity'yi doğrular. Certificate veya token cryptographic proof sağlar. Pod IP değişse bile identity devam eder. Network policy yanlış yapılandırılsa bile authentication başka koruma katmanı sunar. İki kontrol birbirinin yerine geçmez.

Identity-Based Policy

Identity-based policy workload name veya SPIFFE ID üzerinden authorization yapar. Dynamic IP değişiklikleri policy'yi etkilemez. Mesh source principal bu yaklaşımı destekleyebilir. Application endpoint permission'ı da identity ile ilişkilendirilebilir. Network location yalnızca ek context olarak kullanılır.

Defense in Depth

NetworkPolicy gereksiz trafiği sınırlar. mTLS caller identity'yi doğrular. OAuth veya policy engine operation permission'ını kontrol eder. Bir katmanda hata olsa bile diğerleri saldırının ilerlemesini zorlaştırır. Bu kombinasyon Zero Trust yaklaşımına daha yakındır.

Async Servisler Arası Authentication

Asynchronous sistemlerde producer ile consumer aynı network connection üzerinde doğrudan iletişim kurmayabilir. Kafka, RabbitMQ veya cloud queue broker bağlantısını authenticate edebilir. Ancak message'ın original producer identity'si ve user delegation bilgisi ayrıca taşınmak istenebilir. Connection identity ile message-level identity birbirinden ayrılmalıdır. Replay ve message integrity riskleri protokol ve business önemine göre değerlendirilmelidir.

Kafka

Kafka producer ve consumer authentication TLS certificate, SASL veya cloud identity mekanizmasıyla yapılabilir. Topic ACL service identity üzerinden uygulanabilir. Producer identity broker loglarında görünür olmalıdır. Message'a original user context gerekiyorsa ayrı signed metadata eklenebilir. Credential kısa ömürlü veya otomatik rotate edilebilir olmalıdır.

RabbitMQ

RabbitMQ client authentication certificate veya user credential ile yapılabilir. Virtual host ve queue permission service identity ile sınırlandırılmalıdır. Shared account kullanımından kaçınılmalıdır. mTLS unique client identity sağlayabilir. Message-level authorization uygulama tarafından ayrıca doğrulanabilir.

SQS

Cloud queue servislerinde native IAM role workload authentication için kullanılabilir. Static access key gereksiz hale gelir. Queue policy hangi role'ün send veya receive yapabileceğini belirler. Cross-account access federation veya explicit trust ile yönetilir. Message içindeki sensitive context ayrıca şifrelenebilir veya imzalanabilir.

Pub/Sub

Managed pub/sub platformlarında service account veya workload identity kullanılabilir. Publisher ve subscriber permission ayrı tanımlanmalıdır. Shared service account audit görünürlüğünü azaltır. Cross-project access minimum role ile sınırlandırılmalıdır. User delegation gerekiyorsa message metadata modeline açıkça eklenmelidir.

Producer Identity

Broker connection hangi workload'un message yayınladığını doğrulayabilir. Bu identity topic veya queue authorization için kullanılır. Message daha sonra başka sisteme kopyalandığında connection identity kaybolabilir. Gerekiyorsa producer identity signed metadata olarak message'a eklenebilir. Tüketici bu metadata'nın trusted source tarafından üretildiğini doğrulamalıdır.

Consumer Identity

Consumer broker'a kendi workload identity'siyle bağlanmalıdır. Aynı shared credential'ı bütün consumer fleet'e vermek audit değerini azaltabilir. Permission yalnızca gerekli subscription veya queue için verilmelidir. Scaling sırasında credential otomatik sağlanmalıdır. Consumer compromise durumunda etkilenebilecek resource set'i dar olmalıdır.

Message-Level Identity ve Delegation

Async workflow uzun süre devam ettiğinde connection identity tek başına yeterli olmayabilir. Message original producer, original user, timestamp ve integrity bilgisini taşıyabilir. Ancak kullanıcı token'ını olduğu gibi günlerce queue içinde saklamak uygun değildir. Bunun yerine minimal signed context veya workflow identity kullanılabilir. Replay protection ve message idempotency business işlemin niteliğine göre uygulanmalıdır.

Connection Identity

Connection identity producer'ın broker'a bağlandığı sıradaki workload kimliğidir. Broker authentication ve topic permission için kullanılır. Message başka topic veya data store'a taşındığında bu bağlam otomatik korunmaz. Audit sistemi connection logunu message ID ile ilişkilendirebilir. Gerekiyorsa identity bilgisi trusted envelope içinde taşınabilir.

Message Producer

Message producer logical service identity'si metadata içinde bulunabilir. Bu alan client tarafından serbestçe yazılabiliyorsa güvenilir sayılmamalıdır. Broker veya trusted signing component tarafından eklenmesi daha güvenlidir. Consumer expected producer set'ini kontrol edebilir. Cross-service message spoofing böylece azaltılabilir.

Original User

User action async workflow başlattıysa original user kimliği audit için korunabilir. Full access token'ı queue içine koymak yerine user ID ve authorization snapshot reference kullanılabilir. Uzun workflow'da current permission değişiklikleri dikkate alınmalıdır. Kritik adımda yeniden authorization gerekebilir. Delegation lifetime business process süresinden bağımsız tasarlanmalıdır.

Timestamp

Message timestamp replay ve freshness kontrolüne yardımcı olur. Consumer çok eski message'ları business rule'a göre reddedebilir. Timestamp tek başına replay engellemez. Unique message ID ve processed-event store kullanılabilir. Clock synchronization yine önemlidir.

Integrity

Message broker dışında depolanacak veya farklı trust boundary geçecekse message-level signature değerlendirilebilir. Signature payload'ın değiştirilmediğini doğrular. Key ownership producer identity ile ilişkilendirilmelidir. Encryption confidentiality için ayrıca gerekir. Schema canonicalization signature validation için açık olmalıdır.

Replay Protection

Async sistemde aynı message yeniden teslim edilebilir, bu nedenle güvenlik replay'i ile normal at-least-once delivery ayrılmalıdır. Idempotency key business operation'ın tekrar uygulanmasını engelleyebilir. Sensitive command için nonce veya sequence number kullanılabilir. Consumer processed identifier'ları belirli süre saklar. Retention süreleri workflow davranışıyla uyumlu olmalıdır.

Background Worker ve Cron Job Kimliği

Worker ve cron job'ların arkasında doğrudan kullanıcı olmayabilir ancak yine de güçlü service identity gerekir. Bu workload'lara insan hesabı veya kişisel token vermek hatalıdır. Workload identity veya OAuth Client Credentials ile kendi adına authentication yapılmalıdır. Permission yalnızca job'ın gerçekleştirdiği task ile sınırlandırılmalıdır. Credential kısa ömürlü ve job lifecycle'ıyla uyumlu olmalıdır.

Kullanıcı Olmadan Authentication

Scheduled job kullanıcı session'ı olmadan çalışır. User access token kullanmak operasyonel ve güvenlik açısından yanlıştır. Job ayrı machine identity ile tanımlanmalıdır. Audit log işlemin automated workload tarafından yapıldığını göstermelidir. Eğer business owner bilgisi gerekiyorsa metadata olarak ayrıca tutulabilir.

Workload Identity

Kubernetes CronJob service account veya cloud managed identity kullanabilir. Job başladığında kısa ömürlü credential alır. Static secret image içine gömülmez. Job bittiğinde credential kısa süre içinde geçersiz olur. Autoscaling worker aynı identity policy üzerinden yeni token alabilir.

Scoped Permissions

Worker yalnızca kullandığı queue, database operation veya API endpoint için permission almalıdır. Generic backend admin role verilmemelidir. Scope task bazında ayrı olabilir. High-risk job için approval veya additional context gerekebilir. Unused permission telemetry ile temizlenebilir.

Short-Lived Credentials

Job süresi biliniyorsa credential lifetime buna yakın seçilebilir. Uzun batch işlerinde token refresh uygulanır. Çok uzun tek token üretmek risklidir. Refresh failure güvenli şekilde ele alınmalıdır. Credential expiration job state'i bozmayacak şekilde retry tasarımı gerektirir.

Long-Running Workflow'larda Credential Yönetimi

Günlerce veya haftalarca devam eden workflow için tek access token üretmek güvenli değildir. User permission ve service state zaman içinde değişebilir. Workflow kendi kalıcı logical identity'sine sahip olabilir, ancak runtime credential her adımda kısa ömürlü alınmalıdır. Kritik step öncesinde yeniden authorization yapılabilir. User delegation lifetime workflow lifetime'dan ayrı yönetilmelidir.

Günlerce Yaşayan Token Anti-Pattern

Uzun ömürlü token theft riskini büyütür. Permission revoke edilse bile token geçerli kalabilir. Workflow engine token değerini database içinde saklamak zorunda kalabilir. Bunun yerine refreshable workload identity kullanılmalıdır. Her execution step ihtiyaç anında yeni credential alabilir.

Credential Refresh

Workflow engine token expiration yaklaşınca yeni short-lived token almalıdır. Refresh secret yerine workload identity kullanılabilir. Failure durumunda exponential retry uygulanabilir. Sonsuz retry güvenlik veya business deadline sorununa yol açabilir. Credential refresh telemetry ayrı izlenmelidir.

Re-Authorization

Kritik adımlar başlatılmadan önce user veya business permission yeniden değerlendirilebilir. Workflow ilk başlatıldığında verilen izin günler sonra geçerli olmayabilir. Re-authorization current policy üzerinden yapılmalıdır. User artık yetkili değilse işlem durdurulabilir. Audit trail decision time bilgisini saklar.

Workflow Identity

Workflow instance kendine özgü logical identifier taşıyabilir. Workload process değişse bile workflow identity audit continuity sağlar. Ancak bu identifier tek başına authentication credential olmamalıdır. Runtime worker kendi workload identity'siyle işlem yapar. Policy workflow context'i ek authorization input olarak kullanabilir.

User Delegation Lifetime

User delegation sonsuza kadar geçerli olmamalıdır. Business işlem tamamlanma süresine göre delegation window tanımlanabilir. Uzun workflow'da explicit re-consent veya re-authorization gerekebilir. User hesabı devre dışı bırakılırsa pending delegation etkisi belirlenmelidir. Financial process için süre daha sıkı olabilir.

Serverless Service Authentication

Serverless workload'lar kısa ömürlü ve dinamik instance'lar oldukları için static credential dağıtımına uygun değildir. Cloud provider managed identity veya OIDC federation genellikle daha iyi modeldir. Function runtime ihtiyaç anında kısa ömürlü cloud token alabilir. Sidecar proxy kullanmak her serverless platformda mümkün olmadığından authentication application SDK veya platform identity endpoint üzerinden yapılabilir. Permission function veya workload bazında minimum tutulmalıdır.

Managed Workload Identity

Serverless function platform tarafından managed identity ile ilişkilendirilebilir. Application key dosyası saklamaz. Runtime token endpoint kısa ömürlü credential sağlar. IAM permission function'ın kullandığı resource ile sınırlandırılır. Deployment silindiğinde identity lifecycle da kapatılabilir.

OIDC Federation

Function başka cloud veya external API'ye OIDC token ile federated authentication yapabilir. Target STS issuer ve audience doğrular. Static partner secret paylaşılmaz. Trust rule function identity claim'leriyle sınırlandırılır. Cross-cloud serverless integration için güçlü modeldir.

Short-Lived Cloud Credentials

Serverless execution kısa olduğundan credential lifetime da kısa tutulabilir. Platform SDK token'ı otomatik yenileyebilir. Credential log veya environment dump'ta görünmemelidir. Function concurrency artsa bile her instance aynı secure identity mechanism'ı kullanır. Revocation IAM policy üzerinden merkezi yapılabilir.

Sidecar Olmadan Authentication

Bazı serverless platformlarda sidecar veya daemon çalıştırmak mümkün değildir. Application doğrudan platform workload identity endpoint'ine bağlanabilir. OAuth client library token cache ve refresh yapabilir. mTLS gerekiyorsa platform gateway veya application TLS certificate mechanism kullanılabilir. Mimari runtime sınırlarına göre seçilmelidir.

Servisten Veritabanına Authentication

Service authentication yalnızca HTTP API'lerle sınırlı değildir. Veritabanı bağlantılarında da static password yerine dynamic credential veya workload identity kullanılabilir. Cloud managed database'ler IAM tabanlı authentication destekleyebilir. mTLS client certificate ile database identity doğrulanabilir. Database permission'ı application service account düzeyinde minimum tutulmalıdır.

Static Database Password

Static password kolay uygulanır ancak uzun ömürlü secret riskini taşır. Birden fazla replica aynı password'u paylaşabilir. Rotation application connection pool'larını etkileyebilir. Secret manager storage'ı iyileştirir ancak password yine uzun ömürlü olabilir. Dynamic credential varsa geçiş değerlendirilmelidir.

Dynamic Database Credentials

Dynamic database credential secret broker tarafından kısa süre için üretilebilir. Her workload veya session farklı credential alabilir. Expiration sonrası credential otomatik geçersiz olur. Database user lifecycle merkezi platform tarafından yönetilir. Connection pool refresh davranışı doğru tasarlanmalıdır.

IAM Database Authentication

Managed database bazı cloud IAM principal'larının temporary token ile login olmasına izin verir. Static database password gerekmez. Workload role minimum database permission ile eşleştirilir. Token kısa lifetime taşıyabilir. Driver ve pool token refresh desteği test edilmelidir.

mTLS

Database server certificate client tarafından doğrulanabilir ve client certificate authentication uygulanabilir. Certificate identity database role ile eşleştirilebilir. Short-lived certificate otomatik rotate edilmelidir. TLS encryption sensitive query ve result trafiğini korur. Authorization yine database role ve grant'ler üzerinden yapılır.

Workload Identity

Service kendi platform identity'sini kullanarak database credential alabilir. Secret zero problemi azalır. Database access service deployment ile ilişkilendirilebilir. Audit log connection identity'yi application service ile eşleştirir. Permission business need'e göre dar tutulmalıdır.

Servisten Cloud API'lerine Authentication

Cloud API erişiminde static access key kullanmak mümkün olsa da workload identity daha güvenli bir model sunar. IAM role, managed identity veya federation workload'a short-lived credential verir. STS trust relation application identity ile cloud permission arasında köprü kurar. Static key rotation ve repository leakage riski azalır. Cloud resource access için native workload identity çoğu durumda ilk tercih olmalıdır.

Static Access Key

Static access key uzun ömürlü credential riskleri taşır. Key source code veya secret store içinde saklanır. Rotation application deployment'ını etkileyebilir. Shared key audit visibility'yi azaltır. Native role mekanizması varsa static key'den kaçınılmalıdır.

IAM Role

IAM role workload'a belirli cloud permission set'i verir. Compute platform role credential'ını runtime sırasında sağlayabilir. Access key kalıcı saklanmaz. Policy minimum API action ve resource ile sınırlandırılmalıdır. Role assumption olayları audit sistemine gönderilebilir.

Managed Identity

Managed identity cloud resource lifecycle'ıyla birlikte kimlik yönetimini basitleştirir. Secret veya certificate application tarafından korunmaz. Token platform endpoint'inden alınır. RBAC target resource erişimini belirler. Kullanılmayan identity offboarding sırasında kaldırılmalıdır.

Federated Token

External workload OIDC veya SAML benzeri assertion ile cloud trust endpoint'e bağlanabilir. Cloud issuer'ı ve claim'leri doğrular. Kısa ömürlü local credential üretir. Static cross-cloud secret gerekmez. Audience ve subject trust rule dar tutulmalıdır.

STS

Security Token Service temporary cloud credential üretir. Caller mevcut workload identity ile role assumption talep eder. Policy uygun role'ü belirler. Credential kısa lifetime ile verilir. STS outage cloud resource erişimini etkileyebileceği için resilience planlanmalıdır.

Credential Lifecycle Yönetimi

Credential güvenliği yalnızca nasıl üretildiğiyle değil, tüm yaşam döngüsüyle ilgilidir. Issuance, distribution, usage, rotation, renewal, revocation ve retirement aşamaları ayrı kontrol gerektirir. Static credential kullanılıyorsa bu süreçlerin yükü daha yüksektir. Workload identity birçok adımı otomatikleştirir ancak control plane güvenliği kritik hale gelir. Identity inventory lifecycle'ın hangi aşamasında hangi credential'ın bulunduğunu göstermelidir.

Issuance

Credential yalnızca doğrulanmış workload veya client için üretilmelidir. Registration ve attestation policy açık olmalıdır. Issuance event audit log'a yazılır. Human approval gereken yüksek riskli identity'ler ayrı workflow kullanabilir. Default permission minimum tutulmalıdır.

Distribution

Credential güvenli channel üzerinden workload'a iletilmelidir. Build artifact, e-posta veya shared storage kullanılmamalıdır. Runtime API veya protected volume tercih edilebilir. Private key hiçbir zaman merkezi log'a yazılmamalıdır. Distribution failure observability ile görünür olmalıdır.

Usage

Credential hangi service ve resource'larda kullanılıyor izlenmelidir. Unexpected target veya region anomaly olabilir. Last-used bilgisi unused credential cleanup için değerlidir. Sensitive token değerinin kendisi loglanmamalıdır. Identity identifier ve token metadata yeterlidir.

Rotation

Credential belirli aralıklarla otomatik değiştirilmelidir. Rotation kesinti yaratmadan yapılmalıdır. Yeni credential aktifleşirken eski kısa grace period boyunca kullanılabilir. Compromise durumunda normal plan beklenmez. Rotation testleri düzenli çalıştırılmalıdır.

Renewal

Kısa ömürlü credential expiration öncesinde yenilenir. Renewal workload'un halen attestation koşullarını karşılayıp karşılamadığını yeniden doğrulayabilir. Stale deployment yeni credential alamamalıdır. Failure retry mekanizması kontrollü olmalıdır. Uzun grace period güvenlik hedefini zayıflatabilir.

Revocation

Workload compromise veya offboarding durumunda credential derhal geçersiz hale getirilmelidir. Token revoke list veya IAM policy update kullanılabilir. Çok kısa TTL explicit revocation ihtiyacını azaltabilir. Certificate trust veya CA revoke mekanizması planlanmalıdır. Revocation propagation süresi ölçülmelidir.

Retirement

Servis tamamen kapandığında identity, role ve trust relation'ları da kaldırılmalıdır. Credential repository'de veya secret manager'da unutulmamalıdır. Service owner offboarding checklist'i identity cleanup içermelidir. Last-used metriği orphan identity tespitine yardımcı olur. Audit için gerekli geçmiş metadata retention politikasına göre saklanabilir.

Short-Lived Credential Tasarımı

Kısa ömürlü credential risk süresini azaltır ancak availability tasarımını daha önemli hale getirir. TTL çok kısa olursa identity provider veya CA outage hemen application outage'a dönüşebilir. Çok uzun olursa credential theft etkisi büyür. Automatic renewal ve grace period bu dengeyi yönetmeye yardımcı olur. Hangi operasyonun fail-open veya fail-closed davranacağı önceden belirlenmelidir.

TTL Nasıl Belirlenmeli?

TTL risk seviyesi, refresh maliyeti ve platform availability'sine göre seçilmelidir. Yüksek değerli privileged operation için daha kısa süre anlamlı olabilir. Normal internal API token'ında birkaç dakika veya onlarca dakika uygun olabilir. Certificate otomatik rotate ediliyorsa saatler düzeyinde lifetime kullanılabilir. Tek bir global TTL yerine credential türüne göre policy oluşturulabilir.

Security ve Availability Dengesi

Kısa TTL theft blast radius'u azaltır. Ancak IdP erişilemezse yeni token alınamaz. Local validation cached signing key ile devam edebilir fakat issuance etkilenir. Critical system için regional token service veya HA gerekir. Risk analizi iki tarafı birlikte değerlendirmelidir.

Automatic Renewal

Credential expiration yaklaşmadan background refresh yapılmalıdır. Application expiry anını beklememelidir. Jitter kullanmak bütün fleet'in aynı anda refresh yapmasını engeller. Refresh başarısızsa alarm üretilmelidir. Retry backoff identity service'i overload etmemelidir.

Grace Period

Certificate rotation sırasında kısa overlap süresi bağlantı kesintisini önleyebilir. Grace period çok uzun tutulursa eski credential'ın risk süresi büyür. Token modelinde refresh token veya overlapping validity farklı davranabilir. Süre açık security policy ile belirlenmelidir. Emergency revocation grace period'u bypass edebilmelidir.

Expiration Failure

Credential süresi dolduğunda application güvenli şekilde failure üretmelidir. Silent fallback ile static admin secret kullanmak tehlikelidir. Retry ve circuit breaker kullanıcıya kontrollü hata döndürebilir. Expiration metric platform ekibini erken uyarmalıdır. Chaos test credential renewal failure'ı kapsamalıdır.

Service Identity Inventory

Kurumsal ortamda hangi servis identity'lerinin bulunduğunu bilmeden güvenliği yönetmek zordur. Inventory identity, owner, environment, permission, credential type, expiration ve last-used bilgilerini bir arada tutmalıdır. Target service ilişkileri dependency graph ile eşleştirilebilir. Orphan veya deprecated identity'ler düzenli temizlenebilir. Bu envanter migration ve incident response sırasında da değerli bir referans olur.

Identity

Her workload unique ve stabil logical identity taşımalıdır. Identity naming convention organization genelinde anlaşılır olmalıdır. Aynı identity farklı bağımsız servisler tarafından paylaşılmamalıdır. Identity URI, service account veya IAM principal biçiminde olabilir. Mapping sistemi platformlar arası ilişkiyi göstermelidir.

Service Owner

Her identity'nin sorumlu team veya owner bilgisi bulunmalıdır. Incident sırasında kiminle iletişime geçileceği açık olur. Sahipsiz identity security debt oluşturur. Organization değişikliklerinde owner metadata güncellenmelidir. Ownership portal veya service catalog ile entegre edilebilir.

Environment

Identity'nin development, staging veya production ortamına ait olduğu açıkça görünmelidir. Production permission'ı non-production workload'a taşınmamalıdır. Environment policy trust domain veya IAM role ile ayrılabilir. Inventory cross-environment reuse'ı tespit edebilir. Yanlış reuse güvenlik alarmı oluşturabilir.

Permissions

Identity'ye verilen API, cloud ve database permission'ları merkezi görünür olmalıdır. Granted permission ile actual usage karşılaştırılabilir. Broad role'ler iyileştirme adayıdır. Permission owner approval kaydı tutulabilir. Policy change geçmişi audit için saklanmalıdır.

Credential Type

Identity static API key, OAuth secret, certificate veya workload token kullanıyor olabilir. Credential type migration önceliğini belirlemeye yardımcı olur. Long-lived shared secret yüksek riskli aday olarak işaretlenebilir. Automatic rotation capability ayrıca kaydedilebilir. Hedef mimari workload identity kullanımını artırabilir.

Expiration

Static veya certificate credential'ın expiration tarihi inventory'de görünmelidir. Yaklaşan expiration alert oluşturur. Otomatik credential için policy lifetime kaydedilebilir. No-expiry credential ayrıca risk olarak işaretlenmelidir. Emergency rotation planı critical identity için belirtilmelidir.

Last Used

Last-used metadata orphan identity tespitine yardımcı olur. Aylarca kullanılmayan credential kaldırılabilir. Ancak DR veya seasonal workload dikkate alınmalıdır. Owner doğrulaması sonrası retirement yapılmalıdır. Kullanım kaydı privacy ve retention politikasına uygun tutulmalıdır.

Target Services

Bir identity'nin hangi service veya resource'lara eriştiği dependency graph oluşturur. Unexpected target call anomaly olabilir. Policy ile observed graph arasındaki fark least-privilege optimization sağlar. Cross-environment target özellikle incelenmelidir. Inventory architecture review için de değerli olur.

Service Onboarding Süreci

Yeni bir mikroservis production'a girmeden önce identity ve permission modeli oluşturulmalıdır. Identity creation, workload attestation, minimum permission ve token veya certificate policy onboarding'in standart parçaları olmalıdır. Observability baştan eklenirse sonradan kimlik sorunlarını takip etmek kolaylaşır. Security review yalnızca manuel form değil, automated control ve template'lerle desteklenmelidir. Golden path yaklaşımı geliştiricinin güvenli servisi daha hızlı oluşturmasını sağlar.

Identity Oluşturma

Yeni service için unique workload identity oluşturulur. Naming convention service catalog ile uyumlu olmalıdır. Identity environment ayrımını desteklemelidir. Shared account reuse engellenmelidir. Owner metadata aynı anda kaydedilmelidir.

Workload Attestation

Service deployment hangi attribute'larla identity alacağını tanımlar. Kubernetes service account veya image digest örnek sinyallerdir. Attestation rule code review'dan geçmelidir. Çok geniş selector başka workload'un identity almasına yol açmamalıdır. Production rule staging'den ayrı değerlendirilebilir.

Minimum Permissions

Yeni service başlangıçta yalnızca gerekli dependency'lere izin almalıdır. “Internal admin” gibi geniş role verilmemelidir. API method ve cloud resource mümkün olduğunca dar tanımlanır. Pilot traffic sonrası unused permission temizlenebilir. Permission request service owner tarafından belgelenmelidir.

Certificate/Token Policy

Service hangi credential türünü kullanacak açık olmalıdır. Token audience, scope ve TTL standardı belirlenir. Certificate lifetime ve trust domain tanımlanır. Static secret exception ise neden ve expiration tarihi kaydedilir. Rotation otomatik test edilmelidir.

Observability

Authentication success, failure ve authorization denial loglanmalıdır. Source ve destination identity görünür olmalıdır. Correlation ID distributed trace ile ilişki kurar. Sensitive token değeri loglanmamalıdır. Dashboard service owner'a kendi authentication health bilgisini göstermelidir.

Security Review

Review threat model ve permission scope'u doğrular. Static credential kullanımına gerekçe sorulur. Production access ve user delegation özel incelenir. Automated policy check yaygın hataları erken yakalar. Review geliştiriciyi yavaşlatan manuel gate yerine self-service guardrail modeline yaklaşmalıdır.

Service Offboarding Süreci

Servis kapatıldığında code repository'yi archive etmek yeterli değildir. Identity, cloud role, certificate trust ve authorization policy de kaldırılmalıdır. Kullanılmayan credential saldırgan için görünmeyen erişim yolu bırakabilir. Service dependency graph target permission'ların da temizlenmesini sağlar. Offboarding mümkün olduğunca service catalog lifecycle event'ine bağlanmalıdır.

Identity Revocation

Servis artık çalışmıyorsa workload identity issuance durdurulmalıdır. Registration entry kaldırılır. Aktif kısa ömürlü credential kısa sürede expire olur. Kritik durumlarda explicit revocation uygulanabilir. Identity name gelecekte yanlışlıkla tekrar kullanılmamalıdır.

Policy Removal

Source ve destination allow rule'lar kaldırılmalıdır. Orphan policy audit sırasında karışıklık yaratır. Dependency graph retirement etkisini gösterebilir. Shared policy başka servisleri etkiliyorsa dikkatle ayrıştırılmalıdır. Change review uygulanmalıdır.

Certificate Invalidation

Uzun ömürlü certificate varsa offboarding sırasında invalidate edilmelidir. Otomatik workload certificate'ı issuance kesildiğinde kısa sürede expire olur. CA trust relation gereksizse kaldırılabilir. Private key storage güvenli şekilde temizlenmelidir. Audit event retirement kaydı tutmalıdır.

Cloud IAM Role Removal

Service için oluşturulmuş IAM role veya binding kaldırılmalıdır. Shared role kullanımı cleanup'ı zorlaştırır. Resource policy içindeki principal reference da temizlenmelidir. Last-used log role'ün gerçekten boş olduğunu doğrulayabilir. IaC destroy süreci identity cleanup ile entegre edilmelidir.

Unused Credential Cleanup

Secret manager, CI ve config sistemlerinde eski credential kalabilir. Inventory retirement checklist bu lokasyonları kapsamalıdır. Secret revoke edildikten sonra storage'dan silinebilir. Historical audit metadata ayrı tutulabilir. Regular orphan scan unutulan credential'ları tespit eder.

Multi-Cloud Servis Authentication Mimarisi

Multi-cloud ortamında her platformun farklı IAM ve workload identity mekanizması bulunabilir. Bunları tamamen tek sisteme dönüştürmek yerine ortak logical service identity ve federation modeli oluşturmak daha uygulanabilir olabilir. Cloud-native identity resource erişiminde güçlü kalırken SPIFFE veya STS cross-cloud service authentication sağlayabilir. On-premises workload da aynı federation modeline dahil edilebilir. Trust boundaries ve ownership net tanımlandığında portability ile native security özellikleri dengelenebilir.

AWS

AWS workload IAM role üzerinden temporary credential kullanabilir. Cross-cloud servis çağrısında OIDC federation veya SPIFFE identity kullanılabilir. Static access key'den kaçınılmalıdır. CloudTrail identity usage audit sağlar. Mapping sistemi AWS role ile logical service identity ilişkisini göstermelidir.

Azure

Azure workload managed identity ile resource token alabilir. Cross-cloud access federation üzerinden yapılabilir. Azure role assignment minimum scope'ta tutulmalıdır. Identity lifecycle deployment automation ile ilişkilendirilebilir. Multi-cloud audit merkezi SIEM'e aktarılabilir.

GCP

GCP workload service account ve workload identity federation kullanabilir. Key file dağıtımı gerekmez. Service account impersonation çok geniş izinle kullanılmamalıdır. Cross-cloud trust policy audience ve subject claim'lerini sınırlar. Logical service mapping identity graph içinde tutulabilir.

On-Premises

On-prem workload native cloud identity'ye sahip olmayabilir. SPIFFE/SPIRE veya enterprise PKI workload identity sağlayabilir. Cloud access gerektiğinde federation STS üzerinden temporary credential alınabilir. Static cloud key sunucuya kopyalanmamalıdır. Attestation VM veya process metadata üzerinden yapılabilir.

Ortak Identity Plane

Ortak identity plane farklı platform principal'larını logical service identity altında eşleştirebilir. Bu plane SPIFFE, central STS veya identity catalog olabilir. Cloud resource permission native IAM'de kalabilir. Cross-service authentication ortak semantics kullanır. Organization ownership ve trust domain standardı merkezi yönetilir.

Federation

Federation farklı identity issuer'ların birbirine belirli koşullarda güvenmesini sağlar. Trust relation broad organization-wide olmamalıdır. Specific workload ve audience kısıtlaması uygulanmalıdır. Signing key rotation iki taraf arasında otomatik takip edilmelidir. Federation failure DR senaryosu ayrıca test edilmelidir.

Multi-Cluster Kubernetes Authentication

Birden fazla Kubernetes cluster kullanan işletmeler cluster-local service account identity'lerini nasıl ilişkilendireceğine karar vermelidir. Aynı trust domain deployment kolaylığı sağlarken separate trust domain daha güçlü boundary sunabilir. Cross-cluster mTLS certificate trust üzerinden yapılabilir. Federation identity separation'ı korurken kontrollü iletişime izin verir. Cluster compromise senaryosu trust domain kararında önemli bir faktördür.

Cluster-Local Identity

Her cluster kendi service account ve certificate issuance sistemini kullanabilir. Aynı service farklı cluster'da farklı underlying principal taşıyabilir. Logical identity mapping ortak policy için gereklidir. Cluster-local trust compromise etkisini sınırlar. Cross-cluster access explicit federation gerektirir.

Shared Trust Domain

Bütün cluster'lar aynı trust domain altında identity alabilir. Service identity cluster değişse de aynı formatta kalır. Policy ve service mobility kolaylaşır. Ancak compromised cluster'ın identity issuance etkisi daha geniş olabilir. Node ve workload attestation güçlü uygulanmalıdır.

Separate Trust Domains

Her cluster veya environment ayrı trust domain kullanabilir. Bu daha güçlü isolation sağlar. Cross-cluster call federation ve explicit policy gerektirir. Operasyon maliyeti trust bundle sayısıyla artar. Regulated veya high-risk cluster için anlamlı olabilir.

Cross-Cluster mTLS

Service A başka cluster'daki Service B'ye mTLS ile bağlanabilir. Routing ve certificate trust birlikte çalışmalıdır. Source identity cluster attribute'u authorization input olabilir. Gateway veya mesh federation bağlantıyı yönetebilir. Network encryption iki cluster arasında transit güvenliği sağlar.

Federation

Separate trust domain kullanan cluster'lar federation ile birbirinin identity'sini doğrulayabilir. Trust relation yalnızca gerekli cluster çiftleri arasında kurulabilir. Policy target service bazında dar tutulur. Federation certificate ve bundle rotation otomatik olmalıdır. Audit cross-domain çağrıyı açıkça göstermelidir.

Authentication Infrastructure High Availability

Identity altyapısı bütün servis trafiğinin temel bağımlılığı haline geldiğinde yüksek availability kritik olur. Identity provider token issuance, CA certificate issuance, workload identity control plane ve policy engine ayrı failure mode'lara sahiptir. Secret manager erişimi de bazı servisleri etkileyebilir. Local validation ve cached trust data bazı outage senaryolarında sistemi çalışır tutabilir. Ancak yeni credential issuance gerektiğinde control plane availability doğrudan business availability'ye dönüşür.

Identity Provider HA

IdP birden fazla instance ve region üzerinde çalışabilir. Token endpoint load balanced olmalıdır. Signing key consistency güvenli biçimde yönetilmelidir. Resource server cached JWKS ile mevcut token'ları doğrulamaya devam edebilir. Authentication SLO business kritikliğiyle uyumlu olmalıdır.

Certificate Authority HA

Workload certificate'ları kısa ömürlü ise CA outage hızlı etki yaratabilir. Intermediate CA replica modeli kullanılabilir. Root key günlük online operation'da bulunmamalıdır. Issuance queue ve retry behavior kontrollü olmalıdır. Rotation outage testi düzenli yapılmalıdır.

Workload Identity Control Plane HA

SPIRE server veya benzeri identity control plane birden fazla replica ile çalışabilir. Registration data güvenilir storage'da tutulur. Agent mevcut certificate expiration'a kadar çalışabilir. Uzun outage yeni workload'ların identity alamamasına yol açar. Failover prosedürü otomatik test edilmelidir.

Policy Engine HA

Central PDP outage bütün request'leri durdurabilir. Regional replica veya local policy bundle kullanılabilir. Hangi operation'ın cached allow ile devam edebileceği risk temelli belirlenmelidir. Kritik write operation fail-closed olabilir. Read-only düşük riskli path için farklı davranış değerlendirilebilir.

Secret Manager HA

Secret manager bazı legacy credential ve database secret'larının kaynağı olabilir. Outage application startup veya rotation'ı etkileyebilir. Local encrypted cache çok sınırlı durumlarda kullanılabilir. Workload identity adoption secret manager dependency'sini azaltabilir. DR replica ve restore prosedürü test edilmelidir.

Identity Sisteminde Disaster Recovery

Identity sistemi için backup yalnızca database snapshot almak değildir. Signing key, root CA, trust bundle ve registration kayıtlarının recovery süreci ayrı planlanmalıdır. Emergency credential re-issuance yeni trust chain'e geçişi mümkün kılmalıdır. DR ortamı normal production güvenlik seviyesini korumalıdır. Yılda en az belirli aralıklarla recovery tatbikatı yapılması gerçek hazır oluşu ölçer.

Signing Key Backup

Signing private key backup yüksek güvenlikle korunmalıdır. Hardware-backed key kullanılıyorsa backup veya replica modeli vendor özelliğine göre tasarlanır. Backup erişimi minimum sayıda role verilmelidir. Restore operation audit ve dual control gerektirebilir. Compromise edilmiş key backup'tan geri yüklenmemelidir.

Root CA Recovery

Root CA kaybı yeni trust chain kurmayı zorlaştırabilir. Offline backup ve recovery procedure önceden test edilmelidir. Key material çok güçlü encryption ve access control ile korunur. Root compromise ile root loss farklı incident türleridir. Compromise durumunda eski root tekrar kullanılmamalıdır.

Trust Bundle Recovery

Trust bundle version history güvenli storage'da tutulmalıdır. Yanlış bundle deployment service outage oluşturabilir. Recovery önceki known-good version'a hızlı dönüş sağlamalıdır. Multi-region propagation mekanizması test edilmelidir. Bundle signature veya integrity kontrolü uygulanabilir.

Registration Records

Workload identity registration entry'leri hangi workload'un hangi identity'yi alabileceğini belirler. Bu kayıtlar IaC veya version control ile tekrar üretilebilir olmalıdır. Sadece control plane database backup'ına bağımlı kalmak risklidir. Recovery sonrası rule integrity doğrulanmalıdır. Orphan veya obsolete rule geri yüklenmemelidir.

Emergency Credential Re-Issuance

Key compromise durumunda bütün workload'lara yeni credential verilmesi gerekebilir. Automation fleet-wide rotation yapabilmelidir. Trust bundle önce yeni issuer'ı tanımalıdır. Ardından workload credential'ları değişir. Eski issuer güveni mümkün olan en kısa sürede kaldırılır.

DR Testleri

DR planı dokümanda bulunmakla yetinmemelidir. Staging veya isolated environment'da restore tatbikatı yapılmalıdır. Recovery time ve manual step sayısı ölçülmelidir. Eksik permission veya backup problemi gerçek incident öncesinde görülür. Test sonucu runbook güncellemesine dönüştürülmelidir.

CA veya Signing Key Compromise Durumunda Ne Yapılmalı?

CA veya token signing key compromise identity sisteminin en ciddi olaylarından biridir. İlk hedef compromised key kullanımını durdurmaktır. Yeni key veya trust root hızla devreye alınmalı ve credential'lar yeniden üretilmelidir. Hangi token veya certificate'ların etkilenmiş olabileceği audit log üzerinden belirlenmelidir. Incident response planı normal rotation prosedüründen daha hızlı ve yetkili bir akış sunmalıdır.

Compromised Key Isolation

Şüpheli key signing veya issuance sisteminden derhal çıkarılmalıdır. HSM veya key store access kapatılır. İlgili service account ve automation token'ları revoke edilir. Forensic inceleme için gerekli loglar korunur. Yeni credential issuance ayrı trusted environment'da başlatılabilir.

Emergency Rotation

Yeni signing key veya intermediate CA üretilir. Public trust bilgisi resource server'lara hızlı dağıtılır. Overlap süresi compromise durumunda minimum tutulur. Service availability ve security riski birlikte yönetilir. Automation olmadan bu süreç çok zor hale gelir.

Trust Root Güncelleme

Root compromise edilmişse bütün trust bundle'ların yeni root'a geçmesi gerekir. Bu en geniş etkili rotation türüdür. Yeni root önce fleet'e dağıtılmalı ve doğrulanmalıdır. Eski root güveni sonra kaldırılır. Cross-organization federation partner'ları da bilgilendirilmelidir.

Credential Re-Issuance

Eski issuer tarafından verilmiş active credential'lar yeniden üretilmelidir. Kısa lifetime bu süreci hızlandırabilir. Long-lived certificate için explicit revoke gerekir. Workload automation yeni credential'ı runtime'a yüklemelidir. Manual exception'lar ayrı takip edilmelidir.

Incident Audit

Compromised key ile hangi token veya certificate'ların üretildiği araştırılmalıdır. Authentication logları unexpected usage gösterebilir. Source identity, target resource ve timestamp correlate edilir. Etkilenen business transaction'lar ayrıca incelenebilir. Incident sonrası key protection ve monitoring kontrolleri güncellenmelidir.

Fail-Open ve Fail-Closed Kararı

Authentication altyapısı erişilemediğinde sistemin request'i kabul edip etmemesi risk temelli karardır. Fail-open availability'yi koruyabilir fakat güvenlik kontrolünü atlayabilir. Fail-closed güvenliği korur ancak business outage oluşturabilir. Kritik finansal write operation ile düşük riskli read-only işlem aynı davranışı kullanmak zorunda değildir. Decision matrix önceden hazırlanmalı ve outage sırasında doğaçlama yapılmamalıdır.

IdP Erişilemiyorsa

Yeni token issuance IdP outage sırasında başarısız olabilir. Mevcut valid token local signature ile doğrulanmaya devam edebilir. Token TTL çok kısa ise outage etkisi hızlı büyür. Regional IdP replica ve cache stratejisi gerekir. Bypass olarak static master token kullanılmamalıdır.

Policy Engine Erişilemiyorsa

Central PDP erişilemiyorsa bazı sistemler cached decision kullanabilir. Cache TTL permission revoke riskini etkiler. Critical action fail-closed olabilir. Low-risk operation için önceden onaylanmış local policy uygulanabilir. Behavior policy olarak açık tanımlanmalıdır.

JWKS Erişilemiyorsa

Resource server cached signing key ile token doğrulamaya devam edebilir. Unknown kid görülürse yeni key alınamadığı için token reddedilmelidir. Süresiz stale cache kullanmak risklidir. JWKS endpoint outage alarmı üretmelidir. Key rotation sırasında availability planlaması özellikle önemlidir.

Kritik Finansal Operasyonlar

Para transferi veya balance update gibi işlemler authentication ve authorization kontrolü olmadan devam etmemelidir. Fail-closed çoğu durumda daha güvenli seçenektir. Business continuity için identity altyapısı yüksek availability tasarlanmalıdır. Manual emergency path sıkı approval ve audit gerektirir. Güvenlik bypass günlük operasyon yolu olmamalıdır.

Read-Only Operasyonlar

Bazı düşük riskli read-only işlemler cached policy ile sınırlı süre devam edebilir. Veri sensitivity bu kararı etkiler. Sensitive personal data read işlemi düşük risk sayılmayabilir. Stale permission süresi açıkça sınırlandırılmalıdır. Fail mode test ve runbook'ta belgelenmelidir.

Servis Authentication Observability

Authentication sistemi yalnızca request'i kabul veya reddetmekle kalmamalı, kimlik davranışını gözlemlenebilir hale getirmelidir. Source ve destination identity, authentication sonucu, authorization sonucu, issuer, audience ve certificate bilgisi güvenlik telemetry'sinde yer alabilir. Policy ID hangi kuralın karar verdiğini gösterir. Raw token veya private key loglanmamalıdır. Bu görünürlük hem incident response hem de least-privilege optimization için değerlidir.

Source Identity

Caller workload identity her service request logunda bulunabilir. SPIFFE ID, service account veya client ID kullanılabilir. İnsan tarafından gönderilen header değil trusted proxy veya validator bilgisi tercih edilmelidir. Source identity dependency graph oluşturur. Unexpected caller anomaly detection için kullanılabilir.

Destination Identity

Target service identity connection veya routing metadata'dan çıkarılabilir. Multi-cluster ortamda destination cluster da eklenebilir. Bu bilgi cross-environment call tespitini kolaylaştırır. Service rename telemetry mapping gerektirir. Destination resource ve operation ayrıca loglanabilir.

Authentication Result

Authentication success ve failure ayrı metric olarak izlenmelidir. Failure reason expired token, invalid signature veya certificate error olarak ayrılabilir. Sensitive detail client response'a verilmemelidir. Internal log troubleshooting için daha ayrıntılı olabilir. Ani failure artışı key rotation problemi gösterebilir.

Authorization Result

Authentication başarılı olup authorization reddedilmiş olabilir. Bu iki event birbirinden ayrılmalıdır. Deny reason policy ID ile kaydedilebilir. Tekrarlayan deny yanlış permission veya saldırı sinyali olabilir. Service owner dashboard bunu görmelidir.

Token Issuer

Token issuer hangi identity provider'ın credential verdiğini gösterir. Unexpected issuer güvenlik alarmıdır. Multi-tenant sistemde tenant issuer ayrımı önemlidir. Issuer migration sırasında eski ve yeni değer geçici olarak görülebilir. Telemetry rollout ilerlemesini ölçebilir.

Audience

Audience target API ile token eşleşmesini gösterir. Wrong audience failure sayısı token propagation problemi işareti olabilir. Generic audience kullanımı dependency analizinde görünür hale getirilebilir. Raw token loglamadan aud claim kaydedilebilir. High-cardinality etkisi monitoring sistemi kapasitesine göre yönetilmelidir.

Certificate Identity

mTLS connection certificate subject veya SPIFFE ID bilgisi loglanabilir. Serial number incident sırasında specific credential correlation sağlar. Full certificate her request logunda gerekli değildir. Expiration telemetry rotation health gösterebilir. Unknown issuer event güvenlik alarmı olabilir.

Policy ID

Authorization decision hangi policy version ve rule üzerinden verildiğini göstermelidir. Incident sırasında “neden izin verildi?” sorusuna cevap sağlar. Policy deployment sonrası deny artışı hızlı tespit edilir. Human-readable rule name troubleshooting'i kolaylaştırır. Version control commit bilgisi de ilişkilendirilebilir.

Identity Graph ve Service Dependency Graph

Identity graph hangi workload'un hangi resource ve service'e eriştiğini gösteren güvenlik görünürlüğü sunar. Service dependency graph ise runtime call ilişkilerini ortaya çıkarır. İki grafik birlikte granted permission ile actual usage farkını gösterir. Shadow permission olarak tanımlanabilecek kullanılmayan izinler bu sayede tespit edilebilir. Least-privilege optimization manuel tahminden veri odaklı sürece dönüşür.

Hangi Servis Hangisini Çağırıyor?

mTLS telemetry veya distributed tracing source ve destination service ilişkisini gösterebilir. Graph gerçek runtime dependency'leri görünür kılar. Architecture document ile observed traffic karşılaştırılabilir. Beklenmeyen edge security review tetikleyebilir. Migration policy üretiminde bu veri kullanılabilir.

Hangi İzinler Gerçekten Kullanılıyor?

Granted policy set ile authorization logları karşılaştırılabilir. Bir permission aylarca kullanılmıyorsa kaldırma adayıdır. Seasonal işlem veya DR path yanlışlıkla silinmemelidir. Service owner confirmation gerekir. Usage-based policy improvement düzenli süreç haline getirilebilir.

Shadow Permission

Shadow permission tanımlı olduğu halde gerçek workload tarafından kullanılmayan erişim hakkıdır. Zaman içinde role değişikliği veya eski feature nedeniyle kalabilir. Saldırgan bu unutulan izni kullanabilir. Inventory ve last-used telemetry tespit sağlar. Removal controlled rollout ile yapılmalıdır.

Least-Privilege Optimization

Observed usage permission daraltma için güçlü sinyal sağlar. Policy otomatik öneri üretebilir fakat doğrudan silme yerine owner review daha güvenlidir. HTTP method veya resource seviyesinde ayrıntı artırılabilir. Optimization düzenli periyotlarla tekrarlanmalıdır. Permission debt platform security metriği olarak takip edilebilir.

Authentication Anomaly Detection

Authentication logları yalnızca sorun çözmek için değil, saldırı tespiti için de kullanılabilir. Daha önce hiç iletişim kurmamış iki servis arasında call başlaması veya service token'ın yeni region'da kullanılması anlamlı sinyal olabilir. Deprecated identity kullanımı migration sorunu veya compromise göstergesi olabilir. Cross-tenant access denemeleri özellikle yüksek önem taşımalıdır. Anomaly detection normal deployment değişiklikleriyle güvenlik olayını ayırabilmek için service ownership bilgisiyle zenginleştirilmelidir.

Beklenmeyen Service-to-Service Call

Dependency graph'ta bulunmayan yeni service edge ortaya çıktığında alarm üretilebilir. Yeni feature deployment bunu açıklayabilir. Change management bilgisiyle correlation false positive'i azaltır. Kaynak identity permission sahibi değilse request zaten reddedilmelidir. Successful unexpected call daha yüksek risk sinyali olabilir.

Yeni Region

Service identity normalde yalnızca belirli region'da kullanılıyorsa başka region'daki kullanım araştırılmalıdır. Autoscaling veya DR test meşru sebep olabilir. Token theft veya credential copy de olasıdır. Infrastructure metadata event'e eklenmelidir. Policy gerekirse region attribute üzerinden erişimi sınırlar.

Anormal Token Kullanımı

Aynı token identifier'ın beklenmedik sayıda IP veya workload tarafından kullanılması theft sinyali olabilir. Bearer token replay detection için jti veya session metadata kullanılabilir. Çok yüksek request rate abuse gösterebilir. Monitoring token değerini saklamadan fingerprint kullanabilir. Incident durumunda credential revoke edilmelidir.

Deprecated Identity

Migration sonrası deprecated client ID veya certificate identity kullanımı devam ediyorsa telemetry bunu göstermelidir. Bu durum unutulmuş workload'a işaret edebilir. Enforcement tarihinden önce owner bilgilendirilebilir. Cutover sonrası request reddedilir. Identity inventory last-used bilgisini günceller.

Cross-Tenant Access Denemesi

Multi-tenant sistemde bir tenant context ile başka tenant resource'a erişim denemesi ciddi sinyaldir. User ve service identity birlikte incelenmelidir. Authorization policy default olarak tenant boundary uygulamalıdır. Tekrarlayan denial saldırı gösterebilir. Audit log tenant ID'leri privacy politikasına uygun saklamalıdır.

Kurumsal Audit Trail Nasıl Olmalıdır?

Kurumsal audit trail yalnızca endpoint URL ve status code tutmakla sınırlı olmamalıdır. Workload identity, user identity, actor identity, target resource, action, policy decision, timestamp ve correlation ID birlikte olay bağlamını oluşturur. Bu bilgiler dağıtık sistemde aynı business işlemin izini sürmeyi kolaylaştırır. Sensitive token veya secret değeri asla kaydedilmemelidir. Log retention ve erişim yetkisi compliance gereksinimine göre yönetilmelidir.

Workload Identity

Request'i fiziksel olarak hangi service'in gönderdiği kaydedilmelidir. Identity trusted authentication layer'dan alınmalıdır. Service rename mapping audit continuity için korunabilir. Environment ve cluster bilgisi ek context sağlar. Shared identity kullanımından kaçınılmalıdır.

User Identity

İşlem kullanıcı adına yapılıyorsa user identifier audit kaydına eklenir. PII minimization uygulanmalıdır. Token'ın tamamı loglanmaz. User identity issuer bilgisiyle birlikte tutulabilir. Account deletion ve retention policy privacy gereksinimlerine göre ele alınır.

Actor Identity

Actor identity delegation chain'deki service veya admin bileşeni gösterir. User subject ile karıştırılmamalıdır. Token exchange actor claim veya mTLS identity bu değeri sağlayabilir. Finansal işlemlerde özellikle önemlidir. Audit sorguları user ve actor üzerinden ayrı çalışabilmelidir.

Target Resource

Hangi API, account, document veya transaction üzerinde işlem yapıldığı kaydedilmelidir. Çok hassas resource değerinin kendisi loglanmak zorunda değildir. Stable identifier yeterli olabilir. Resource tenant bilgisi authorization audit'i destekler. Masking policy uygulanmalıdır.

Action

HTTP method tek başına business action'ı her zaman açıklamaz. “payment.approve” veya “customer.read” gibi semantic action daha yararlı olabilir. Policy decision bu action üzerinden verilebilir. Audit dashboard business risk seviyesine göre filtreleme yapabilir. Action naming standardı organization genelinde tutarlı olmalıdır.

Policy Decision

Allow veya deny sonucu ve ilgili policy ID kaydedilmelidir. Gerekirse decision reason eklenebilir. Sensitive internal policy detail client response'a verilmemelidir. Policy version incident sırasında historical behavior'ı açıklamaya yardımcı olur. Deny event'ler security monitoring'e aktarılabilir.

Timestamp

Timestamp merkezi ve güvenilir saat kaynağıyla üretilmelidir. Distributed service logları aynı zaman standardını kullanmalıdır. Millisecond precision bazı transaction analizlerinde yararlı olabilir. Clock drift detection uygulanmalıdır. Retention süresi compliance gereksinimine göre belirlenir.

Correlation ID

Correlation ID aynı business request'in birden fazla service logundaki olaylarını ilişkilendirir. External kullanıcı tarafından gönderilen ID doğrudan trusted kabul edilmemelidir. Gateway veya first trusted hop yeni identifier üretebilir. Trace ID ile correlation yapılabilir. Audit query distributed call chain'i bu değer üzerinden yeniden kurabilir.

Servis Authentication Test Stratejisi

Authentication mekanizması yalnızca valid credential ile test edilmemelidir. Expired token, wrong audience, wrong issuer, forged token, invalid certificate ve revoked identity gibi negatif testler en az pozitif test kadar önemlidir. Unauthorized service ve cross-tenant erişim senaryoları policy güvenliğini doğrular. Testler CI ve staging environment'da otomatik çalıştırılmalıdır. Production'a çıkmadan önce security contract'ın gerçekten uygulandığını bu testler gösterir.

Valid Credential

Beklenen issuer ve audience ile geçerli credential request'i başarıyla geçmelidir. Required scope doğru operation'a izin vermelidir. mTLS kullanılıyorsa trusted certificate kabul edilir. Audit log success identity bilgisini doğru gösterir. Bu test happy path'in temel doğrulamasıdır.

Expired Token

Süresi dolmuş token kesinlikle reddedilmelidir. Clock skew toleransı kontrollü tutulmalıdır. Client uygun authentication error alır. Resource server expired token'ı refresh etmeye çalışmamalıdır. Telemetry failure reason'ı ayrı göstermelidir.

Wrong Audience

Başka API için verilen token hedef service tarafından reddedilmelidir. Bu test cross-service token misuse korumasını doğrular. Signature valid olması sonucu değiştirmemelidir. Generic audience istemeden kabul edilmemelidir. CI security testinde düzenli çalıştırılabilir.

Wrong Issuer

Başka tenant veya test IdP token'ı production API'de reddedilmelidir. Public key valid görünse bile issuer allowlist'e uymuyorsa güven verilmemelidir. Multi-issuer config explicit olmalıdır. Unknown issuer discovery otomatik yapılmamalıdır. Bu test trust boundary'yi doğrular.

Forged Token

Payload değiştirilmiş veya invalid key ile imzalanmış token reddedilmelidir. Algorithm confusion testi de uygulanabilir. Signature validation hiçbir code path'te bypass edilmemelidir. Error response fazla detail vermemelidir. Security log olayın forged token olduğunu kaydedebilir.

Invalid Certificate

Expired, self-signed veya untrusted CA certificate mTLS bağlantısında reddedilmelidir. Wrong service identity certificate da policy tarafından engellenmelidir. Certificate hostname veya SPIFFE identity validation test edilir. Revoked certificate davranışı ayrıca denenir. Failure connection layer'da gerçekleşebilir.

Wrong Workload Identity

Geçerli certificate taşıyan fakat yetkisiz service request'i authorization tarafından reddedilmelidir. Bu test authentication ve authorization ayrımını doğrular. Identity valid olması permission anlamına gelmez. Audit log source identity'yi doğru göstermelidir. Default-deny policy burada önemlidir.

Revoked Identity

Identity revoke edildikten sonra yeni credential alamamalıdır. Mevcut credential'ın davranışı token TTL veya revoke modeline göre doğrulanır. Emergency revoke propagation süresi ölçülebilir. Cache stale allow yaratmamalıdır. Offboarding testinde bu senaryo otomatikleştirilebilir.

Unauthorized Service

Service graph'ta izni olmayan source service hedef API'ye çağrı yaptığında request reddedilmelidir. Network bağlantısı mümkün olsa bile authorization koruması çalışmalıdır. Policy ID deny logunda görünür olmalıdır. Bu test lateral movement senaryosunu temsil eder. Mesh ve application policy birlikte denenebilir.

Cross-Tenant Access

Service ve user identity geçerli olsa bile başka tenant resource'a erişim reddedilmelidir. Tenant context trusted source'tan gelmelidir. Header değiştirme testi uygulanabilir. Policy resource ownership'i doğrulamalıdır. Multi-tenant security test suite içinde zorunlu olmalıdır.

Token Replay Testleri

Token replay testleri ele geçirilen credential'ın başka client veya request bağlamında tekrar kullanılıp kullanılamadığını ölçer. Bearer token doğal olarak replay'e açıktır ve risk TTL ile sınırlandırılır. mTLS-bound token client certificate olmadan çalışmamalıdır. DPoP proof request-specific signature ve nonce ile ek koruma sağlar. High-risk API'lerde bu testler gerçek attack simulation olarak uygulanmalıdır.

Bearer Token Replay

Geçerli bearer token başka process'ten gönderildiğinde genellikle kabul edilir. Bu behavior threat model açısından bilinmelidir. Audience ve scope başka hedeflerde kullanımı sınırlar. TTL kısa tutulmalıdır. Token theft detection ek kontrol sağlayabilir.

mTLS-Bound Token

Bound token başka client certificate ile gönderildiğinde reddedilmelidir. Resource server token binding claim ile TLS certificate fingerprint veya public key bilgisini karşılaştırır. Token tek başına yeterli olmamalıdır. Certificate rotation binding behavior'ı test edilmelidir. Proxy termination mimarisi bu bilgiyi güvenilir biçimde iletmelidir.

DPoP

DPoP proof başka HTTP method veya URL için tekrar kullanıldığında reddedilmelidir. jti ve timestamp replay kontrolüne yardımcı olur. Server nonce bazı senaryolarda ek koruma sağlar. Public key token ile eşleşmelidir. Clock skew kontrollü uygulanmalıdır.

Replay Detection

Replay detection token identifier veya proof identifier kullanımını izleyebilir. Çok yüksek state maliyeti büyük scale'de sorun olabilir. Yalnızca yüksek değerli operation'larda daha ayrıntılı cache kullanılabilir. Detection yalnızca alert üretebilir veya request'i engelleyebilir. Business impact'e göre karar verilmelidir.

Authentication Chaos Testleri

Identity sistemi production trafiğinin temel bağımlılığıysa control plane outage senaryoları düzenli test edilmelidir. IdP, CA, policy engine veya mesh control plane arızasında sistemin nasıl davranacağı önceden bilinmelidir. Certificate ve JWKS rotation sırasında da failure injection yapılabilir. Chaos test amacı kesinti yaratmak değil, fail behavior ve recovery süresini doğrulamaktır. Test sonucu SLO ve runbook geliştirmesine dönüşmelidir.

IdP Outage

Token endpoint kapatıldığında yeni client token alamaz. Mevcut token'lar expiration'a kadar local validation ile çalışabilir. Sistem hangi noktada business impact yaşamaya başladığını ölçmelidir. Retry storm IdP geri geldiğinde ek yük yaratmamalıdır. Regional failover doğrulanmalıdır.

CA Outage

CA erişilemezken mevcut valid certificate'lar çalışmaya devam edebilir. Yeni workload veya rotation zamanı gelen workload etkilenir. Certificate TTL outage tolerance'ı doğrudan belirler. Agent retry behavior kontrollü olmalıdır. Emergency CA failover planı test edilmelidir.

Certificate Rotation

Rotation testi yeni certificate'ın connection kesintisi olmadan kullanılmasını doğrular. Old certificate overlap süresi kontrol edilir. Proxy reload veya application reload behavior gözlemlenir. Trust bundle update sırası test edilir. Failure telemetry alarm üretmelidir.

JWKS Rotation

Yeni signing key yayınlandığında resource server unknown kid görür. Controlled refresh sonrası token validation başarılı olmalıdır. JWKS endpoint kısa süre unavailable olduğunda behavior test edilir. Eski key kaldırılmadan önce token lifetime beklenmelidir. Cache policy doğrulanır.

Policy Engine Outage

PDP kapatıldığında PEP fail-open veya fail-closed davranışı göstermelidir. Critical operation için beklenen davranış ayrıca test edilir. Local cache varsa stale decision süresi ölçülür. Recovery sonrası policy sync doğrulanır. Outage event audit log'a yazılmalıdır.

Mesh Control Plane Failure

Mesh control plane outage mevcut data plane proxy'lerini hemen durdurmayabilir. Ancak yeni policy ve certificate update gecikebilir. Yeni pod onboarding etkilenebilir. Data plane cached config ile ne kadar süre güvenli çalışıyor ölçülmelidir. Recovery sonrası config convergence gözlemlenmelidir.

Performance ve Ölçeklenebilirlik

Güvenlik mekanizmaları performans maliyeti oluşturabilir, ancak doğru tasarım bu maliyeti yönetilebilir seviyede tutar. mTLS handshake connection pooling ile amorti edilebilir. JWT validation CPU kullanır ancak local public key doğrulaması network round-trip gerektirmez. Central authorization çağrıları cache veya distributed enforcement ile optimize edilebilir. Security performance tuning yapılırken validation adımlarını kaldırmak yerine connection ve cache mimarisi iyileştirilmelidir.

mTLS Handshake Maliyeti

TLS handshake public key cryptography nedeniyle yeni connection açılışında maliyet oluşturur. Persistent connection ve HTTP/2 bu maliyeti azaltır. Session resumption ek fayda sağlayabilir. Çok kısa connection pattern'i performansı olumsuz etkiler. Benchmark gerçek traffic profiliyle yapılmalıdır.

Token Validation CPU

JWT signature validation her request'te cryptographic işlem gerektirir. Modern library ve CPU'da maliyet çoğu API için yönetilebilir. Çok yüksek throughput service'te benchmark yapılmalıdır. Token validation sonucu dikkatli cache edilebilir ancak expiration ve permission context unutulmamalıdır. Güvenlik kontrolünü atlamak çözüm değildir.

Authorization Round-Trip

Her request'in central PDP'ye network çağrısı yapması latency ekler. Local sidecar veya policy bundle bu maliyeti azaltabilir. Decision cache yalnızca güvenli key ve TTL ile kullanılmalıdır. High-risk operation fresh decision isteyebilir. Latency SLO ile security requirement dengelenmelidir.

Certificate Issuance Load

Çok sayıda ephemeral workload kısa certificate lifetime kullanıyorsa CA issuance hacmi yüksek olabilir. Jitter rotation spike'ını azaltır. Horizontal scaling ve regional intermediate CA kullanılabilir. Unnecessary certificate renewal'dan kaçınılmalıdır. Capacity test autoscaling burst senaryosunu kapsamalıdır.

Sidecar/Proxy Overhead

Her pod için proxy CPU ve memory tüketir. Büyük cluster'da toplam maliyet anlamlı olabilir. Resource request gerçek telemetry'ye göre ayarlanmalıdır. Proxy feature set gereksiz modüllerden arındırılabilir. Ambient veya node-level data plane alternatifleri bazı durumlarda daha verimli olabilir.

Connection Pooling

Connection pooling TLS handshake sayısını azaltır. HTTP/2 ve gRPC aynı connection üzerinden birçok request taşıyabilir. Certificate rotation sırasında uzun yaşayan connection'ın yeni identity'yi ne zaman kullanacağı değerlendirilmelidir. Maximum connection age policy gerekli olabilir. Pool size target service capacity ile uyumlu olmalıdır.

Uygulama İçinde mi, Platform Katmanında mı?

Authentication logic'in tamamını application içine koymak ekiplerin aynı güvenlik kodunu tekrar yazmasına yol açabilir. Tüm kontrolü platform katmanına taşımak ise business authorization context'ini kaybettirebilir. Workload mTLS ve certificate lifecycle service mesh veya workload identity layer'da daha iyi yönetilebilir. Token claim ve resource authorization application veya policy engine tarafından uygulanabilir. Sağlıklı mimari sorumlulukları katmanlara ayırır.

Application-Native Authentication

Application doğrudan OAuth token veya certificate doğrulayabilir. Framework middleware yaygın protokolleri destekler. Business claim validation application'a yakın olur. Ancak her dil ve ekipte configuration drift oluşabilir. Platform standard library veya shared middleware sağlanabilir.

API Gateway

Gateway external token validation için merkezi boundary sağlar. Rate limit ve partner authentication burada uygulanabilir. Internal service call'ları gateway üzerinden zorla geçirmek her zaman gerekli değildir. Gateway user identity context'ini güvenli biçimde içeri aktarır. Internal workload identity ayrı mekanizma kullanır.

Service Mesh

Mesh automatic mTLS ve service-level policy sağlar. Application certificate handling yapmaz. Source identity trusted proxy metadata olarak görülebilir. Business permission yine application'da kalabilir. Mesh ek operasyon katmanı getirir.

Sidecar

Sidecar proxy her workload yanında çalışır. TLS termination ve policy enforcement local yapılır. Strong isolation ve per-workload telemetry sağlar. CPU ve memory overhead vardır. Lifecycle application deployment ile koordineli olmalıdır.

Ambient Mesh

Ambient yaklaşım sidecar olmadan ortak node veya network katmanında mesh fonksiyonları sunmayı hedefler. Resource overhead bazı senaryolarda azalabilir. Workload identity ve policy yine korunabilir. Feature parity ve debugging modeli platform seçimine göre değişir. Pilot üzerinden gerçek operasyon etkisi ölçülmelidir.

Workload Identity API

Application veya proxy local workload identity API üzerinden token veya certificate alabilir. Static credential gerekmez. Platform attestation ve rotation'ı yönetir. API availability node-level agent'a bağlı olabilir. Access socket veya local endpoint permission'ı sıkı tutulmalıdır.

Service Mesh Kullanmanın Operasyonel Maliyeti

Service mesh güçlü güvenlik ve observability sunar ancak ücretsiz operasyon özelliği değildir. Control plane, proxy lifecycle, certificate infrastructure, policy ve upgrade süreçleri ek sorumluluk oluşturur. Debugging sırasında network, proxy ve application katmanlarını birlikte incelemek gerekebilir. Büyük microservice platformunda bu yatırım değerli olabilir. Küçük ekipte ise OAuth ve basit workload identity daha düşük maliyetli çözüm sunabilir.

Control Plane

Control plane configuration ve identity metadata dağıtır. High availability tasarlanmalıdır. Resource consumption ve API load ölçülmelidir. Config hatası geniş fleet'i etkileyebilir. Change rollout canary yapılmalıdır.

Proxy Lifecycle

Proxy version application pod lifecycle'ıyla birlikte yönetilir. Security patch hızlı rollout gerektirebilir. Version skew support matrix açık olmalıdır. Auto injection kolaylık sağlarken debugging'te hangi version'ın çalıştığı görünür olmalıdır. Resource tuning telemetry'ye dayanmalıdır.

Certificate Infrastructure

Mesh mTLS kullandığında CA ve workload certificate issuance kritik hale gelir. Root ve intermediate key protection gerekir. Rotation otomatik olsa bile monitoring şarttır. Trust domain ve federation architecture planlanmalıdır. CA outage runbook bulunmalıdır.

Policy Management

Yüzlerce service için authorization rule sayısı hızla artabilir. Naming standardı ve ownership olmadan policy yönetimi zorlaşır. Policy-as-code test ve review süreci gerekir. Default-deny rollout telemetry ile yapılmalıdır. Unused policy cleanup otomatik önerilebilir.

Debugging

Request failure application değil proxy policy nedeniyle oluşabilir. Developer hangi layer'ın reddettiğini hızlı görmelidir. Mesh telemetry source identity ve policy ID sunmalıdır. Standard diagnostic command support süresini azaltır. Platform training gerekli olabilir.

Upgrade Management

Mesh upgrade control plane ve data plane compatibility planı gerektirir. Canary cluster veya namespace kullanılabilir. Security patch geciktirilmemelidir. Application team'leri breaking behavior konusunda bilgilendirilmelidir. Rollback prosedürü önceden test edilmelidir.

Vendor Lock-In ve Portability

Service authentication teknolojisi seçilirken yalnızca mevcut platform değil gelecekteki portability de değerlendirilmelidir. Cloud-native IAM tek cloud içinde güçlü ve düşük operasyon maliyetli olabilir. Multi-cloud requirement ortaya çıktığında ortak workload identity veya federation katmanı gerekebilir. SPIFFE gibi open standard'lar identity semantics'i platformdan ayırabilir. Exit strategy hangi config ve identity mapping'in taşınabileceğini önceden düşünmelidir.

Cloud-Native IAM

Native IAM cloud resource access için en doğal entegrasyonu sunar. Managed identity ve role mekanizmaları güçlüdür. Vendor-specific API ve policy modeline bağımlılık oluşur. Tek cloud stratejisinde bu trade-off kabul edilebilir. Internal logical service identity ayrı catalog içinde tutulabilir.

Multi-Cloud Requirement

Multi-cloud ortamda iki veya daha fazla IAM modelini birlikte yönetmek gerekir. Static cross-cloud key kullanımından kaçınılmalıdır. Federation ortak trust relationship sağlar. Central policy bazı use case'lerde abstraction sunabilir. Operasyon ekibi her platformun failure mode'unu yine bilmelidir.

SPIFFE-Based Identity

SPIFFE identity URI ve SVID standardı cloud'dan bağımsız workload identity sağlar. Kubernetes ve VM birlikte desteklenebilir. Cloud resource permission yine native IAM'de kalabilir. Federation cross-domain communication'ı yönetir. SPIRE operasyonu organization sorumluluğuna eklenir.

Open Standards

OAuth, OIDC, mTLS ve SPIFFE gibi standartlar entegrasyon portability'sini artırır. Vendor-specific extension gerektiğinde standard layer mümkün olduğunca korunmalıdır. Token claim ve identity naming internal sözleşmeyle tanımlanabilir. Standard compliance gerçek interoperability testleriyle doğrulanmalıdır. Yalnızca ürün dokümanındaki destek ifadesine güvenilmemelidir.

Exit Strategy

Platform değişikliğinde identity ve permission modelinin nasıl taşınacağı bilinmelidir. Client registration, service identity ve policy inventory export edilebilir olmalıdır. Static vendor-specific identifier application koduna gömülmemelidir. Migration dual authentication dönemi gerektirebilir. Exit strategy bugün migration yapılacağı anlamına gelmez, riskin bilinçli yönetildiğini gösterir.

Servis Authentication Teknoloji Karar Matrisi

Authentication teknolojisi seçimi sistemin ölçeği, güvenlik seviyesi ve deployment modeline göre yapılmalıdır. Basit backend entegrasyonunda OAuth Client Credentials yeterli olabilir. Kubernetes iç trafiğinde mTLS ve workload identity daha doğal hale gelir. Multi-cloud yapıda federation, kullanıcı delegation senaryosunda token exchange öne çıkar. Yüksek güvenlikli API için sender-constrained token veya certificate-bound model değerlendirilebilir.

Basit Backend Integration → OAuth Client Credentials

İki backend API ve merkezi IdP varsa Client Credentials düşük operasyon maliyetiyle güçlü çözüm sunar. Token audience target API'yi sınırlar. Scope minimum permission sağlar. Client secret yerine private key veya workload identity kullanılabilir. mTLS ek güvenlik ihtiyacında ayrıca eklenebilir.

Kubernetes Internal Traffic → mTLS / Workload Identity

Kubernetes pod'ları dinamik olduğu için IP tabanlı identity uygun değildir. Service account ve workload certificate birlikte güçlü model sunar. Mesh automatic mTLS operasyonu kolaylaştırabilir. Default-deny service policy eklenmelidir. User delegation gerektiğinde token layer ayrıca kullanılır.

Büyük Microservice Platformu → Service Mesh

Yüzlerce service için ortak mTLS ve policy standardı mesh ile merkezi yönetilebilir. Certificate rotation uygulama ekiplerinden ayrılır. Service graph observability sunar. Platform team operasyon kapasitesi gereklidir. Mesh tek başına business authorization çözümü değildir.

Multi-Cloud → Federated Workload Identity

Farklı cloud'larda static credential paylaşmak yerine federation kullanılabilir. Her cloud workload kendi native identity'sini kanıtlar. STS target platform için short-lived token verir. SPIFFE ortak internal service identity sağlayabilir. Trust relation minimum scope ile sınırlandırılmalıdır.

Kullanıcı Bağlamı Downstream'e Gitmeli → Token Exchange

User token'ını ham biçimde forwarding etmek yerine STS target service için yeni token üretebilir. Original user subject korunur. Actor service identity ayrıca gösterilir. Audience ve scope daraltılır. Auditability ve least privilege güçlenir.

High-Security API → mTLS-Bound veya Sender-Constrained Token

Token theft ve replay etkisi yüksekse sender-constrained model değerlendirilebilir. Token belirli certificate veya public key sahipliğine bağlanır. Çalınan token tek başına kullanılamaz. Operational key lifecycle maliyeti artar. Threat model güvenlik kazanımını haklı göstermelidir.

Cloud Resource Access → Native Workload Identity

Cloud API erişiminde native IAM role veya managed identity çoğu zaman en doğru seçimdir. Static access key gerekmez. Credential platform tarafından kısa ömürlü verilir. Permission resource bazında sınırlandırılır. Multi-cloud erişim gerekiyorsa federation eklenebilir.

OAuth Client Credentials mı mTLS mi?

Client Credentials ve mTLS aynı problemi farklı biçimde çözen tam alternatifler değildir. OAuth Client Credentials authorization server üzerinden application-level access token ve scope sağlar. mTLS transport connection üzerinde cryptographic workload identity ve encryption sağlar. Bir sistem yalnızca birini kullanabilir veya iki yöntemi birlikte uygulayabilir. Seçim “token mı certificate mı?” sorusundan önce hangi güvenlik katmanının çözüleceğine göre yapılmalıdır.

Client Credentials'ın Çözdüğü Problem

Client Credentials servis kimliğine application permission bağlamayı kolaylaştırır. Token target audience ve scope taşır. Central IdP client registration ve revocation yönetir. HTTP API'lerle entegrasyonu basittir. Kullanıcı bağlamı gerektirmeyen backend işlemlerinde doğal çözümdür.

mTLS'nin Çözdüğü Problem

mTLS connection'ın iki ucundaki workload'ları cryptographic olarak doğrular. Aynı zamanda trafikte encryption sağlar. Token forwarding ihtiyacı olmadan transport identity sunar. Certificate identity service policy'de kullanılabilir. Business scope bilgisi tek başına sağlamaz.

Neden Birbirlerinin Tam Alternatifi Değildirler?

OAuth token application-level authorization semantics taşır. mTLS connection-level identity ve encryption sağlar. Kullanıcı delegation OAuth token ile ifade edilebilirken mTLS bunu doğal olarak taşımaz. mTLS bearer token replay riskini azaltacak binding için kullanılabilir. İki katman birlikte daha güçlü security model oluşturabilir.

Birlikte Kullanım

Service A Service B'ye mTLS ile bağlanabilir ve aynı request'te OAuth access token gönderebilir. Service B certificate'tan workload identity'yi doğrular. Token'dan scope ve user delegation bilgisini alır. İki identity arasında policy uyumu kontrol edilebilir. High-security enterprise API'lerde bu model yaygındır.

JWT mi mTLS mi?

JWT ve mTLS de farklı katmanlarda çalışır. JWT application seviyesinde imzalı claim taşır ve async ortamda bile kullanılabilir. mTLS transport connection'a bağlı workload identity sağlar. Delegation ve resource scope JWT ile daha kolay ifade edilir. Internal synchronous service communication'da iki mekanizma birlikte kullanılabilir.

Transport-Level Identity

mTLS identity TLS connection sırasında doğrulanır. Connection kimliği transport ile bağlıdır. Proxy veya service mesh bu bilgiyi application'a aktarabilir. JWT transport'tan bağımsızdır. Network connection değişse bile token expiration'a kadar kullanılabilir.

Application-Level Claims

JWT issuer, subject, audience ve scope gibi zengin claim'ler taşır. Resource server business authorization için kullanabilir. mTLS certificate'a fazla business claim eklemek iyi model olmayabilir. Permission policy identity'den ayrı tutulmalıdır. JWT bu ayrımı daha doğal destekler.

Delegation

User delegation JWT veya başka access token formatıyla temsil edilebilir. Original user ve actor service ayrı claim'lerde taşınabilir. mTLS yalnızca workload connection identity'sini gösterir. Bu nedenle kullanıcı adına downstream işlemde token layer gerekir. İki bağlam birlikte değerlendirilebilir.

Async Communication

mTLS connection identity message broker bağlantısında çalışır ancak message başka yerde işlenirken original connection kaybolur. JWT veya signed message identity context'i taşımaya yardımcı olur. Replay riskine dikkat edilmelidir. Long-lived token queue içinde saklanmamalıdır. Workflow-specific signed context daha iyi olabilir.

Hybrid Pattern

Synchronous internal çağrıda mTLS workload identity sağlar. JWT access token service-specific permission ve user context taşır. Async event'te connection identity broker authentication için kullanılır ve message envelope gerekli actor bilgisini taşır. Hybrid model farklı güvenlik ihtiyaçlarını doğru katmana yerleştirir. Operasyon standardı bu katmanları açıkça tanımlamalıdır.

SPIFFE mi Cloud IAM mi?

Cloud IAM ve SPIFFE farklı avantajlara sahiptir. Tek cloud kullanan organizasyonda native workload identity operasyon açısından genellikle daha basittir. Multi-cloud, Kubernetes artı VM ve portability ihtiyacında SPIFFE ortak identity layer sunabilir. Birini seçmek diğerini tamamen bırakmak anlamına gelmez. Cloud resource permission native IAM'de kalırken internal service identity SPIFFE üzerinden yönetilebilir.

Tek Cloud

Tek cloud ortamında native managed identity düşük operasyon maliyetlidir. Cloud API'leri doğrudan IAM token kabul eder. Additional identity control plane gerekmeyebilir. Internal mTLS için platform service mesh veya managed certificate kullanılabilir. SPIFFE ancak özel portability veya heterogeneous workload ihtiyacı varsa ek değer sağlar.

Multi-Cloud

Multi-cloud yapıda her platform farklı principal formatı kullanır. SPIFFE logical workload identity'yi ortaklaştırabilir. Federation cloud access için yine kullanılabilir. Identity mapping ve policy complexity artar. Organization operational capacity bu yatırımı desteklemelidir.

Kubernetes + VM

Kubernetes service account ve VM instance identity farklı mekanizmalardır. SPIFFE her iki workload tipine ortak identity formatı verebilir. Attestation yöntemi platforma göre değişir. Policy SPIFFE ID üzerinden ortak yazılabilir. Hybrid infrastructure için güçlü kullanım senaryosudur.

Portability

SPIFFE ID application identity semantics'ini cloud provider'dan ayırabilir. Workload başka platforma taşındığında logical identity korunabilir. Cloud IAM role mapping değişse bile internal policy daha stabil kalır. Bunun karşılığında SPIRE veya benzeri infrastructure işletilir. Portability ihtiyacı gerçek business roadmap ile ölçülmelidir.

Operasyonel Karmaşıklık

Cloud IAM provider tarafından büyük ölçüde yönetilir. SPIFFE/SPIRE trust domain, server, agent ve CA operasyonu gerektirir. Büyük platform organization bu kontrolü isteyebilir. Küçük ekip için ek operasyon maliyeti gereksiz olabilir. Teknoloji kararı yalnızca güvenlik özelliği sayısına göre verilmemelidir.

API Gateway mi Service Mesh mi?

API Gateway ve Service Mesh farklı trafik yönleri ve trust boundary'ler için tasarlanır. External API authentication gateway'de, internal workload authentication mesh'te yönetilebilir. Token exchange gateway veya internal STS ile kullanıcı context'ini downstream'e güvenli taşıyabilir. mTLS mesh içinde automatic olabilir. Büyük kurumsal mimaride iki katman birbirini tamamlar.

External API Authentication

Gateway user veya partner token'ını ilk giriş noktasında doğrular. OAuth, API key veya partner mTLS uygulanabilir. Rate limit ve request validation ek kontrollerdir. External credential doğrudan bütün internal servislere açılmamalıdır. Gateway trust boundary olarak hareket eder.

Internal Workload Authentication

Mesh internal service call'larda workload identity sağlar. Certificate rotation ve mTLS proxy tarafından yönetilir. Source service policy ile doğrulanır. User token yoksa bile service identity bulunur. Bu model backend worker ve cron job çağrılarında da çalışır.

Token Exchange

Gateway veya Service A external token'ı STS üzerinden internal service-specific token'a çevirebilir. Target audience ve scope daraltılır. Actor identity korunur. Downstream yalnızca internal issuer'a güvenebilir. External token formatı internal servislerden soyutlanır.

mTLS

Gateway ile internal service arasında da mTLS kullanılabilir. Mesh service-to-service connection'ları otomatik şifreler. External partner mTLS ile internal workload mTLS farklı trust domain kullanabilir. Certificate policy boundary'lere göre ayrılmalıdır. Gateway certificate'ı business user identity yerine geçmez.

İki Katmanlı Kurumsal Mimari

Gateway north-south authentication ve abuse protection uygular. Mesh east-west identity ve transport security sağlar. STS delegation token üretir. Central policy engine user ve service authorization kararlarını destekler. Audit layer bütün identity chain'i correlation ID ile birleştirir.

Örnek Kurumsal Zero Trust Authentication Mimarisi

Kurumsal Zero Trust mimaride hiçbir service yalnızca internal network içinde olduğu için güvenilir sayılmaz. Kullanıcı merkezi IdP üzerinden authentication yapar. Gateway external token'ı doğrular. Internal service'ler workload identity ve mTLS kullanır. Downstream delegation gerektiğinde STS service-specific access token üretir ve policy engine her kritik operation için explicit authorization kararı verir.

Kullanıcı → Identity Provider

Kullanıcı güçlü authentication yöntemiyle IdP'ye giriş yapar. MFA veya passkey risk seviyesine göre uygulanabilir. IdP external access token üretir. Token kısa lifetime ve belirli audience taşır. User session ve service identity birbirinden ayrı tutulur.

Kullanıcı → API Gateway

Kullanıcı token'ı gateway'e gönderir. Gateway issuer, audience, expiration ve permission kontrolü yapar. Rate limit ve security filtering uygulanabilir. Valid user context trusted internal header veya token exchange input olarak hazırlanır. Raw external token gereksiz internal hop'lara taşınmaz.

Gateway → Service A

Gateway Service A ile internal trusted connection kurar. Service A gateway workload identity'sini doğrular. Kullanıcı context'i ayrı authorization input olarak gelir. Gateway bütün internal izinlere sahip olmak zorunda değildir. Service A kendi endpoint policy'sini uygulamaya devam eder.

External Access Token

External token yalnızca external trust boundary için üretilmiştir. Gateway token'ı tam doğrular. Internal service'lerin aynı token'ı doğrudan kabul etmesi zorunlu değildir. Kullanıcı claim'leri minimum gerekli set'e indirilebilir. Token değeri loglanmaz.

Workload Authentication

Gateway workload identity mTLS certificate veya platform identity üzerinden doğrulanır. Service A çağrının gerçekten approved gateway'den geldiğini bilir. Network IP tek güven sinyali değildir. Certificate kısa ömürlüdür. Authorization gateway identity'ye yalnızca gerekli endpoint erişimini verir.

Service A → STS

Service A downstream Service B erişimi için STS'e bağlanır. Kendi workload identity'sini kanıtlar. User subject context'i token exchange input olarak sunulur. STS policy target service ve scope belirler. Issuance audit log'a kaydedilir.

Token Exchange

External veya intermediate token Service B'ye özel internal token'a dönüştürülür. Audience Service B olarak ayarlanır. Scope minimum operation set'ine indirilir. Actor olarak Service A korunabilir. Token kısa ömürlü üretilir.

Service A → Service B

Service A Service B'ye mTLS connection üzerinden çağrı yapar. Service B source certificate'tan Service A workload identity'sini doğrular. Aynı request internal access token taşır. Token user delegation ve permission bağlamını sağlar. İki identity birlikte policy değerlendirmesine girer.

mTLS / SPIFFE Identity

Connection SPIFFE X.509-SVID veya benzeri workload certificate ile kurulabilir. Service B caller'ın logical service identity'sini doğrular. Certificate trust domain policy ile eşleşmelidir. Automatic rotation credential bakımını kolaylaştırır. Wrong workload certificate connection veya authorization aşamasında reddedilir.

Internal Access Token

Internal token organization STS tarafından imzalanır. Service B strict issuer ve audience validation yapar. Scope gerekli operation'ı göstermelidir. User subject ve actor claim audit için kullanılabilir. Token başka serviste kabul edilmez.

Service B → Policy Engine

Service B user, actor, workload ve resource context ile authorization kararı isteyebilir. PDP policy-as-code üzerinden allow veya deny üretir. Policy ID response ile birlikte alınabilir. Critical path latency için local cache veya sidecar değerlendirilebilir. Deny sonucu audit sistemine gönderilir.

Audit / Observability Layer

Gateway, Service A, STS, Service B ve policy engine olayları ortak correlation ID ile ilişkilendirilir. User identity ve workload identity ayrı alanlarda tutulur. Token değeri kaydedilmez. Unexpected service call ve policy denial anomaly detection sistemine aktarılır. Bu görünürlük Zero Trust modelinin sürekli doğrulama bölümünü destekler.

Minimum Güvenli Kurumsal Mimari

Her işletmenin ilk günden service mesh veya SPIFFE kurması gerekmez. Merkezi IdP, OAuth Client Credentials, kısa ömürlü token, strict audience validation, secret manager ve central audit birçok backend sistemi için güçlü başlangıç oluşturur. Burada en kritik konu shared credential sayısını azaltmak ve her servise unique identity vermektir. User token ile service token ayrılmalıdır. Sistem büyüdükçe workload identity ve mTLS eklenebilir.

Central Identity Provider

Merkezi IdP client registration ve token issuance için ortak güven noktası sağlar. Issuer policy bütün API'lerde tutarlı uygulanır. Signing key rotation merkezi yönetilir. High availability ve DR planı gerekir. Admin access güçlü authentication ile korunmalıdır.

OAuth Client Credentials

Her backend service ayrı client identity alır. Scope minimum permission'ı tanımlar. Client secret gerekiyorsa secret manager'da tutulur. Mümkün olduğunda private key veya workload federation kullanılır. Shared global client hesabından kaçınılır.

Short-Lived Tokens

Access token lifetime sınırlı tutulur. Application otomatik token refresh yapar. Long-lived bearer token kullanılmaz. Riskli API için daha kısa TTL seçilebilir. IdP HA token lifetime ile birlikte planlanır.

Strict Audience Validation

Her API kendi audience identifier'ını kontrol eder. Başka service için verilmiş token reddedilir. Bu kontrol automated test ile doğrulanır. Generic internal audience mümkün olduğunca kullanılmaz. Token exchange ileride bu modeli daha da güçlendirebilir.

Secret Manager

Legacy client secret ve database password merkezi secret manager içinde tutulur. Access service identity ile sınırlandırılır. Secret rotation otomatik hale getirilir. Raw secret loglanmaz. Workload identity adoption arttıkça static secret sayısı azaltılır.

Central Audit

Authentication ve authorization event'leri merkezi log sistemine gönderilir. Source identity, target service ve outcome görünür olur. Correlation ID distributed trace sağlar. Sensitive token değeri saklanmaz. Incident ve compliance sorguları bu kayıtlar üzerinden yapılır.

İleri Seviye Kurumsal Mimari

Daha büyük veya regüle işletmeler minimum mimarinin üzerine workload identity, automatic mTLS, SPIFFE/SPIRE, token exchange ve centralized policy engine ekleyebilir. Multi-cloud federation farklı platformların trust ilişkisini kısa ömürlü credential üzerinden kurar. Identity graph gerçek service dependency ve permission kullanımını gösterir. Fine-grained authorization user, actor, workload ve resource context'ini birlikte değerlendirir. Bu yapı daha güçlü güvenlik sağlar ancak platform engineering kapasitesi gerektirir.

Workload Identity

Her service instance runtime sırasında cryptographic identity alır. Static bootstrap secret kullanılmaz. Credential kısa ömürlüdür. Attestation deployment metadata'yı doğrular. Identity service catalog ile ilişkilendirilir.

Automated mTLS

Mesh veya workload proxy certificate issuance ve rotation'ı otomatik yapar. East-west traffic encrypted ve mutually authenticated olur. Strict mode plaintext'i engeller. Certificate telemetry rotation health'i gösterir. Application code TLS detaylarıyla uğraşmaz.

SPIFFE/SPIRE

Heterogeneous infrastructure ortak SPIFFE identity kullanabilir. SPIRE node ve workload attestation gerçekleştirir. X.509-SVID mTLS için dağıtılır. Federation multi-cloud trust sağlar. Platform ekibi CA ve control plane HA'sını yönetir.

Token Exchange

User delegation service-specific token ile taşınır. Raw external token internal chain boyunca dolaşmaz. Audience ve scope her hop için daraltılır. Actor service audit context'inde korunur. STS central trust service haline gelir.

Centralized PDP

Authorization policy merkezi engine tarafından değerlendirilir. Application veya proxy PEP olarak davranır. Policy-as-code version control içinde tutulur. Decision cache latency'yi azaltabilir. HA ve fail mode açık tasarlanmalıdır.

Fine-Grained Authorization

Resource instance ve action düzeyinde permission kontrolü yapılır. User, service ve environment attribute'ları birlikte değerlendirilir. Tenant isolation güçlü biçimde uygulanır. Policy unit test zorunlu hale gelir. Audit log decision reason'ı saklayabilir.

Multi-Cloud Federation

Cloud workload'lar static key olmadan birbirinin trust endpoint'ine bağlanır. Native identity assertion STS tarafından doğrulanır. Short-lived target credential üretilir. Trust relation audience ve workload pattern ile sınırlandırılır. SPIFFE ortak internal identity layer olarak kullanılabilir.

Identity Graph

Identity graph workload, permission ve target ilişkilerini merkezi görünür hale getirir. Unused permission tespit edilir. Unexpected service call anomaly olarak işaretlenir. Owner ve environment metadata security review'ı kolaylaştırır. Zero Trust posture ölçülebilir hale gelir.

Static Credential'dan Workload Identity'ye Migration

Static API key ve client secret kullanan mevcut sistemi bir anda workload identity modeline taşımak gerekli değildir. Önce machine identity inventory çıkarılır ve shared credential'lar ayrıştırılır. Daha sonra short-lived token ve central authorization devreye alınabilir. mTLS ve workload identity aşamalı olarak eklenir. Final state'te static secret'lar kaldırılır ve default-deny policy uygulanır.

1. Machine Identity Inventory

Hangi service hangi API key, client secret veya certificate'ı kullanıyor belirlenir. Owner ve target resource bilgisi eklenir. Shared credential'lar risk olarak işaretlenir. Last-used telemetry toplanır. Bu liste migration önceliğini belirler.

2. Shared Credentials'ı Ayırmak

Aynı key'i kullanan servisler ayrı client identity'lere geçirilir. Audit visibility hemen iyileşir. Her identity minimum permission alır. Eski shared key transition süresinde monitor edilir. Final cutover sonrası revoke edilir.

3. Short-Lived Token Kullanımına Geçmek

Long-lived API key yerine OAuth access token kullanılabilir. Client her ihtiyaçta kısa token alır. Audience ve scope uygulanır. Client authentication başlangıçta secret ile kalabilir. Daha sonra workload identity'ye geçirilebilir.

4. Central Authorization Oluşturmak

Permission logic merkezi policy veya standart scope modeline taşınır. Her service kendi custom allowlist formatını kullanmaz. Policy-as-code review ve test edilir. Default-deny için hazırlık yapılır. Identity inventory policy mapping ile ilişkilendirilir.

5. mTLS'i Devreye Almak

Internal service traffic önce permissive veya selective mTLS ile migrate edilebilir. Automatic certificate distribution kurulmalıdır. Telemetry plaintext kalan path'leri gösterir. Service pair'ler sırayla strict hale getirilir. Certificate identity authorization input olarak kullanılabilir.

6. Workload Identity Eklemek

Platform service account veya attestation üzerinden workload identity verir. OAuth client secret ihtiyacı federation ile kaldırılabilir. Certificate issuance workload identity'ye bağlanır. Autoscaling instance'lar otomatik credential alır. Static secret kullanımı daha da azalır.

7. Static Secret'ları Kaldırmak

Yeni identity modelinin kullanım oranı telemetry ile doğrulanır. Eski secret'lar deprecated işaretlenir. Owner'lara cutover tarihi bildirilir. Final removal sonrası secret revoke edilir ve storage'dan temizlenir. Unexpected kullanım alarm olarak izlenir.

8. Default-Deny Policy'ye Geçmek

Observed dependency graph üzerinden explicit allow rule'lar oluşturulur. Audit mode ile olası deny etkisi görülür. Canary environment default-deny uygulanır. Hatalar düzeltildikten sonra rollout genişletilir. Exception süreli ve kayıtlı olmalıdır.

Migration Sırasında Dual Authentication

Legacy API key ile yeni workload identity bir süre birlikte desteklenebilir. Bu dual authentication geçişi kesintisiz yapmayı kolaylaştırır. Ancak eski yöntem süresiz açık bırakılırsa migration tamamlanmaz ve bypass yolu oluşur. Telemetry hangi caller'ın hangi yöntemi kullandığını açıkça göstermelidir. Deprecated credential için kesin cutover ve final removal tarihi belirlenmelidir.

Legacy API Key

Eski client'lar geçiş döneminde API key kullanmaya devam edebilir. Her kullanım telemetry'de deprecated olarak işaretlenir. Yeni service registration bu yöntemi alamamalıdır. Permission minimum seviyede tutulmalıdır. Expiration tarihi migration planına bağlanmalıdır.

Yeni Workload Identity

Migrate edilen service mTLS veya federated token kullanır. Identity unique ve short-lived credential ile temsil edilir. Yeni authentication path production traffic ile test edilir. Audit iki yöntemi ayırt eder. Kullanım stabil olduğunda legacy path kapatılır.

Telemetry ile Adoption Ölçmek

Request sayısının yüzde kaçı yeni authentication yöntemi kullanıyor izlenebilir. Service owner bazlı dashboard migration durumunu gösterir. Unexpected legacy usage alarm üretir. Cutover kararı gerçek traffic verisine dayanır. Bu yaklaşım deployment listesine bakmaktan daha güvenilirdir.

Deprecated Credentials

Eski credential inventory'de deprecated olarak işaretlenir. Yeni issuance durdurulur. Owner ve son kullanım tarihi görünür olur. Security riskine göre grace period belirlenir. Süre sonunda credential revoke edilir.

Cutover

Belirlenen tarihte target API yeni authentication yöntemini default hale getirir. Legacy path yalnızca explicit exception ile çalışabilir. Canary veya percentage rollout riski azaltır. Authentication failure telemetry yakından izlenir. Rollback planı sınırlı süre kullanılabilir.

Final Removal

Migration tamamlandığında legacy authentication code path kaldırılmalıdır. API key secret store ve documentation'dan temizlenir. Policy yalnızca workload identity kabul eder. Security test eski credential'ın reddedildiğini doğrular. Bu adım atlanırsa migration gerçek anlamda bitmiş sayılmaz.

Kurumsal Service Authentication Definition of Done

Service authentication'ın tamamlandığını söylemek için yalnızca token doğrulaması çalışıyor olması yeterli değildir. Her workload unique identity taşımalı, static shared secret azaltılmış ve credential kısa ömürlü olmalıdır. Rotation, audience validation, least privilege ve default-deny uygulanmalıdır. User identity ile service identity audit kayıtlarında ayrı görünmelidir. Revocation ve disaster recovery süreçleri gerçek testlerle doğrulanmalıdır.

Her Workload'un Unique Identity'si Var mı?

Her servis ayrı logical identity taşımalıdır. Aynı account ilgisiz workload'lar arasında paylaşılmamalıdır. Identity owner ve environment bilgisiyle inventory'de görünmelidir. Autoscaling replica aynı service identity policy'sini güvenli biçimde kullanabilir. Cross-service paylaşım audit değerini azaltır.

Static Shared Secret Kaldırıldı mı?

Shared API key ve global password mümkün olduğunca kaldırılmalıdır. Legacy exception varsa owner ve expiration tarihi bulunmalıdır. Workload identity veya private key tabanlı authentication tercih edilir. Secret manager kullanmak tek başına final hedef değildir. Shared secret usage telemetry ile izlenmelidir.

Credential Short-Lived mi?

Token ve certificate lifetime risk seviyesine uygun olmalıdır. No-expiry credential bulunmamalıdır. Application automatic refresh yapabilmelidir. Expiration failure test edilmelidir. Credential TTL policy merkezi olarak belgelenmelidir.

Automatic Rotation Var mı?

Certificate veya secret rotation manuel takvime bağlı olmamalıdır. Yeni credential otomatik dağıtılmalıdır. Rotation sırasında kesinti oluşmamalıdır. Failure alarm üretmelidir. Emergency rotation ayrıca test edilmelidir.

Audience Doğrulanıyor mu?

Her resource server kendi target audience değerini doğrulamalıdır. Wrong audience token testte reddedilmelidir. Generic audience kullanımı gerekçelendirilmelidir. Token exchange service-specific audience üretmelidir. Audience validation library config içinde zorunlu olmalıdır.

Least-Privilege Policy Var mı?

Service yalnızca gerekli endpoint ve resource permission'larına sahip olmalıdır. Broad admin role varsayılan olmamalıdır. Actual usage ile granted permission karşılaştırılmalıdır. Unused rule düzenli temizlenmelidir. Policy owner açıkça tanımlanmalıdır.

Default Deny Uygulanıyor mu?

Yeni identity otomatik full access almamalıdır. Explicit allow rule gerekli dependency'yi tanımlar. Migration sırasında audit mode kullanılabilir. Exception süreli olmalıdır. Policy bypass path güvenlik testinde doğrulanmalıdır.

Kullanıcı ve Service Identity Ayrı İzleniyor mu?

User subject ve actor workload aynı log alanında karıştırılmamalıdır. Delegation chain açık görünmelidir. User token service identity yerine kullanılmamalıdır. mTLS veya workload token caller service'i doğrular. Audit iki kimlik üzerinden sorgulanabilir olmalıdır.

Audit Trail Var mı?

Source identity, target, action ve policy decision kaydedilmelidir. Correlation ID distributed chain'i bağlar. Raw token ve secret loglanmamalıdır. Retention compliance gereksinimine göre ayarlanır. Security monitoring audit verisini kullanabilmelidir.

Revocation Test Edildi mi?

Identity revoke edildiğinde yeni credential alamamalıdır. Active token veya certificate'ın davranışı bilinmelidir. Propagation süresi ölçülmelidir. Emergency revoke runbook test edilmelidir. Manual intervention sayısı azaltılmalıdır.

DR Test Edildi mi?

IdP, CA ve policy engine recovery tatbikatı yapılmalıdır. Signing key ve trust bundle backup doğrulanmalıdır. Recovery time ölçülmelidir. Restore sonrası identity integrity kontrol edilir. Runbook test sonucuna göre güncellenmelidir.

Servisler Arası Kimlik Doğrulamada Sık Yapılan Hatalar

Servis authentication projelerinde sorun çoğu zaman kullanılan protokolden değil, yanlış trust varsayımından kaynaklanır. Internal network'e otomatik güvenmek, bütün servislere aynı API key'i vermek veya JWT'de yalnızca signature kontrol etmek sık görülen örneklerdir. mTLS'in authorization sağladığını düşünmek ve service mesh'i tek başına Zero Trust kabul etmek de yanıltıcıdır. Manuel rotation ve eksik audit visibility operasyon riskini büyütür. Sağlıklı tasarım identity, permission ve lifecycle katmanlarını birlikte ele alır.

Internal Network'e Otomatik Güvenmek

Internal ağda çalışan her workload güvenilir değildir. Compromised pod aynı network içinde request üretebilir. Network segmentation gerekli fakat yeterli değildir. Workload identity ve authorization ayrıca uygulanmalıdır. Zero Trust network location'ı tek güven kriteri olarak kabul etmez.

Tüm Servislerde Aynı API Key'i Kullanmak

Shared key caller identity'yi belirsiz hale getirir. Bir servis compromise olduğunda diğerlerinin permission'ı da kullanılabilir. Audit hangi workload'un işlem yaptığını gösteremez. Her service unique identity almalıdır. Migration en hızlı kazanımı burada sağlayabilir.

Uzun Ömürlü Client Secret Kullanmak

Client secret yıllarca değişmeden kalmamalıdır. Sızıntı etkisi uzun sürer. Secret manager kullanılsa bile lifetime problemi devam eder. Workload identity, private key veya short-lived credential değerlendirilebilir. Rotation otomatik olmalıdır.

JWT'de Sadece Signature Kontrol Etmek

Valid signature token'ın doğru API için üretildiği anlamına gelmez. Issuer, audience, expiration ve algorithm ayrıca doğrulanmalıdır. Scope veya permission kontrolü endpoint bazında yapılmalıdır. Wrong issuer token reddedilmelidir. Security test bu claim'leri ayrı ayrı denemelidir.

Audience Kontrolünü Atlamak

Audience validation yoksa bir internal API token'ı başka serviste kullanılabilir. Bu lateral movement riskini artırır. Her service unique audience kullanmalıdır. Token exchange target-specific token üretir. Wrong audience testi CI'da zorunlu olmalıdır.

Kullanıcı Token'ını Bütün Servislere Forward Etmek

Raw forwarding token leakage yüzeyini büyütür. External token broad scope taşıyabilir. Downstream actor service identity belirsiz kalabilir. Token exchange daha dar audience ve scope sağlar. Basit sistemlerde forwarding kullanılsa bile risk bilinçli değerlendirilmelidir.

mTLS'i Authorization Sanmak

mTLS caller kimliğini doğrular. Certificate sahibi olmak her endpoint'e erişim hakkı vermez. Service-level ve business authorization ayrıca uygulanmalıdır. User permission mTLS içinde doğal olarak bulunmaz. Authentication ve authorization ayrımı documentation'da açık olmalıdır.

Service Account'u Business Permission Sanmak

Service account logical workload identity sağlar. Bu account'un varlığı business resource'a erişim anlamına gelmemelidir. IAM veya application policy permission'ı ayrıca tanımlar. Çok geniş service account role risklidir. Identity ve permission lifecycle ayrı yönetilmelidir.

Certificate Rotation'ı Manuel Yapmak

Manuel rotation forgotten expiration ve outage riskini artırır. Kısa certificate lifetime pratik hale gelmez. Workload identity agent veya mesh otomatik rotation yapmalıdır. Expiration telemetry alarm sağlamalıdır. Emergency rotation düzenli test edilmelidir.

Service Mesh'i Otomatik Zero Trust Sanmak

Mesh mTLS sağlasa bile bütün service'ler birbirine erişebiliyorsa Zero Trust hedefi tamamlanmamıştır. Default-deny ve least privilege gerekir. User authorization application katmanında devam eder. Policy audit ve anomaly detection eklenmelidir. Mesh bir platform aracıdır, güvenlik modeli değildir.

Authentication Loglarını Tutmamak

Authentication failure görünmüyorsa incident sırasında root cause bulmak zorlaşır. Source identity, target ve outcome loglanmalıdır. Raw credential kaydedilmemelidir. Policy decision ve correlation ID audit değerini artırır. Merkezi monitoring anormal usage pattern'lerini gösterebilir.

Sık Sorulan Sorular

Servisler arası güvenlik tasarımında en çok sorulan sorular kullanılan teknolojiyle değil, hangi identity'nin nerede doğrulanacağıyla ilgilidir. JWT, mTLS, Client Credentials ve workload identity aynı probleme farklı katmanlardan yaklaşır. API Gateway external, service mesh internal traffic için farklı görevler üstlenebilir. User delegation ayrı tasarlanmalıdır. Aşağıdaki yanıtlar mimari karar verirken temel ayrımları daha hızlı görmenize yardımcı olur.

Servisler birbirini nasıl doğrulamalıdır?

Servisler mümkün olduğunda unique workload identity ile doğrulanmalıdır. Küçük backend sistemlerinde OAuth Client Credentials kullanılabilir. Kubernetes ve yüksek servis sayısında mTLS veya workload identity daha uygun olabilir. Credential kısa ömürlü ve otomatik rotate edilmelidir. Authentication sonrasında ayrıca authorization policy uygulanmalıdır.

Microservice'ler arasında JWT kullanmak güvenli midir?

JWT doğru validation ve kısa lifetime ile güvenli şekilde kullanılabilir. Signature yanında issuer, audience, expiration ve scope kontrol edilmelidir. Bearer token theft ve replay riski bilinmelidir. Yüksek güvenlikte sender-constrained token değerlendirilebilir. JWT transport encryption yerine geçmez.

Kullanıcının JWT'si downstream servislere gönderilmeli mi?

Her durumda ham şekilde forwarding önerilmez. Token target audience açısından downstream API'ye uygun olmayabilir. Broad permission ve leakage riski oluşabilir. Token exchange service-specific ve daha dar token üretebilir. Basit ve kısa service chain'de forwarding bilinçli tercih olabilir.

OAuth Client Credentials mı mTLS mi kullanılmalı?

İki mekanizma farklı sorunları çözer. Client Credentials application-level token ve scope sağlar. mTLS workload connection identity ve encryption sağlar. Birlikte kullanılmaları mümkündür. Seçim threat model ve platform kabiliyetine göre yapılmalıdır.

mTLS tek başına yeterli midir?

mTLS transport authentication ve encryption sağlar. Business authorization sağlamaz. Service identity geçerli olsa bile endpoint permission ayrıca kontrol edilmelidir. User delegation gerekiyorsa token context gerekir. Default-deny policy mTLS modelini güçlendirir.

Service mesh authentication için gerekli midir?

Service mesh zorunlu değildir. Uygulamalar doğrudan mTLS veya OAuth kullanabilir. Mesh büyük service fleet'te certificate rotation ve policy standardizasyonunu kolaylaştırır. Operasyon maliyeti vardır. Küçük ekip için daha basit yöntemler yeterli olabilir.

SPIFFE ve SPIRE nedir?

SPIFFE workload identity için açık standartlar tanımlar. SPIFFE ID logical service kimliğini ifade eder. SVID credential bu identity'yi cryptographic olarak kanıtlar. SPIRE attestation, issuance ve rotation süreçlerini uygular. Multi-cloud ve heterogeneous infrastructure'da ortak identity layer sağlayabilir.

Kubernetes Service Account güvenli bir workload identity midir?

Service account iyi bir logical identity temelidir. Modern kısa ömürlü projected token kullanılması daha güvenlidir. Aynı account ilgisiz workload'larda paylaşılmamalıdır. External system token issuer ve audience doğrulaması yapmalıdır. Service account permission minimum tutulmalıdır.

Workload Identity Federation nedir?

Federation bir platform identity'sinin başka sistem tarafından trusted assertion olarak kabul edilmesidir. Hedef STS short-lived local credential üretir. Static cross-cloud secret gerekmez. Trust issuer, audience ve subject ile sınırlandırılır. Multi-cloud ve CI/CD entegrasyonunda güçlü modeldir.

Static API key yerine ne kullanılmalıdır?

Backend API için OAuth Client Credentials kullanılabilir. Cloud resource erişiminde native workload identity tercih edilebilir. Kubernetes internal traffic için mTLS ve service identity uygundur. Partner entegrasyonunda private key veya mTLS client authentication değerlendirilebilir. Hedef static ve shared credential sayısını azaltmaktır.

Token Exchange nedir?

Token Exchange mevcut security token'ın target resource için yeni token'a dönüştürülmesidir. STS original subject ve caller service identity'sini doğrular. Yeni token daha dar audience ve scope taşır. Downstream service yalnızca kendisi için üretilen token'ı kabul eder. Delegation ve least privilege için güçlü modeldir.

DPoP nedir?

DPoP access token kullanımını client public key sahipliğine bağlayan proof-of-possession yaklaşımıdır. Client her request için signed proof üretir. Resource server proof ile token binding'i doğrular. Çalınan token tek başına kullanılamaz. Replay riskinin yüksek olduğu API'lerde değerlendirilebilir.

mTLS-bound access token nedir?

mTLS-bound token belirli client certificate ile ilişkilendirilmiş access token'dır. Resource server token'ın binding bilgisiyle TLS certificate'ı karşılaştırır. Token başka client'a kopyalansa bile kullanılamaz. Certificate private key sahipliği ek proof sağlar. Yüksek güvenlikli machine API'lerde yararlıdır.

Multi-cloud servis authentication nasıl yapılır?

Her cloud'da native workload identity korunabilir. Cross-cloud erişim için OIDC federation veya STS kullanılabilir. SPIFFE ortak logical service identity sağlayabilir. Static cloud access key paylaşılmamalıdır. Trust relation minimum workload ve target resource ile sınırlandırılmalıdır.

API Gateway ve Service Mesh birlikte kullanılabilir mi?

Evet, görevleri birbirini tamamlar. Gateway external kullanıcı ve partner authentication'ı yönetebilir. Mesh internal service identity ve mTLS sağlayabilir. STS kullanıcı delegation token'ını internal servislere göre daraltabilir. Audit iki katmanın identity bilgilerini ilişkilendirmelidir.

Machine identity nasıl rotate edilir?

Credential kısa ömürlü tasarlanır ve identity platformu expiration öncesinde yenisini üretir. Certificate veya token automatic refresh ile değiştirilir. Eski credential kısa grace period sonrası geçersiz olur. Compromise durumunda emergency revocation uygulanır. Rotation failure monitoring ile izlenmelidir.

Zero Trust microservice authentication nasıl uygulanır?

Her workload unique identity taşır ve internal network otomatik trusted sayılmaz. mTLS veya signed token authentication sağlar. Default-deny service authorization minimum dependency'yi açar. User ve actor identity ayrı değerlendirilir. Continuous telemetry, short-lived credential ve policy review Zero Trust modelini tamamlar.

Sonuç

Servisler Arası Kimlik Doğrulama: Kurumsal Çözümler yaklaşımında asıl hedef yalnızca servislerin bir token veya certificate göndermesi değildir. Sağlıklı mimari workload authentication, service authorization ve user delegation sorumluluklarını birbirinden ayırır. Küçük sistemlerde OAuth Client Credentials ve kısa ömürlü token yeterli olabilirken, büyük Kubernetes veya multi-cloud platformlarında workload identity, mTLS, SPIFFE ve merkezi policy yapıları daha güçlü sonuç verir. Loglama ve kimlik olaylarının birlikte değerlendirilmesi de incident yönetiminin önemli parçasıdır; kurumsal loglama yaklaşımına ilişkin ek içerik için https://www.diyarbakiryazilim.com.tr/posts/kurumsal-yazilimlarda-loglama-ve-hata-takip-sistemleri adresini inceleyebilirsiniz. Diyarbakır Yazılım Topluluğu'nun çalışmalarını görmek için https://www.diyarbakiryazilim.com.tr/projects, topluluk hakkında bilgi almak için https://www.diyarbakiryazilim.com.tr/about adreslerini kullanabilirsiniz.

Servisler Arası Kimlik Doğrulama: Kurumsal Çözümler Hakkında Sık Sorulan Sorular

Kurumsal mikroservis güvenliği planlanırken servis kimliğinin nasıl üretileceği, mTLS ile OAuth arasındaki fark, sertifika lifecycle'ı ve Zero Trust yaklaşımı sık gündeme gelir. Tek bir ürün veya protokol bütün soruları tek başına çözmez. Authentication, authorization, delegation ve audit katmanlarının birlikte tasarlanması gerekir. Aşağıdaki sorular, özellikle kurumsal servisler arası kimlik doğrulama ve API güvenliği hizmeti arayan ekiplerin ilk değerlendirme sırasında kullanabileceği pratik çerçeveyi sunar. Mikroservis ve API güvenliği danışmanlığı yakınımda şeklinde araştırma yaparken de kullanılan araç isimlerinden önce bu mimari prensiplerin sorulması daha doğru sonuç verir.

Servisler arası kimlik doğrulama nedir ve kurumsal mikroservis mimarilerinde neden önemlidir?

Servisler arası kimlik doğrulama bir workload'un başka servise bağlanırken kendi kimliğini güvenilir biçimde kanıtlamasıdır. Bu mekanizma internal network içindeki her bağlantıya otomatik güvenme yaklaşımını ortadan kaldırır. Her service unique identity kullandığında hangi workload'un hangi işlemi yaptığı audit kayıtlarında görülebilir. Authentication sonrasında least-privilege authorization uygulanarak compromised service'in bütün sisteme erişmesi engellenebilir. Özellikle yüzlerce API'nin bulunduğu kurumsal yapılarda bu ayrım güvenlik ve operasyon görünürlüğü açısından kritik hale gelir.

Servisler arası kimlik doğrulamada mTLS, OAuth 2.0 Client Credentials ve JWT arasındaki farklar nelerdir?

mTLS transport katmanında iki taraflı workload authentication ve encryption sağlar. OAuth 2.0 Client Credentials bir service'in authorization server'dan kendi adına access token almasına imkan verir. JWT ise access token veya assertion bilgisinin imzalı claim formatında taşınmasını sağlayan bir token biçimidir. Bu nedenle üç kavram birbirinin birebir alternatifi değildir ve aynı sistemde birlikte kullanılabilir. Örneğin Service A, Service B'ye mTLS ile bağlanırken Service B için audience ve scope içeren JWT access token gönderebilir.

Mikroservislerde Zero Trust yaklaşımıyla güvenli servis iletişimi nasıl sağlanır?

Zero Trust yaklaşımında internal network'te bulunmak otomatik güven anlamına gelmez. Her workload unique identity ile authentication yapmalı ve service communication mümkün olduğunda encrypted channel üzerinden gerçekleşmelidir. Default-deny policy yalnızca açıkça gerekli service dependency'lerine izin vermelidir. Credential kısa ömürlü olmalı, automatic rotation uygulanmalı ve kullanıcı delegation bilgisi workload identity'den ayrı tutulmalıdır. Authentication, authorization ve anomaly telemetry birlikte izlendiğinde güven modeli yalnızca ilk bağlantı anına bağlı kalmaz.

Kurumsal sistemlerde servis kimlikleri, sertifikalar ve erişim yetkileri nasıl güvenli şekilde yönetilmelidir?

Service identity inventory her workload'un owner, environment, credential type ve permission bilgilerini merkezi görünür hale getirmelidir. Certificate ve token'lar mümkün olduğunca kısa ömürlü üretilmeli ve manual işlem gerektirmeden rotate edilmelidir. Static shared secret yerine workload identity veya federation tercih edilebilir. Yetkiler default-deny ve least-privilege prensibine göre service veya resource bazında sınırlandırılmalıdır. Audit trail source workload, user, actor, target resource ve policy decision bilgisini birlikte kaydetmelidir.

Yakınımda servisler arası kimlik doğrulama ve mikroservis güvenliği konusunda danışmanlık veren yazılım firması nasıl bulabilirim?

Danışmanlık seçerken yalnızca OAuth, JWT veya service mesh kurabilen bir ekip aramak yeterli değildir. Mevcut machine identity inventory'sini çıkarabilen, static credential kullanımını ölçebilen ve workload authentication ile authorization katmanlarını ayrı tasarlayan bir yaklaşım tercih edilmelidir. Ayrıca token lifecycle, certificate rotation, audit, disaster recovery ve migration planının birlikte değerlendirilmesi önemlidir. Diyarbakır ve çevresinde mikroservis, API güvenliği ve servisler arası authentication süreçleri hakkında iletişim kurmak için https://www.diyarbakiryazilim.com.tr adresini kullanabilirsiniz. Servisler Arası Kimlik Doğrulama: Kurumsal Çözümler kapsamında mevcut yapınızı inceleyerek static credential'dan workload identity ve daha güçlü Zero Trust modeline geçiş için kademeli bir yol haritası oluşturabilirsiniz.