Google PCA: Güvenlik, Uyumluluk ve Veri Koruma Mimarisi — Çalışma kılavuzu

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Şunun bir parçası: Google Professional Cloud Architect — Ç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ış

Google Cloud’da güvenlik, uyumluluk ve veri koruma; paylaşılan sorumluluk ve derinlemesine savunma üzerine kuruludur. Google altta yatan altyapıyı güvence altına alırken, siz güvenli kimlikleri, ağları, uygulamaları ve veri işlemeyi tasarlarsınız. Yol gösterici bir model olarak Sıfır Güven (Zero Trust) modelini benimseyin: ağa asla zımnen güvenmeyin, kimliği ve bağlamı sürekli olarak doğrulayın ve en az ayrıcalık ilkesini sıkı bir şekilde uygulayın. İhlal olasılığına göre tasarım yapın: kimlik bilgilerinin sızabileceğini, uç noktaların taranabileceğini ve dahili servislerin kötüye kullanılabileceğini varsayın. Bunu birden çok kontrolle (önleyici, tespit edici, müdahaleci), güçlü kriptografi ve anahtar yönetimi, sağlam izleme ve tatbikatı yapılmış olay müdahalesi ile telafi edin.

Ödünleşimler kaçınılmazdır. Daha güçlü kontroller gecikmeyi, operasyonel karmaşıklığı ve maliyetleri artırabilir. Mimarınız, kanıtlanabilir uyumluluğu ve adli bilişim hazırlığını korurken, riskleri kullanılabilirlik ve performansa karşı açıkça tartmalıdır.

Kimlik ve Erişim Mimarisi

• İlkeler ve model

  • Varsayılan olarak en az ayrıcalık ilkesi: bir görevi tamamlamak için gereken en küçük izin kümesini verin ve ilkel roller (Owner, Editor, Viewer) yerine önceden tanımlanmış rolleri veya özel rolleri tercih edin.
  • Görevler ayrılığı: rolleri geliştiriciler (CI/CD), dağıtımcılar, operatörler ve güvenlik ekipleri arasında bölün. Acil durumlar için güçlü kontrollere ve günlük kaydına sahip acil durum hesapları (break-glass accounts) kullanın.
  • Sıfır Güven (Zero Trust) uygulaması: kullanıcıyı, cihazı, konumu ve riski doğrulamak için bağlama duyarlı erişim kullanın; güçlü MFA gerektirin; ve oturum bağlamını sürekli olarak değerlendirin.
  • Kuruluş Politikası ve IAM Deny: koruma raylarını (örneğin, hizmet hesabı anahtarı oluşturulmasını engelleme, alan adı paylaşımını kısıtlama) kod haline getirin ve pazarlık konusu olmayan sınırları zorunlu kılmak için deny (reddetme) politikalarını kullanın.

• IAM uygulaması ve hizmet hesabı stratejisi

  • Hiyerarşi odaklı bir erişim modeli oluşturun: klasörler iş kollarını veya ortamları (prod, non-prod) yansıtır; projeler etki alanını (blast radius) ve faturalandırmayı izole eder; hizmet hesapları (SA’lar) iş yüklerini temsil eder.
  • Bir iş yükü, bir hizmet hesabı: birbiriyle alakasız hizmetler arasında SA’ları paylaşmaktan kaçının. İzinleri dağıtım kapsamına (proje) ve kaynak kapsamına göre etiketleyin.
  • Service Account Impersonation ve Workload Identity Federation aracılığıyla kısa ömürlü kimlik bilgilerini tercih edin. Kullanıcı tarafından yönetilen hizmet hesabı anahtarlarını devre dışı bırakın; kaçınılmazsa, kullanımı izole edin, sık sık rotasyona tabi tutun ve denetim günlükleriyle izleyin.
  • Kimliğine bürünülen bir SA’nın istek anında nelere erişebileceğini kısıtlamak için Access Boundaries kullanın (örneğin, GCS nesne yollarını sınırlayın), bu sayede ayrıcalıklı bir SA kötüye kullanılsa bile etki alanı (blast radius) kontrol altında tutulur.
  • Koşullu IAM: erişimi kısıtlamak için kaynak düzeyinde koşullar (zaman, IP, principal nitelikleri) uygulayın. Örnek: kurumsal IP aralıkları ve değişiklik pencereleri dışında üretim ortamına erişimi engelleyin.

• Hata modları ve ödünleşimler

  • Gereğinden fazla ayrıcalığa sahip roller (örneğin, proje kapsamında Editor rolü) riski artırır; daha ayrıntılı (granular) rolleri tercih edin ve politika analizörleri aracılığıyla doğrulayın.
  • CI/CD ve yerel betiklerdeki hizmet hesabı anahtarlarının kontrolsüz yayılımı yaygın bir ihlal vektörüdür; kimliğe bürünme (impersonation) ile bazı eski araçların uyarlanması gerekebilir.
  • IAM Deny politikaları güçlüdür ancak sorun gidermesi zor olabilir; değişiklikleri üretim dışı ortamlarda aşamalandırın ve açık deneme çalıştırmaları (dry run) ile test edin.

Örnek (anahtar oluşturmadan kimliğe bürünme):

• gcloud auth print-access-token –impersonate-service-account=svc-ci@proj.iam.gserviceaccount.com

Veri Koruma ve Kriptografi

• Cloud KMS ve anahtar yönetimi modelleri
  • Bekleme durumundaki veriler için yerel şifreleme (encryption at rest) varsayılan olarak etkindir. Ek kontrol için BigQuery, Cloud Storage, Compute Engine diskleri, Pub/Sub ve GKE kalıcı birimleri (persistent volumes) gibi hizmetlerde Müşteri Tarafından Yönetilen Şifreleme Anahtarları (CMEK) kullanın.
  • Ortam ve veri alanına göre bir anahtar hiyerarşisi tasarlayın. Etki alanını (blast radius) sınırlamak için her konum için ayrı anahtar halkaları (keyrings) ve her uygulama veya veri kümesi için ayrı anahtarlar kullanın.
  • Rotasyon: Zamanlanmış rotasyonu etkinleştirin ve uygulamalar için zarf şifrelemesi (envelope encryption) ile eski anahtar sürümlerini kontrollü bir şekilde kullanımdan kaldırın. Rotasyon sıklığını artırmadan önce tüketici uyumluluğunu doğrulayın.
  • External Key Manager (EKM) ve External Key Access (EKA), yasal düzenlemelere uyum kontrolü için anahtarları Google Cloud dışında konumlandırır. Dezavantajları arasında ek gecikme ve harici HSM’lerin kullanılabilirliğine olan bağımlılık yer alır; performansı düşürülmüş modda (degraded-mode) operasyonlar için planlama yapın.
  • CryptoKey’ler üzerinde IAM en az ayrıcalık ilkesini (least privilege) uygulayın. Erişim kanıtı için anahtar düzeyinde denetim günlüklerini (audit logs) kullanın.

Örnek (Rotasyonlu CMEK):

• gcloud kms keyrings create app-ring –location=us-central1

• gcloud kms keys create data-key –keyring=app-ring –location=us-central1 –purpose=encryption –rotation-period=90d

• Uygulama Düzeyinde Şifreleme

  • Uygulama katmanındaki hassas alanları şifrelemek için zarf şifrelemesi (örneğin, Tink) kullanarak seçici erişim ve kiracı verilerinin yalıtımını (tenant data isolation) sağlayın. Kiracılar arası etkiyi en aza indirmek için kiracı başına anahtarlar türetin.
  • Kurcalamayı (tampering) ve yeniden oynatma (replay) saldırılarını önlemek için bütünlüğü (AEAD) doğrulayın.

• Secret Manager ve Gizli Veri Yaşam Döngüsü

  • Kimlik bilgilerini, token’ları ve API anahtarlarını sürümlenmiş gizli veriler (secrets) olarak saklayın; asla imajlarda, Git’te veya instance metadata’da saklamayın. Çalışma zamanı hizmet hesabına (runtime service account) gizli veri veya proje düzeyinde IAM izni verin.
  • Rotasyon: Yeni bir sürüm oluşturmak, bağımlılıkları güncellemek ve eski sürümleri iptal etmek için Pub/Sub ile tetiklenen Cloud Functions/Cloud Run kullanarak otomatikleştirin. Uzun ömürlü veritabanı parolalarını, IAM tabanlı veritabanı kimlik doğrulaması veya kısa ömürlü token’lar ile değiştirmeyi tercih edin.
  • Yapılandırma güvenliği: Gizli olmayan yapılandırmaları (ConfigMap, ortam değişkenleri) gizli verilerden ayırın. Günlüklerde (log) ve hata mesajlarında gizli verilerin açığa çıkmasını önleyin.

