Google PCD: Kimlik, Kimlik Doğrulama ve Uygulama Güvenliği — Çalışma kılavuzu

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Şunun bir parçası: Google Professional Cloud Developer — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Google sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Genel Bakış

Kimlik, Google Cloud’da yeni çevre (perimeter) haline gelmiştir. Uygulamaların, sırları, anahtarları ve yazılım tedarik zincirini korurken, sorumluları (principals) (kullanıcılar, servisler) doğrulaması ve verilere ve API’lere en az ayrıcalıkla erişim için yetkilendirmesi gerekir. Bu bölüm, Google Cloud IAM, modern kimlik doğrulama protokolleri, ağ ve API savunmaları, şifreleme, günlük kaydı ve müdahale süreçlerini birleştiren uçtan uca tasarım ve operasyonel uygulamaları özetlemektedir. Vurgu, kısa ömürlü kimlik bilgileri, merkezi politika ve güvenli bir şekilde hata veren (fail-safe) katmanlı kontroller üzerindedir.

Kimlikler, Kimlik Doğrulama ve Erişim Kontrolü

IAM rolleri ve hizmet hesapları
- İlkel (primitive) roller yerine kaynak hiyerarşisini (kuruluş > klasör > proje) ve önceden tanımlanmış rolleri kullanın. Özel rolleri yalnızca önceden tanımlanmış rollerin çok geniş olduğu durumlarda tercih edin.
- İş yüklerine hizmet hesapları (SA) atayın. Varsayılan Compute Engine veya App Engine SA’larını yeniden kullanmayın. Her iş yükü sınırı için bir SA, en az ayrıcalık ilkesini ve güvenin rotasyonunu basitleştirir.
- En dar kaynak kapsamında minimum izin setini vererek en az ayrıcalık ilkesini uygulayın.
- Kimliğe bürünme (Impersonation): İnsanların, CI/CD’nin veya diğer hizmetlerin anahtarları saklamadan geçici erişim elde etmesini sağlamak için Service Account Token Creator aracılığıyla kısa ömürlü kimlik bilgilerini tercih edin:
  - Çağıran kimliğe, hedef SA üzerinde roles/iam.serviceAccountTokenCreator rolünü verin.
  - Örnek:

undefined

Workload Identity
- GKE: Kubernetes hizmet hesaplarını Google hizmet hesaplarına bağlamak için Workload Identity kullanın; token’lar otomatik olarak yansıtılır ve değiştirilir—JSON anahtarları gerekmez.
- Harici iş yükleri: Uzun ömürlü anahtarları saklamadan OIDC/SAML kimlik bilgilerini (örneğin, GitHub Actions veya şirket içinden (on-prem)) Google erişim token’ları ile değiştirmek için Workload Identity Federation kullanın.
Hata modları ve ödünleşimler
- Gereğinden geniş roller veya geniş kapsamlı izinler yanal harekete (lateral movement) yol açar. Eksik Token Creator ayrıcalıkları, kimliğe bürünme akışlarını engeller. JSON anahtar dosyaları, ihlal etki alanını (blast radius) artırır.
OAuth 2.0, OpenID Connect ve Google Identity ile kullanıcı kimlik doğrulaması
- Son kullanıcı kimlik doğrulaması için, IdP olarak Google veya kurumsal bir IdP ile OIDC kullanın; ID token’larını sunucu tarafında doğrulayın. API erişimi için, uygun kapsamlara (scope) sahip OAuth 2.0 erişim token’ları kullanın.
- Token’ları doğrulayın: IdP’nin JWKS’lerini kullanarak iss, aud, exp, iat ve imzayı doğrulayın; JWKS’leri önbelleğe alın ve anahtar rotasyonunu zorunlu kılın.
- Mobil/SPA arka uçları (backend) için, PKCE ile Yetkilendirme Kodu akışını (Authorization Code flow) tercih edin. Örtük (implicit) akışlardan kaçının.
- Servisten servise iletişim için, OAuth 2.0 Service Account JWT akışını veya mTLS’i kullanın; statik API anahtarlarından kaçının.
- Örnek (gcloud ile token kimliğine bürünme):

