Një postim në lidhje me çelësat AWS Access duke pasur parasysh sigurinë

Është koha për të folur për çelësat AWS Access. Në ekipin e Teknologjisë së Blerësit të drejtpërdrejtë në Grupin LEGO ne po shkojmë drejt praktikave më të mira të sigurisë duke u dhënë inxhinierëve tanë një gjë më pak për t'u shqetësuar dhe duke hequr çelësat e tyre personalë AWS Access (dhe duke e bërë procesin e marrjes së çelësave të përkohshëm po aq të lehtë sa ekzekutimi i një komande ).

Këtu janë disa pyetje për ju:
1. A keni akses në një llogari të Shërbimeve Ueb në Amazon (AWS)?
2. A keni ndonjë çelës aksesi AWS?
3. Nëse keni , a i mbroni ato në mënyrë strikte sa fjalëkalimet tuaja të tjera?
4. Pika bonus: A i keni rrotulluar çelësat që kur i keni marrë?

Nëse i jeni përgjigjur jo dy pyetjeve të fundit, atëherë mund të keni kuptuar pse heqja e çelësave të zhvilluesve tanë në mbretërinë (AWS) është një gjë e mirë.

Këshillë: Tastet e hyrjes AWS mbrojnë të njëjtin nivel aksesi si emri juaj i përdoruesit dhe fjalëkalimi

Ky artikull përshkruan se si i kemi zëvendësuar ato me diçka më të sigurt dhe më të përshtatshme me praktikat më të mira të AWS me sa më pak fërkime të jetë e mundur.

LEGO.com është pritur tërësisht në AWS dhe një pjesë e madhe e ekipit tonë inxhinierik mbi 30 po punojnë në ndërtimin dhe mirëmbajtjen e shërbimeve tona pa server. Kjo do të thotë se ata kërkojnë nivele të ndryshme aksesi në llogaritë tona AWS.

Së pari, pse ia vlen të mbrohet një llogari AWS?

AWS ofron një koleksion të gjerë shërbimesh dhe burimesh sipas kërkesës që u mundëson kompanive dhe zhvilluesve të bëjnë shumë gjëra nga thjesht ruajtja e imazheve ose të dhënave deri tek shërbimi i lojërave masive me shumë lojtarë për një audiencë globale, ose në rastin tonë, duke pritur një faqe globale të tregtisë elektronike dhe përpunimi i backend-it pas tij.

Kjo do të thotë që këto llogari mbajnë shumë gjëra me interes, si informacione të identifikueshme personale, detaje të kartës së kreditit dhe veçanërisht në rastin tonë, imazhe të klasifikuara për produkte të papublikuara.

Jo vetëm që mbledhja e të dhënave është një minierë e mundshme ari për këdo që nuk duhet të ketë akses, por edhe modeli i pagesës për përdorim do të thotë që kur është karta juaj e kreditit në linjë, edhe ju do të dëshironit të kufizoni se kush mund të grumbullojë potencialisht skedë me makinat e minierave të bitcoin.

Nga këndvështrimi i korporatës, aksesi i paautorizuar mund të çojë në

  • Dëmtimi i reputacionit
  • Koha e ndërprerjes së sitit

Pra, si mund t'i mbrojmë llogaritë tona?