Örnek (yeni gizli veri sürümü ekleme):

• gcloud secrets versions add db-password –data-file=password.txt –secret=db-password

• Compute Güvenliğini Artırma ve Gizli Bilişim (Confidential Computing)

  • Shielded VMs: Bootkit ve rootkit’lere karşı koruma sağlamak için güvenli önyüklemeyi (secure boot), vTPM’i ve bütünlük izlemeyi (integrity monitoring) etkinleştirin. Kuruluş ilkesi (organization policy) aracılığıyla zorunlu kılın ve CI/CD işlem hatlarında (pipelines) doğrulayın.
  • Confidential VMs: Varsayılan olarak bellek şifrelemesi, minimum yapılandırma değişikliğiyle kullanım halindeki verileri (data-in-use) korur; yüksek verim gerektiren, kripto-yoğun iş yükleri için performans etkisini değerlendirin.
  • Güvenliği artırılmış imajlar (Hardened images): Google tarafından optimize edilmiş veya CIS ile güçlendirilmiş temel imajlardan başlayın; yamaları OS Config ile yönetin ve gereksiz paketleri ve portları devre dışı bırakın.

Ağ ve Uç Nokta Güvenliği

• Ağ segmentasyonu ve dışarı giden trafik (egress) kontrolü

  • Ayrı VPC’ler, alt ağlar (subnets) ve hiyerarşik güvenlik duvarı politikaları kullanarak katmana ve hassasiyete göre segmentlere ayırın. Doğu-batı (east-west) kontrollerini uygulamak için kimlik tabanlı güvenlik duvarı etiketlerini (firewall tags) hizmetten hizmete kısıtlamalarla (örneğin, GKE NetworkPolicy) birleştirin.
  • Veri sızıntısını (data exfiltration) en aza indirmek için dışarı giden trafiği Cloud NAT, DNS politikaları ve kısıtlanmış Private Google Access ile kontrol edin. Gerekli durumlarda, dışarı giden trafik için açık izin listeleri (egress allowlists) ve proxy denetimi kullanın.

• VPC Service Controls (VPC SC)

  • Kapsam dahilindeki verileri barındıran projelerin etrafında hizmet perimetreleri (service perimeters) oluşturarak Google tarafından yönetilen API’lerden (GCS, BigQuery, Secret Manager, Pub/Sub, vb.) veri sızıntısını azaltın.
  • Erişim seviyeleri (Access levels): Perimetre içindeki hizmetlere erişmek için karşılanması gereken bağlam koşullarını (kullanıcı kimliği, IP aralıkları, cihaz durumu) tanımlayın.
  • Kontrollü çoklu perimetre iş akışları için perimetre köprüleri (perimeter bridges) ve hedefleri kısıtlamak için dışarı giden trafik kuralları (egress rules) kullanın. İşlem hatlarını (pipelines) bozmamak için deneme modunda (dry-run mode) test edin.
  • Sınırlamalar: Compute Engine IP’lerine giden trafiği doğrudan korumaz; güvenlik duvarı ve dışarı giden trafik kontrolleriyle tamamlayın. Bazı araçlar ve hibrit mimariler, perimetreye duyarlı hizmet hesapları (perimeter-aware service accounts) ve kısıtlanmış VIP’lere Private Service Connect bağlantısı gerektirebilir.

