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, gcloud auth login --cred-file veya kurum içi özel bir araç kullanılabilir. CLI, tarayıcıyı kurumsal IdP’ye (Okta/Entra ID) yönlendirir. 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 staging veya dev ortamlarıyla dinamik olarak sınırlandırarak, production ortamına yanlışlıkla erişme riskini azaltabilirsiniz.

SOC 2 Denetimlerini Basitleştirme ve Sıfır Güven Modelini Destekleme SOC 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: Kullanıcı Bazında Daha Güçlü İzlenebilirlik: Federasyona dayalı erişim, bulut üzerindeki etkinlikleri harici bir IdP üzerinden oluşturulan çalışan kimliğiyle ilişkilendirebilir. Bu, ortak servis hesabı anahtarlarının kullanıldığı yapılara kıyasla işlemlerin hangi kullanıcı tarafından gerçekleştirildiğinin daha net bir şekilde izlenmesini sağlar. Denetim sırasında güvenlik ekipleri Cloud Audit Logs ve IdP kayıtlarını birlikte kullanarak bulut üzerindeki etkinlik ile ilgili çalışanın kimliği arasında daha güçlü ve izlenebilir bir bağlantı kurabilir. Daha Kolay İşten Ayrılma Süreci ve Erişim Kanıtı Yönetimi: SOC 2 ve benzeri uyumluluk çerçeveleri açısından WIF, kimlik doğrulamayı kurumsal IdP’de merkezileştirerek ve uzun ömürlü bulut kimlik bilgilerinin kullanımını azaltarak erişimin yetkilendirilmesine ve sonlandırılmasına ilişkin kanıtların yönetimini kolaylaştırabilir. Kuruluşların yine de geçerli gereksinimleri karşılamak için erişim incelemeleri, işten ayrılma süreçleri, loglama ve kanıtların saklanmasına ilişkin kontrolleri dokümante etmesi gerekir. Mükerrer Kimliklerin Azaltılması: WIF, Google tarafından yönetilen kimliklere dizin senkronizasyonu gerektirmediği için kuruluşların Google Cloud üzerinde oluşturması, yönetmesi ve düzenli olarak gözden geçirmesi gereken yinelenen kullanıcı kimliklerinin sayısını azaltabilir.

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.