Google Cloud Platform (GCP) Credentials Güvenliği ve Service Account Yönetimi Rehberi

Bulut altyapılarında meydana gelen güvenlik ihlallerinin ezici bir çoğunluğu, yanlış yapılandırılmış kimlik denetimi mekanizmalarından ve sızdırılan erişim anahtarlarından kaynaklanmaktadır. Modern bulut mimarilerinde GCP credentials güvenliği sağlamak, veri merkezlerinizin sanal kapılarını kilitli tutmanın en temel şartıdır. Birçok kurum, sistemlerini Google Cloud altyapısına taşırken uygulama servisleri arasındaki iletişimi yönetmek için Service Account yapılarını kullanır. Ancak bu hesapların kontrolsüzce oluşturulması, süresi geçmeyen JSON anahtar dosyalarının kod depolarına gönderilmesi veya geniş yetkiler verilmesi büyük güvenlik risklerini beraberinde getirir.

Daha önce ele aldığımız AWS, Google Cloud ve Microsoft Azure Karşılaştırması başlıklı yazımızda da vurguladığımız gibi, Google Cloud Platform (GCP) sunduğu gelişmiş IAM (Identity and Access Management) mimarisiyle son derece esnek bir yapı sunar. Ancak bu esneklik, doğru güvenlik prensipleriyle desteklenmediğinde ciddi bir zafiyete dönüşebilir. Bu rehberde, GCP üzerinde Service Account yönetimi, Workload Identity kullanımı, credential rotasyonu ve en az yetki prensibinin (Principle of Least Privilege) uygulamaya nasıl geçirileceğini somut örneklerle inceleyeceğiz.

Service Account Nedir ve Nasıl Çalışır?

Google Cloud Platform üzerinde iki ana kimlik türü bulunur: Kullanıcı Hesapları (User Accounts) ve Servis Hesapları (Service Accounts). Kullanıcı hesapları gerçek insanları temsil ederken, Service Account'lar uygulamalar, sanal makineler (Compute Engine), konteynerler (GKE) veya otomasyon araçları (Terraform, GitHub Actions) tarafından kullanılır.

Bir Service Account, varsayılan olarak bir e-posta adresi biçiminde tanımlanır: sa-app-prod@proje-kimligi.iam.gserviceaccount.com

Service Account'ların geleneksel kullanıcı hesaplarından temel farkları şunlardır:

• Parolaları yoktur ve 2FA (İki Faktörlü Doğrulama) gerektirmezler.
• Google Workspace veya Cloud Identity alan adına bağlı olmadan proje düzeyinde oluşturulabilirler.
• Diğer kaynaklara erişmek için OAuth 2.0 erişim jetonları (access tokens) veya kriptografik anahtar çiftleri kullanırlar.

Servis hesapları doğrudan IAM rollerine bağlanır. Dolayısıyla, bir servis hesabına ele geçirildiği takdirde tüm projenizi tehlikeye atabilecek Roles/Owner veya Roles/Editor gibi geniş kapsamlı roller vermek son derece tehlikelidir.

En Az Yetki Prensibi (Principle of Least Privilege) ile IAM Yapılandırması

GCP credentials güvenliği sağlamanın ilk adımı, servis hesaplarına yalnızca ihtiyaç duydukları minimum yetkiyi vermektir. Google Cloud, binlerce önceden tanımlanmış (predefined) ve özel (custom) IAM rolü sunar.

Yanlış Yaklaşım: İlkel (Primitive) Roller

Sık yapılan hatalardan biri, hızlı çözüm üretmek adına servis hesabına Editor (roles/editor) veya Owner (roles/owner) yetkisi vermektir. Bu durum, yalnızca Cloud Storage üzerinde dosya okuması gereken bir uygulamanın, tüm veri tabanlarını silebilmesine veya yeni sanal sunucular başlatabilmesine olanak tanır.

Doğru Yaklaşım: İnce Ayarlı (Fine-grained) ve Özel Roller

Uygulamanızın sadece belirli bir Cloud Storage kovasına (bucket) dosya yüklemesi gerekiyorsa, projenin tamamını kapsayan roller yerine nesne düzeyinde kısıtlanmış roller tanımlamalısınız.

Örnek olarak gcloud CLI kullanarak bir servis hesabına yalnızca belirli bir depolama alanı için okuma-yazma yetkisi vermek üzere aşağıdaki komutları çalıştırabilirsiniz:

# 1. Servis Hesabını Oluşturun
gcloud iam service-accounts create sa-storage-writer \
    --description="Sadece görsel yüklemeleri için kullanılır" \
    --display-name="Storage Writer SA"

