GCP - Basic Information
Last updated
Last updated
AWS Hacking öğrenin ve pratik yapın:HackTricks Eğitim AWS Kırmızı Takım Uzmanı (ARTE) GCP Hacking öğrenin ve pratik yapın: HackTricks Eğitim GCP Kırmızı Takım Uzmanı (GRTE)
Google Cloud, geleneksel bir dosya sistemine kavramsal olarak benzer bir Kaynak hiyerarşisi kullanır. Bu, politikalar ve izinler için belirli ekleme noktaları ile mantıksal bir ebeveyn/çocuk iş akışı sağlar.
Yüksek seviyede, bu şekilde görünür:
Bir sanal makine (Compute Instance olarak adlandırılır) bir kaynaktır. Bir kaynak, muhtemelen diğer Compute Instance'lar, depolama kovaları vb. ile birlikte bir projede bulunur.
Bir projeyi herhangi bir organizasyondan roles/resourcemanager.projectCreator ve roles/resourcemanager.projectMover izinleri ile bir organizasyona taşımak mümkündür. Proje başka bir organizasyonun içindeyse, öncelikle organizasyondan çıkarmak için GCP desteği ile iletişime geçmek gerekir. Daha fazla bilgi için şurayı kontrol edin.
Organizasyonunuzun bulut kaynakları üzerinde merkezi kontrol sağlamaya olanak tanır:
Organizasyonunuzun kaynaklarının nasıl kullanılabileceği üzerinde kısıtlamalar yapılandırmak için merkezi kontrol sağlayın.
Geliştirme ekiplerinizin uyum sınırları içinde kalmasını sağlamak için koruma önlemleri tanımlayın ve oluşturun.
Proje sahiplerine ve ekiplerine uyumu ihlal etme endişesi olmadan hızlı hareket etme konusunda yardımcı olun.
Bu politikalar, tüm organizasyonu, klasör(ler) veya proje(ler) etkilemek üzere oluşturulabilir. Hedeflenen kaynak hiyerarşi düğümünün altındaki varlıklar organizasyon politikasını miras alır.
Bir organizasyon politikasını tanımlamak için, bir kısıtlama seçersiniz; bu, belirli bir Google Cloud hizmetine veya bir grup Google Cloud hizmetine karşı bir kısıtlama türüdür. Bu kısıtlamayı istediğiniz kısıtlamalarla yapılandırırsınız.
Alan adına dayalı kaynak paylaşımını sınırlayın.
Kimlik ve Erişim Yönetimi hizmet hesaplarının kullanımını sınırlayın.
Yeni oluşturulan kaynakların fiziksel konumunu kısıtlayın.
Hizmet hesabı oluşturmayı devre dışı bırakın.
Organizasyonunuzun kaynakları üzerinde ince ayar kontrolü sağlayan daha birçok kısıtlama vardır. Daha fazla bilgi için, Tüm Organizasyon Politikası Hizmeti kısıtlamalarının listesinigörebilirsiniz.
Bunlar, her rolün bir dizi izin içerdiği AWS'deki IAM politikalarına benzer.
Ancak, AWS'deki gibi, rollerin merkezi bir deposu yoktur. Bunun yerine, kaynaklar Y'ye X erişim rolleri verir ve bir kaynağa kimin erişimi olduğunu öğrenmenin tek yolu, o kaynak üzerinde get-iam-policy yöntemini kullanmaktır.
Bu bir sorun olabilir çünkü bu, bir ilkenin hangi izinlere sahip olduğunu öğrenmenin tek yolunun, her kaynağa kimin izin verdiğini sormak olduğunu gösterir ve bir kullanıcının tüm kaynaklardan izinleri alma yetkisi olmayabilir.
IAM'de üç tür rol vardır:
Temel/Primitif roller, Sahip, Düzenleyici ve Görüntüleyici rollerini içerir; bu roller IAM'ın tanıtılmasından önce mevcuttu.
Ön tanımlı roller, belirli bir hizmet için ayrıntılı erişim sağlar ve Google Cloud tarafından yönetilir. Birçok ön tanımlı rol vardır, hepsini sahip oldukları ayrıcalıklarla birlikte buradan görebilirsiniz.
Özel roller, kullanıcı tarafından belirtilen bir izin listesine göre ayrıntılı erişim sağlar.
GCP'de binlerce izin vardır. Bir rolün izinlere sahip olup olmadığını kontrol etmek için buradan izni arayabilirsiniz ve hangi rollerin buna sahip olduğunu görebilirsiniz.
Ayrıca, buradan ön tanımlı rolleri arayabilirsiniz her ürün tarafından sunulan. Bazı rollerin kullanıcılara eklenemeyeceğini ve yalnızca SA'lara eklenebileceğini unutmayın; çünkü içerdiği bazı izinler nedeniyle. Ayrıca, izinlerin yalnızca ilgili hizmete eklenirse geçerli olacağını unutmayın.
Veya bir özel rolün burada belirli bir izni kullanıp kullanamayacağını kontrol edin.
GCP - IAM, Principals & Org Policies EnumGCP konsolunda Kullanıcılar veya Gruplar yönetimi yoktur; bu, Google Workspace'te yapılır. Ancak, Google Workspace'te farklı bir kimlik sağlayıcısını senkronize edebilirsiniz.
Workspace kullanıcıları ve gruplarına https://admin.google.com adresinden erişebilirsiniz.
MFA, Workspace kullanıcılarına zorlanabilir, ancak bir saldırgan, GCP'ye cli üzerinden erişmek için bir token kullanabilir; bu, MFA ile korunmayacaktır (sadece kullanıcı giriş yaptığında oluşturulurken MFA ile korunacaktır: gcloud auth login).
Bir organizasyon oluşturulduğunda birkaç grup oluşturulması şiddetle önerilir. Bunlardan herhangi birini yönetiyorsanız, organizasyonun tamamını veya önemli bir kısmını tehlikeye atmış olabilirsiniz:
Grup
Fonksiyon
gcp-organization-admins
(kontrol listesi için grup veya bireysel hesaplar gereklidir)
Organizasyona ait herhangi bir kaynağı yönetmek. Bu rolü dikkatli bir şekilde atayın; organizasyon yöneticileri, tüm Google Cloud kaynaklarınıza erişim sağlar. Alternatif olarak, bu işlev yüksek ayrıcalıklı olduğundan, bir grup oluşturmak yerine bireysel hesaplar kullanmayı düşünün.
gcp-network-admins
(kontrol listesi için gereklidir)
Ağlar, alt ağlar, güvenlik duvarı kuralları ve Cloud Router, Cloud VPN ve bulut yük dengeleyicileri gibi ağ cihazları oluşturma.
gcp-billing-admins
(kontrol listesi için gereklidir)
Faturalama hesaplarını ayarlama ve kullanımını izleme.
gcp-developers
(kontrol listesi için gereklidir)
Uygulamaları tasarlama, kodlama ve test etme.
gcp-security-admins
Tüm organizasyon için erişim yönetimi ve organizasyon kısıtlama politikaları dahil olmak üzere güvenlik politikalarını oluşturma ve yönetme. Google Cloud güvenlik altyapınızı planlamak için daha fazla bilgi için Google Cloud güvenlik temelleri kılavuzuna bakın.
gcp-devops
Sürekli entegrasyon ve teslimatı destekleyen uçtan uca boru hatları oluşturma veya yönetme, izleme ve sistem sağlama.
gcp-logging-admins
gcp-logging-viewers
gcp-monitor-admins
gcp-billing-viewer
(artık varsayılan olarak yok)
Projelerdeki harcamaları izleme. Tipik üyeler finans ekibinin bir parçasıdır.
gcp-platform-viewer
(artık varsayılan olarak yok)
Google Cloud organizasyonu genelinde kaynak bilgilerini gözden geçirme.
gcp-security-reviewer
(artık varsayılan olarak yok)
Bulut güvenliğini gözden geçirme.
gcp-network-viewer
(artık varsayılan olarak yok)
Ağ yapılandırmalarını gözden geçirme.
grp-gcp-audit-viewer
(artık varsayılan olarak yok)
Denetim günlüklerini görüntüleme.
gcp-scc-admin
(artık varsayılan olarak yok)
Güvenlik Komut Merkezi'ni yönetme.
gcp-secrets-admin
(artık varsayılan olarak yok)
Secret Manager'da gizli bilgileri yönetme.
Güçlü şifreleri zorunlu kıl
8 ile 100 karakter arasında
Yeniden kullanım yok
Süre sona erme yok
İnsanlar Workspace'e üçüncü taraf bir sağlayıcı aracılığıyla erişiyorsa, bu gereksinimler uygulanmaz.
Bunlar, kaynakların bağlı olabileceği ve GCP ile kolayca etkileşimde bulunabilmesi için erişim sağladığı ilkelerdir. Örneğin, bir VM'ye bağlı bir Hizmet Hesabının kimlik doğrulama token'ına metadata'da erişmek mümkündür.
IAM ve erişim kapsamlarını kullanırken bazı çelişkilerle karşılaşmak mümkündür. Örneğin, hizmet hesabınızın compute.instanceAdmin IAM rolü olabilir, ancak ihlal ettiğiniz örnek, https://www.googleapis.com/auth/compute.readonly kapsam kısıtlaması ile sınırlı olabilir. Bu, örneğinize otomatik olarak atanan OAuth token'ını kullanarak herhangi bir değişiklik yapmanızı engeller.
Bu, AWS'deki IAM rollerine benzer. Ancak AWS'deki gibi, herhangi bir hizmet hesabı herhangi bir hizmete bağlanabilir (bunu bir politika aracılığıyla izin vermesi gerekmez).
Bulacağınız birçok hizmet hesabı aslında, bir hizmet kullanmaya başladığınızda GCP tarafından otomatik olarak oluşturulur, örneğin:
Ancak, özel hizmet hesapları oluşturmak ve bunlara eklemek de mümkündür, bu da şöyle görünecektir:
GCP'ye bir hizmet hesabı olarak erişmenin 2 ana yolu vardır:
OAuth tokenları aracılığıyla: Bunlar, metadata uç noktaları gibi yerlerden veya http isteklerini çalarak elde edeceğiniz tokenlardır ve erişim kapsamları ile sınırlıdır.
Anahtarlar: Bunlar, hizmet hesabı olarak istekleri imzalamanıza ve hatta hizmet hesabı olarak eylemler gerçekleştirmek için OAuth tokenları oluşturmanıza olanak tanıyan genel ve özel anahtar çiftleridir. Bu anahtarlar tehlikelidir çünkü sınırlamak ve kontrol etmek daha karmaşıktır, bu yüzden GCP bunları oluşturmanızı önermemektedir.
Her seferinde bir SA oluşturulduğunda, GCP hizmet hesabı için bir anahtar oluşturur ve kullanıcı bu anahtara erişemez (ve web uygulamasında listelenmez). bu başlığa göre bu anahtar, GCP tarafından dahili olarak erişilebilir OAuth tokenları oluşturmak için metadata uç noktalarına erişim vermek amacıyla kullanılmaktadır.
Erişim kapsamları, GCP API uç noktalarına erişmek için oluşturulan OAuth tokenlarına eklenir. Bunlar, OAuth tokenının izinlerini kısıtlar. Bu, bir token bir kaynağın sahibi olsa bile, o kaynağa erişim sağlamak için token kapsamına sahip değilse, tokenın bu ayrıcalıkları (kötüye) kullanmak için kullanılamayacağı anlamına gelir.
Google aslında önerir ki erişim kapsamları kullanılmasın ve tamamen IAM'e güvenilsin. Web yönetim portalı aslında bunu zorunlu kılar, ancak erişim kapsamları yine de özel hizmet hesapları kullanılarak programlı olarak örneklere uygulanabilir.
Hangi kapsamların atanmış olduğunu sorgulayarak görebilirsiniz:
Önceki scopes, veriye erişmek için gcloud kullanılarak varsayılan olarak oluşturulanlardır. Bunun nedeni, gcloud kullandığınızda önce bir OAuth token'ı oluşturmanız ve ardından bunu uç noktalarla iletişim kurmak için kullanmanızdır.
Bu potansiyel scopes arasında en önemli olanı cloud-platform'dur, bu temelde GCP'deki herhangi bir hizmete erişmenin mümkün olduğu anlamına gelir.
Burada tüm olası scopes listesini bulabilirsiniz.
Eğer gcloud tarayıcı kimlik bilgilerine sahipseniz, diğer scopes ile bir token elde etmek mümkündür, şöyle bir şey yaparak:
Terraform tarafından tanımlandığı gibi https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam GCP ile terraform kullanarak bir kaynağa erişim vermenin farklı yolları vardır:
Üyelikler: Prensipleri rollerin üyeleri olarak kısıtlama olmaksızın belirlersiniz. Bir kullanıcıyı bir rolün üyesi olarak koyabilir ve ardından aynı rolün bir üyesi olarak bir grubu koyabilir ve ayrıca bu prensipleri (kullanıcı ve grup) diğer rollerin üyesi olarak ayarlayabilirsiniz.
Bağlantılar: Birden fazla prensip bir role bağlanabilir. Bu prensipler hala diğer rollerin üyeleri veya bağlanmış olabilir. Ancak, bir role bağlı olmayan bir prensip bağlı bir rolün üyesi olarak ayarlandığında, bağlantı uygulandığında, üyelik kaybolacaktır.
Politikalar: Bir politika otoritativdir, roller ve prensipleri belirtir ve ardından, bu prensiplerin daha fazla rolü olamaz ve bu rollerin daha fazla prensibi olamaz, bu politika değiştirilmedikçe (diğer politikalar, bağlantılar veya üyeliklerde bile değil). Bu nedenle, bir rol veya prensip politika içinde belirtildiğinde, tüm ayrıcalıkları o politika ile sınırlıdır. Açıkça, bu, prensibe politikayı değiştirme veya ayrıcalık yükseltme izinleri (yeni bir prensip oluşturma ve ona yeni bir rol bağlama gibi) verildiğinde aşılabilir.
AWS Hacking'i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE) GCP Hacking'i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
