GCP - Basic Information

Sıfırdan kahraman olacak şekilde AWS hacklemeyi öğrenin htARTE (HackTricks AWS Red Team Expert)!

HackTricks'i desteklemenin diğer yolları:

Kaynak hiyerarşisi

Google Cloud, kavramsal olarak geleneksel bir dosya sistemininkinden benzer olan bir Kaynak hiyerarşisi kullanır. Bu, belirli politika ve izinler için belirli ek noktalarla mantıksal bir ebeveyn/çocuk iş akışı sağlar.

Yüksek seviyede şöyle görünür:

Organization
--> Folders
--> Projects
--> Resources

Proje Göçleri

Herhangi bir organizasyon olmadan bir projeyi bir organizasyona göç etmek mümkündür. Bu işlem için roles/resourcemanager.projectCreator ve roles/resourcemanager.projectMover izinlerine sahip olmak gerekmektedir. Eğer proje başka bir organizasyonun içindeyse, önce onları organizasyondan çıkarmak için GCP destek ekibiyle iletişime geçmek gerekmektedir. Daha fazla bilgi için buraya bakabilirsiniz.

Organizasyon Politikaları

Organizasyonunuzun bulut kaynakları üzerinde merkezi kontrol sağlamaya olanak tanır:

  • Organizasyonunuzun kaynaklarının nasıl kullanılabileceğine dair kısıtlamaları yapılandırmak için merkezi kontrol sağlar.

  • Geliştirme ekiplerinin uyumluluk sınırları içinde kalmasını sağlamak için sınırlar tanımlar ve oluşturur.

  • Proje sahiplerinin ve ekiplerinin uyumluluğu bozmadan hızlı bir şekilde ilerlemelerine yardımcı olur.

Bu politikalar, tüm organizasyonu, klasör(ler)i veya proje(leri) etkileyebilir. Hedeflenen kaynak hiyerarşisi düğümünün alt kümeleri organizasyon politikasını devralı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 tür kısıtlamadır. Ardından, bu kısıtlamayı istediğiniz kısıtlamalarla yapılandırırsınız.

Ortak kullanım durumları

  • Alan adına göre kaynak paylaşımını sınırlama.

  • Kimlik ve Erişim Yönetimi hizmet hesaplarının kullanımını sınırlama.

  • Yeni oluşturulan kaynakların fiziksel konumunu kısıtlama.

  • Hizmet hesabı oluşturmayı devre dışı bırakma

Varsayılan Organizasyon Politikaları

Google'ın GCP organizasyonunuzu kurarken varsayılan olarak ekleyeceği politikalar şunlardır:

