Last updated
Jifunze & fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Jifunze & fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Google Cloud inatumia Hali ya Rasilimali ambayo ni sawa, kimsingi, na ile ya mfumo wa kawaida wa faili. Hii inatoa mtiririko wa kazi wa kimantiki wa mzazi/mtoto wenye maeneo maalum ya kiambatisho kwa sera na ruhusa.
Kwa kiwango cha juu, inaonekana kama hii:
A virtual machine (called a Compute Instance) is a resource. A resource resides in a project, probably alongside other Compute Instances, storage buckets, etc.
Ni uwezekano wa kuhamasisha mradi bila shirika lolote kwenda shirika lenye ruhusa roles/resourcemanager.projectCreator na roles/resourcemanager.projectMover. Ikiwa mradi uko ndani ya shirika lingine, inahitajika kuwasiliana na msaada wa GCP ili kuhamasisha kutoka shirika hilo kwanza. Kwa maelezo zaidi angalia hii.
Ruhusu kuimarisha udhibiti juu ya rasilimali za wingu za shirika lako:
Kuimarisha udhibiti ili kuweka vizuizi juu ya jinsi rasilimali za shirika lako zinaweza kutumika.
Mwelekeo na kuanzisha mipaka kwa timu zako za maendeleo ili kubaki ndani ya mipaka ya kufuata sheria.
Saidia wamiliki wa miradi na timu zao kuhamasisha haraka bila wasiwasi wa kuvunja sheria.
Sera hizi zinaweza kuundwa ili kuathiri shirika lote, folda au miradi. Wana wa node ya rasilimali iliyolengwa wanarithi sera za shirika.
Ili kufafanua sera ya shirika, unachagua kizuizi, ambacho ni aina maalum ya vizuizi dhidi ya huduma za Google Cloud au kundi la huduma za Google Cloud. Unapanga kizuizi hicho kwa vizuizi unavyotaka.
Punguza ushirikiano wa rasilimali kulingana na kikoa.
Punguza matumizi ya akaunti za huduma za Usimamizi wa Utambulisho na Ufikiaji.
Punguza eneo halisi la rasilimali mpya zilizoundwa.
Zima uundaji wa akaunti za huduma.
Kuna vizuizi vingi zaidi vinavyokupa udhibiti wa kina wa rasilimali za shirika lako. Kwa maelezo zaidi, angalia orodha ya vizuizi vyote vya Sera za Shirika.
Hizi ni kama sera za IAM katika AWS kwani kila jukumu lina seti ya ruhusa.
Hata hivyo, tofauti na katika AWS, hakuna repo ya kati ya majukumu. Badala yake, rasilimali zinatoa majukumu ya ufikiaji X kwa wakala Y, na njia pekee ya kugundua nani ana ufikiaji wa rasilimali ni kutumia get-iam-policy njia juu ya rasilimali hiyo.
Hii inaweza kuwa tatizo kwa sababu hii inamaanisha kwamba njia pekee ya kugundua ni ruhusa zipi wakala ana ni kuuliza kila rasilimali ni nani inayoipa ruhusa, na mtumiaji anaweza asiwe na ruhusa za kupata ruhusa kutoka kwa rasilimali zote.
Kuna aina tatu za majukumu katika IAM:
Majukumu ya Msingi/Msingi, ambayo yanajumuisha Mmiliki, Mhariri, na Mtazamaji ambayo yalikuwepo kabla ya kuanzishwa kwa IAM.
Majukumu yaliyotangazwa, ambayo yanatoa ufikiaji wa kina kwa huduma maalum na yanadhibitiwa na Google Cloud. Kuna majukumu mengi yaliyotangazwa, unaweza kuona yote pamoja na ruhusa zao hapa.
Majukumu ya Kijadi, ambayo yanatoa ufikiaji wa kina kulingana na orodha ya ruhusa iliyotolewa na mtumiaji.
Kuna maelfu ya ruhusa katika GCP. Ili kuangalia ikiwa jukumu lina ruhusa unaweza kutafuta ruhusa hapa na kuona ni majukumu gani yana hiyo.
Unaweza pia kutafuta hapa majukumu yaliyotangazwa yanayotolewa na kila bidhaa. Kumbuka kwamba baadhi ya majukumu hayawezi kuunganishwa na watumiaji na tu kwa SAs kwa sababu ya ruhusa wanazozishikilia. Zaidi ya hayo, kumbuka kwamba ruhusa zitachukua madhara tu ikiwa zime unganishwa na huduma husika.
Au angalia ikiwa jukumu la kijadi linaweza kutumia ruhusa maalum hapa.
Katika konso ya GCP hakuna usimamizi wa Watumiaji au Vikundi, hiyo inafanywa katika Google Workspace. Ingawa unaweza kusawazisha mtoa huduma tofauti wa utambulisho katika Google Workspace.
Unaweza kufikia watumiaji na vikundi vya Workspaces katika https://admin.google.com.
MFA inaweza kulazimishwa kwa watumiaji wa Workspaces, hata hivyo, mshambuliaji anaweza kutumia tokeni kufikia GCP kupitia cli ambayo haitalindwa na MFA (italindwa na MFA tu wakati mtumiaji anapoingia kuunda hiyo: gcloud auth login).
Wakati shirika linaundwa vikundi kadhaa vinapendekezwa kwa nguvu kuundwa. Ikiwa unasimamia yoyote kati yao unaweza kuwa umepata hatari kwa shirika lote au sehemu muhimu ya shirika:
Lazimisha nywila zenye nguvu
Kati ya herufi 8 na 100
Hakuna matumizi tena
Hakuna muda wa kumalizika
Ikiwa watu wanapata ufikiaji wa Workspace kupitia mtoa huduma wa tatu, masharti haya hayatumiki.
Hizi ni wakala ambao rasilimali zinaweza kuwa zilizounganishwa na ufikiaji wa kuingiliana kwa urahisi na GCP. Kwa mfano, inawezekana kufikia tokeni ya uthibitisho ya Akaunti ya Huduma iliyounganishwa na VM katika metadata.
Inawezekana kukutana na mizozo wakati wa kutumia IAM na mipaka ya ufikiaji. Kwa mfano, akaunti yako ya huduma inaweza kuwa na jukumu la IAM la compute.instanceAdmin lakini mfano uliyovunja umewekwa vizuizi vya mipaka ya https://www.googleapis.com/auth/compute.readonly. Hii itakuzuia kufanya mabadiliko yoyote kwa kutumia tokeni ya OAuth ambayo inatolewa kiotomatiki kwa mfano wako.
Ni sawa na majukumu ya IAM kutoka AWS. Lakini tofauti na katika AWS, akaunti yoyote ya huduma inaweza kuunganishwa na huduma yoyote (haihitaji kuiruhusu kupitia sera).
Baadhi ya akaunti za huduma ambazo utaziona kwa kweli zinaundwa kiotomatiki na GCP unapokuwa unatumia huduma, kama:
Hata hivyo, inawezekana pia kuunda na kuunganisha kwenye rasilimali akaunti za huduma za kawaida, ambazo zitakuwa kama hii:
Kuna njia 2 kuu za kufikia GCP kama akaunti ya huduma:
Kupitia token za OAuth: Hizi ni token ambazo utapata kutoka maeneo kama vile metadata endpoints au kuiba maombi ya http na zinapunguzwa na mipaka ya ufikiaji.
Funguo: Hizi ni jozi za funguo za umma na za kibinafsi ambazo zitakuruhusu kusaini maombi kama akaunti ya huduma na hata kuunda token za OAuth ili kufanya vitendo kama akaunti ya huduma. Funguo hizi ni hatari kwa sababu ni ngumu zaidi kuzizuia na kudhibiti, ndiyo maana GCP inapendekeza kutosababisha hizo.
Kumbuka kwamba kila wakati akaunti ya SA inaundwa, GCP inaunda funguo kwa akaunti ya huduma ambayo mtumiaji hawezi kufikia (na haitatajwa katika programu ya wavuti). Kulingana na hii mada funguo hii inatumiwa ndani na GCP kutoa ufikiaji wa metadata endpoints ili kuunda token za OAuth zinazoweza kufikiwa.
Mipaka ya ufikiaji ime unganishwa na token za OAuth zilizozalishwa ili kufikia viwango vya API vya GCP. Zinapunguza idhini za token ya OAuth. Hii inamaanisha kwamba ikiwa token inamhusu Mmiliki wa rasilimali lakini haina katika mipaka ya token kufikia rasilimali hiyo, token haiwezi kutumika (ku)kandamiza hizo haki.
Google kwa kweli inapendekeza kwamba mipaka ya ufikiaji isitumike na kutegemea kabisa IAM. Kituo cha usimamizi wa wavuti kwa kweli kinadhibiti hili, lakini mipaka ya ufikiaji bado inaweza kutumika kwa mifano kwa kutumia akaunti za huduma za kawaida kimaandishi.
Unaweza kuona ni mipaka gani imepewa kwa kuuliza:
Mipango ya awali ni zile zinazozalishwa kwa default kwa kutumia gcloud ili kufikia data. Hii ni kwa sababu unapoitumia gcloud kwanza unaunda token ya OAuth, kisha unaitumia kuwasiliana na maeneo ya mwisho.
Mipango muhimu zaidi kati ya hizo ni cloud-platform, ambayo kimsingi inamaanisha kwamba inawezekana kufikia huduma yoyote katika GCP.
Unaweza kupata orodha ya mipango yote inay posible hapa.
Ikiwa una gcloud akreditivu za kivinjari, inawezekana kupata token yenye mipango mingine, ukifanya kitu kama:
Kama ilivyoainishwa na terraform katika https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam kutumia terraform na GCP kuna njia tofauti za kutoa ufikiaji kwa principal juu ya rasilimali:
Uanachama: Unapoweka principals kama wanachama wa majukumu bila vizuizi juu ya jukumu au principals. Unaweza kuweka mtumiaji kama mwanachama wa jukumu kisha kuweka kundi kama mwanachama wa jukumu hilo hilo na pia kuweka principals hao (mtumiaji na kundi) kama wanachama wa majukumu mengine.
Mikataba: Principals kadhaa wanaweza kuunganishwa na jukumu. Principals hao bado wanaweza kuunganishwa au kuwa wanachama wa majukumu mengine. Hata hivyo, ikiwa principal ambaye hajaunganishwa na jukumu amewekwa kama mwanachama wa jukumu lililounganishwa, wakati wa pili mkataba unapotumika, uanachama utaondoka.
Sera: Sera ni mamlaka, inaonyesha majukumu na principals na kisha, principals hao hawawezi kuwa na majukumu zaidi na majukumu hayo hayawezi kuwa na principals zaidi isipokuwa sera hiyo ibadilishwe (hata katika sera nyingine, mikataba au uanachama). Kwa hivyo, wakati jukumu au principal inapoainishwa katika sera, haki zake zote zinapunguziliwa mbali na sera hiyo. Kwa wazi, hii inaweza kupuuziliwa mbali ikiwa principal atapewa chaguo la kubadilisha sera au ruhusa za kupandisha hadhi (kama kuunda principal mpya na kumuweka kwenye jukumu jipya).
Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
