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

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Şunun bir parçası: Google Associate Cloud Engineer — Ç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 modeline ve varsayılan olarak güvenli, derinlemesine savunma yaklaşımına dayanır. Google fiziksel altyapıyı, temel hizmetleri ve varsayılan şifrelemeyi güvence altına alırken; siz kimlik ve erişim, veri sınıflandırma ve saklama, uygulama yapılandırmaları ve operasyonel süreçleri güvence altına alırsınız. Kaynak hiyerarşisi boyunca en az ayrıcalık ilkesine göre tasarım yapın, bireyler yerine grupları kullanın, yönetilen kimlikleri ve kısa ömürlü kimlik bilgilerini tercih edin ve herhangi bir kontrolün başarısızlığının bir güvenlik ihlaline yol açmaması için kontrolleri katmanlandırın. Durumun sürekli olarak ölçülebilmesi ve iyileştirilebilmesi için en başından itibaren gözlemlenebilirlik ve müdahale iş akışları oluşturun.

Kimlik ve Erişim Temelleri

Paylaşılan sorumluluk ve en az ayrıcalık
- Projeleri, güven sınırlarını yansıtan klasörlerle tek bir organizasyon altında düzenleyin. Güvenli varsayılanları zorunlu kılmak için Organization Policy kısıtlamaları uygulayın (örneğin, genel IP’lere izin vermeme, konumları kısıtlama, hizmet hesabı anahtarı oluşturmayı engelleme).
- IAM rollerini kullanıcılara değil, Google Groups’a atayın ve temel roller yerine önceden tanımlanmış rolleri tercih edin. Rol atamalarını düzenli olarak gözden geçirin ve kullanılmayan yetkileri kaldırın.
- Denetlenebilirliği ve ilişkilendirmeyi etkinleştirin. VM’lere yönetici işletim sistemi erişimi için, kullanıcı başına SSH anahtarlarıyla OS Login kullanın; gruplara roles/compute.osLogin veya roles/compute.osAdminLogin rollerini atayın. Örnek:
  - gcloud compute project-info add-metadata –metadata enable-oslogin=TRUE
  - gcloud projects add-iam-policy-binding PROJECT_ID –member=‘group:ops@example.com’ –role=‘roles/compute.osAdminLogin’
- Yaygın hata modları: kullanıcılara sahip (owner) veya düzenleyici (editor) rolleri vermek, proje genelinde SSH anahtarları kullanmak ve uzun ömürlü hizmet hesabı anahtarları oluşturmak.
BeyondCorp ve Identity-Aware Proxy (IAP) ile uygulama erişim koruması
- IAP, HTTPS uygulamaları ve TCP yönlendirme (SSH/RDP) için kimlik duyarlı erişimi Google’ın uç noktasında sonlandırarak uygulamaları veya bastion sunucularını internete açma ihtiyacını ortadan kaldırır. Cihaz durumu, IP aralıkları veya kullanıcı grupları gibi gereksinimler eklemek için bağlam duyarlı erişim politikaları (Access Context Manager) ile birlikte kullanın.
- Faydaları: merkezi kimlik doğrulama/yetkilendirme (authN/Z), güçlü ilişkilendirme, azaltılmış saldırı yüzeyi ve basitleştirilmiş güvenlik duvarı politikası (load balancer/IAP hariç gelen trafiği reddetme).
- Dezavantajları: yanlış yapılandırma yöneticileri dışarıda bırakabilir; acil durum erişim yolu bulundurun (kısıtlanmış proje sahibi, bant dışı konsol erişimi). Bazı eski protokoller veya HTTP olmayan hizmetler, IAP TCP yönlendirmesi veya alternatif kontroller gerektirebilir.
Hizmet hesapları ve iş yükü kimliği
- İş yüklerinin kısa ömürlü jetonları otomatik olarak alabilmesi için hizmet hesaplarını Compute Engine, Workload Identity ile GKE, Cloud Run ve Cloud Functions’a eklemeyi tercih edin. Anahtarları gömmekten kaçının; org policy ile hizmet hesabı anahtarı oluşturmayı devre dışı bırakın. Hizmet hesaplarındaki IAM kapsamını dar tutun (en az ayrıcalık ilkesi).
- Hata modları: kimliğe bürünmeye (impersonation) olanak tanıyan roles/iam.serviceAccountUser rolünü geniş bir kapsama atamak; yatay hareket (lateral movement) hedefi haline gelen aşırı ayrıcalıklı hizmet hesapları.