Erişim Yönetimi Politikaları

  • Alan adı kısıtlı kişiler: Belirtilen alan dışındaki Kritik Kişileri kullanıcı eklemeyi engeller. Bu, yalnızca belirlediğiniz alanlardaki yönetilen kullanıcı kimliklerinin platform bildirimleri almasına izin verir.

  • Alan adı kısıtlı paylaşım: Belirtilen alan dışındaki IAM politikalarına kullanıcı eklemeyi engeller. Bu, yalnızca belirlediğiniz alanlardaki yönetilen kullanıcı kimliklerinin bu organizasyon içindeki kaynaklara erişmesine izin verir.

  • Genel erişim engelleme: Cloud Storage kovalarının genel erişime açık olmasını engeller. Bu, bir geliştiricinin Cloud Storage kovalarını kimliksiz internet erişimine sahip olacak şekilde yapılandırmasını engeller.

  • Düzey erişimine sahip kova: Cloud Storage kovalarındaki nesne düzeyinde erişim denetim listelerini (ACL'ler) engeller. Bu, Cloud Storage kovalarındaki tüm nesnelere tutarlı bir şekilde IAM politikaları uygulayarak erişim yönetiminizi basitleştirir.

  • İşletim sistemi girişini gerektir: Yeni projelerde oluşturulan VM'lerde OS Girişinin etkin olmasını sağlar. Bu, IAM kullanarak örneklerinize SSH erişimini yönetmenizi sağlar ve ayrıca bireysel SSH anahtarları oluşturmanıza ve yönetmenize gerek kalmaz.

Hizmet hesapları için ek güvenlik politikaları

  • Otomatik IAM izinlerini devre dışı bırak: App Engine ve Compute Engine hizmet hesaplarının varsayılan olarak bir projede Editör IAM rolünü otomatik olarak almalarını engeller. Bu, hizmet hesaplarının oluşturulduğunda aşırı derecede geniş izinli IAM rollerini almamalarını sağlar.

  • Hizmet hesabı anahtar oluşturmayı devre dışı bırak: Genel hizmet hesabı anahtarlarının oluşturulmasını engeller. Bu, kalıcı kimlik bilgilerinin açığa çıkma riskini azaltmaya yardımcı olur.

  • Hizmet hesabı anahtar yükleme işlemini devre dışı bırak: Genel hizmet hesabı anahtarlarının yüklenmesini engeller. Bu, sızdırılan veya yeniden kullanılan anahtar materyallerinin riskini azaltmaya yardımcı olur.

Güvenli VPC ağı yapılandırma politikaları

  • VM örnekleri için izin verilen harici IP'leri tanımlayın: Compute örneklerinin genel IP'ye sahip olmasını engeller, bu da onları internet trafiğine açık hale getirebilir.

  • VM iç içe sanallaştırmasını devre dışı bırak: Compute Engine VM'lerinde iç içe VM'lerin oluşturulmasını engeller. Bu, izlenmeyen iç içe VM'lerin güvenlik riskini azaltır.

  • VM seri bağlantısını devre dışı bırak: Compute Engine VM'lerine seri bağlantı erişimini engeller. Bu, Compute Engine API'sını kullanarak sunucunun seri bağlantısına girişi engeller.

  • Cloud SQL örneklerinde yetkilendirilmiş ağları kısıtlayın: Genel veya iç olmayan ağ aralıklarının Cloud SQL veritabanlarınıza erişmesini engeller.

  • IP Adresi Türüne Göre Protokol Yönlendirmeyi Kısıtlayın: Dış IP adresleri için VM protokol yönlendirmesini engeller.

  • Cloud SQL örneklerinde Genel IP erişimini kısıtlayın: Genel IP'ye sahip Cloud SQL örneklerinin oluşturulmasını engeller, bu da onları internet trafiğine açık hale getirebilir.

  • Paylaşılan VPC proje lien kaldırmasını kısıtlayın: Paylaşılan VPC ana bilgisayar projelerinin yanlışlıkla silinmesini engeller.

  • Yeni projeler için iç DNS ayarını Zonal DNS Only olarak ayarlar: Hizmet kullanılabilirliğini azaltan eski bir DNS ayarının kullanılmasını engeller.

  • Varsayılan ağ oluşturmayı atla: Varsayılan VPC ağının ve ilgili kaynakların otomatik oluşturulmasını engeller. Bu, aşırı derecede genişletilmiş varsayılan güvenlik duvarı kurallarını önler.

  • VPC Dış IPv6 kullanımını devre dışı bırak: Yetkisiz internet erişimine açık olabilen harici IPv6 alt ağlarının oluşturulmasını engeller.

IAM Rolleri

Bu, her rolün bir dizi izni içerdiği AWS'deki IAM politikalarına benzerdir.

Ancak AWS'den farklı olarak, rollerin merkezi bir deposu yoktur. Bunun yerine, kaynaklar X erişim rollerini Y prensiplere verir, ve bir kaynağa kimin erişimi olduğunu öğrenmenin tek yolu, o kaynağın üzerinde get-iam-policy yöntemini kullanmaktır. Bu bir sorun olabilir çünkü bu, bir prensibin hangi izinlere sahip olduğunu öğrenmenin tek yolunun, izin verdiği tüm kaynaklara sormak olduğu anlamına gelir ve bir kullanıcının tüm kaynaklardan izinleri almak için izni olmayabilir.

IAM'de üç tür rol vardır:

  • Temel/İlkel roller, IAM'in tanıtılmasından önce var olan Sahip, Editör ve Görüntüleyici rollerini içerir.

  • Önceden tanımlanmış roller, belirli bir hizmet için ayrıntılı erişim sağlar ve Google Cloud tarafından yönetilir. Birçok önceden tanımlanmış rol vardır, onların tümünü ve sahip oldukları ayrıcalıkları 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 bulunmaktadır. Bir rolün bir izne sahip olup olmadığını kontrol etmek için buradan izni arayabilirsiniz ve hangi rollerin ona sahip olduğunu görebilirsiniz.

Ayrıca, her ürün tarafından sunulan önceden tanımlanmış rolleri buradan arayabilirsiniz. Bazı rollerin kullanıcılara bağlanamayacağını ve yalnızca Hizmet Hesaplarına bağlanabileceğini unutmayın çünkü içerdikleri bazı izinler. Ayrıca, izinlerin yalnızca ilgili hizmete bağlandığında etkili olacağını unutmayın.

Veya bir özel rolün burada belirli bir izni kullanıp kullanamayacağını kontrol edebilirsiniz.

Kullanıcılar

GCP konsolunda Kullanıcılar veya Gruplar yönetimi yapılmaz, bu Google Workspace'de gerçekleştirilir. Ancak Google Workspace'de farklı bir kimlik sağlayıcı senkronize edebilirsiniz.

Workspace kullanıcılarına ve gruplarına https://admin.google.com adresinden erişebilirsiniz.

MFA, Workspace kullanıcılarına zorunlu olabilir, ancak bir saldırgan MFA tarafından korunmayan GCP'ye erişmek için bir belirteç kullanabilir (kullanıcı giriş yaparak yalnızca MFA tarafından korunur: gcloud auth login).

Gruplar

Bir organizasyon oluşturulduğunda birkaç grubun kesinlikle oluşturulması önerilir. Bunlardan herhangi birini yönetiyorsanız, tüm organizasyonu veya önemli bir kısmını tehlikeye atabilirsiniz:

Varsayılan Şifre Politikası

  • Güçlü şifreleri zorunlu kılma

  • 8 ile 100 karakter arası

  • Tekrar kullanımı yok

  • Süresizlik yok

  • İnsanlar üçüncü taraf sağlayıcı aracılığıyla Workspace'e erişiyorsa, bu gereksinimler uygulanmaz.

Hizmet hesapları

Bunlar, kaynakların bağlı olabileceği ve GCP ile kolayca etkileşimde bulunabileceği temsilcilerdir. Örneğin, bir Hizmet Hesabının VM'ye bağlı kimlik doğrulama belirteçlerine erişmek mümkündür. IAM ve erişim kapsamlarını birlikte kullanırken bazı çakışmalarla karşılaşabilirsiniz. Örneğin, hizmet hesabınızın compute.instanceAdmin IAM rolüne sahip olabilir ancak ele geçirdiğiniz örneğin https://www.googleapis.com/auth/compute.readonly kapsam kısıtlaması ile kısıtlanmış olabilir. Bu durum, örneğinize otomatik olarak atanan OAuth belirteci kullanarak herhangi bir değişiklik yapmanızı engeller.

Bu, AWS'den IAM rollerine benzer. Ancak AWS'den farklı olarak, herhangi bir hizmet hesabı herhangi bir hizmete bağlanabilir (bunu bir politika aracılığıyla izin vermesine gerek yoktur).

Karşılaşacağınız hizmet hesaplarının bir kısmı aslında GCP'yi kullanmaya başladığınızda otomatik olarak oluşturulur, örneğin:

PROJECT_NUMBER-compute@developer.gserviceaccount.com
PROJECT_ID@appspot.gserviceaccount.com

Ancak, kaynaklara özel hizmet hesapları oluşturmak ve bunlara bağlamak da mümkündür, ki bu da şöyle görünecektir:

SERVICE_ACCOUNT_NAME@PROJECT_NAME.iam.gserviceaccount.com

Erişim kapsamları

Erişim kapsamları, GCP API uç noktalarına erişmek için oluşturulan OAuth belgelerine eklenir. Bunlar OAuth belgesinin izinlerini kısıtlar. Bu, bir belgenin bir kaynağın Sahibi olmasına rağmen, belgeye o kaynağa erişim izni verilmediyse, belge o ayrıcalıkları (kötüye) kullanmak için kullanılamaz.

Google aslında öneriyor ki erişim kapsamları kullanılmasın ve tamamen IAM'a güvenilsin. Web yönetim portalı aslında bunu zorlar, ancak erişim kapsamları hala özel servis hesapları kullanılarak örneklerde uygulanabilir.

Kapsamların ne olduğunu sorgulayarak görebilirsiniz:

curl 'https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=<access_token>'

{
"issued_to": "223044615559.apps.googleusercontent.com",
"audience": "223044615559.apps.googleusercontent.com",
"user_id": "139746512919298469201",
"scope": "openid https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/cloud-platform https://www.googleapis.com/auth/appengine.admin https://www.googleapis.com/auth/sqlservice.login https://www.googleapis.com/auth/compute https://www.googleapis.com/auth/accounts.reauth",
"expires_in": 2253,
"email": "username@testing.com",
"verified_email": true,
"access_type": "offline"
}

Önceki kapsamlar varsayılan olarak gcloud kullanılarak veriye erişmek için oluşturulanlardır. Bu, gcloud kullandığınızda önce bir OAuth belirteci oluşturmanız ve ardından uç noktalara başvurmanız gerektiği anlamına gelir.

Bu kapsamlar arasında en önemlisi muhtemelen cloud-platform'dur, bu da temelde GCP'deki herhangi bir hizmete erişilebileceği anlamına gelir.

Burada tüm olası kapsamların bir listesini bulabilirsiniz.

Eğer gcloud tarayıcı kimlik bilgilerine sahipseniz, başka kapsamlara sahip bir belirteç elde etmek mümkündür, şöyle bir şey yaparak:

# Maybe you can get a user token with other scopes changing the scopes array from ~/.config/gcloud/credentials.db

# Set new scopes for SDKs credentials
gcloud auth application-default login --scopes=https://www.googleapis.com/auth/userinfo.email,https://www.googleapis.com/auth/cloud-platform,https://www.googleapis.com/auth/sqlservice.login,https://www.googleapis.com/auth/appengine.admin,https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/accounts.reauth,https://www.googleapis.com/auth/admin.directory.user,https://www.googleapis.com/auth/admin.directory.group,https://www.googleapis.com/auth/admin.directory.domain,https://www.googleapis.com/auth/admin.directory.user

# Print new token
gcloud auth application-default print-access-token

# To use this token with some API you might need to use curl to indicate the project header with --header "X-Goog-User-Project: <project-name>"

Terraform IAM Politikaları, Bağlantılar ve Üyelikler

Terraform tarafından https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam tanımlandığı gibi GCP ile terraform kullanarak bir ilkeye erişim sağlamanın farklı yolları vardır:

  • Üyelikler: İlkelere kısıtlama olmaksızın rollerin üyeleri olarak ilkelere sahip olursunuz. Bir kullanıcıyı bir rolün üyesi olarak belirleyebilir ve ardından aynı rolün bir üyesi olarak bir grup belirleyebilir ve bu ilkelere (kullanıcı ve grup) diğer rollerin üyesi olarak da belirleyebilirsiniz.

  • Bağlantılar: Bir role çeşitli ilkelere bağlanabilir. Bu ilkelere hala bağlanabilir veya diğer rollerin üyeleri olabilir. Ancak, role bağlı olmayan bir ilke bir bağlı role üye olarak belirlenirse, bir sonraki bağlantı uygulandığında üyelik kaybolacaktır.

  • Politikalar: Bir politika yetkilidir, rolleri ve ilkelere gösterir ve sonra, bu ilkelere daha fazla rol ve bu rollerin daha fazla ilke sahip olamaz. Politika değiştirilene kadar (başka politikalarda, bağlantılarda veya üyeliklerde bile) rol veya ilke belirtildiğinde, tüm ayrıcalıkları o politika tarafından sınırlanır. Açıkçası, bu durum, ilkenin politikayı değiştirme veya ayrıcalık yükseltme izinleri verildiğinde atlanabilir (yeni bir ilke oluşturmak ve ona yeni bir rol bağlamak gibi).

Referanslar

Sıfırdan kahraman olmak için AWS hackleme öğrenin htARTE (HackTricks AWS Red Team Expert)!

HackTricks'ı desteklemenin diğer yolları:

Last updated