GCP <--> Workspace Pivoting
Kutoka GCP kwenda GWS
Misingi ya Uteuzi wa Upanuzi wa Kikoa
Uteuzi wa Upanuzi wa Kikoa wa Google Workspace unaruhusu kitu cha kitambulisho, iwe ni programu ya nje kutoka Soko la Google Workspace au akaunti ya Huduma ya GCP ya ndani, kuwa na upatikanaji wa data kote kwenye Workspace kwa niaba ya watumiaji.
Hii kimsingi inamaanisha kwamba akaunti za huduma ndani ya miradi ya GCP ya shirika zinaweza kuwa na uwezo wa kujifanya kuwa watumiaji wa Workspace wa shirika hilo (au hata kutoka shirika lingine).
Kwa habari zaidi kuhusu jinsi hii inavyofanya kazi angalia:
GCP - Understanding Domain-Wide DelegationKufilisika kwa uteuzi uliopo
Ikiwa mshambuliaji amefilisika kupata upatikanaji fulani juu ya GCP na anajua barua pepe halali ya mtumiaji wa Workspace (bora msimamizi wa juu), wa kampuni, anaweza kutambaza miradi yote anayo upatikanaji, kutambaza akaunti zote za Huduma za miradi, angalia kwa akaunti za huduma anazo upatikanaji, na kurudia hatua hizi zote na kila akaunti ya huduma anayeweza kujifanya kuwa.
Tafadhali kumbuka kwamba wakati wa kusanidi uteuzi wa upanuzi wa kikoa hakuna mtumiaji wa Workspace unahitajika, kwa hivyo kujua mmoja halali ni wa kutosha na unahitajika kwa udanganyifu. Hata hivyo, mamlaka ya mtumiaji aliyejifanya itatumika, kwa hivyo ikiwa ni Msimamizi wa Juu utaweza kupata kila kitu. Ikiwa hana upatikanaji wowote hii itakuwa bure.
Skripti hii rahisi ita zalisha kitufe cha OAuth kama mtumiaji aliyejifanya ambacho unaweza kisha kutumia kupata APIs zingine za Google na au bila gcloud
:
Hii ni zana inayoweza kutekeleza shambulizi kwa kufuata hatua hizi:
Kutambua Miradi ya GCP kwa kutumia API ya Meneja wa Rasilmali.
Endelea kila rasilimali ya mradi, na tambua rasilmali za akaunti za Huduma za GCP ambazo mtumiaji wa awali wa IAM ana ufikiaji kwa kutumia GetIAMPolicy.
Endelea kwenye kila jukumu la akaunti ya huduma, na pata majukumu yaliyojengwa, ya msingi, na ya desturi na ruhusa ya serviceAccountKeys.create kwenye rasilimali ya akaunti ya huduma ya lengo. Inapaswa kuzingatiwa kuwa jukumu la Mhariri kiasili lina ruhusa hii.
Unda ufunguo binafsi mpya wa
KEY_ALG_RSA_2048
kwa kila rasilimali ya akaunti ya huduma ambayo imepatikana na ruhusa inayofaa katika sera ya IAM.Endelea kwenye kila akaunti mpya ya huduma na unda
JWT
kitu kwa hiyo ambayo inajumuisha sifa za ufunguo binafsi wa SA na wigo wa OAuth. Mchakato wa kuunda kitu cha JWT kipya utaendelea kwenye mchanganyiko wote wa sasa wa viwango vya OAuth kutoka kwenye orodha ya oauth_scopes.txt, ili kupata uwezekano wote wa kupeleka. Orodha oauth_scopes.txt inasasishwa na viwango vyote vya OAuth ambavyo tumegundua kuwa muhimu kwa kutumia vibaya utambulisho wa Workspace.Mbinu ya
_make_authorization_grant_assertion
inaonyesha umuhimu wa kutangaza mtumiaji wa eneo la kazi wa lengo, unaoitwa subject, kwa kuzalisha JWT chini ya DWD. Ingawa inaweza kuonekana kuwa inahitaji mtumiaji maalum, ni muhimu kuelewa kuwa DWD inaathiri kila utambulisho ndani ya kikoa. Kwa hivyo, kuunda JWT kwa mtumiaji yeyote wa kikoa kuathiri utambulisho wote katika kikoa hicho, kulingana na ukaguzi wetu wa mchanganyiko. Kwa ufupi, mtumiaji mmoja sahihi wa Workspace ni wa kutosha kuendelea mbele. Mtumiaji huyu anaweza kufafanuliwa katika faili ya config.yaml ya DeleFriend. Ikiwa mtumiaji wa eneo la kazi wa lengo hajulikani tayari, zana inarahisisha kutambua moja kwa moja watumiaji sahihi wa eneo la kazi kwa kutafuta watumiaji wa kikoa wenye majukumu kwenye miradi ya GCP. Ni muhimu kutambua (tena) kuwa JWTs ni maalum kwa kikoa na sio yanayoundwa kwa kila mtumiaji; hivyo, mchakato wa moja kwa moja unalenga utambulisho mmoja wa kipekee kwa kikoa.Tambua na unda tokeni mpya ya ufikiaji wa mwavuli kwa kila JWT na thibitisha tokeni dhidi ya API ya tokeninfo.
Gitlab wameunda skripti hii ya Python ambayo inaweza kufanya mambo mawili - kuorodhesha saraka ya mtumiaji na kuunda akaunti mpya ya utawala huku ikionyesha json na sifa za SA na mtumiaji wa kujifanya. Hapa ndio jinsi unavyoweza kuitumia:
Unda ujumbe mpya (Uthabiti)
Inawezekana kuchunguza Uteuzi wa Upanuzi wa Kikoa kwenye https://admin.google.com/u/1/ac/owl/domainwidedelegation.
Mshambuliaji mwenye uwezo wa kuunda akaunti za huduma katika mradi wa GCP na mamlaka ya super admin kwa GWS anaweza kuunda ujumbe mpya kuruhusu SAs kujifanya kuwa baadhi ya watumiaji wa GWS:
Kuzalisha Akaunti Mpya ya Huduma na Jozi ya Muhimu Inayolingana: Kwenye GCP, rasilimali mpya za akaunti ya huduma zinaweza kuzalishwa kwa njia ya mwingiliano kupitia kiolesura au kwa kutumia wito wa API moja kwa moja na zana za CLI. Hii inahitaji jukumu la
iam.serviceAccountAdmin
au jukumu lolote la desturi lenyeruhusa ya iam.serviceAccounts.create
. Mara akaunti ya huduma inapoundwa, tutasonga mbele kuzalisha jozi ya muhimu inayohusiana (ruhusa yaiam.serviceAccountKeys.create
).Uundaji wa ujumbe mpya: Ni muhimu kuelewa kwamba jukumu la Super Admin pekee lina uwezo wa kuanzisha ujumbe wa kikoa wa ulimwengu katika Google Workspace na ujumbe wa kikoa wa ulimwengu hauwezi kuwekwa kwa njia ya programu, Unaweza tu kuundwa na kurekebishwa kwa mikono kupitia konsoli ya Google Workspace.
Uundaji wa sheria unaweza kupatikana chini ya ukurasa Mipangilio ya API → Simamia Upanuzi wa Kikoa wa Ulimwengu katika konsoli ya Usimamizi wa Google Workspace.
Kuambatisha ruhusa za OAuth scopes: Wakati wa kusanidi ujumbe mpya, Google inahitaji vigezo 2 tu, Kitambulisho cha Mteja, ambacho ni Kitambulisho cha OAuth cha Rasilimali ya Akaunti ya Huduma ya GCP na OAuth scopes ambazo hufafanua wito wa API ambao ujumbe unahitaji.
Orodha kamili ya OAuth scopes inaweza kupatikana hapa, lakini hapa kuna mapendekezo:
https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/admin.directory.group, https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.domain, https://mail.google.com/, https://www.googleapis.com/auth/drive, openid
Kutenda kwa niaba ya kitambulisho cha lengo: Kufikia hatua hii, tuna kitu kilichotekelezwa kwa niaba katika GWS. Sasa, kwa kutumia muhimu ya faragha ya Akaunti ya Huduma ya GCP, tunaweza kufanya wito wa API (katika wigo uliofafanuliwa katika vigezo vya OAuth scope) kuzindua na kutenda kwa niaba ya kitambulisho chochote kilichopo katika Google Workspace. Kama tulivyojifunza, akaunti ya huduma itazalisha vivuli vya ufikiaji kulingana na mahitaji yake na kulingana na ruhusa anayo kwa maombi ya REST API.
Angalia sehemu iliyopita kwa zana za kutumia ujumbe huu.
Ujumbe wa Msalaba wa Shirika
Kitambulisho cha OAuth SA ni cha ulimwengu na kinaweza kutumika kwa ujumbe wa msalaba wa shirika. Hakuna kizuizi kilichotekelezwa kuzuia ujumbe wa msalaba wa ulimwengu. Kwa maneno rahisi, akaunti za huduma kutoka kwa mashirika tofauti ya GCP zinaweza kutumika kuanzisha ujumbe wa kikoa wa ulimwengu kwenye mashirika mengine ya Workspace. Hii ingesababisha hitaji la ufikiaji wa Super Admin tu kwa Workspace, na sio ufikiaji wa akaunti sawa ya GCP, kwani adui anaweza kuunda Akaunti za Huduma na muhimu za faragha kwenye akaunti yake ya GCP inayodhibitiwa kibinafsi.
Kuunda Mradi wa kuhesabu Workspace
Kwa chaguo-msingi watumiaji wa Workspace wanayo ruhusa ya kuunda miradi mipya, na wakati mradi mpya unapoanzishwa mjenzi anapata jukumu la Mmiliki juu yake.
Hivyo basi, mtumiaji anaweza kuunda mradi, kuwezesha APIs kuhesabu Workspace katika mradi wake mpya na kujaribu kuhesabu.
Ili mtumiaji aweze kuhesabu Workspace pia anahitaji ruhusa za kutosha za Workspace (si kila mtumiaji ataweza kuhesabu saraka).
Angalia uchambuzi zaidi katika:
GCP - IAM, Principals & Org Policies EnumKutumia Gcloud
Unaweza kupata habari zaidi kuhusu mchakato wa gcloud
kuingia katika:
Kama ilivyoelezwa hapo, gcloud inaweza kuomba wigo wa https://www.googleapis.com/auth/drive
ambao ungeiruhusu mtumiaji kupata ufikivu wa diski ya mtumiaji.
Kama muhalifu, ikiwa umefanikiwa kimwili kompyuta ya mtumiaji na mtumiaji bado ameingia kwenye akaunti yake unaweza kuingia kwa kutengeneza token na ufikivu wa diski kwa kutumia:
Ikiwa mshambuliaji anachukua udhibiti wa kompyuta ya mtumiaji, anaweza pia kuhariri faili google-cloud-sdk/lib/googlecloudsdk/core/config.py
na kuongeza kwenye CLOUDSDK_SCOPES
wigo wa 'https://www.googleapis.com/auth/drive'
:
Hivyo, wakati mtumiaji atakapoingia tena atatengeneza token yenye ufikiaji wa gari ambao mshambuliaji anaweza kutumia kufikia gari. Kwa dhahiri, kivinjari kitaeleza kuwa token iliyoundwa itakuwa na ufikiaji wa gari, lakini kwa kuwa mtumiaji atajiita mwenyewe gcloud auth login
, labda hatafahamu chochote.
Kutaja faili za gari: curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"
Kutoka GWS kwenda GCP
Kufikia watumiaji walio na mamlaka ya GCP
Ikiwa mshambuliaji ana ufikiaji kamili juu ya GWS ataweza kufikia vikundi vyenye ufikiaji wa mamlaka juu ya GCP au hata watumiaji, hivyo kuhamia kutoka GWS kwenda GCP kawaida ni "rahisi" tu kwa sababu watumiaji katika GWS wana mamlaka makubwa juu ya GCP.
Kupandisha Mamlaka ya Vikundi vya Google
Kwa chaguo-msingi, watumiaji wanaweza kujiunga kwa hiari na vikundi vya Workspace vya Shirika na vikundi hivyo vinaweza kuwa na ruhusa za GCP zilizopewa (angalia vikundi vyako katika https://groups.google.com/).
Kwa kutumia google groups privesc unaweza kuweza kupanda hadi kikundi chenye aina fulani ya ufikiaji wa mamlaka kwa GCP.
Marejeo
Last updated