GCP IAM Güvenlik En İyi Uygulamaları

Tarafındankomut
0 Yorum

Google Cloud Platform’da bir proje yönetirken IAM yapılandırmasını “sonra düzeltirim” diye ertelemek, ilerleyen süreçte hem güvenlik açıklarına hem de beklenmedik maliyet artışlarına yol açar. Yıllar içinde onlarca GCP ortamı üzerinde çalışırken gördüğüm en yaygın sorun şu: Geliştirici ekipler hızlı hareket etmek için servis hesaplarına roles/owner veriyor, bu hesapların anahtarları bir süre sonra unutuluyor ve ortalık karışıyor. Bu yazıda GCP IAM güvenliğini gerçekten sağlam bir temele oturtmak için izlemeniz gereken pratik yolları ele alacağım.

IAM Temel Prensipleri ve Neden Önemli

IAM, GCP’deki her şeyin kapı bekçisidir. Compute Engine’den BigQuery’e, Cloud Storage’dan Kubernetes Engine’e kadar her servise erişim IAM politikaları üzerinden yönetilir. Temel prensip en az ayrıcalık (least privilege) ilkesidir. Yani bir kullanıcıya veya servis hesabına işini yapması için gereken minimum izinleri verirsiniz, fazlasını değil.

Pratikte bu ilkeyi uygulamak düşündüğünüzden zor olabilir. Çünkü organizasyonunuz büyüdükçe kimlerin neye eriştiğini takip etmek giderek zorlaşır. İşte bu yüzden baştan düzgün bir yapı kurmak kritik önem taşır.

GCP IAM’in temel bileşenleri:

  • Principal (Kimlik): Google hesabı, servis hesabı, grup veya domain
  • Role (Rol): Bir izin koleksiyonu (primitive, predefined veya custom)
  • Policy (Politika): Principal ile Role’ü birbirine bağlayan tanım
  • Resource (Kaynak): Politikanın uygulandığı GCP kaynağı

Organizasyon Hiyerarşisini Doğru Kurmak

GCP’de kaynaklar hiyerarşik bir yapıda organize edilir: Organization > Folder > Project > Resource. Bu hiyerarşiyi doğru kurmak, IAM politikalarını doğru noktada uygulamak açısından kritik.

Örneğin bir şirkette production, staging ve development ortamları için ayrı projeler oluşturuyorsunuz. Bu projeleri ilgili klasörlere bağlamak ve politikaları klasör seviyesinde tanımlamak, her proje için aynı politikayı tek tek uygulamak yerine çok daha verimli bir yaklaşım.

# Organizasyon hiyerarşisini görüntüle
gcloud resource-manager folders list --organization=ORG_ID

# Yeni bir klasör oluştur
gcloud resource-manager folders create 
  --display-name="Production" 
  --organization=ORG_ID

# Klasör altında proje oluştur
gcloud projects create prod-my-app-2024 
  --folder=FOLDER_ID 
  --name="Production App"

Politikalar hiyerarşide yukarıdan aşağıya miras alınır. Organization seviyesinde verdiğiniz bir rol, altındaki tüm klasör ve projeleri etkiler. Bu nedenle Organization seviyesinde mümkün olduğunca az kullanıcıya rol atayın.

Primitive Roller Neden Kullanılmamalı

roles/owner, roles/editor ve roles/viewer primitive roller olarak bilinir. Çoğu GCP ortamında bu rollerin fazla kullanıldığını görüyorum. Sorun şu: roles/editor rolü yüzlerce izni bir arada barındırır ve birinin gerçekten ihtiyaç duyduğundan çok daha fazlasını verir.

Gerçek dünya senaryosu: Bir ekip üyesinin Cloud Storage’daki bir bucket’a dosya yüklemesi gerekiyor. Bunun için roles/editor vermek yerine:

# YANLIS: Fazla geniş yetki
gcloud projects add-iam-policy-binding my-project 
  --member="user:[email protected]" 
  --role="roles/editor"

# DOGRU: Yalnizca ihtiyac duyulan izin
gcloud storage buckets add-iam-policy-binding gs://my-bucket 
  --member="user:[email protected]" 
  --role="roles/storage.objectCreator"

Bu yaklaşım hem daha güvenli hem de denetlenebilirlik açısından çok daha temiz. Birisi Storage’a izinsiz erişmeye çalıştığında log kayıtlarında tam olarak neyi yapmaya çalıştığını görebilirsiniz.

Servis Hesapları ve Doğru Kullanımı