Veri Koruma ve Anahtar Yönetimi

Şifreleme, Cloud KMS, CMEK ve zarf şifrelemesi
- Google, bekleyen (at rest) ve aktarılan (in transit) tüm verileri varsayılan olarak şifreler. Ek kontrol ve görev ayrılığı için Cloud KMS’te Müşteri Tarafından Yönetilen Şifreleme Anahtarlarını (CMEK) kullanın. Birçok hizmet (BigQuery, Cloud Storage, Pub/Sub, Compute Engine diskleri) CMEK’i destekler; hizmetler, CMEK’inizin nesne başına veya yığın başına DEK’leri (Veri Şifreleme Anahtarları) sardığı zarf şifrelemesini (envelope encryption) kullanır.
- Anahtar hiyerarşisini planlayın: bölge başına anahtar halkaları (key rings), veri alanı başına şifreleme anahtarları (crypto keys) ve riske bağlı olarak her 90-365 günde bir rotasyon. Örnek rotasyon:
  - gcloud kms keys update KEY_NAME –keyring=KR –location=REGION –rotation-period=90d –next-rotation-time=YYYY-MM-DDT00:00:00Z
- Erişim kontrolü: hizmet hesaplarına Cloud KMS CryptoKey Encrypter/Decrypter rolünü yalnızca gerekli anahtarlar üzerinde verin. Cloud KMS kullanım günlükleri ile izleyin.
- Hata modları ve dezavantajları: bir CMEK’i devre dışı bırakmak veya silmek, bağımlı verileri okunamaz hale getirir; olay müdahale planları (runbook) hazırlayın, rotasyondan önce IAM’i iki kez kontrol edin ve dağıtımlar arasında anahtar kullanılabilirliğini sağlayın. Anahtarları Google Cloud dışında tutmanız gerekiyorsa External Key Manager’ı değerlendirin; ek gecikmeyi ve harici bağımlılık riskini hesaba katın.
Secret Manager ve kodda gömülü kimlik bilgilerini ortadan kaldırma
- API anahtarlarını, veritabanı parolalarını ve jetonları, otomatik sürüm oluşturma ve IAM tabanlı erişim ile Secret Manager’da saklayın. Rotasyonu, kaynak sistemi güncelleyen ve yeni bir gizli anahtar sürümü yazan Cloud Scheduler → Pub/Sub → Cloud Functions/Run aracılığıyla entegre edin. Uygulamalar, gizli anahtarları başlangıçta veya talep üzerine alır ve minimum düzeyde önbelleğe alır.
- En iyi uygulamalar: gizli anahtarları asla koda veya imajlara dahil etmeyin (commit); gizli anahtarları günlüklere yazdırmaktan kaçının; iş yükü kimliklerine roles/secretmanager.secretAccessor rolünü atayın; hassasiyeti etiketlemek için etiketleri (labels) kullanın.
- Hata modları: çökme durumlarında günlüğe kaydedilen ortam değişkenlerine gizli anahtarları gömmek; rotasyondan sonra bağımlı uygulamaları güncellemeyi unutmak; gizli anahtarlar üzerinde geniş kapsamlı IAM.
Veri sınıflandırma, saklama ve gizlilik
- Verileri sınıflandırın (herkese açık, dahili, gizli, düzenlemeye tabi) ve varlıkları etiketlerle (labels) etiketleyin. Ayrıntılı kontrol için BigQuery sütun düzeyinde güvenlik ve satır erişim politikalarını kullanın. Keşif ve maskeleme için Sensitive Data Protection (DLP) kullanın.
- Saklama politikalarını uygulayın: Cloud Storage Nesne Yaşam Döngüsü (yaşa dayalı sınıf geçişleri, silme), bekletme (hold) özellikli bucket saklama politikaları ve BigQuery tablo veya bölüm TTL’leri. Saklama süresini yasal gereksinimlerle uyumlu hale getirin; daha uzun saklama süresi riski ve maliyeti artırır.
- Gizlilik ve yerleşiklik: org politikalarıyla kaynak konumlarını kısıtlayın; egemenlik ve gecikme gereksinimlerine göre çok bölgeli (multi-regional) ve bölgesel (regional) depolama arasında seçim yapın. Denetim günlükleri ve SCC durum panoları ile kanıt oluşturun.

Ağ ve Uç Nokta Güvenliği

Ağlar için derinlemesine savunma
- Varsayılan olarak reddetme (deny) tutumuyla VPC güvenlik duvarı kurallarını kullanın; yalnızca gerekli kaynak aralıklarına ve bağlantı noktalarına izin verin. API trafiğini genel internetten uzak tutmak için Private Google Access ve Private Service Connect’i tercih edin. VPC Flow Logs ve Firewall Rules Logging’i etkinleştirin; giden (egress) trafik modellerini düzenli olarak gözden geçirin.
- Giden trafik kontrolü için, tüm giden trafiği (egress) reddedin, ardından FQDN giden proxy veya NAT artı proxy aracılığıyla gerekli hedeflere açıkça izin verin. Cloud NAT günlüklerini izleyin ve DNS günlük kaydını yapılandırın.
VPC Service Controls (VPC SC), hizmet perimetreleri ve erişim seviyeleri
- Kimlik bilgileri ele geçirilse bile veri sızdırma risklerini azaltmak için desteklenen Google API’lerini (örneğin, BigQuery, Storage, Pub/Sub) hizmet perimetreleri içine alın. Kullanıcı grubuna, IP’ye veya cihaz duruşuna göre erişim seviyeleri tanımlamak için Access Context Manager’ı kullanarak bağlama duyarlı politikaları etkinleştirin.
- Gerektiğinde meşru perimetreler arası entegrasyonlar ve perimetre köprüleri için giden (egress) kuralları yapılandırın. Zorunlu kılmadan önce olası kesintileri ortaya çıkarmak için VPC SC deneme (dry-run) modunda test edin.
- Hata modları: CI/CD veya projeler arası işlerin istemeden engellenmesi, üçüncü taraf entegrasyonlarının başarısız olması veya geliştiricilerin yönetilmeyen cihazlarla sistemi atlatması. İstisnaları belgeleyin ve düzenli olarak gözden geçirin.
Cloud Armor, DDoS koruması ve WAF kuralları
- Google’ın küresel uç (edge) altyapısı, her zaman açık L3/L4 DDoS koruması sağlar. Cloud Armor, harici HTTP(S) yük dengeleyiciler için hız sınırlama, coğrafi/IP tabanlı erişim, özel ifadeler ve önceden yapılandırılmış WAF kural setleri dahil olmak üzere L7 korumaları ekler.
- Temel bir WAF oluşturma ve ekleme örneği:

undefined

- Politikayı HTTPS yük dengeleyicinizin arka uç (backend) hizmetine ekleyin.

En iyi uygulamalar: yanlış pozitifleri azaltmak için kuralları önizleme (preview) modunda başlatın, bilinen iyi trafik için izin verme kuralları ekleyin ve uygunsa uyarlanabilir korumayı (adaptive protection) etkinleştirin. Dezavantajları: Cloud Armor, HTTP(S) ve proxy tabanlı yük dengeleyicilerde uygulanır; ağ yük dengeleyicileri ve dahili LB’ler başka kontroller gerektirir.

← İzleme · Tüm alanlar · Güvenilirlik →

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