• Uç Nokta ve Uygulama Koruması

  • Cloud Armor: Global harici yük dengeleyicinin (load balancer) arkasındaki HTTP(S) uygulamalarını L3/L4/L7 DDoS azaltma, IP izin/reddetme listeleri, coğrafi tabanlı kontroller ve hız sınırlama (rate limiting) ile koruyun.
  • WAF kuralları: OWASP Top 10 için önceden yapılandırılmış yönetilen kuralları ve özel imzaları uygulayın; yanlış pozitifleri (false positives) azaltmak için ince ayar yapın. API sürümüne veya uygulama bileşenine göre politikaları özelleştirmek için her bir arka uç hizmetine (backend service) ekleyin.
  • API koruması: Kimlik doğrulama, kota, şema doğrulama ve tehdit tespiti için API’leri API Gateway veya Apigee ile ön yüzeylendirin; uç nokta zorlaması için Cloud Armor’ı entegre edin; uygun yerlerde reCAPTCHA Enterprise ve bot kontrollerini değerlendirin.
  • Dezavantajlar: Daha derinlemesine denetim, gecikme ve operasyonel gürültü ekleyebilir. Kuralları önizleme modunda (preview mode) aşamalandırın, günlükleri izleyin ve kademeli olarak uygulayın.

Güvenlik Operasyonları, İzleme ve Uyumluluk

• Security Command Center (SCC) ve tehdit tespiti

  • SCC, projeler ve kuruluşlar genelindeki varlık envanterini ve bulguları bir araya getirir. Güvenlik duruşunun temelini oluşturmak (herkese açık bucket’lar, açık güvenlik duvarı kuralları), sapmaları izlemek ve düzeltme iş akışlarını yönlendirmek için kullanın.
  • Premium tehdit tespiti, kötü amaçlı yazılımları, kripto madenciliğini ve anormal davranışları belirlemek için Event Threat Detection, VM Threat Detection ve Container Threat Detection’ı içerir.
  • Bulguları biletleme ve SOAR işlem hatlarıyla entegre edin; uyarı yorgunluğunu önlemek için son kullanma tarihli bastırma/istisna politikaları tanımlayın.

• Güvenlik açığı ve artifact güvenliği

  • Container imajlarını CVE’ler için taramak amacıyla Artifact Analysis’i kullanın; CI’dan gelen imzalı onaylarla (attestation) Binary Authorization kullanarak dağıtım zamanı politikalarını zorunlu kılın.
  • OS Config aracılığıyla yama yönetimi; riske maruz kalma pencerelerini izleyin ve canary dağıtımlarıyla güncellemeleri otomatikleştirin.

• Denetim günlükleri, gizlilik ve kanıt

  • Cloud Audit Logs, varsayılan olarak Yönetici Etkinliği (Admin Activity) ve Sistem Olayı (System Event) günlüklerini sağlar; Veri Erişimi (Data Access) günlükleri hizmet başına etkinleştirilebilir ve ücretlidir. Analiz için günlükleri BigQuery’ye, değiştirilemez saklama ve yasal bekletme (legal hold) için ise Cloud Storage’a yönlendirin.
  • Veri sınıflandırma: PII’ı (Kişisel Tanımlanabilir Bilgiler) keşfetmek ve sınıflandırmak, etiketler uygulamak ve koruma seviyeleriyle (CMEK, VPC SC, Confidential VMs) eşleştirmek için Cloud DLP’yi kullanın.
  • Gizlilik ve veri yerleşimi: Kuruluş politikası aracılığıyla konumları kısıtlayın; CMEK ve depolama konumlarını yasal gerekliliklerle uyumlu hale getirin.
  • Yasal bekletmeler ve saklama: Bucket saklama politikalarını ve bekletmelerini etkinleştirin; gerektiğinde Nesne Sürümlemeyi (Object Versioning) kullanın. Savunulabilir kanıtlar üretmek için adli imajlar ve günlükler için gözetim zincirini (chain of custody) belgeleyin.

• Olay müdahalesi ve adli bilişime hazırlık

  • Runbook’lar, erişim yolları ve otomasyon hazırlayın. Müdahale ekiplerinin en az ayrıcalıklı erişime sahip olduğundan ve denetimin kuruluş, klasörler ve projeler genelinde etkinleştirildiğinden emin olun.
  • Sınırlama: Örnekleri (instance) yük dengeleyicilerden kaldırarak, çıkış trafiğini (egress) engelleyen güvenlik duvarı kuralları uygulayarak veya projeleri daha sıkı kuruluş politikalarına sahip bir ortama taşıyarak izole edin; güvenliği ihlal edilmiş hizmet hesaplarını devre dışı bırakın ve gizli bilgileri (secret) ve anahtarları değiştirin (rotate).
  • Adli Bilişim: Çevrimdışı analiz için disklerin anlık görüntülerini (snapshot) alın ve imajları dışa aktarın; dışa aktarımlar yoluyla günlükleri koruyun. Uygulanabilir olduğunda paket yansıtmayı (packet mirroring) kullanın. Kanıtları değiştirmekten kaçının; kopyalar üzerinde çalışın.
  • Kurtarma: Güvenilir imajlardan yeniden oluşturun, gizli bilgileri (secret) yeniden yükleyin ve duman (smoke) ve güvenlik testleriyle doğrulayın. Olay sonrası incelemeler yapın ve çıkarılan dersleri koruma mekanizmalarına (guardrails) ve tespit sistemlerine dahil edin.