Servis hesapları GCP güvenliğinin en kritik parçalarından biri. Yanlış yönetilen servis hesapları ciddi güvenlik açıklarına yol açar.

Servis Hesabı Oluşturma ve Yönetimi

# Servis hesabi olustur
gcloud iam service-accounts create my-app-sa 
  --display-name="My Application Service Account" 
  --description="Production uygulamasi icin servis hesabi" 
  --project=my-project

# Servis hesabina minimum gerekli rol ata
gcloud projects add-iam-policy-binding my-project 
  --member="serviceAccount:[email protected]" 
  --role="roles/storage.objectViewer"

# Servis hesabini listele
gcloud iam service-accounts list --project=my-project

Servis Hesabı Anahtarlarından Kaçının

Bu konuda ne kadar vurgulansam az: Servis hesabı JSON anahtarlarını mümkün olduğunca kullanmayın. Bu anahtarlar çalındığında veya yanlışlıkla bir Git repository’sine push edildiğinde büyük sorunlar çıkar.

Bunun yerine Workload Identity Federation veya GCE üzerinde çalışıyorsanız attached service accounts kullanın:

# GCE instance'a servis hesabi baglama (anahtar gerekmez)
gcloud compute instances create my-instance 
  [email protected] 
  --scopes=https://www.googleapis.com/auth/cloud-platform 
  --zone=europe-west1-b

# Workload Identity Federation ile harici kimlik saglayicisi yapilandirma
gcloud iam workload-identity-pools create my-pool 
  --location=global 
  --display-name="My Workload Identity Pool"

gcloud iam workload-identity-pools providers create-oidc my-provider 
  --workload-identity-pool=my-pool 
  --location=global 
  --issuer-uri="https://token.actions.githubusercontent.com" 
  --attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository"

Eğer zorunlu olarak anahtar kullanmanız gerekiyorsa, bu anahtarları Secret Manager‘da saklayın ve düzenli aralıklarla rotate edin.

Custom Rol Oluşturma

Predefined roller işinizi karşılamıyorsa custom roller oluşturabilirsiniz. Özellikle ince taneli izin yönetimi gerektiğinde bu yaklaşım çok işe yarıyor.

# Mevcut bir rolun izinlerini incele
gcloud iam roles describe roles/storage.objectViewer

# Custom rol icin YAML dosyasi olustur
cat > custom-role.yaml << 'EOF'
title: "Limited Storage Manager"
description: "Sadece belirli storage islemleri icin ozel rol"
stage: "GA"
includedPermissions:
  - storage.objects.get
  - storage.objects.list
  - storage.objects.create
  - storage.buckets.get
EOF

# Custom rolu proje seviyesinde olustur
gcloud iam roles create limitedStorageManager 
  --project=my-project 
  --file=custom-role.yaml

# Custom rolu kullaniciya ata
gcloud projects add-iam-policy-binding my-project 
  --member="user:[email protected]" 
  --role="projects/my-project/roles/limitedStorageManager"

Custom roller oluştururken dikkat etmeniz gereken bir nokta: Bu rolleri organizasyon seviyesinde veya proje seviyesinde oluşturabilirsiniz. Birden fazla projede kullanılacaksa organizasyon seviyesinde oluşturmak daha mantıklı.

Koşullu IAM Politikaları (Condition-Based Access)

GCP IAM’in güçlü özelliklerinden biri koşullu erişim. Belirli koşullar sağlandığında erişime izin vermek veya reddetmek için kullanılır.

Örneğin bir müteahhit ekibine sadece iş günleri ve mesai saatlerinde erişim vermek istiyorsunuz:

# Zaman koşullu IAM politikasi ekle
gcloud projects add-iam-policy-binding my-project 
  --member="user:[email protected]" 
  --role="roles/compute.viewer" 
  --condition='expression=request.time.getDayOfWeek("Europe/Istanbul") >= 1 && request.time.getDayOfWeek("Europe/Istanbul") <= 5 && request.time.getHours("Europe/Istanbul") >= 9 && request.time.getHours("Europe/Istanbul") <= 18,title=business-hours-only,description=Sadece is gunleri erisim'

Kaynak bazlı koşullar da oldukça kullanışlı. Örneğin sadece belirli tag’e sahip kaynaklar üzerinde işlem yapılmasına izin vermek:

# Kaynak etiketi kosullu erisim
gcloud projects add-iam-policy-binding my-project 
  --member="serviceAccount:[email protected]" 
  --role="roles/compute.instanceAdmin.v1" 
  --condition='expression=resource.matchTag("my-project/environment","development"),title=dev-env-only,description=Sadece development ortami'