undefined

Hata modları
- aud/iss doğrulanmaması token karışıklığına (token confusion) izin verir. Süresi dolmuş token’ları kabul etmek veya JWKS’leri döndürmemek riski artırır. Mobil uygulamalarda yenileme token’ları (refresh token) kullanmak, uzun ömürlü kimlik bilgilerini açığa çıkarır.
Tarayıcı erişimi için Identity-Aware Proxy (IAP)
- Cloud Run, GKE veya Compute Engine üzerindeki HTTP uygulamalarını, kimlik doğrulama mantığını uygulamaya gömmeden ön yüzde korumak için IAP kullanın. Erişim için “IAP-secured Web App User” rolünü zorunlu kılın.
- Uygulamalar imzalı bir başlık (header) (x-goog-iap-jwt-assertion) alır. Kullanıcı kimliğine ve e-postasına güvenmek için JWT’yi doğrulayın; kimlik doğrulama için X-Forwarded-* başlıklarına güvenmeyin.
- Yaygın tuzaklar: IAP üzerinden yönlendirilmeyen baypas yolları, yanlış yapılandırılmış arka uç güvenlik duvarı veya Cloud Load Balancing bütünlüğü olmadan istemci IP başlıklarına güvenmek.

Sırlar, Anahtarlar ve Şifreleme

Secret Manager
- API anahtarlarını, veritabanı parolalarını ve webhook sırlarını (secret) Secret Manager’da saklayın. Sürüm oluşturma, IAM kontrolleri ve denetim günlüklerine güvenin.
- Erişim desenleri
  - Başlangıçta çekin ve bellekte önbelleğe alın; sır (secret) değişikliği sinyallerinde (Pub/Sub bildirimleri) yenileyin.
  - Sırları imajlara veya ortam değişkenlerine gömmekten (baking) kaçının. Ortam değişkenleri kullanılıyorsa, bunların asla günlüğe kaydedilmediğinden veya kilitlenme raporlarına dökülmediğinden emin olun.
- Rotasyon
  - Yeni sürümler oluşturmak, bağımlılıkları güncellemek ve eskilerini kullanımdan kaldırmak için Cloud Scheduler + Cloud Functions/Run ile otomatikleştirin.
  - Örnek:

undefined

Hata modları
- İstek başına aşırı Secret Manager çağrısı, gecikme ve kota tükenmesi riski ekler. Eksik roles/secretAccessor rolü, çalışma zamanı 403 hatalarına neden olur.
Cloud KMS ve uygulama şifrelemesi
- Zarf şifrelemesi (envelope encryption) kullanın: yerel olarak oluşturulan bir veri şifreleme anahtarı (DEK) veriyi şifreler; Cloud KMS müşteri tarafından yönetilen anahtar (CMEK) ise DEK’i şifreler (KEK).
- Anahtarları düzenli olarak döndürün; yeniden şifreleme için plan yapın. Yazma sırasında “eskiyi çöz, yeniyi şifrele” yöntemini tercih edin; duran veriler (at-rest) için toplu yeniden şifreleme işleri daha maliyetlidir.
- Uyumluluk gerektirdiğinde servisler (BigQuery, GCS, Pub/Sub, Cloud SQL, vb.) için CMEK’i etkinleştirin. KMS anahtarlarını verilerle aynı bölgede tutun.
- Örnek CLI:
  - Şifreleme:

undefined

- Şifre Çözme:

undefined

Uygulama hatalarından kaçınmak için iyi incelenmiş kripto kütüphaneleri (örneğin, Tink) kullanın.
Hata modları
- Konum uyuşmazlıkları CMEK kullanımını engeller. İstek başına KMS şifre çözme işlemi gecikme ekler; DEK’leri rotasyon farkındalığıyla bellekte önbelleğe alın. Eksik roles/cloudkms.cryptoKeyEncrypterDecrypter rolü 403 hatalarına yol açar.

