--- title: "GCP Güvenliği Güçlendirme Kontrol Listesi | Snow Tree" url: "https://www.snow-tree.com/tr/gcp-security-hardening/" --- Güvenli GCP altyapısı # Küçük ve Orta Ölçekli Ekipler için GCP Güvenliği Güçlendirme Kontrol Listesi Ayrı bir güvenlik departmanı olmadan Google Cloud üzerinde üretim iş yükleri çalıştıran ekipler için pratik bir güvenlik temeli. Ciddi bir olaya giden en olası yolların en kolay azaltılabildiği yerden başlayın. ## Bu sayfada 1. [Yaygın GCP tehdit yolları](https://www.snow-tree.com/tr/#threat-paths) 2. [Kimlik ve erişim](https://www.snow-tree.com/tr/#identity) 3. [Ağ ve uç](https://www.snow-tree.com/tr/#network) 4. [Veriler ve sırlar](https://www.snow-tree.com/tr/#data) 5. [GKE güvenliğini güçlendirme](https://www.snow-tree.com/tr/#gke) 6. [Algılama ve kurtarma](https://www.snow-tree.com/tr/#detection) 7. [Öncelikli 30, 60 ve 90 günlük kontrol listesi](https://www.snow-tree.com/tr/#checklist) 8. [Resmi kaynaklar](https://www.snow-tree.com/tr/#references) ## Yaygın GCP tehdit yolları Çoğu bulut olayı, küçük bir sahiplik veya yapılandırma boşluğuyla başlar. Bu yolları bir saldırgan bulmadan önce siz bulun. - Aşırı yetkilendirilmiş bir kullanıcı, hizmet hesabı veya iş yükü kimliği, çalınan tek bir kimlik bilgisini projeler genelinde geniş erişime dönüştürebilir. - Açıkta kalan bir yönetim uç noktası, hata ayıklama bağlantı noktası veya aşırı serbest bir güvenlik duvarı kuralı, normal uygulama trafiği için tasarlanmış tüm kontrolleri atlatabilir. - Herkese açık bir depolama paketi veya kapsamı aşırı geniş imzalı bir URL, uygulamada görünür bir ihlal olmadan müşteri verilerini ifşa edebilir. - Eski görüntüler, unutulmuş ad alanları, kullanılmayan hizmet hesapları ve sahipsiz kaynaklar dağıtılabilir durumda kaldığında, bakımsız iş yükleri kalıcı bir risk oluşturur. - Eksik veya kısa süre saklanan denetim kanıtları, bir politikayı kimin değiştirdiğini, erişimin ne zaman başladığını ve hangi verilere ulaşıldığını belirlemeyi zorlaştırır. - Test edilmemiş bir yedekleme yalnızca bir umuttur. Geri yükleme hataları, eksik saklama ve erişilemeyen şifreleme anahtarları, bir güvenlik olayını kalıcı kayba dönüştürebilir. ## Kimlik ve erişim Kimliği birincil kontrol düzlemi olarak ele alın. Her kişinin, otomasyon sürecinin ve iş yükünün, amacı sınırlı ve kendine ait bir kimliği olmalıdır. ### Kaynak sınırını açıkça belirtin Koruma önlemleri için kuruluşu ve klasörleri kullanın; geliştirme, hazırlık (staging) ve üretim ortamlarını ayrı projelere veya daha güçlü güven sınırlarına ayırın. Kuruluş politikalarını uygulanabilir en üst düzeyde uygulayın, hizmet kullanımını kısıtlayın ve üretim projelerini birbiriyle ilgisiz ürünler arasında paylaşmaktan kaçının. ### En dar kapsamda minimum rolü verin Geniş temel (ilkel) roller yerine önceden tanımlanmış veya özel rolleri tercih edin, bunları gruplara ve iş yükü kimliklerine verin ve kaynak adının veya etiketin erişimi daraltabildiği yerlerde IAM koşullarını kullanın. Kullanılmayan izinleri gözden geçirin ve yalnızca acil durum erişimi (break-glass) sürecine ait olması gereken kalıcı üretim erişimini kaldırın. ### Uzun ömürlü kimlik bilgilerini kaldırın Pod'ların dışa aktarılmış hizmet hesabı anahtarları olmadan kısa ömürlü kimlik bilgileri alması için Workload Identity Federation for GKE kullanın. Mümkün olduğunda kuruluş politikasıyla anahtar oluşturmayı ve yüklemeyi engelleyin, kalan anahtarların envanterini çıkarın ve Cloud Audit Logs'taki yüksek riskli IAM değişiklikleri için uyarı oluşturun. ## Ağ ve uç Bir uygulama kusurunun er ya da geç ağdan erişilebilir olacağını varsayın. Bu kusurun nelere erişebileceğini sınırlayın. ### Varsayılan olarak reddederek başlayın ve adlandırılmış yollar ekleyin Pod trafiği için en az ayrıcalık ilkesine göre VPC güvenlik duvarı kuralları ve Kubernetes NetworkPolicies kullanın. Ortamları ayrı ağlara bölün, her giriş (ingress) yolunu belgeleyin ve geniş adres aralıklarından yönetim bağlantı noktalarına veya tüm protokollere izin veren geniş hata ayıklama kurallarını kaldırın. ### Düğümleri ve kontrol düzlemlerini özel tutun GKE düğümlerindeki harici IP adreslerini devre dışı bırakın. DNS tabanlı özel kontrol düzlemi uç noktasını tercih edin ve bir IP uç noktası kaçınılmaz olduğunda onu yetkili ağlarla sınırlayın. İş yüklerine geniş internet erişimi yerine bilinçli bir çıkış yolu verin. ### Yalnızca bilinçli olarak herkese açılan hizmetleri yayınlayın Uygulamaları rastgele Pod veya düğüm adresleri yerine incelenmiş bir ağ geçidi veya yük dengeleyici üzerinden kullanıma sunun. TLS'yi yönetilen sertifikalarda sonlandırın, giriş (ingress) ana makinelerini ve yollarını kısıtlayın, istek ve hız sınırları uygulayın ve yönetim arayüzlerini kimliğe duyarlı erişimin arkasında tutun. ## Veriler ve sırlar Beklemedeki, aktarılan ve kullanımdaki verileri koruyun, ardından bunları kurtarabileceğinizi kanıtlayın. Verilerin keşfi kontrolün bir parçasıdır. ### Kazara oluşan herkese açık erişimi önleyin Cloud Storage'da herkese açık erişim önlemeyi ve tek tip paket düzeyinde erişimi zorunlu kılın. Paketleri hassasiyete göre sınıflandırın, nesne ve anahtar erişimini kısıtlayın, yüksek değerli veriler için günlük kaydını etkinleştirin ve risk veya uyumluluk modelinizin gerektirdiği durumlarda müşteri tarafından yönetilen şifreleme anahtarlarını kullanın. ### Sırları görüntülerden ve kaynak koddan uzak tutun Kimlik bilgilerini Secret Manager'da saklayın ve belirli bir iş yükü kimliğine belirli bir sır sürümü için erişim verin. Sırları planlı olarak döndürün, Git'e veya kapsayıcı görüntülerine kopyalamaktan kaçının ve sıradan Kubernetes Secrets'ı tam bir koruma sınırı olarak görmeyin. ### Yalnızca yedekleme oluşturmayı değil, kurtarmayı da test edin Kurtarma noktası ve kurtarma süresi hedeflerini (RPO/RTO) tanımlayın, kopyaları üretimin arıza alanının dışında saklayın ve yedeklere ve şifreleme anahtarlarına erişimi iş yükü kimliğinden koruyun. Belirli bir programla yalıtılmış bir ortama geri yükleme yapın, verileri doğrulayın ve geçen süreyi ve varsa manuel adımları kaydedin. ## GKE güvenliğini güçlendirme GKE yönetilen kontrol düzleminin güvenliğini sağlar, ancak küme yapılandırmanız, ad alanlarınız, kabul politikalarınız ve iş yükleriniz sizin yönetiminizde kalır. ### Ad alanlarını izolasyon sözleşmesi haline getirin Ekipleri ve ortamları ad alanlarına veya kümelere ayırın, bunların içinde dar kapsamlı Kubernetes RBAC rolleri bağlayın ve kaynak kotaları ile NetworkPolicies uygulayın. Uygulama dağıtımı için küme genelinde yazma erişiminden kaçının ve ayrı bir kimliğe ihtiyaç duyan her iş yüküne kendi hizmet hesabını verin. ### Yalnızca güvendiğiniz görüntüleri ve yapılandırmaları kabul edin Kısıtlı (restricted) Pod Security standardını veya eşdeğer Policy Controller kurallarını zorunlu kılın. Görüntüleri değişmez özet (digest) ile dağıtın, güvenlik açıklarına karşı tarayın, kökenin önemli olduğu yerlerde Binary Authorization kullanın ve beklenmedik ana makine erişimini, ayrıcalık yükseltmeyi ve cluster-admin bağlamalarını reddedin. ### Kapsayıcılardaki gereksiz yetkileri kaldırın Kapsayıcıları root olmayan kullanıcıyla çalıştırın, Linux capabilities'i kaldırın, mümkün olduğunda salt okunur bir kök dosya sistemi kullanın ve RuntimeDefault seccomp profilini uygulayın. Hizmet hesabı jetonunu gerekmedikçe bağlamayın, ayrıcalıklı kapsayıcılardan ve ana makine ad alanlarından kaçının, düğüm hizmet hesabının yetkilerini en aza indirin ve Shielded Nodes ile Container-Optimized OS kullanın. ## Algılama ve kurtarma Kontroller başarısız olur. Kimsenin hata yapmadığına duyulan güvene değil, kanıtlara ve prova edilmiş eylemlere dayanın. ### İhtiyacınız olan kanıtları toplayın Cloud Audit Logs'u ve GKE sistem ve iş yükü günlüklerini, soruşturma ihtiyaçlarınıza uygun saklama süresiyle merkezi bir hedefte tutun. Hassas veriler için Veri Erişimi denetim günlüklerini seçici olarak etkinleştirin, günlüklere erişimi kısıtlayın ve IAM, güvenlik duvarı, depolama ve küme yapılandırmasındaki yönetimsel değişiklikleri kaydedin. ### Güvenlik açısından önemli değişiklikler için uyarı oluşturun Depolamanın herkese açık hale gelmesi, geniş kapsamlı güvenlik duvarı veya IAM değişiklikleri, beklenmeyen hizmet hesabı anahtarları, kabul (admission) retleri, kontrol düzleminin açığa çıkması, tekrarlanan kimlik doğrulama hataları, devre dışı bırakılan günlük kaydı, başarısız yedeklemeler ve süresi dolmak üzere olan sertifikalar için uyarı oluşturun. Her uyarıyı, doğrulama veya reddetme adımlarıyla birlikte bir sahibine yönlendirin. ### Müdahaleyi prova edin Sızdırılmış kimlik bilgileri, herkese açık hale gelmiş veriler, ele geçirilmiş iş yükleri ve kaybedilen bölgeler veya projeler için kısa runbook'lar yazın. Olayı sınırlama yetkisini kimin verebileceğini, erişimin nasıl iptal edileceğini, kanıtların nasıl korunacağını ve hizmetin nasıl geri yükleneceğini belirtin. Runbook'ları onları kullanacak kişilerle test edin. ## Öncelikli 30, 60 ve 90 günlük kontrol listesi Eksik bir güvenlik temeliyle başlıyorsanız, işleri önce maruziyeti azaltacak ve sonraki incelemeleri tekrarlanabilir kılacak şekilde sıralayın. ### 1–30. günler: bariz yolları kapatın Projelerin ve sahiplerinin envanterini çıkarın, kullanılmayan ve uzun ömürlü kimlik bilgilerini kaldırın, denetim günlüğü kaydının açık olduğunu doğrulayın, herkese açık paketleri engelleyin, en geniş güvenlik duvarı kurallarını ve IAM izinlerini inceleyin, üretim yedeklemelerindeki boşlukları belirleyin ve sahipsiz herkese açık uç noktaları düzeltin. Her bulguya bir sahip ve son tarih atayın. ### 31–60. günler: temeli tekrarlanabilir hale getirin Ağ, kimlik ve iş yükü yapılandırmasını incelemeden geçen kod olarak altyapıya ve GitOps ile dağıtıma taşıyın. Workload Identity, özel düğümler, kısıtlı Pod Security, güvenilir görüntü denetimleri, merkezi günlükler ve en önemli değişiklikler için uyarıları uygulamaya alın. ### 61–90. günler: kanıtlayın ve sürdürün Geri yükleme testleri ve bir olay masa başı tatbikatı (tabletop) yapın, ayrıcalıklı erişimi ve istisnaların geçerlilik sürelerini inceleyin, görüntüleri ve bağımlılıkları yeniden tarayın, sahiplerin uyarı aldığını doğrulayın ve kalan boşlukları ölçün. Kanıtlar eskimeden önce kontrolleri düzenli bir inceleme döngüsüne alın. Bu kontrol listesini başlangıç noktası olarak kullanın. Snow Tree bu temeli yönetilen platform hizmeti veya odaklı bir danışmanlık çalışması aracılığıyla uygulayabilir. [Yönetilen platform](https://www.snow-tree.com/tr/managed-platform/) [Danışmanlık](https://www.snow-tree.com/tr/consulting/) ## Resmi kaynaklar Platform varsayılanları veya ürün özellikleri değiştiğinde Google'ın güncel rehberliğini teknik doğruluk kaynağı olarak kullanın. - [Google Cloud: GKE kümenizin güvenliğini güçlendirmeye yönelik en iyi uygulamalar](https://docs.cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster) - [Google Cloud: GKE güvenliği için en iyi uygulamalar](https://docs.cloud.google.com/docs/security/gke-security-bps) Yönetilen platform ## Yazılımınızı Snow Tree geliştirsin, barındırsın ve işletsin. [Proje başlat](mailto:support+snow-tree-platform-1-issue-@gitlab.snow-tree.com?subject=Snow%20Tree%20project)