# 2. Özel BUCKET Düzeyinde Yetki Tanımlayın (Proje Genelinde Değil)
gcloud storage buckets add-iam-policy-binding gs://kurumsal-gorsel-depo \
    --member="serviceAccount:sa-storage-writer@proje-kimligi.iam.gserviceaccount.com" \
    --role="roles/storage.objectUser"

Bu yaklaşım sayesinde, sa-storage-writer hesabının bilgileri sızsa dahi saldırgan sadece kurumsal-gorsel-depo kovasındaki nesnelere erişebilir; Compute Engine sunucularına veya BigQuery veri tabanlarına erişemez.

Statik JSON Key Kullanımını Bırakın: Workload Identity Dönemi

Geçmişte GCP üzerinde bir servis hesabını dış sistemlerle (örneğin bir on-premise sunucu veya GitHub Actions) entegre etmenin standart yolu, Google Cloud Console üzerinden bir .json private key dosyası indirmekti. Ancak bu yöntem günümüz siber güvenlik standartlarında kabul edilemez riskler barındırır.

Statik JSON Key Tehlikeleri

• Süre Sınırı Yoktur: Varsayılan olarak oluşturulan private key dosyalarının süresi 9999 yılına kadar geçerlidir.
• Kod Depolarına Sızma: Yanlışlıkla Git depolarına (GitHub, GitLab) commit edilen anahtarlar, botlar tarafından saniyeler içinde taranarak ele geçirilir.
• İzlenebilirlik Zorluğu: Bir JSON anahtarının kaç farklı sunucuda kopyalandığını veya kimlerin elinde olduğunu takip etmek imkansızdır.

Benzer güvenlik stratejilerini incelediğimiz AWS Güvenlik Rehberi: IAM Rolleri ve Credentials Güvenliği içeriğimizde belirttiğimiz gibi, bulut sağlayıcılarında uzun ömürlü anahtarlar yerine her zaman geçici jetonlar (short-lived tokens) tercih edilmelidir.

Google Cloud bu sorunu çözmek için Workload Identity Federation teknolojisini sunmaktadır.

Workload Identity Federation Nasıl Çalışır?

Workload Identity, AWS, Azure, GitHub Actions, GitLab veya HashiCorp Vault gibi dış kimlik sağlayıcılarının (OpenID Connect - OIDC veya SAML 2.0 destekleyen) GCP üzerinde statik anahtar kullanmadan doğrudan kimlik doğrulamasını sağlar.

Şematik olarak akış şu şekilde işler:

• Dış sistem (örneğin GitHub Actions), OIDC belirtecini (token) üretir.
• Bu belirteç GCP Workload Identity Pool'a gönderilir.
• GCP, gelen belirtecin doğruluğunu teyit eder ve ilgili dış sisteme kısa ömürlü (1 saat geçerli) bir GCP OAuth 2.0 Access Token teslim eder.
• Hiçbir aşamada uzun ömürlü JSON private key oluşturulmaz ve saklanmaz.

# GitHub Actions İş Akışında Workload Identity Kullanım Örneği
name: GCP Deployment
on:
  push:
    branches: [ "main" ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: 'read'
      id-token: 'write' # OIDC token almak için gereklidir

    steps:
    - name: Checkout Code
      uses: actions/checkout@v4

    - name: Authenticate to Google Cloud
      uses: google-github-actions/auth@v2
      with:
        workload_identity_provider: 'projects/123456789/locations/global/workloadIdentityPools/github-pool/providers/github-provider'
        service_account: 'sa-deployer@proje-kimligi.iam.gserviceaccount.com'

    - name: Set up Cloud SDK
      uses: google-github-actions/setup-gcloud@v2

    - name: Deploy Step
      run: gcloud app deploy

Kaçınılmaz Durumlarda Service Account Key Yönetimi ve Rotasyonu

Eğer eski bir mimari nedeniyle statik JSON anahtarı kullanmak zorundaysanız, sıkı güvenlik kuralları uygulamalısınız.

1. Anahtar Yaşlandırma ve Otomatik Rotasyon

GCP üzerinde anahtarların periyodik olarak değiştirilmesi (rotasyon) şarttır. Bir anahtarın maksimum ömrü 90 günü geçmemelidir. Bu süreci manuel yapmak yerine GCP Cloud Asset Inventory ve Cloud Functions/Run kullanarak otomatikleştirin.

2. Service Account Key Kısıtlamaları (Organizasyon Politikaları)

Organizasyon seviyesinde JSON anahtar oluşturulmasını engellemek veya kısıtlamak mümkündür. Resource Manager üzerinde aşağıdaki politikayı etkinleştirerek yazılımcıların rastgele anahtar indirmesini engelleyebilirsiniz:
• constraints/iam.disableServiceAccountKeyCreation: Bu politika True olarak ayarlandığında, kullanıcılar servis hesapları için yeni private key oluşturamazlar.
• constraints/iam.disableServiceAccountKeyUpload: Dışarıdan oluşturulmuş public key yüklemesini engeller.

Bu politikayı aktifleştirmek için CLI komutu:

gcloud resource-manager org-policies enable-enforce \
    iam.disableServiceAccountKeyCreation \
    --organization=ORGANIZASYON_ID

Audit Logging ve GCP Credentials İzleme

Oluşturulan tüm kimlik doğrulama isteklerinin ve servis hesabı hareketlerinin izlenmesi, olası bir sızma durumunda erken uyarı almanızı sağlar.

Cloud Audit Logs Yapılandırması

Google Cloud Console üzerinden IAM & Admin > Audit Logs sekmesine giderek Data Access loglarını aktif edin. Özellikle aşağıdaki servislerin loglanması kritik önem taşır:
• Identity and Access Management (IAM) API
• Security Token Service API
• Cloud Resource Manager API

Security Command Center (SCC) İle Şüpheli Hareket Tespiti

GCP Security Command Center, pasif durumdaki yetkili servis hesaplarını ve uzun süredir rotasyona uğramamış anahtarları tespit eder. Örneğin, 90 günden uzun süredir kullanılmayan bir servis hesabı Service Account Inactive uyarısı ile panoda görünür. Anomali tespiti için Security Command Center uyarısını Cloud Pub/Sub üzerinden SIEM (örneğin Splunk veya Datadog) sistemlerinize entegre edebilirsiniz.

GCP Service Account Yönetiminde Sık Yapılan 5 Hata ve Çözümleri

Saha tecrübelerimize göre cloud mimarilerinde en sık karşılaşılan GCP credentials güvenliği hataları ve çözümleri şunlardır:

Varsayılan Servis Hesaplarını (Default Service Accounts) Kullanmak:

- Hata: Compute Engine veya App Engine başlatıldığında otomatik oluşturulan varsayılan servis hesapları genelde Editor rolüne sahiptir. - Çözüm: Sunucu oluştururken varsayılan servis hesabını değil, özel oluşturduğunuz minimal yetkili servis hesabını atayın. Mümkünse varsayılan hesapları devre dışı bırakın.

Servis Hesaplarına Servis Hesabı Aktarma Yetkisi Vermek (iam.serviceAccounts.actAs):

- Hata: Bir kullanıcının veya servis hesabının yüksek yetkili başka bir servis hesabı adına işlem yapmasına (impersonation) kontrolsüzce izin vermek. - Çözüm: actAs yetkisini sadece çok spesifik iş akışlarına kısıtlayın ve koşullu IAM kuralları (IAM Conditions) ekleyin.

JSON Anahtarlarını Uygulama Kodunun İçine Gömme (Hardcoding):

- Hata: credentials.json dosya içeriğini kodun içine yazmak veya repository klasörüne eklemek. - Çözüm: Ortam değişkenleri (Environment Variables), GCP Secret Manager veya HashiCorp Vault kullanın.

Geliştirme ve Üretim Ortamlarında Aynı Servis Hesabını Kullanmak:

- Hata: Dev/Test sunucusu ile Prod sunucusunun aynı IAM yetkilerini ve credentials verilerini paylaşması. - Çözüm: Ortamları (Projects) tamamen ayırın (GCP Project Isolation). Dev ortamındaki bir zafiyet Prod verilerini etkilememelidir.

Erişim Jetonu Sürelerini Uzun Tutmak:

- Hata: Üretilen OAuth jetonlarının geçerlilik sürelerini maksimum sınıra çekmek. - Çözüm: Varsayılan 1 saatlik süreyi koruyun veya hassas işlemler için gcloud üzerinde daha kısa ömürlü jetonlar talep edin.

Sonuç ve Önerilen Adımlar

Google Cloud mimarinizi güvenceye almak, sürekli dikkat ve güncel standartlara uyum gerektiren bir süreçtir. Şifresiz ve anahtarsız kimlik doğrulama modellerinin standart haline geldiği günümüzde, statik anahtarlara olan bağımlılığı azaltmak en öncelikli hedefiniz olmalıdır.

Güvenlik altyapınızı güçlendirmek için hemen bugün şu üç adımı atın:

Google Cloud panelinizden IAM & Admin > Service Accounts bölümüne girerek aktif tüm .json anahtarlarını listeleyin ve kullanılmayanları anında silin.

GitHub, GitLab veya CI/CD boru hatlarınızda statik anahtar kullanımını kaldırıp Workload Identity Federation kurulumunu tamamlayın.

Organizasyon seviyesinde iam.disableServiceAccountKeyCreation kısıtlamasını devreye alarak ekibinizin yeni statik anahtar üretmesini engelleyin.