Në përgjithësi, ekzistojnë dy metoda të kontrollit të aksesit në AWS:

  1. Kontrolli i aksesit në nivelin e burimit (Politikat mbi burimin që përcaktojnë se kush mund t'i qaset atij)
  2. Kontrolli i qasjes në nivelin e përdoruesit (Politikat e aplikuara për llogaritë/rolet e përdoruesve për të kufizuar atë që ata mund të bëjnë)

Ne do të përqendrohemi në pikën e dytë pasi është më e gjera dhe përfshin shumicën e faktorëve jashtë kontrollit tonë si administrator AWS.

Bazat e Menaxhimit të Përdoruesit AWS

Le të supozojmë se duam të ruajmë në mënyrë të sigurt disa imazhe në një kovë S3 në një llogari të re AWS.

Në AWS ju krijoni një "përdorues rrënjë" kur hapni një llogari të re. Ky përdorues rrënjësor është administratori super i fuqishëm që mund të bëjë absolutisht gjithçka dhe nuk mund të kufizohet. Si gjithmonë, AWS ka në mendje sigurinë dhe ka një listë kontrolli në tastierën e Menaxhimit të Identitetit dhe Qasjes (IAM), e cila përfshin përcaktimin e politikave të fjalëkalimit dhe sigurimin e llogarisë suaj të përdoruesit rrënjë me Autentifikimin me shumë faktorë (MFA) në mënyrë që vetëm ju (ose dikush me fjalëkalimi juaj dhe gjeneratori i shenjave) mund të identifikohet dhe të fitojë këto privilegje super të fuqishme.

Është praktika më e mirë që të përdorni llogarinë e përdoruesit rrënjë vetëm kur ju duhet absolutisht dhe të përdorni shërbimin IAM për të krijuar llogari të tjera përdoruesish me privilegj më të ulët për përdorimin tuaj të përditshëm. Le të themi se keni krijuar një përdorues administratori për veten tuaj dhe një përdorues që Bob të ngarkojë gjithashtu imazhe në llogarinë tuaj. Llogaria juaj tani do të duket diçka si kjo:

Shërbimi IAM i AWS zbërthen Kontrollin e Qasjes së Nivelit të Përdoruesit në Përdorues, Politika, Grupe dhe Role.

Përdoruesit

Një përdorues është një burim që përmban një emër përdoruesi dhe fjalëkalim që identifikon në mënyrë unike një përdorues fizik, duke përfshirë çelësat e aksesit të krijuar për të hyrë në konsolën AWS dhe/ose API-të.

Ka një ngarkesë të tërë cilësimesh sigurie të disponueshme rreth burimit të përdoruesit, si politikat e fjalëkalimit, vërtetimi me shumë faktorë dhe aktivizimi ose çaktivizimi i çelësave të hyrjes, por gjëja e rëndësishme që duhet të theksohet këtu është se nuk ka asnjë mënyrë jashtë kutisë për të skadojnë "Çelësat e hyrjes" pas një date ose një kohe të caktuar.

Kjo është për arsye të mirë pasi çelësat e hyrjes përdoren për qasje programatike në burimet AWS, kështu që shpesh do t'i vendosni ato në skedarin tuaj të paracaktuar të kredencialeve AWS dhe më pas do t'i harroni ato. AWS Çelësat e hyrjes janë po aq të rëndësishëm për t'u mbajtur të sigurt sa fjalëkalimi juaj, pasi të dy mbrojnë të njëjtin nivel aksesi në llogarinë tuaj AWS dhe burimet brenda.

politikat

Politikat listojnë veprimet e lejuara ose të mohuara në burimet e specifikuara AWS. Ndërsa mund të krijoni politikat tuaja të përshtatura, ka politika të menaxhuara nga AWS të cilat mbulojnë grupe të zakonshme lejesh si "administratori", i cili ofron të gjitha lejet për të gjitha burimet, ose "CloudWatchReadOnlyAccess" që ofron leje vetëm për lexim për burimet AWS CloudWatch.

Grupet

Grupet ju lejojnë të menaxhoni politikat ose lejet për një grup përdoruesish si një entitet i tërë, në vend që të menaxhoni lejet e të gjithë përdoruesve në mënyrë të pavarur. Kjo bëhet një kursim i konsiderueshëm i kohës pasi të keni më shumë se një person (Përdorues) që ka nevojë për qasje në llogarinë tuaj AWS.

Rolet

Tani, Rolet përdoren pak më ndryshe nga ndërveprimet e drejtpërdrejta të Grupeve, Përdoruesve dhe Politikave. Rolet janë në thelb grupe lejesh që mund të supozohen, qoftë nga shërbime të tjera AWS, ose nga Përdoruesit e Federuar (ku vërtetimi nuk menaxhohet nga AWS). Çelësi këtu është të supozohet se një rol gjeneron çelësat e përkohshëm të hyrjes AWS.

Pra, tani ju keni të paktën dy përdorues në llogarinë tuaj AWS. Një përdorues rrënjësor që keni përdorur për të krijuar një përdorues administratori për mashtrimet tuaja të përditshme AWS dhe një përdorues të devijimit për Bob. Ju keni krijuar një grup për administratorët dhe një grup për zhvilluesit me politika të përshtatshme të bashkangjitura vetëm në rast se duhet t'u jepni më shumë njerëzve qasje në llogarinë tuaj. Grupet janë një mënyrë e shkëlqyer për të menaxhuar një numër të vogël përdoruesish.

Kjo është gjithçka që ju nevojitet për një llogari personale AWS, por çfarë ndodh kur filloni të organizoni projekte dhe duhet të siguroni akses për më shumë zhvillues, testues apo edhe përdorues fundorë? A u besoni atyre që të mbrojnë kredencialet e tyre AWS aq sa dëshironi të mbroni të dhënat dhe burimet tuaja?

Menaxhimi i përdoruesve të korporatës AWS

Pra, le ta zgjerojmë këtë në një mjedis të korporatës me një ekip të plotë prej 30 inxhinierësh që kanë nevojë për nivele të ndryshme aksesi në disa llogari AWS.

Konfigurimi më i zakonshëm i AWS që kam hasur është përdorimi i llogarive të veçanta të dev, testimit dhe prodhimit AWS ku zhvilluesit mund të bëjnë pothuajse çdo gjë në dev dhe testim, por kanë akses vetëm për lexim ose fare në prodhim.

Pra, si e vendosni aksesin e kërkuar për këta 30 inxhinierë në 3 llogari AWS me 3 nivele aksesi? Bazuar në hyrjen time të shkurtër në fillim të artikullit, ka dy mënyra të gjera për të arritur këtë.

opsioni 1

Përdorimi i përdoruesve, grupeve dhe politikave: Krijoni një përdorues të ri AWS për secilin nga 30 zhvilluesit në secilën prej llogarive AWS në të cilat ata kanë nevojë për qasje dhe shtojini ato në grupe me politikat e duhura të bashkangjitura.

Kjo qasje kërkon kohë për t'u konfiguruar dhe do të ketë një kosto të lartë të menaxhimit - përdoruesi në bord/jashtë imbarkimit do të duhet të përfshijë një administrator të llogarisë AWS. Do të thotë gjithashtu që përdoruesit tuaj duhet të mbajnë mend tre fjalëkalime të ndryshme vetëm për këto llogari AWS dhe kjo nuk i përshtatet praktikave të mira të fjalëkalimeve.

Opsioni 2

Përdorimi i roleve: Në një skenar të korporatës, ne të gjithë kemi një hyrje të korporatës që e përdorim për qasje në email dhe intranet. Ne mund të përdorim të njëjtin hyrje për AWS duke vendosur federatën e identitetit (shpjeguar në seksionin tjetër të këtij artikulli) që na mundëson të trashëgojmë role të ndryshme AWS bazuar në grupet e Active Directory (AD) ku jemi në nivelin e korporatës.

Ky opsion i dytë ka shumë përfitime në botën e menaxhimit të përdoruesve. E para është kur një përdorues largohet nga kompania, zakonisht ekziston një politikë për të çaktivizuar përdoruesin e tyre në shërbimin e hyrjes së korporatës dhe kjo automatikisht do të çaktivizojë përdoruesin e tyre nga mundësia për të hyrë në AWS pasi ata nuk mund të vërtetojnë më dhe të marrin rolin me lejet .

Përfitimi i dytë nuk është krijimi i dyfishtë i përdoruesve dhe asnjë fjalëkalim shtesë që përdoruesit të mbajnë mend. Përfitimi i tretë dhe më i rëndësishëm është se kur një përdorues merr një rol, atij mund t'i lëshohen çelësa aksesi të përkohshëm. E mbani mend atë që thashë më parë për asnjë zgjidhje jashtë kutisë për çelësat e Accessit që skadojnë për përdoruesit e AWS?

Qasja e Federuar e Përdoruesit

Mënyra se si ne lidhim serverin tonë të korporatës AD dhe AWS quhet Federata e Identitetit ose Qasja e Federuar e Përdoruesit.

Qasja e Federuar e Përdoruesit është një proces i njohur gjithashtu si një hyrje dhe në thelb është një proces për të transferuar vërtetimin e përdoruesit - dmth. “Identifikohu me GitHub | Facebook | Twitter | …”.

Disa terma kyç për të ditur:

  • Përdoruesi / Klienti: Përdoruesi që dëshiron të identifikohet dhe të përdorë shërbimin
  • Ofruesi i Shërbimit (SP): Shërbimi që përdoruesi dëshiron të aksesojë
  • Ofruesi i Identitetit (IdP): Shërbimi që ofron vërtetimin e përdoruesit dhe tashmë ka të dhëna për përdoruesin për t'i vërtetuar ato

Hidhni një sy imazhit më poshtë për një shembull të Qasjes së Federuar të Përdoruesit në veprim: një përdorues që dëshiron të hyjë në Medium.

Përdoruesi dëshiron të hyjë në Medium për të shkruar një blog. Ofruesi i Shërbimit (SP) në këtë rast është i Mesëm dhe ofron krijimin dhe pritjen e blogut, por nuk dëshiron të menaxhojë hyrjen/autentifikimin e përdoruesit. Ofruesi i Identitetit (IdP) në këtë rast është Google, Facebook ose Twitter dhe ata janë të specializuar në vërtetimin dhe të dhënat e përdoruesve dhe kështu ata i lejojnë shërbimet e tjera t'u dërgojnë kërkesa për të vërtetuar vizitorët në faqet e tyre.

Si e bën këtë Grupi LEGO

Le të ecim përmes procesit të konfigurimit dhe përdorimit të Qasjes së Federuar të Përdoruesit për të hyrë në llogaritë tona AWS.

Hapi i parë është një konfigurim shumë i thjeshtuar dhe më pas ka 4 hapa të nivelit të lartë për procesin aktual të hyrjes:

  1. Krijoni një marrëdhënie besimi
  2. Filloni një përpjekje për hyrje
  3. Vërtetim i suksesshëm
  4. Dërgojini të gjitha në PS
  5. Ju jeni brenda!

1. Krijoni një marrëdhënie besimi

Hapi i parë është krijimi i një marrëdhënie besimi midis IdP dhe SP, në këtë rast serverët tanë LEGO AD dhe llogaritë tona AWS.

Kjo bëhet nga ekipet që kujdesen për IdP dhe SP duke shkëmbyer disa skedarë meta të dhënash.

Në mënyrë tipike, Metadata e SP përmban një hartë të fushave të të dhënave të përdoruesit që do t'i kërkojë kur përdoruesi të vërtetojë me sukses (si emri i përdoruesit, emaili, Grupet AD etj.). Ai do të përmbajë gjithashtu një certifikatë që IdP të verifikojë kërkesën dhe një URL në mënyrë që IdP të dijë se si ta dërgojë përdoruesin përsëri në SP.

Të dhënat meta të IdP zakonisht përmbajnë URL-në ku PS duhet të ridrejtojë përdoruesin për të nisur procesin e hyrjes dhe një certifikatë në mënyrë që PS të mund të verifikojë se përgjigja vjen nga IdP.

Ne kemi krijuar Grupe AD në serverin tonë LEGO AD që korrespondojnë me secilin prej roleve tona AWS në secilën prej llogarive tona AWS. Inxhinierët tanë më pas shtohen në këto grupe AD për t'u dhënë atyre mundësinë për të marrë rolin përkatës AWS në llogarinë përkatëse AWS. Kjo listë e Grupeve AD ku inxhinieri ynë është anëtar është konfiguruar si një nga fushat e të dhënave të përdoruesit në Metadatat tona të SP.

2. Filloni një përpjekje për hyrje

Ekzistojnë dy lloje të Federatës së Identitetit: identifikimi i iniciuar nga SP ose identifikimi i iniciuar nga IdP. Në të dyja llojet, ju po përpiqeni të hyni në PS, por ndryshimi është nëse së pari shkoni te PS (i cili më pas ju ridrejton te IdP për t'u identifikuar) OSE IdP (nëpërmjet një url që i tregon IdP-së se ku keni ndërmend të ridrejtoheni pasi të identifikoheni me sukses).

Me hyrjen e inicuar nga SP, ju shkoni së pari në PS, si në skenarin e Mesëm, ku ju kërkohet mesazhet "Identifikohu me X".

Me hyrjen e inicuar nga IdP, ju shkoni në një URL të veçantë të ofruar nga IdP dhe i dërgoni asaj kredencialet tuaja të hyrjes. Ne përdorim hyrjen e iniciuar nga IdP pasi ka më pak ridrejtime dhe zhvilluesit tanë thjesht shënojnë URL-në ku duhet të lundroni për t'u identifikuar.

Ka disa mënyra për të dërguar detajet e hyrjes, por mënyra se si e bëjmë këtë është duke përdorur NTLM.

NTLM qëndron për Windows NT LAN Manager, por zakonisht njihet si protokoll Windows Challenge/Response. Në thelb është një hap përpara nga Autoriteti Bazë.

Nëse nuk keni dëgjuar për Basic Auth, ky është përcaktimi i një titulli Autorizimi me vlerën e vendosur në fjalën Basic e ndjekur nga një varg i koduar nga Base64 i emrit tuaj të përdoruesit dhe fjalëkalimit të ndarë me dy pika. Është një mënyrë e njohur për të kaluar detajet e hyrjes, por e vetmja "siguri" rreth saj është që fjalëkalimi është i turbullt – çdokush mund ta dekodojë atë në Base64 dhe të marrë kredencialet.

Me NTLM fjalëkalimi nuk transmetohet kurrë. Në fakt, procesi është si më poshtë:

  1. Klienti i dërgon një kërkesë IdP-së për të inicuar hyrjen duke përdorur NTLM
  2. IdP përgjigjet me një varg sfidash që klienti ta kodojë
  3. Klienti e bën këtë duke përdorur fjalëkalimin e Përdoruesit dhe e kthen atë
  4. Më pas IdP mund të përcaktojë nëse kriptimi është bërë duke përdorur fjalëkalimin e saktë

3. Vërtetim i suksesshëm

Nëse Klienti vërteton me sukses me IdP, IdP përgjigjet me detajet që PS renditi në meta të dhënat e tij kur lidhja e besimit u krijua në Hapin 1.

Këto detaje të përdoruesit i dërgohen klientit duke përdorur një protokoll të quajtur SAML (Security Assertion Markup Language). Ky është një standard për komunikimin e të dhënave të Autentifikimit ndërmjet palëve dhe përfshin të gjitha të dhënat që i nevojiten SP-së, duke përfshirë detajet e sesionit, përveç detajeve të kërkuara të përdoruesit. Emrat alternativë për IdP-në dhe PS-në tonë janë përkatësisht Autorizuesi SAML dhe Konsumatori SAML.

4. Dërgojini të gjitha në PS

Përgjigja SAML nga IdP përmbante një listë të Grupeve AD ku Përdoruesi është anëtar. Ne ia paraqesim këtë listë Përdoruesit në mënyrë që ata të zgjedhin rolin që dëshirojnë të marrin. Më pas, ne e dërgojmë këtë përzgjedhje dhe të gjithë përgjigjen SAML në PS për verifikimin dhe inicializimin e sesionit të përdoruesit.

Me AWS ne i dërgojmë kërkesën Shërbimit Secure Token (STS) për të marrë rolin e zgjedhur të AWS.

"Shërbimi i Tokenit të Sigurisë AWS (STS) është një shërbim ueb që ju mundëson të kërkoni të përkohshme kredenciale me privilegje të kufizuar për përdoruesit e AWS Identity and Access Management (IAM) ose për përdoruesit që ju vërtetoni (përdorues të federuar )»

Ekzistojnë tre metoda që mund të përdorni për të marrë një rol:

  • AssumeRole - zakonisht për qasje në llogari
  • AssumeRoleWithSAML — për përdoruesit që kanë vërtetuar me një përgjigje SAML
  • AssumeRoleWithWebIdentity — Përdoruesit që kanë vërtetuar me një përgjigje të pajtueshme me OpenId Connect dmth. Cognito, Facebook, Google

Meqenëse marrim një përgjigje SAML, ne thërrasim metodën AWS STS AssumeRoleWithSAML për të marrë rolin tonë të zgjedhur AWS.

5. Jeni brenda!

PS krijon një seancë për ju në shërbimin e tyre dhe në rastin tonë përgjigjet me çelësat e përkohshëm të hyrjes AWS me lejet e përcaktuara nga Roli që keni marrë dhe me kohën e seancës të përcaktuar nga minimumi i kohëzgjatjes së kërkuar në kërkesën AWS STS AssumeRoleWithSAML ose kohëzgjatja maksimale e konfiguruar në Rolin AWS.

Nga këndvështrimi i një përdoruesi

Ky proces zgjidh problemin e të paturit të çelësave të përhershëm AWS në kompjuterin tuaj, por nuk do të miratohet nëse është i vështirë për t'u përdorur - ose shumë më i vështirë se një sekret i caktuar dhe i harruar. Le të shohim se çfarë përjeton në të vërtetë Përdoruesi kur kalon procesin e hyrjes.

Për të hyrë në AWS në një shfletues, ne thjesht shkojmë te URL-ja speciale për hyrjen e inicuar nga IdP - kjo do të thotë (2) shfletuesi ynë lidhet me ofruesin e identitetit për t'u vërtetuar dhe (3) përgjigja e suksesshme i paraqitet më pas përdoruesit për zgjedhjen e rolit përpara se të kaloni (4) te ofruesi i shërbimit (AWS), i cili verifikon se përgjigja ka ardhur nga ofruesi i besuar i identitetit përpara (5) duke ju lejuar të vazhdoni te konsola AWS.

Nga këndvështrimi i përdoruesit, kjo do të thotë (2) klikoni në URL-në e shënuar dhe identifikohuni në heshtje duke përdorur një hyrje në (SSO), (3) të paraqitur me një listë rolesh dhe llogarish AWS bazuar në grupet AD të përdoruesit, (4) përzgjedhja e rolin e dëshiruar, (5) akses në tastierën AWS me lejet e atij roli.

Për aksesin e linjës së komandës në AWS ndiqet një proces i ngjashëm, por pa ridrejtime të shfletuesit që e bëjnë procesin e hyrjes në shfletues kaq të qetë. Pra, ne krijuam një mjet CLI!

Mjeti ynë CLI

AWS tashmë ofron një "Mjet të linjës së komandës të shkruar në Python" që trajton rrjedhën e identifikimit të përdoruesit të federuar. Meqenëse i gjithë grumbulli ynë është i shkruar në Node.js, ne krijuam një skript ekuivalent të shkruar në Node.js dhe ia furnizuam zhvilluesve tanë si një paketë NPM nga Regjistri ynë i Paketave GitHub.

Kjo i lejon zhvilluesit tanë të qëndrojnë në kontekstin e terminalit të tyre të preferuar dhe të gjenerojnë automatikisht çelësat e përkohshëm të aksesit AWS që mund t'i përdorin menjëherë për të thirrur AWS API.

Si duket

Mjeti ynë CLI quhet "oktan" sipas monorepos tonë kryesor. Komanda e hyrjes oktan aktivizon fluksin e hyrjes të inicuar nga IdP për të kërkuar dhe marrë çelësat e përkohshëm të hyrjes AWS.

Fillimisht përdoruesit i kërkohet emri i përdoruesit dhe fjalëkalimi dhe më pas kërkesa e parë dërgohet te serverët tanë të korporatës AD. Nëse merret një përgjigje e suksesshme, atëherë njoftoni përdoruesin se është identifikuar me sukses.

Përdoruesit më pas i paraqitet një listë mjedisesh (nuk tregohet në pamjen e ekranit pasi lista zëvendësohet me përzgjedhjen, "dev" në këtë rast). Këto mjedise lidhen me llogaritë tona të ndryshme AWS që i kemi krahasuar me emra të dobishëm të formatit ‹project›-‹env›.

Kur një mjedis është zgjedhur, përdoruesit i paraqitet një listë rolesh që ai mund t'i marrë nëse ka më shumë se një zgjedhje. Nëse ata kanë vetëm një rol të përshtatshëm, atëherë ai rol zgjidhet automatikisht dhe kërkesa për AWS dërgohet menjëherë.

Nëse merret një përgjigje e suksesshme, atëherë ne i tregojmë përdoruesit se ata janë identifikuar me sukses në AWS, që do të thotë se ata morën me sukses rolin e zgjedhur dhe se çelësi i hyrjes dhe sekreti AWS janë ruajtur në profilin e tyre të "parazgjedhur" awscli.

Vlen gjithashtu të përmendet se kemi disa parametra opsionale për të rregulluar sjelljen e paracaktuar. Ato kryesore janë:

  • kohëzgjatja e seancës - sa kohë zgjasin kredencialet tuaja përpara se të skadojnë
  • profili — një profil alternativ awscli për të ruajtur kredencialet

Si punon

Fragmenti nga zbatimi ynë më poshtë duhet të ketë kuptim bazuar në procesin e përshkruar më sipër.

Së pari ne dërgojmë një kërkesë identifikimi në pikën tonë përfundimtare të hyrjes të iniciuar nga IdP. Serveri ynë ADFS më pas përgjigjet me pohimin SAML i cili përfshin një listë të llogarive dhe roleve AWS që përdoruesi lejohet të marrë në bazë të grupeve AD ku ata janë anëtar.

Më pas i listojmë këto role që përdoruesi të zgjedhë rolin e dëshiruar dhe në fund dërgojmë thirrjen AWS STS AssumeRoleWithSAML në AWS. Përgjigja ndaj kësaj është një çelës i përkohshëm dhe sekret i hyrjes AWS, të cilin e kemi vendosur për përdoruesin në profilin e tyre të paracaktuar të awscli.

Përmbledhje

  • Çelësat e hyrjes AWS janë sekrete
  • Krijimi i përdoruesve të AWS IAM për përdorues individual kërkon kohë, rezulton në një fjalëkalim tjetër që përdoruesi duhet të mbajë mend/ruajtur dhe ka mirëmbajtje shpenzime (hapa shtesë për hipje/jashtë hipjes).
  • Çelësat e hyrjes AWS të lëshuara për përdoruesit e AWS IAM nuk skadojnë kurrë derisa të çaktivizohen/fshihen.
  • Supozimi i roleve AWS përfshin lëshimin e të përkohshëm çelësave të hyrjes AWS.
  • Federata e Identitetit është ekzistenca e një marrëdhënie besimi midis dy shërbimeve, një Ofruesi i Identitetit (IdP) dhe një Ofruesi i Shërbimit (SP).
  • Federata e identitetit midis grupeve tona të korporatës AD dhe roleve tona AWS do të thotë që ne mund të përdorim të dhënat tona të hyrjes së korporatës për të marrë një rol AWS dhe për të marrë çelësat e përkohshëm të hyrjes AWS,
  • Kjo do të thotë që zhvilluesit tanë nuk kanë çelësa të aksesit personal AWS jetëgjatë që, nëse zbulohen, mund të japin akses të padëshiruar në një nga llogaritë tona AWS,
  • Ne krijuam një mjet Node.js CLI për t'u mundësuar zhvilluesve tanë të kërkojnë lehtësisht këta çelësa të përkohshëm të hyrjes AWS.

Shpresoj që ky postim të ketë paraqitur pikat kryesore të largimit nga përdoruesit vendas të AWS dhe në përdorimin e Roleve AWS dhe Qasjes së Federuar të Përdoruesit për një konfigurim më të sigurt dhe të ulët të mirëmbajtjes për lejimin e aksesit në llogaritë tuaja AWS.

Nicole Yip është një inxhiniere e lartë e infrastrukturës në Grupin LEGO, duke punuar në ekipin që ndërton LEGO.com.