Pratik Problem Senaryosu

Bir fintech SaaS şirketi olan NimbusPay, Google Cloud üzerindeki çok kiracılı (multi-tenant) mikroservislerde PCI etiketli verileri işlemeli, AB’de veri yerleşimini zorunlu kılmalı, API katmanı saldırılarına karşı koruma sağlamalı ve kontrollerin denetlenebilir kanıtlarını üretmelidir. Şirket, aynı ana bilgisayar adı (hostname) altında v1’i canlı tutarken yeni bir v2 API’sini kullanıma sunacaktır.

Yaklaşım:

1. Projeleri ve kimlikleri bölümlendirin

• Her ortam ve mikroservis katmanı (veri alımı, işleme, raporlama) için ayrı projeler oluşturun. Her hizmete benzersiz bir iş yükü hizmet hesabı (workload service account) atayın. Gerekçe: patlama yarıçapını (blast radius) izole eder ve en az ayrıcalık ilkesini ayrık iş yükleriyle eşleştirir.

2. Sıfır Güven (Zero Trust) ve en az ayrıcalık ilkesini uygulayın

• Hizmet hesaplarına ve DevOps gruplarına önceden tanımlanmış/özel roller atayın; üretim erişimini kurumsal IP’ler ve çalışma saatleriyle kısıtlamak için koşullu IAM uygulayın. Gerekçe: yanal hareketi (lateral movement) ve kazara yapılan değişiklikleri azaltır.

3. Statik hizmet hesabı anahtarlarını kaldırın

• Kuruluş politikası aracılığıyla kullanıcı tarafından yönetilen SA anahtarlarını devre dışı bırakın. CI/CD ve operasyonlar için Hizmet Hesabı Kimliğine Bürünme’yi (Service Account Impersonation) kullanın; kiracı başına GCS yollarını sınırlayan Erişim Sınırları (Access Boundaries) uygulayın. Gerekçe: sık karşılaşılan bir kimlik bilgisi sızıntı vektörünü ortadan kaldırır ve token’lar çalınsa bile veri erişimini kısıtlar.

4. Verileri CMEK ve bölgesel kontrollerle koruyun

• europe-west bölgelerinde Cloud KMS anahtar halkaları (keyring) ve anahtarları oluşturun; BigQuery veri kümeleri, GCS bucket’ları ve Persistent Disk’ler için CMEK’i etkinleştirin. Zamanlanmış rotasyon ve sürüm izlemeyi yapılandırın. Gerekçe: AB yerleşimi ve PCI ile uyumlu, kanıtlanabilir kriptografik kontrol.

5. Kart verileri için uygulama katmanı şifrelemesini benimseyin

• CMEK ile sarmalanmış kiracı başına veri anahtarlarıyla zarf şifrelemesini (Tink AEAD) kullanın; veritabanlarında yalnızca şifreli metni (ciphertext) saklayın. Gerekçe: alan düzeyinde koruma ve olay triyajı sırasında kapsamın en aza indirilmesi.

6. Gizli bilgileri (secret) merkezileştirin ve otomatik olarak değiştirin (rotate)

• Veritabanı kimlik bilgilerini ve API token’larını, hizmet başına IAM ile Secret Manager’da saklayın. Yeni sürümler oluşturan ve dağıtımları güncelleyen Pub/Sub tetiklemeli rotasyon işleri uygulayın. Mümkün olan yerlerde, Cloud SQL için IAM DB kimlik doğrulamasına geçin. Gerekçe: minimum kesinti ile denetlenebilir gizli bilgi yaşam döngüsü.