Yetkilendirme, API’ler ve Çevre Güvenliği

Uygulama yetkilendirmesi
- Rol tabanlı kontroller: basit, hızlı ama kaba tanelidir. Nitelik tabanlı erişim kontrolü (ABAC), ayrıntılı kararlar için kullanıcı niteliklerini, kaynak niteliklerini ve bağlamı (zaman, cihaz duruşu) kullanır.
- Politika değerlendirmesini merkezileştirin veya bir sidecar/OPA kullanın; kimlik ve kiracı taleplerini mikroservisler arasında tutarlı bir şekilde yayın.
- Çoklu kiracılık desenleri
  - tenant_id‘yi kimlik doğrulama token’larına gömün ve her veri erişim yolunda bunu zorunlu kılın; sıkı izolasyon için satır seviyesinde filtreleme veya kiracı başına ayrı veri setleri kullanın.
  - Mevzuata uygun izolasyon gerekiyorsa kiracı başına hizmet hesapları veya KMS anahtarları kullanmayı düşünün.
- Hata modları
  - Eksik kiracı kontrolleri nedeniyle güvensiz doğrudan nesne referansları (IDOR). Servisler arasında farklılaşan yetkilendirme mantığının tutarsız uygulamaya neden olması.
Güvenli API tasarımı
- Tüm girdileri doğrulayın ve normalleştirin; büyük boyutlu payload’ları reddedin. Güçlü içerik türlerini zorunlu kılın. Dosya yüklemeleri için tehdit modellemesi yapın; büyük nesneler için imzalı URL’ler (signed URL) kullanın.
- Hız sınırlama ve kotalar: Kötüye kullanımı ve 429 hatalarını azaltmak için Cloud Armor hız sınırlaması veya Apigee kullanın. İstemcilerde jitter ile üstel geri çekilme (exponential backoff) uygulayın.
- CORS
  - Minimal Access-Control-Allow-* başlıkları döndürün; kimlik bilgisi gerektiren isteklerde joker karakterli origin’lerden kaçının. Preflight önbellekleme gecikmeyi azaltır.
- CSRF savunmaları
  - Authorization başlıklarında bearer token’lar bulunan durumsuz (stateless) API’leri tercih edin. Çerez tabanlı oturumlar için SameSite=strict veya lax, güvenli çerezler ve bir CSRF token’ı (double-submit veya synchronizer) kullanın.
- Örnek (Cloud Armor kuralı):

undefined

Hata modları
- Basit IP tabanlı sınırlama, IPv6 veya proxy’ler ile atlatılabilir. Aşırı izin veren CORS, token sızıntısına olanak tanır. Çerezlerle birlikte eksik CSRF token’ları, oturum çalmaya (session riding) izin verir.
Ağ kontrolleri ve veri çevresi
- Hiyerarşik güvenlik duvarı politikalarını ve VPC güvenlik duvarı kurallarını kullanın; HTTP(S) Load Balancing arkasındayken Google Front Ends sağlık kontrollerine izin verin.
- Örnek:

undefined

Cloud Armor, WAF, bot savunması ve coğrafi/IP kısıtlamaları sağlar; kuralları ayarlayın ve yanlış pozitifleri (false positive) gözden geçirin.
Private service access, Google tarafından yönetilen hizmetlere (örneğin, Cloud SQL, Memorystore) özel IP bağlantısı sağlar; genel giden trafikten (public egress) ve IP izin listelerinden (allowlist) kaçının.
VPC Service Controls, desteklenen hizmetler etrafında çevreler (perimeter) oluşturarak veri sızdırma riskini azaltır; cihaz/konum bağlamı için Access Context Manager ile birleştirin.
Hata modları
- Yanlış yapılandırılmış çevreler CI/CD’yi engelleyebilir veya servisten servise çağrıları bozabilir. Eksik PSA tahsisleri, özel IP eklenmesini engeller. Aşırı katı WAF kuralları, erişilebilirlik olaylarına neden olabilir.

← Uygulama Verisi · Tüm alanlar · Sürekli Teslimat →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →