Google PCNE: Güvenlik Duvarı Politikası, Cloud Armor ve Ağ Güvenliği — Çalışma kılavuzu

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Şunun bir parçası: Google Professional Cloud Network 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’daki güvenlik duvarı politikası, Cloud Armor ve ağ güvenliği; segmentasyon, saldırı yüzeyini azaltma, DDoS dayanıklılığı ve gözlemlenebilirlik için katmanlı kontroller sağlar. Etkili tasarımlar; kimlik tabanlı hedeflemeyi, hiyerarşik uygulamayı, en az ayrıcalıklı giriş (ingress) ve çıkış (egress) kurallarını ve Google’ın global yük dengeleyicilerine bağlı uç (edge) korumalarını birleştirir. Operasyonel başarı; kural değerlendirmesini, zımni davranışları, günlük kaydı kapsamını ve farklı yük dengeleme modları için trafiğin gerçekte nereden kaynaklandığını anlamaya bağlıdır.

VPC güvenlik duvarı kuralları ve kimlik tabanlı hedefleme

VPC güvenlik duvarı kuralları durum bilgilidir (stateful) ve ağ, yön ve önceliğe göre değerlendirilir.

Yön ve zımni kurallar:
- Giriş (Ingress), bir sanal makine NIC’ine giren trafiğe göre; çıkış (egress) ise buradan ayrılan trafiğe göre değerlendirilir.
- Her VPC’de iki zımni kural bulunur: zımni tümünü reddet giriş kuralı ve zımni tümüne izin ver çıkış kuralı. Bunlar değiştirilemez ve günlük (log) oluşturmazlar. Varsayılan ağ ayrıca birkaç izin veren kural oluşturur; özel VPC’ler oluşturmaz.
Öncelik ve değerlendirme:
- Öncelikler 0–65535 arasında değişir ve daha düşük olan önce değerlendirilir. Eşleşen ilk kural, eylemi tamamen belirler.
- Aynı önceliğe sahip birden fazla kural eşleşirse, en spesifik IP aralığı kazanır; özgüllük eşit ve eylemler çakışıyorsa, reddetme (deny) kazanır. Aynı öncelikli çakışmalardan kaçının.
Hedefler ve kaynaklar:
- Hedefler, kuralın hangi sanal makinelere uygulanacağını tanımlar: ağ etiketleri, sanal makine hizmet hesapları veya güvenli etiketler. Kaynaklar/hedefler IP CIDR’larıdır; giriş için aynı VPC içindeki kaynaklar için kaynak hizmet hesapları veya etiketleri de belirtebilirsiniz.
- Ağ etiketleri, proje kullanıcıları tarafından ayarlanabilen sanal makine meta verileridir; basittir ancak daha az kontrollüdür. Hizmet hesapları, iş yükü kimliği ve IAM’e bağlı, kötüye kullanımı daha zor olan kimlik tabanlı hedefleme sağlar. Güvenli etiketler (IAM aracılığıyla bağlanan kuruluş düzeyinde kaynak yöneticisi etiketleri), güvenlik ekiplerinin, geliştiricilerin korumayı atlayan etiketleri kendi kendilerine atamalarına izin vermeden bir kuralın hangi sanal makineleri hedefleyebileceğini kontrol etmelerini sağlar; bunları daha güçlü yönetişim için kullanın.
Günlük kaydı:
- O kuralla eşleşen izin verilen veya reddedilen bağlantıları yakalamak için güvenlik duvarı kuralı günlüğünü kural başına etkinleştirin. Zımni reddetmeler günlüğe kaydedilmez; reddetme günlüklerine ihtiyacınız varsa, günlük kaydı etkinleştirilmiş açık, yüksek öncelikli bir reddetme kuralı ekleyin.
- Günlükler kural referansını, eylemi, 5’li (5-tuple) bilgiyi, baytları içerir ve adli analiz (forensics) için dışa aktarılabilir.

Tasarım ve operasyonlar:

En az ayrıcalıklı giriş (ingress): Açık, yüksek öncelikli reddetme kuralları kullanarak varsayılan olarak reddetme yöntemini tercih edin, ardından hizmet hesabına veya güvenli etikete göre kapsamı belirlenmiş izinler ekleyin. Bir yük dengeleyicinin arkasındaki örnek grupları için, yalnızca trafiğin gerçekten kaynaklandığı yük dengeleyici veya sağlık denetimi aralıklarından gelen trafiğe izin verin.
En az ayrıcalıklı çıkış (egress): Zımni izin ver kuralını, açık, yüksek öncelikli tümünü reddet çıkış kuralı ve hedeflenmiş izinlerle (NAT aralıkları, iş ortağı IP’leri veya Private Google Access aracılığıyla Google API’leri için) değiştirin. Geri dönüş akışlarını bozmamaya dikkat edin; durum bilgili olma (statefulness), izin verilen bağlantılara verilen yanıtların ek kurallar olmadan geçmesine olanak tanır.
Kimlik tabanlı hedefleme:
- IP hareketliliğinden bağımsız olarak “kimin konuşabileceği” politikasını belirlemek için hizmet hesaplarını kullanın.
- Geliştiricilerin kendilerine izin veren ağ etiketlerini uygulamalarını önlemek için güvenli etiketleri kullanın.
Yaygın tuzaklar ve hata modları:
- Yük dengeleyici kaynak kimliği: Harici HTTP(S) yük dengeleyiciler için, arka uçlar (backend’ler) bağlantıları istemci IP’lerinden değil, Google Front End proxy’lerinden geliyormuş gibi görür. İstemci IP’sine izin verme/reddetme için Cloud Armor’u kullanın; GFE çıkış ve sağlık denetimi aralıklarına izin vermek için VPC güvenlik duvarını kullanın. TCP/UDP Ağ Yük Dengeleyicileri için, arka uçlar istemci IP’sini görür; istemci IP’lerinin güvenlik duvarı izin listeleri doğrudan uygulanır.
- Eksik reddetme günlükleri: Zımni kurallardan kaynaklanan reddetmeler günlüğe kaydedilmez. Engellenen trafiği gözlemlemek için günlük kaydı etkinleştirilmiş açık bir reddetme kuralı ekleyin.
- NAT atlatma: Bir sanal makinenin harici bir IP’si varsa, çıkış için bunu kullanır ve Cloud NAT’ı atlar. NAT kullanımını zorlamak için harici IP’yi kaldırın.
- Kural uyuşmazlığı teşhisi: Yönü, hedef kimliğini (etiket/hizmet hesabı/güvenli etiket), önceliği ve kaynak filtrelerini doğrulayın. Günlükler bir eşleşme göstermiyorsa, trafik beklediğiniz kurala ulaşmıyor demektir.

Kısa örnek, günlük kaydı ile kimlik tabanlı giriş izni:

Hedef: hizmet hesabı sa: web-backend@project.iam.gserviceaccount.com
Kaynak aralıkları: GFE proxy aralıkları + Google sağlık denetimleri
Öncelik: 100
Eylem: tcp:80,443’e izin ver
Günlük Kaydı: açık

Hiyerarşik güvenlik duvarı politikası, segmentasyon ve hizmet çevreleri

Hiyerarşik güvenlik duvarı politikaları, VPC düzeyindeki kurallardan önce kuruluş veya klasör genelindeki kuralları zorunlu kılar. Bunları, koruma sınırlarını (örneğin, “yük dengeleyici arkasında olmayan VM’lere internetten gelen tüm trafiği engelle” veya “0.0.0.0/0’dan gelen RDP/SSH’yi engelle”) garanti altına almak için kullanın. Daha alt düzeydeki VPC kuralları, daha önce eşleşmiş bir kuruluş/klasör engelleme kuralını geçersiz kılamaz.

Segmentasyon stratejisi:

Gelen trafik segmentasyonu (Ingress segmentation):
- Kuruluş/klasör politikası: Riskli portlar için yüksek öncelikli engellemeler ve onaylanmış giriş noktaları dışında varsayılan bir engelleme. Gereken yerlerde Google sağlık kontrolü aralıklarına izin verin.
- VPC kuralları: Hizmet hesabı veya güvenli etiket (secure tag) ile hedeflenen, iş yüküne özgü izinler. Dahili hizmetler için, kısıtlanmış kurallarla doğu-batı erişimi için Private Service Connect veya dahili yük dengelemeyi kullanın.
Giden trafik segmentasyonu (Egress segmentation):
- Zımni olarak tüm giden trafiğe izin veren kuralı, kuruluş/klasör veya VPC kapsamında yüksek öncelikli bir tümünü engelleme kuralıyla değiştirin, ardından yalnızca gerekenleri açın:
  - Cloud NAT veya onaylanmış giden trafik güvenlik duvarları (egress firewalls) üzerinden internete giden trafik.
  - Private Google Access ve private.googleapis.com veya restricted.googleapis.com uç noktaları aracılığıyla Google API’leri. Kısıtlanmış uç nokta (restricted endpoint), yetkisiz kimliklere veya projelere veri sızdırılmasını önlemek için VPC Service Controls ile birlikte çalışır.
  - 0.0.0.0/0 trafiğini üçüncü taraf bir güvenlik duvarı üzerinden yönlendiren ancak yine de Google API’lerine “hairpinning” (geri dönüş) olmadan doğrudan erişim gerektiren tasarımlar için, Google API’leri VIP bloklarına yönelik statik rotaları varsayılan internet ağ geçidine ekleyin ve alt ağlarda Private Google Access’i etkinleştirin. Bu, birinci taraf hizmetler için üçüncü taraf cihaza olan bağımlılığı ve gecikmeyi azaltırken güvenlik kontrollerini korur.

Hizmet çevresi (Service perimeter) etkileşimleri:

VPC Service Controls, veri sızdırılmasını azaltmak için projeler ve desteklenen Google API’leri etrafında çevreler (perimeter) tanımlar. Çevreler etkinleştirildiğinde:
- API çağrılarının çevre bağlamında kalmasını sağlamak için restricted.googleapis.com’u tercih edin.
- DNS’in ilgili alan adlarını kısıtlanmış veya özel uç noktalara yönlendirdiğinden ve rotaların güvenilmeyen giden trafik cihazlarına geri dönmediğinden emin olun.
- Çevre dışı uç noktalara kazara sızıntıları önlemek için çevre politikasını giden trafik güvenlik duvarı izin listeleriyle birleştirin.

Artıları ve eksileri:

Kuruluş düzeyindeki engellemeler risk yönetimini basitleştirir ancak değişiklik kontrolü yavaşsa meşru denemeleri engelleyebilir; güvenli etiketler (secure tags) ve belgelenmiş talep iş akışları kullanarak istisnaları delege edin.
Agresif giden trafik engellemeleri etki alanını (blast radius) azaltır ancak kesintileri önlemek için sağlam hizmet keşfi ve değişiklik kontrolü gerektirir.

Cloud Armor, WAF ve küresel uç nokta korumaları

Cloud Armor, uç noktada koruma sağlamak için güvenlik politikalarını harici HTTP(S) ve harici TCP/SSL Proxy yük dengeleyicilerine bağlar.

WAF kuralları:
- OWASP Top 10 ve yaygın CVE’ler için önceden yapılandırılmış kuralları ve üstbilgiler, IP’ler, ülkeler, URI’lar ve daha fazlasıyla eşleşmek için bir ifade dili kullanan özel kuralları kullanın.
- Her bir arka uç hizmetine (backend service) ekleyin ve kuralları önceliğe göre sıralayın. Eylemler arasında izin verme, belirli yanıtlarla engelleme veya HTTP(S) için yönlendirme bulunur.
Hız sınırlama (Rate limiting):
- Kayan pencereler ve anlık artış (burst) kontrolleri ile anahtar başına kotalar (örneğin, istemci IP’si, üstbilgi veya çereze göre) uygulayın. Hız tabanlı yasaklar, kötü niyetli kaynaklar için otomatik olarak geçici engellemeler ekler.
Uyarlanabilir Koruma (Adaptive Protection):
- ML tabanlı anomali tespiti, normal istek modellerini öğrenir ve L7 DDoS veya kötüye kullanımı ortaya çıkarır. Aday kurallar önerebilir veya otomatik olarak oluşturabilir; bunları önce önizleme modunda dağıtın.
Önizleme modu (Preview mode):
- Yeni kuralları trafiği etkilemeden değerlendirin. Önizleme sonuçları günlüğe kaydedilir ve düşük riskli ayarlama yapılmasına olanak tanır. Doğrulamadan sonra zorunlu uygulama moduna geçin.

DDoS savunması ve küresel yük dengeleyici kontrolleri:

Google’ın küresel anycast ağı, hacimsel L3/L4 saldırılarını emer; SYN/ACK doğrulaması, bozuk paket işleme ve otomatik ölçeklenen uç nokta kapasitesi, harici HTTP(S) ve TCP/SSL Proxy için platforma yerleşiktir.
L7 taşkınlarını, kimlik bilgisi doldurma (credential stuffing) saldırılarını ve uygulama kötüye kullanımını azaltmak için Cloud Armor ile birleştirin.
Yük dengeleyicide TLS politikalarını, modern şifreleri ve gerektiğinde istemci mTLS’ini zorunlu kılın. IPv6 gereksinimleri için, IPv6 VIP’leri olan küresel bir harici HTTP(S) veya TCP/SSL Proxy yük dengeleyici kullanın.
Yük dengelemeli bir uygulamaya belirli istemci IP’lerini izin listesine eklemek için:
- HTTP(S) kullanıyorsanız, istemci IP’sine göre anahtarlanmış Cloud Armor izin listelerini tercih edin ve arka uç güvenlik duvarı kurallarını GFE ve sağlık kontrolü kaynaklarıyla sınırlı tutun.
- Bir TCP/UDP Ağ Yük Dengeleyici kullanıyorsanız, arka uçlar gerçek istemci IP’sini görür; VPC güvenlik duvarı izin listelerini doğrudan hedeflenen örneklere (güvenli etiket veya hizmet hesabına göre) uygulayın ve Google sağlık kontrolü IP’lerini dahil edin.

Operasyonel uyarılar:

Kurallar uç noktada değerlendirilir; yanlış izin listeleri anında küresel kesintilere neden olabilir. Önizleme ve aşamalı dağıtımları kullanın ve Cloud Armor günlüklerini ve yük dengeleyici metriklerini izleyin.
Oturum benzeşimi (session affinity) ihtiyaçları değişiklik gösterir: Karma protokoller için (örneğin, aynı istemciden aynı arka uç havuzuna giden HTTP ve TFTP), yük dengeleyicideki istemci IP benzeşimi, portlar arasında kalıcılığı (stickiness) korur.

← VPC Mimarisi · Tüm alanlar · Hibrit Bağlantı →

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