Google ACE: Kaynak Hiyerarşisi, IAM ve Faturalandırma Yönetimi — Ç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ış

Kaynak hiyerarşisi, kimlik ve erişim yönetimi (IAM) ve faturalandırma yönetimi, Google Cloud operasyonlarının kontrol düzlemini oluşturur. Dayanıklı bir tasarım, politika ve sorumluluk kapsamını belirlemek için net bir hiyerarşi (kuruluş, klasörler, projeler) ile başlar; grup merkezli yönetim ve iş yükleri için kısa ömürlü kimlik bilgileri ile en az ayrıcalık ilkesini (least-privilege) uygular; maliyet ilişkilendirmesi için bütçeler, dışa aktarımlar ve etiketler kullanır; ve kuruluş politikaları ve kapsamlı denetim günlüğü kaydı ile yönetişimi zorunlu kılar. Operasyonel mükemmellik, kalıtımı standartlaştırmaktan, faturalandırmayı ve günlükleri merkezileştirmekten ve uzun ömürlü anahtarlar yerine hizmet hesabı kimliğine bürünmeyi (impersonation) kullanmaktan gelir. Bu bölüm, temel yapıları, amaçlanan kullanımlarını ve kaçınılması gereken yaygın hata modlarını detaylandırmaktadır.

Kaynak Hiyerarşisi ve Kimlik Modeli

• Kaynak hiyerarşisi

  • Kuruluş (Organization): Kök düğüm, Cloud Identity veya Google Workspace ile oluşturulur. Global politikalara (IAM, kuruluş politikaları, etiketler) sahiptir.
  • Klasörler (Folders): Departmanlar, ortamlar (ör. dev, prod) veya uygulamalar için isteğe bağlı gruplama. Yetki devri ve politika kapsamlandırması için kullanışlıdır.
  • Projeler (Projects): Kaynaklar, API’ler, kotalar, IAM ve faturalandırma ilişkisi için idari sınırdır. Çoğu Google Cloud kaynağı projelerin alt öğesidir.
  • Kalıtım (Inheritance): IAM politikaları ve kuruluş politikaları yukarıdan aşağıya doğru kalıtılır. Daha üst seviyelerdeki reddetme (deny) ve kısıtlamalar önceliklidir. İstisnaları ve acil durum (break-glass) ihtiyaçlarını en aza indirmek için yerleşimi (kuruluş → klasörler → projeler) planlayın.

• Kimlikler (Principals)

  • Google hesapları (kullanıcılar), Google grupları, hizmet hesapları ve Workload Identity Federation aracılığıyla harici kimlikler.
  • Yaşam döngüsü değişikliklerini ve gözden geçirmeleri basitleştirmek için insan erişiminde birincil bağlama hedefi Google grupları olmalıdır.
  • Hizmet hesapları, uygulamaları veya servisleri temsil eder; anahtarlar yerine iş yükü kimliğini (workload identity) tercih edin.

• İş yükü kimlikleri (Workload identities)

  • Google Cloud içinde: GCE/GAE/Cloud Run/GKE, bağlı hizmet hesabı için kısa ömürlü token’lar oluşturmak üzere metadata sunucusunu kullanır.
  • Google Cloud dışında: Workload Identity Federation, harici kimlikleri (OIDC/SAML/AWS) statik anahtarlar olmadan hizmet hesaplarıyla eşleştirir.

• Tasarım ödünleşimleri ve hata modları

  • Klasör yapısı olmayan dağınık projeler, politika tekrarına ve sapmasına neden olur.
  • Rolleri doğrudan kullanıcılara atamak operasyonel yükü artırır; grup tabanlı bağlamaları tercih edin.
  • Geniş izinlere sahip Compute Engine varsayılan hizmet hesabını kullanmak riski artırır; her iş yükü için en az ayrıcalıklı hizmet hesapları oluşturun.
  • Bir projeyi yanlış klasör altına yerleştirmek, yanlış politikaların kalıtılmasına neden olur; etiketleri kullanın veya projeleri değişiklik kontrolü ile dikkatlice taşıyın.

IAM Rolleri ve Politika Tasarımı

• Rol türleri

  • Temel roller (Basic roles - Viewer, Editor, Owner): Geniş kapsamlı, eski rollerdir. Sıkı kontrol edilen acil durum (break-glass) senaryoları dışında kaçının.
  • Önceden tanımlanmış roller (Predefined roles): Her servis için özel olarak hazırlanmıştır; çoğu kullanım durumu için bunları tercih edin.
  • Özel roller (Custom roles): Özel ihtiyaçlar için kuruluş veya proje kapsamında izinlerin bir araya getirilmesidir.
  • Koşullu roller (Conditional roles): IAM Koşulları (CEL), kaynak adı, klasör, etiketler veya zaman gibi bağlamlar ekler; güçlü rolleri kısıtlamak için kullanın.

• Politika ilkeleri

  • En az ayrıcalık ilkesi (Least privilege): Yalnızca en dar kapsamda (kaynak/proje/klasör) minimum rolü atayın.
  • Görevlerin ayrılığı (Separation of duties): Görevleri ayırın (ör. ağ yöneticisi, güvenlik yöneticisi, faturalandırma yöneticisi). Dağıtım (deploy) ve onaylama eylemlerini tek bir kimlikte birleştirmeyin.
  • Kalıtım farkındalığı: Kuruluş/klasör seviyesindeki bir bağlama, tüm alt öğeleri etkiler; uygulamadan önce hedeflenen etki alanını (blast radius) belgeleyin.

• Reddetme politikaları (Deny policies)

  • IAM Deny, başka bir yerde verilmiş olsa bile izinleri açıkça engeller; koruma sağlamak (guardrails) için kullanın (ör. iam.serviceAccountKeys.create iznini reddetme).
  • Reddetme (Deny) önceliklidir; zaman sınırlı istisna süreçleriyle belgelenmiş bir acil durum (break-glass) prosedürü olduğundan emin olun.

• Örnekler

  • Özel bir rolü dev ortamından prod ortamına kopyalama:

undefined

• OS Login ile grup tabanlı SSH yönetici izni verme:

undefined

• Hata modları
  • Kuruluş veya klasör seviyesinde verilen Editor rolü, istemeden tüm projelere yayılır.
  • Aşırı katı koşullara sahip koşullu roller, otomasyonları sessizce bozabilir; dağıtımdan önce Policy Troubleshooter ile test edin.
  • Özel roller yeni izinler konusunda geri kalabilir; periyodik olarak gözden geçirin.

Faturalandırma ve Maliyet Yönetimi

• Faturalandırma hesapları ve ilişkilendirme

  • Ücretli hizmetler için bir proje tam olarak bir faturalandırma hesabına bağlı olmalıdır.
  • Roller: Billing Account Administrator hesabı ve ödeme yöntemlerini yönetir; Billing Account User projeleri bağlar; Project Billing Manager bir projenin faturalandırma bağlantısını yönetir.
  • Kurumsal bir faturalandırma hesabında merkezileştirin; projelerin faturalandırma ilişkisini güncelleyerek projeleri taşıyın.

• Bütçeler, uyarılar ve ilişkilendirme

  • Bütçeler harcama limitleri değil, uyarılar oluşturur. Eğer zorunlu bir uygulama gerekiyorsa, Pub/Sub ve Cloud Functions/Cloud Run ile programatik düzeltme kullanın.
  • Günlük/aylık maliyet analizi ve tahmini için faturalandırma verilerini BigQuery’ye aktarın; maliyet ilişkilendirmesi için kaynak etiketleri (labels) ve etiketler (tags) ile birleştirin.
  • Etiketler (Labels ve tags): Anahtarları standartlaştırın (ör. cost_center, env, app). Eksik etiketler, ilişkilendirme doğruluğunu azaltır.

• Maliyet analizi

  • SKU/servis bazında değişken tahminler hesaplamak için SQL ile BigQuery dışa aktarımını kullanın. Ayrıntılı raporlama için kaynak meta verileriyle (ör. GCE etiketleri) birleştirin.
  • Çoklu proje analizi için, tüm proje dışa aktarımlarını birleştirin veya tek bir merkezi veri setine aktarın.

• Yaygın tuzaklar

  • Yeni projeler için bütçelerin yapılandırılmaması; proje oluşturulduğunda otomatik olarak bütçe oluşturmak için bir politika belirleyin.
  • BigQuery dışa aktarımının olmaması, sınırlı geçmişe dönük içgörü anlamına gelir; geçmiş veriyi oluşturmak için erken etkinleştirin.
  • Projelerde kişisel kredi kartlarının kullanılması sorumluluğu parçalar; uygun IAM ve ödeme profilleriyle kurumsal faturalandırma hesabı altında birleştirin.
  • Paylaşılan hizmet projelerindeki maliyet anomalileri, etiketleme ve çapraz faturalandırma (cross-charging) politikası gerektirir.

Güvenli İş Yükü Kimlik Doğrulama ve Erişim Modelleri

• Hizmet hesabı kimliğine bürünme (impersonation)
  • Anahtarlar yerine kimliğe bürünmeyi tercih edin. Bir çağrı kimliğine (caller identity) roles/iam.serviceAccountTokenCreator rolünü atayın; bu kimlik, hizmet hesabı gibi davranmak için kısa ömürlü jetonlar (token) alır.
  • Örnek:

undefined

• Anahtarlar ve rotasyon
  • Kullanıcı tarafından yönetilen anahtarlardan kaçının. Gerekliyse Secret Manager‘da saklayın, en az 90 günde bir rote edin, kullanımı izleyin ve VPC Service Controls ile CMEK kullanarak kısıtlayın.
  • Anahtar oluşturmayı engellemek için kısıtlamaları (constraints) zorunlu kılın:

undefined

• OS Login ve SSH

  • Grup tabanlı IAM rolleri (compute.osLogin, compute.osAdminLogin) ile OS Login kullanın. Her kullanıcı, kimin sorumlu olduğunun izlenebildiği (attributable) erişim için genel SSH anahtarını kendi Google hesabına yükler. Denetimi Yönetici Etkinliği (Admin Activity) ve Veri Erişimi (Data Access) logları aracılığıyla yapın.
  • Paylaşılan SSH anahtarlarını imajların içine gömmekten (baking) kaçının.

• Workload Identity Federation

  • Şirket içi (on-prem) veya diğer bulut ortamları için, anahtar oluşturmadan Google Cloud’a erişim sağlamak üzere kimlik federasyonunu (identity federation) yapılandırın. Bu, veri sızdırma (exfiltration) riskini azaltır.

• Hata modları ve azaltma yöntemleri

  • Anahtarları depolarda (repo) veya CI/CD değişkenlerinde saklamak ele geçirilmeye (compromise) yol açar; kimliğe bürünme (impersonation) veya federasyona geçiş yapın.
  • Geniş rollere sahip varsayılan hizmet hesapları risklidir; constraints/iam.allowedPolicyMemberDomains ile kısıtlayın ve temel (primitive) rolleri kaldırın.
  • Eski GCE örneklerinde (instance) kapsamın (scope) eksik olması API erişimini engelleyebilir; API başına IAM artı varsayılan uygulama kimlik bilgilerini (default application credentials) kullanmayı tercih edin.

Yönetişim, Kuruluş Politikaları, Denetim ve Sorun Giderme

• Kuruluş politikaları ve kısıtlamalar

  • Kısıtlamaları kullanarak koruyucu önlemler uygulayın: VM’lerde harici IP’lere izin vermeme, bölgeleri kısıtlama, anahtar oluşturmayı engelleme, izin verilen hizmetleri kısıtlama, tek tip bucket düzeyinde erişim gerektirme, alan adı paylaşımını kısıtlama.
  • Kaynak hiyerarşisine göre hedefleyin ve ortama özgü istisnalar için etiketlerle hassaslaştırın.

• Cloud Identity ve yaşam döngüsü

  • Cloud Identity, kullanıcı dizinini, SSO’yu ve idari rolleri sağlar. Yetkileri dar bir şekilde (ör. Grup Yöneticisi, Kullanıcı Yönetimi Yöneticisi) devredin ve grup üyeliğini ve erişimi güncellemek için işe başlama-pozisyon değiştirme-işten ayrılma iş akışlarını otomatikleştirin.
  • Hassas ortamlar için Access Approvals ve Access Transparency kullanın.