7. Ağları segmentlere ayırın ve çıkış trafiğini (egress) kontrol edin

• Web→API→DB akışlarını zorunlu kılmak için hiyerarşik güvenlik duvarı politikalarını kullanın; web→DB doğrudan erişimini engelleyin. Google API’leri için çıkış (egress) izin listeleri ve Özel Google Erişimi (kısıtlı) ile Cloud NAT’ı etkinleştirin. Gerekçe: doğu-batı (east-west) hareketini kısıtlar ve onaylanmamış veri sızdırmayı engeller.

8. Veri hizmetlerini VPC Service Controls ile çevreleyin

• BigQuery, GCS ve Secret Manager projelerini bir hizmet perimetresine yerleştirin; kurumsal IP ve yönetilen cihazlar gerektiren erişim seviyeleri tanımlayın. Kuru çalıştırma (dry-run) ile test edin, ardından zorunlu kılın. Gerekçe: çalınan token’lar veya yanlış yapılandırılmış istemciler yoluyla veri sızdırılmasını azaltır.

9. Uç noktayı (edge) ve API’leri güvence altına alın

• Global HTTPS yük dengeleyiciyi Cloud Armor yönetilen kuralları ve hız sınırlaması (rate limiting) ile ön cepheye yerleştirin. /v1 ve /v2’yi ayrı arka uç hizmetlerine ayırmak için yol tabanlı yönlendirme kullanın ve sürüm başına özel WAF politikaları uygulayın. Kimlik doğrulama, kotalar ve şema doğrulaması için Apigee’yi entegre edin. Gerekçe: katmanlı API koruması, sorunsuz v1→v2 geçişi ve yanlış pozitiflerin (false positive) en aza indirilmesi.

10. İşlem (compute) kaynaklarını güçlendirin ve artifact’leri onaylayın

• İşleme düğümleri için Shielded VM’leri ve Confidential VM’leri etkinleştirin; CIS ile güçlendirilmiş temel imajları benimseyin. Artifact Registry’deki imajları tarayın, GKE için Binary Authorization ile imzalı onaylar (attestation) gerektirin. Gerekçe: önyükleme zincirini (boot chain) ve kullanım halindeki verileri (data-in-use) korur ve tedarik zinciri güvenini zorunlu kılar.

11. SCC ile güvenlik duruşunu ve tehditleri izleyin

• Riskli yapılandırmaları ve çalışma zamanı tehditlerini tespit etmek için SCC Premium’u etkinleştirin; SLA’lar için biletleme sistemiyle entegre edin. Kabul edilen riskleri son kullanma tarihleriyle bastırın. Gerekçe: sürekli güvence ve eyleme geçirilebilir sinyal.

12. Günlükleri tutun, saklayın ve kanıt üretin

• Yönetici Etkinliği (Admin Activity), Veri Erişimi (Data Access) ve VPC Akış Günlüklerini (VPC Flow Logs) saklama politikaları ve yasal bekletmelerle BigQuery ve Cloud Storage’a yönlendirin. Veri kümelerini yerleşim ve hassasiyet etiketleriyle etiketleyin. Gerekçe: kapsamı belirlenmiş erişimle soruşturmaları ve dış denetimleri destekler.

13. Olay müdahalesi ve adli bilişim için hazırlık yapın

• Güvenliği ihlal edilmiş hizmetleri, projeleri daha sıkı politikalara sahip bir karantina klasörüne taşıyarak, ilgili SA’ları devre dışı bırakarak ve çevrimdışı analiz için disklerin anlık görüntülerini alarak izole etmek için runbook’lar oluşturun. Gerekçe: korunmuş kanıtlarla hızlı sınırlama.

Dağıtımı destekleyen kısa komutlar:

undefined

undefined

undefined

Bu adımlarla NimbusPay, katmanlı koruma (kimlik, kripto, ağ ve uç nokta), doğrulanabilir uyumluluk, tek bir ana bilgisayar adı altında kontrollü API evrimi ve olayları tespit etme, sınırlama ve kurtarma hazırlığı elde eder.

← Ağ · Tüm alanlar · Güvenilirlik →

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

Google'a göz atın →