Privileged Access Management ve İzin İnceleme

Zaman zaman yönetici erişimine ihtiyaç duyulur ama bu erişimin kalıcı olması gerekmez. Just-In-Time (JIT) access yaklaşımı burada devreye girer. GCP’de bu için Privileged Access Manager (PAM) kullanılabilir.

Bunun yanı sıra mevcut IAM politikalarınızı düzenli olarak gözden geçirmek kritik önem taşır:

# Projedeki tum IAM politikalarini goruntule
gcloud projects get-iam-policy my-project 
  --format=json > iam-policy-backup.json

# Belirli bir kullanicinin sahip oldugu rolleri listele
gcloud projects get-iam-policy my-project 
  --flatten="bindings[].members" 
  --format="table(bindings.role)" 
  --filter="bindings.members:user:[email protected]"

# Kullanilmayan servis hesaplarini tespit et (90 gundir aktif olmayan)
gcloud iam service-accounts list 
  --format="table(name,email,disabled)" 
  --project=my-project

IAM Recommender de değerli bir araç. Google’ın machine learning tabanlı bu servisi, kullanılmayan izinleri tespit ederek daha az ayrıcalıklı rollere geçmenizi öneriyor:

# IAM Recommender onerileri listele
gcloud recommender recommendations list 
  --project=my-project 
  --location=global 
  --recommender=google.iam.policy.Recommender 
  --format="table(name,stateInfo.state,description)"

VPC Service Controls ile Çevre Güvenliği

IAM tek başına yeterli değildir. VPC Service Controls, GCP servislerinizi bir çevre (perimeter) içine alarak veri exfiltration riskini azaltır. IAM ile birlikte kullanıldığında güvenliği çok daha güçlü hale getirir.

Gerçek dünya senaryosu: Finans departmanınızın BigQuery verisine sadece şirket ağından erişilmesi gerekiyor. VPC Service Controls ile bunu sağlayabilirsiniz:

# Access policy olustur
gcloud access-context-manager policies create 
  --organization=ORG_ID 
  --title="My Access Policy"

# Servis cevresi olustur
gcloud access-context-manager perimeters create my-perimeter 
  --policy=POLICY_ID 
  --title="Finance Data Perimeter" 
  --resources=projects/PROJECT_NUMBER 
  --restricted-services=bigquery.googleapis.com,storage.googleapis.com

# Erisim seviyesi tanimla (kurumsal IP araligina gore)
gcloud access-context-manager levels create corporate-network 
  --policy=POLICY_ID 
  --title="Corporate Network" 
  --basic-level-spec=conditions.yaml

Audit Log’ları Etkinleştirme ve İzleme

IAM yapılandırmanız ne kadar iyi olursa olsun, kim neye erişiyor ve ne yapıyor bilmeden güvenliği tam olarak sağlayamazsınız. Cloud Audit Logs bu noktada devreye giriyor.

# Data Access audit log'larini etkinlestir
cat > audit-policy.yaml << 'EOF'
auditConfigs:
  - service: allServices
    auditLogConfigs:
      - logType: ADMIN_READ
      - logType: DATA_READ
      - logType: DATA_WRITE
EOF

gcloud projects set-iam-policy my-project audit-policy.yaml

# IAM politika degisikliklerini izle (Cloud Logging sorgusu)
gcloud logging read 
  'protoPayload.serviceName="iam.googleapis.com" AND protoPayload.methodName:"setIamPolicy"' 
  --project=my-project 
  --limit=50 
  --format="table(timestamp,protoPayload.authenticationInfo.principalEmail,protoPayload.resourceName)"

Log’ları analiz etmenin ötesinde, şüpheli aktiviteler için alerting kurmanız gerekiyor. Örneğin birisi organizasyon seviyesinde bir role atandığında anında bildirim almak:

# Log-based alert icin sink olustur
gcloud logging sinks create iam-changes-sink 
  bigquery.googleapis.com/projects/my-project/datasets/security_logs 
  --log-filter='protoPayload.serviceName="iam.googleapis.com"' 
  --project=my-project

# Kritik IAM degisiklikleri icin metric olustur
gcloud logging metrics create iam-policy-changes 
  --description="IAM politika degisikliklerini izler" 
  --log-filter='protoPayload.methodName:"setIamPolicy" OR protoPayload.methodName:"createServiceAccount"' 
  --project=my-project