• Denetim günlük kaydı

  • Yönetici Etkinliği ve Sistem Olayı günlükleri her zaman açıktır; Veri Erişimi günlükleri ise açıkça etkinleştirilmelidir ve maliyete neden olabilir.
  • Klasörlerden/kuruluştan gelen birleştirilmiş havuzları (aggregated sinks) bir güvenlik projesine yönlendirerek merkezileştirin. CMEK ve kısıtlı erişim ile koruyun.
  • Kuruluş politikası çakışmalarını tespit etmek için Politika Reddedildi (Policy Denied) günlüklerini izleyin.

• Çok projeli sorun giderme araç seti

  • Policy Troubleshooter: Etkin IAM ve reddetme politikaları göz önüne alındığında erişime neden izin verildiğini veya reddedildiğini teşhis edin.
  • Cloud Asset Inventory: Kuruluş/klasörler/projeler genelinde IAM bağlamalarını ve politika geçmişini sorgulayın. Örnek: gcloud asset search-all-iam-policies
    –scope=organizations/ORG_ID
    –query=‘policy:roles/storage.objectAdmin AND “bucket-name”’
  • Logs Explorer: Projeler arasındaki eylemleri izlemek için sorumlu (principal), yöntem ve kaynağa göre filtreleyin.
  • Operatör bağlamı değiştirmek için gcloud yapılandırmaları: gcloud config configurations activate PROD
  • Yaygın hata modları: dağıtımları engelleyen çakışan kuruluş politikaları, soruşturmaları zorlaştıran eksik Veri Erişimi günlükleri ve yanlış kapsamda verilen IAM izinleri. Olay çözüm süresini (MTTR) azaltmak için runbook’lar (operasyonel kılavuzlar) ve değişiklik öncesi önizlemeler oluşturun.

Pratik Problem Senaryosu

Aurelia Retail, bir satın almanın ardından birden fazla ekibi ve projeyi birleştiriyor. Faturalandırmayı merkezileştirmeli, yüzlerce Compute Engine VM’sinde tutarlı IAM ve SSH yönetimini uygulamalı ve minimum kesintiyle yönetişim kurmalıdırlar.

1. Kurumsal bir faturalandırma hesabı oluşturun ve projeleri bağlayın

• Gerekçe: Tek bir faturalandırma hesabı, ödeme yöntemlerini, kredileri ve bütçeleri merkezileştirir. Projeleri aşırı yetkilendirme yapmadan yeniden bağlamak için bir proje taşıma grubuna Faturalandırma Hesabı Kullanıcısı (Billing Account User) ve ekip liderlerine Proje Faturalandırma Yöneticisi (Project Billing Manager) rolü verin.
• Eylem: Konsolda faturalandırma hesabını oluşturun. Her proje için faturalandırma ilişkisini güncelleyin. Merkezi bir analiz projesinde Faturalandırma verilerinin BigQuery’ye aktarımını (Billing export) derhal etkinleştirin.

2. Kaynak hiyerarşisini klasörler ve etiketlerle standartlaştırın

• Gerekçe: Projeleri ortam klasörlerinin (prod, nonprod) altına yerleştirmek, koruyucu önlemlerin kalıtımını ve hedeflenmiş istisnaları destekler. Etiketler, klasör ağaçlarını kopyalamadan kuruluş politikalarının hassas bir şekilde hedeflenmesini sağlar.
• Eylem: prod ve nonprod için klasörler oluşturun; projeleri buna göre taşıyın. env=prod|nonprod ve uygulama tanımlayıcıları için etiketler tanımlayın.

3. En az ayrıcalık ve görevler ayrılığı ilkeleriyle grup tabanlı IAM uygulayın

• Gerekçe: Gruplar, yaşam döngüsünü ve denetimi basitleştirir. Rolleri dağıtımcılar, güvenlik ve ağ yöneticileri arasında bölmek, etki alanını (blast radius) azaltır.
• Eylem: app-operators, net-admins, sec-admins ve billing-managers için Google grupları oluşturun. Önceden tanımlanmış rolleri gerektiği gibi klasör/proje kapsamında bağlayın; temel rollerden kaçının.

4. OS Login tabanlı SSH yönetimini zorunlu kılın

• Gerekçe: Kullanıcı hesaplarına eklenmiş bireysel SSH anahtarları, ilişkilendirilebilir ve iptal edilebilir erişim sağlar. OS Login rolleri, paylaşılan anahtarları ortadan kaldırarak Linux hesaplarını IAM aracılığıyla yönetir.
• Eylem: Her projede OS Login meta verilerini etkinleştirin. ops-admins grubuna compute.osAdminLogin rolünü verin. Örnek: gcloud compute project-info add-metadata
  –metadata enable-oslogin=TRUE

5. Hizmet hesabı anahtarlarını kimliğe bürünme (impersonation) ile değiştirin

• Gerekçe: Kısa ömürlü kimlik bilgileri, anahtar sızdırılma riskini azaltır ve rotasyonu basitleştirir. Denetim günlükleri, kimin kimin kimliğine büründüğünü yakalayarak izlenebilirliği artırır.
• Eylem: CI/CD çalıştırıcı kimliklerine, iş yükü hizmet hesapları üzerinde roles/iam.serviceAccountTokenCreator rolünü verin. Kullanıcı tarafından yönetilen anahtarları kaldırın ve yeni anahtarları engellemek için bir kuruluş politikası uygulayın.

6. Koruyucu önlemler için kuruluş politikaları uygulayın

• Gerekçe: Kısıtlamalar, tüm projelerde riskli yapılandırmaları önlerken, gerekçelendirildiği durumlarda etiketlenmiş istisnalara izin verir.
• Eylem: prod ortamında harici IP’lere izin vermemek, bölgeleri onaylanmış konumlarla sınırlamak ve hizmet hesabı anahtarı oluşturmayı devre dışı bırakmak için kısıtlamalar uygulayın. Belgelenmiş onaylara sahip belirli projeler için istisnalara izin vermek üzere etiketleri kullanın.

7. Maliyet yönetişimi kurun

• Gerekçe: Bütçeler, aşırı harcamadan önce sahipleri uyarır; BigQuery’ye aktarım, maliyet ilişkilendirmeyi ve tahminlemeyi sağlar. Etiketler, kaynak harcamalarını maliyet merkezleriyle eşleştirir.
• Eylem: Klasör ve ana uygulama başına Pub/Sub bildirimleriyle bütçeler oluşturun. Dağıtım şablonları ve CI’daki politika doğrulaması aracılığıyla etiket politikalarını zorunlu kılın.

8. Denetimi merkezileştirin ve sorun gidermeyi hızlandırın

• Gerekçe: Kuruluş genelinde birleştirilmiş günlük kaydı ve varlık envanteri, soruşturmaları ve uyumluluk raporlamasını hızlandırır.
• Eylem: CMEK korumalı bucket’lara sahip bir güvenlik projesine birleştirilmiş havuzlar (aggregated sinks) oluşturun. Kritik hizmetler (Cloud Storage, BigQuery) için Veri Erişimi günlüklerini etkinleştirin. IAM bağlamalarını rutin olarak taramak için Cloud Asset Inventory kullanın. Operatörleri, erişim başarısız olduğunda Policy Troubleshooter’ı ve Yönetici Etkinliği/Veri Erişimi’ni izlemek için Logs Explorer’ı kullanmaları konusunda eğitin.

9. Değişikliği önizlemeler ve aşamalı dağıtımla operasyonel hale getirin

• Gerekçe: IAM ve politika etkilerini uygulamadan önce doğrulamak, kesintileri azaltır.
• Eylem: IAM ve kuruluş politikalarını önce nonprod ortamında test edin. Mevcut olduğunda kuru çalıştırmaları (dry-run) ve politika simülasyonunu kullanın. Dağıtım otomasyonu için kanarya dağıtımları (canaries) ve geri alma planları uygulayın.

Bu yaklaşım, merkezileştirilmiş faturalandırma ve maliyet öngörüsü, OS Login aracılığıyla ilişkilendirilebilir SSH yönetimi, kimliğe bürünme (impersonation) ile en az ayrıcalıklı IAM, kuruluş politikaları aracılığıyla güçlü önleyici kontroller ve yeni çok projeli ortamda sağlam denetim ve sorun giderme yetenekleri sağlar.

Tüm alanlar · Compute Engine ve Sanal Makine İşlemleri →

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

Google'a göz atın →