Çoklu Bulut Ortamlarında Geliştirici Erişimini “Workforce Identity Federation” ile Ölçeklendirme
SaaS ve yazılım mühendisliğinin hızla geliştiği dünyada, pazara çıkış hızı en değerli rekabet unsurlarından biridir. Mühendislik ekiplerinin sorunları hızla çözebilmesi ve yeni özellikleri gecikmeden yayına alabilmesi için canlı ortamın loglarına, staging ortamlarına, bulut altyapısına, CLI araçlarına ve yapay zeka platformlarına anında ve sorunsuz bir şekilde erişebilmesi gerekir. Ancak CTO, CISO ve SecOps ekipleri açısından bakıldığında, geliştirici çevikliği beraberinde dağınık kimlik yönetimi ve statik kimlik bilgilerinin kontrolsüzce yayılması riskini de getirir.
Teknoloji platformları büyüdükçe çoklu bulut mimarileri de çoğu kuruluşun çalışma ortamının doğal bir parçası hâline gelir. Kurumsal çalışan dizinleri genellikle Okta veya Microsoft Entra ID gibi merkezi kimlik servisi sağlayıcılarda (IdP) tutulurken; canlı ortamlar, veri ambarları ve yapay zeka ve makine öğrenmesi işlem hatları Google Cloud, AWS veya hibrit bulut altyapıları üzerinde çalışır.
Bu ikisi arasındaki kimlik yönetimi boşluğunu kapatmak için ekipler çoğu zaman uzun ömürlü servis hesabı anahtarlarına veya ek kimlik senkronizasyon mekanizmalarına başvurur. Bu yaklaşım, gereksiz operasyonel yük ve güvenlik riskleri yaratır. Sabit kodlanmış (hardcoded) kimlik bilgileri ve manuel erişim incelemelerinden genişleyen saldırı yüzeyine kadar uzanan bu operasyonel borç, mühendislik ekipleri büyüdükçe kuruluşların daha hızlı hareket etmesini zorlaştırır.
Workforce Identity Federation (WIF), harici kimlikler için Google tarafından yönetilen, senkronize bir kullanıcı dizini oluşturulmasına veya sürdürülmesine gerek kalmadan Google Cloud’a erişim sağlayan, senkronizasyon gerektirmeyen modern bir federasyon modeli sunarak bu sorunu çözüyor.
Eski Nesil IAM SaaS Ekiplerinde Neden Yetersiz Kalıyor?
Erken aşamadaki mühendislik ekiplerinde, statik Google Cloud servis hesabı anahtarları oluşturmak hızlı ve düşük maliyetli bir çözüm gibi görünebilir. Ancak bir mühendislik organizasyonu 10 geliştiriciden 100’ü aşkın geliştiriciye ulaştığında, bu yaklaşım giderek artan güvenlik riskleri yaratır.
Eski Nesil Bulut Anahtarlarının Gizli Maliyetleri
- Denetlenmeyen Geliştirici Bilgisayarları: Statik anahtar dosyaları yerel makinelerde, ortam dosyalarında, shell geçmişlerinde veya IDE yapılandırmalarında saklanabilir. Bu da bir geliştiricinin bilgisayarının ele geçirilmesi durumunda güvenlik riskinin ve olası zararın boyutunu artırır.
- Yanlışlıkla Kod Depolarına Sızan Kimlik Bilgileri: Otomatik gizli bilgi tarayıcıları kullanılmasına rağmen, statik bulut kimlik bilgileri aktif hata ayıklama sırasında özel ve hatta zaman zaman herkese açık Git depolarına yanlışlıkla commit edilebilir veya kurum içi mesajlaşma araçları üzerinden paylaşılabilir.
- Kimlik Senkronizasyonunun Getirdiği Operasyonel Yük: Okta/Entra ID ile bulut dizin servisleri arasındaki eski tip kullanıcı senkronizasyon süreçlerini sürdürmek, senkronizasyon gecikmelerine, sahipsiz hesaplara ve BT ekipleri için sürekli bakım ihtiyacına yol açabilir.
- Kullanıcı Bazında Denetlenebilirliğin Kaybolması: Birden fazla geliştirici veya BI aracı canlı ortamdaki hassas veri tabanlarını ortak servis hesabı anahtarları üzerinden sorguladığında, denetim kayıtlarında yalnızca makine hesabının kimliği görünür. Bu da güvenlik operasyon ekiplerinin olay incelemeleri sırasında işlemleri gerçekleştiren bireysel kullanıcıları belirlemesini ve kullanıcı bazında sorumluluk takibi yapmasını zorlaştırır.
Eski Nesil Anahtarlar ve Workforce Identity Federation Karşılaştırması
| Mimari Metrik | Eski Nesil Servis Hesabı Anahtarları | Workforce Identity Federation (WIF) |
|---|---|---|
| Kimlik Bilgisinin Geçerlilik Süresi | Kalıcı (manuel olarak yenilenene kadar) | Kısa ömürlü, varsayılan oturum süresi 1 saat. Oturum süresi 15 dakika ile 12 saat arasında yapılandırılabilir. |
| Saklama Konumu | Yerel disk, .env dosyaları, CI/CD gizli bilgileri |
Uzun ömürlü servis hesabı anahtarı gerekmez. Kimlik bilgisi yapılandırma dosyaları, servis hesabı özel anahtarları yerine yapılandırma bilgilerini içerir. Kısa ömürlü kimlik bilgileri dinamik olarak alınır. |
| Çalışanın Sistemden Ayrılması | Günler veya haftalar sürebilir, statik anahtarların bulunup devre dışı bırakılması gerekir. | IdP’deki hesap devre dışı bırakılarak yeni erişim engellenir. Daha önce verilmiş kısa ömürlü tokenlar ise süreleri dolana kadar geçerli kalır. |
| Denetim Kaydı Görünürlüğü | Genel makine hesabı, örneğin “service-account-x“ |
Kullanıcının IdP kimliğiyle eşleştirilen federasyona dayalı çalışan kimliği |
| Dizin Yönetimi | Karmaşık senkronizasyon süreçleri ve yinelenen dizinler | Senkronizasyon gerektirmeyen kimlik doğrulama; ek bir dizin senkronizasyonu gerektirmez. |
| Yasal Uyum Yükü | Yüksek, manuel anahtar takibi ve yenileme kayıtları gerekir. | Merkezi kimlik yönetimi ve bulut denetim kayıtları sayesinde operasyonel yük azalır. |
Cloud Audit Logs, etkinlikleri IdP üzerinden yapılandırılan federasyona dayalı çalışan kimliğiyle ilişkilendirebilir. Böylece ortak servis hesabı anahtarlarına kıyasla işlemleri belirli kullanıcılarla ilişkilendirmek ve bireysel sorumluluğu daha güçlü bir şekilde takip etmek mümkün olur.
Detaylı İnceleme: Workforce Identity Federation Nasıl Çalışır?Workforce Identity Federation, statik anahtar yönetiminin yerini, kurumsal kimlik servisi sağlayıcınız ile Google Cloud arasında kurulan OIDC (OpenID Connect) veya SAML 2.0 tabanlı federasyona bırakır. Adım Adım Kimlik Doğrulama Akışı1. SSO Kimlik Doğrulaması: Geliştirici bir CLI oturumu başlatır. Örneğin, 2. Token Oluşturma: Geliştirici çok faktörlü kimlik doğrulama (MFA) adımını tamamlar. IdP, e-posta adresi, departman ve grup üyelikleri gibi doğrulanmış kullanıcı bilgilerini içeren imzalı bir OIDC/SAML tokenı oluşturur. 3. Federasyon Değişimi: Google Cloud CLI, yapılandırılmış federasyon akışını kullanarak harici IdP’den bir doğrulama (assertion) veya token alır ve bunu Google’ın Security Token Service’i üzerinden takas eder. 4. Token Doğrulama ve Yetkilendirme: Google Cloud harici kimlik doğrulama bilgisini doğrular ve yapılandırılan öznitelik eşleştirmelerini ve koşulları uygular. Ardından, ortaya çıkan federasyona dayalı kimliği Google tarafından yönetilen senkronize bir kullanıcı dizinine ihtiyaç duymadan, yetkilendirme sürecinde kullanır. 5. Geçici Erişim Tokenı Verilmesi: Google Cloud’un Security Token Service’i (STS), harici kimlik bilgisini kısa ömürlü bir Google Cloud erişim tokenına dönüştürür. Bu token, federasyona dayalı kimliğe verilen izinler kapsamında Google Cloud kaynaklarına erişmek için kullanılır. |
Workforce Identity ve Workload Identity: Doğru Federasyon Modelini Kullanın
Mühendislik ekipleri için kritik bir ayrım, Workforce Identity Federation ile Workload Identity Federation arasındaki farktır. Her ikisi de benzer kimlik ve erişim sorunlarını çözmeye yardımcı olur, ancak farklı türdeki kimlikler için tasarlanmıştır.
Workforce Identity Federation insan kullanıcılar için tasarlanmıştır. Çalışanlar, yükleniciler, tedarikçiler ve iş ortakları, Okta veya Microsoft Entra ID gibi harici bir IdP üzerinden Google Cloud kaynaklarına erişmek için WIF’i kullanabilir.
Workload Identity Federation ise makine kimlikleri ve iş yükleri için tasarlanmıştır. CI/CD işlem hatları, uygulamalar ve Kubernetes veya sanal makineler üzerinde çalışan iş yükleri uzun ömürlü servis hesabı anahtarlarına ihtiyaç duymadan bulut kaynaklarına erişebilir.
Modern bir mühendislik organizasyonunda bu iki yaklaşım birlikte çalışabilir:
| Kimlik Türü | Tipik Kullanıcılar veya Sistemler | Önerilen Federasyon Modeli |
|---|---|---|
| İnsan kullanıcılar | Geliştiriciler, mühendisler, analistler, yükleniciler | Workforce Identity Federation |
| CI/CD iş yükleri | GitHub Actions, derleme işlem hatları, dağıtım sistemleri | Workload Identity Federation |
| Kubernetes iş yükleri | GKE uygulamaları ve servisleri | Workload Identity Federation |
| Harici uygulamalar | SaaS uygulamaları ve otomatik çalışan servisler | Workload Identity Federation |
| İnsanların Google Cloud’a erişimi | gcloud, Cloud Console, API’leri kullanan geliştiriciler |
Workforce Identity Federation |
Bu ayrım, geliştirici erişimini modernize ederken özellikle önem kazanıyor. Workforce Identity Federation insan kullanıcılar için uzun ömürlü kimlik bilgilerini ortadan kaldırabilirken, Workload Identity Federation otomatik çalışan iş yükleri için benzer bir anahtarsız erişim yaklaşımı sunar.
Çoklu bulut ortamlarında kurumsal IdP merkezi kimlik kaynağı olarak kullanılmaya devam edebilir ve her bulut platformu kendi federasyon mekanizması üzerinden bu kimlikleri kullanabilir. Google Cloud Workforce Identity Federation, insan kullanıcıların Google Cloud’a erişimini yönetirken, diğer bulut sağlayıcılarının ilgili kimlik servisleri de kendi ortamlarına erişimi yönetir.
Öznitelik Tabanlı Erişim Kontrolü (ABAC) ile Ayrıntılı Erişim Yönetimi
WIF’in mühendislik platformlarına kazandırdığı en güçlü özelliklerden biri Öznitelik Tabanlı Erişim Kontrolü (ABAC) yaklaşımıdır.
Güvenlik ekipleri, her kullanıcıya manuel olarak IAM rolleri atamak veya farklı bulut ortamlarında ayrı IAM gruplarını yönetmek yerine, IdP’den gelen token doğrulamalarındaki özniteliklere göre erişim yetkilerini dinamik olarak tanımlayabilir.
Gerçek Hayattan ABAC Örneği
Bir mühendislik organizasyonu, IdP üzerinden department ve project gibi kullanıcı özniteliklerini (claim) iletebilir. Bu öznitelikler Google Cloud’a eşlenebilir ve ardından uygun kaynaklara erişimi kısıtlamak için IAM principal set‘lerinde veya attribute condition‘larında kullanılabilir.
Örneğin:
attribute.department = "data-science"
attribute.project = "fraud-detection"
Bu yaklaşım, büyük kuruluşlarda erişim yetkilerinin yönetimini önemli ölçüde kolaylaştırır:
- Rol Değişikliklerinde Daha Az IAM Yönetimi: Bir mühendis Billing ekibinden Core Platform ekibine geçtiğinde, IdP’deki grup veya rol bilgisinin güncellenmesi, sonraki Google Cloud yetkilendirme kararlarında kullanılan öznitelikleri de değiştirebilir. Bunun için ayrıca senkronize bir kullanıcı dizini yönetmek gerekmez.
- Ortamların İzolasyonu: Junior geliştiricilerin veya üçüncü parti yüklenicilerin erişimini
stagingveyadevortamlarıyla dinamik olarak sınırlandırarak,productionortamına yanlışlıkla erişme riskini azaltabilirsiniz.
SOC 2 Denetimlerini Basitleştirme ve Sıfır Güven Modelini DesteklemeSOC 2 Type II, ISO 27001 veya HIPAA sertifikalarını almak ya da yenilemek isteyen SaaS şirketleri için kullanıcı erişimlerini düzenli olarak gözden geçirmek, geçmişten beri en zahmetli operasyonel süreçlerden biri olmuştur. Eski nesil statik anahtar yapılarının denetlenmesi; her anahtarın kime ait olduğunun, en son ne zaman yenilendiğinin ve kullanılmayan kimlik bilgilerinin devre dışı bırakıldığının kanıtlanmasını gerektirir. Workforce Identity Federation, uzun ömürlü kimlik bilgileri veya senkronize kullanıcı hesapları yerine kimliği erişim kararlarının merkezine koyarak Sıfır Güven (Zero Trust) güvenlik modelini destekler:
|
4 Aşamalı Stratejik Mühendislik Uygulama Planı
Yerleşik bir mühendislik ekibini statik servis hesabı anahtarlarından uzaklaştırmak, iş akışlarının kesintiye uğramaması için aşamalı ve kontrollü bir geçiş yaklaşımı gerektirir.
Aşama 1: Mevcut Anahtar Kullanımını Denetleme
Aktif servis hesabı anahtar dosyalarını, kimlik bilgisi dosyalarını, CI/CD gizli bilgilerini ve diğer uzun ömürlü bulut kimlik bilgilerini envantere almak için kod depoları, yerel geliştirici makineleri ve CI/CD işlem hatları genelinde otomatik taramalar çalıştırın.
Kimlik bilgisi kullanımını geliştiriciler ve analistler gibi insan kullanıcılar ile CI/CD işlem hatları ve uygulamalar gibi makine iş yüklerine göre kategorize edin. İnsan erişimi Workforce Identity Federation’a taşınabilirken, makine iş yükleri için genel olarak Workload Identity Federation veya başka bir anahtarsız iş yükü kimlik doğrulama mekanizması değerlendirilmelidir.
Aşama 2: Workforce Identity Havuzlarını Yapılandırma
Google Cloud’da bir Workforce Identity Havuzu oluşturun ve IdP’nizle OIDC/SAML tabanlı bir güven ilişkisi kurun. Gruplar veya e-posta adresleri gibi IdP claim‘lerini Google Cloud öznitelikleriyle eşleştirmek için öznitelik eşlemelerini (attribute mapping) yapılandırın. Ardından bu öznitelikleri IAM principal set‘lerde veya attribute condition‘larda kullanarak erişim yetkilerini belirleyin.
Aşama 3: Geliştirici Araçlarını ve CLI İş Akışlarını Güncelleme
Geliştirici onboarding dokümantasyonunu ve kurum içi CLI araçlarını güncelleyin. Geliştiricilerin gcloud ve desteklenen istemci kütüphanelerini tarayıcı üzerinden SSO ile kullanabilmesi için önceden yapılandırılmış, gizli bilgi içermeyen kimlik bilgisi yapılandırma dosyaları sağlayın.
Aşama 4: Yeni Anahtar Oluşturulmasını Kısıtlama
Kullanıcıların yeni harici servis hesabı anahtarları oluşturmasını engellemek için kuruluş politikalarını uygulayın. Örneğin, Google Cloud Organizational Policy kapsamında constraints/iam.managed.disableServiceAccountKeyCreation gibi kısıtlamalar kullanarak yeni servis hesabı anahtarlarının oluşturulmasını devre dışı bırakabilirsiniz.
Bulut Kimlik Mimarinizi Kartaca ile Modernize Edin
Sıfır güven tabanlı çoklu bulut mimarisine geçiş yapmak, statik anahtarların kontrolsüz yayılmasını önlemek ve sıkı SOC 2 uyumluluk gereksinimlerini karşılamak derin bir bulut ve IAM uzmanlığı gerektirir.
Bir Google Cloud Premier iş ortağı olarak bulut mimarisi, DevOps ve SecOps mühendisliği alanlarında uzmanlaşan Kartaca, hızla büyüyen SaaS ve teknoloji şirketlerinin güvenli ve kesintisiz erişilebilen mühendislik ortamları oluşturmasına yardımcı olur.
Kartaca’nın kıdemli bulut mimarları, özel Workforce Identity Federation havuzları tasarlamak, Okta/Microsoft Entra ID’yi Google Cloud ile entegre etmek ya da veri platformlarınız genelinde hassas ABAC ilkeleri uygulamak gibi ihtiyaçlarınız için desteğe hazır.
Anahtar yayılımını ortadan kaldırmaya ve geliştirici iş akışlarını hızlandırmaya hazır mısınız? Bulut kimlik mimarinizi tasarlamak, yayına almak ve otomatikleştirmek için bizimle iletişime geçin.
Yazan: Gizem Terzi Türkoğlu
Yayınlanma Tarihi: 01.10.2026