Organization Policy ile Güvenlik Kısıtlamaları

IAM izinlerinin yanı sıra Organization Policy Service, belirli işlemleri tamamen yasaklamanıza olanak tanır. Bu, IAM’den bağımsız çalışır ve daha güçlü bir koruma katmanı sağlar.

# Servis hesabi anahtari olusturmayi yasakla
gcloud resource-manager org-policies set-policy 
  --organization=ORG_ID 
  disableServiceAccountKeyCreation.yaml

# Harici IP atamamasini engelleyen politika
gcloud resource-manager org-policies set-policy 
  --project=my-project 
  compute.vmExternalIpAccess.yaml

# Desteklenmis kisirlama politikalarini listele
gcloud resource-manager org-policies list-available-constraints 
  --organization=ORG_ID 
  --filter="name:iam"

Org policy’ler özellikle büyük organizasyonlarda, merkezi güvenlik ekibinin tüm projelerde geçerli olan temel kuralları zorlaması için ideal.

Gruplara Dayalı Erişim Yönetimi

Bireysel kullanıcılara doğrudan IAM rolü atamak, ekip büyüdükçe yönetimi zorlaştırır. Bunun yerine Google Groups veya Cloud Identity gruplarını kullanmak çok daha ölçeklenebilir bir yaklaşım.

# Gruba rol ata
gcloud projects add-iam-policy-binding my-project 
  --member="group:[email protected]" 
  --role="roles/bigquery.dataEditor"

# Gruba birden fazla rol ata (farkli servisler icin)
gcloud projects add-iam-policy-binding my-project 
  --member="group:[email protected]" 
  --role="roles/cloudsql.client"

gcloud projects add-iam-policy-binding my-project 
  --member="group:[email protected]" 
  --role="roles/secretmanager.secretAccessor"

Bu yaklaşımın avantajı şu: Yeni bir ekip üyesi işe başladığında tek yapmanız gereken onu ilgili gruba eklemek. Ayrıldığında da gruptan çıkarmak yeterli. Onlarca projeye tek tek gidip izin düzenlemenize gerek kalmıyor.

Düzenli Güvenlik Denetimi

IAM güvenliği sürekli bir süreçtir, tek seferlik bir yapılandırma değil. Aylık veya çeyreklik olarak şunları yapmanızı öneririm:

  • Kullanılmayan servis hesaplarını ve anahtarları temizlemek
  • IAM Recommender önerilerini inceleyip uygulamak
  • Ayrılan çalışanların erişimlerinin kaldırılıp kaldırılmadığını kontrol etmek
  • Primitive role (owner, editor) atamalarını gözden geçirmek
  • Servis hesabı anahtarlarının yaşını kontrol etmek (90 günden eski anahtarlar rotate edilmeli)

Security Command Center bu denetimleri otomatize etmek için güçlü bir araç. Özellikle Security Health Analytics, IAM ile ilgili güvenlik bulgularını otomatik olarak tespit eder.

# SCC bulgularini listele (IAM ile ilgili)
gcloud scc findings list organizations/ORG_ID 
  --filter="category:IAM AND state:ACTIVE" 
  --format="table(name,category,severity,createTime)"

Sonuç

GCP IAM güvenliği, bir kez yapıp unutulan bir konfigürasyon değil, sürekli dikkat gerektiren bir disiplin. Bu yazıda ele aldığım pratikler, yıllar içinde gerçek ortamlarda edindiğim deneyimlerin bir özeti. En kritik noktalara değineyim:

Öncelikle least privilege ilkesinden taviz vermeyin. Birine işini yapacak minimum izni verin, “sonra daraltırım” diye geniş roller atmayın. İkinci olarak, servis hesabı JSON anahtarlarını mümkün olduğunca ortadan kaldırın. Workload Identity Federation modern ortamlarda bu ihtiyacı neredeyse tamamen karşılıyor.

Bireysel kullanıcılara değil gruplara rol atayın, erişim yönetimini ölçeklenebilir hale getirin. Organization Policy ile temel güvenlik kurallarını IAM’den bağımsız olarak zorlayın. Audit log’larını mutlaka aktif tutun ve kritik değişiklikler için alerting kurun.

Son olarak, IAM Recommender ve Security Command Center gibi araçları düzenli olarak kullanarak mevcut yapınızdaki açıkları proaktif biçimde tespit edin. Güvenlik reaktif değil proaktif bir süreç olduğunda, hem ekibiniz hem de altyapınız çok daha sağlıklı bir yerde olacak.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir