Sådan får du adgang til din AWS-konto

(Nicolo Marchesi) (3. december 2020)

Sådan får du adgang til din AWS-konto

Hej der. Du har lige oprettet din første AWS-konto, og du kan ikke vente med at dykke ned i alle de spændende tjenester og teknologier, som AWS har at tilbyde dig for at begynde at bygge den næste store ting. Men vent et øjeblik … skal du logge ind med dine root-kontooplysninger? Eller er det bedre at generere en ny bruger? Eller måske bruge en rolle?

Sænk et minut, og i slutningen af ​​blogindlægget lover jeg, at du vil være i stand til at vælge den bedste måde for at få adgang til din AWS-konto sikkert .

Vær dog opmærksom på, at vi overvejer adgang til en enkelt aws-konto, da vi vil dække strategier med flere konti næste gang . Vi er nødt til at gå, før vi kan løbe, ikke?

Konti og ressourcer

Hver utrolig rejse med AWS starter med konti og ressourcer, og en konto er ligesom en tom kasse.

De ting, du kan placere i din konto, kan være alt, hvad der er relateret til AWS tjenester, for eksempel netværk, virtuelle maskiner, containere og så videre.

Men den mest afgørende del er, at som standard deler ingen konto nogen ressource, så intet kan gå ind eller ud mellem to forskellige AWS-konti. Og det er fantastisk at opdele dine arbejdsbelastninger og være sikker på, at kun de rigtige personer har adgang til alt.

IAM – Identitet & Adgangsadministration

Inden for hver konto er IAM der for at beskytte ressourcerne i din konto ved at styre, hvilke enheder der kan udføre nogle handlinger på disse ressourcer:

  • HVEM – hvilke identiteter
  • HVAD – kan udføre nogle handlinger
  • HVOR – på nogle ressourcer
  • HVORDAN – og opfyldte nogle betingelser

Jeg definerer disse som 4W , og indtil videre skal vi kun fokusere på de første 3.

I starten – rodbrugeren

Når du loggede ind, efter at du oprettede AWS-kontoen, brugte du den konto rodbruger .

Det er forskelligt fra de andre, du kan oprette, fordi:

  • Oprettet ved kontoregistrering
  • Dig kan logge ind ved hjælp af den e-mail-adresse og adgangskode, du brugte til at oprette kontoen
  • Du kan få adgang til faktureringsoplysningerne
  • Det har ubegrænset adgang til alle ressourcer på din konto

Denne bruger er super vigtig, og du skal beskytte den på den bedste måde, du kan. Det er en superadministrator på steroider, da det er i stand til at se faktureringsoplysningerne sammen med at være i stand til at gøre alt med alle dine ressourcer.

Så den første ting at gøre skal være:

  • Aktivér multifaktorautentificering (MFA), og gem QR-koden et sikkert sted
  • Slet alle adgangsnøgler relateret til denne bruger for at deaktivere programmatisk adgang (du har ikke brug for det alligevel!)

Og den næste ting skal være at beslutte, hvordan du får adgang til denne konto fra nu af.

Indefra AWS

Lad os lige nu fokusere på, hvad AWS giver os uden at stole på 3. part. Dette er især nyttigt, hvis vi fokuserer på denne enkelt konto, fordi vi har brug for at beherske de tre IAM-byggesten: bruger, grupper og roller.

Brugere

Kan du huske rodbrugeren? IAM-brugere er den samme type enhed, men forskelligt fra rodbrugeren. De har ikke standardfaktureringstilladelser og administratoradgang (medmindre du giver dem … som du ikke burde).

Med en bruger kan vi oprette en enhed, der kan logge på AWS webkonsol. eller med programmatisk adgang gennem et sæt legitimationsoplysninger (en adgangsnøgle og en hemmelig adgangsnøgle), der er faste og ikke vil ændre sig over tid. Sammen med SSH / HTTPS-nøgler til AWS CodeCommit eller legitimationsoplysninger til Amazon-nøglerum (til Apache Cassandra)

  • Login-legitimationsoplysninger til webkonsollen
  • Adgangs- og hemmelige nøgleoplysninger til programmatisk adgang til APIer, CLI og SDK
  • SSH / HTTPS nøgler til AWS CodeCommit
  • legitimationsoplysninger til Amazon nøglerum (til Apache Cassandra)

Kornet adgang

Det er fuldt ud muligt med en IAM-bruger at aktivere en eller flere adgangsnøgler afhængigt af hvordan du vil have denne bruger til at opføre sig.For eksempel:

  • En dataanalytiker, der kun skal kontrollere analyserne på webkonsollen, men uden behov for programmatisk adgang
  • En serverfri DevOps, der skal udføre handlinger på konsol og brug CLI til at give nogle ressourcer har brug for begge disse adgang
  • En udvikler, der arbejder på et enkelt arkiv og ikke behøver at interagere med AWS-ressourcer, vil have SSH / HTTPS-nøgler til AWS CodeCommit.

Vær opmærksom på, at deling IAM-brugeroplysninger er et stort nej-nej, , da det er det første skridt til at miste legitimationsoplysninger og styring og lægge dig åben for sikkerhedstrusler.

Du don vil du ikke have din produktionskonto slettet til fordel for et komplet sæt bitcoin-minearbejdere, gør du?

Håndhæv sikkerhed

En anden cool funktion hos AWS IAM-brugere er at være i stand til at håndhæve adgangskoden kompleksitet (som standard er ret høj med en længde mellem 8-128 chara cters, mindst 3 specialtegn og ikke at være identiske med dit AWS-kontonavn eller din e-mail-adresse) og adgangskodens udløbstid for at sikre, at dine brugere efter et bestemt tidspunkt vil ændre adgangskoden.

Ovenpå heraf kan du aktivere MFA med forskellige enheder:

  • En virtuel MFA-enhed med en godkendelsesapp installeret på din mobile enhed eller computer
  • En U2F-sikkerhedsnøgle som en YubiKey eller en hvilken som helst anden kompatibel U2F-enhed
  • En anden hardware-MFA-enhed som Gemalto-tokenet

Generelt er der en detaljeret tilgang, da du kan have specifikke midler til hver IAM-bruger .

Hvornår skal du bruge

Hvis du har meget få brugere (mellem 1–5) med præcise tilladelser bundet til hver enkelt, kan IAM-brugere spare lidt tid på den oprindelige konfiguration og konsoladgang. Pas på statiske legitimationsoplysninger , fordi de er væsentlige sikkerhedsspørgsmål, så håndter meget forsigtigt. Eller brug AWS CLI get-session-token til at generere midlertidige legitimationsoplysninger ud fra statiske.

Grupper

Ikke en enhed i sig selv, men IAM-grupper er der for at samle IAM-brugere sammen og give det samme sæt tilladelser til en gruppe brugere. Dette glatter lidt de uslebne kanter af IAM-brugere, men generelt gælder de samme ting, som vi har set for IAM-brugere.

En god ting at huske på er, at en IAM-bruger stadig kan have personlige politikker, mens den er tilknyttet med en gruppe, med den resulterende tilladelse lig fletning af gruppen og personlige.

Dette burde være mere undtagelsen end den typiske arbejdsgang. Med for mange individuelle tilladelser opretter vi mange politikker, der ikke kan vedligeholdes, og vi mister det samlede overblik over tilladelserne på kontoen.

Hvornår skal du bruge

Hvis du har få brugere (mellem 5–15), IAM-grupper kan spare nogle af besværet med at administrere og konfigurere hver IAM-bruger. Men den samme overvejelse som IAM-brugere gælder, så undgå dem, hvis det er muligt, medmindre du bare arbejder på en enkelt konto.

Roller

Og her er vi til AWS-roller. IAM-roller kan have tilladelser (ligesom brugere) og logge på konsollen (igen som brugere …). I stedet for at være entydigt forbundet med en person, kan enhver, der har brug for det, påtage sig en rolle.

Så en person bærer hætten for den rolle, som han vil påtage sig, og

IAM-rollelogoet lige fået meget mere mening, ikke?

Midlertidige legitimationsoplysninger

En anden vigtig forskel fra IAM-brugere er, at IAM-roller ikke har statiske legitimationsoplysninger. Når nogen påtager sig rollerne, genereres og gives et sæt midlertidige legitimationsoplysninger . Det er muligt at tilpasse, hvor længe disse legitimationsoplysninger vil vare og yderligere begrænse adgangen, hvis det er nødvendigt.

Tiden kan indstilles fra 900 sekunder (15 minutter) op til 12 timer, men efter min mening indstilles en time- lang udløb er den bedste kompromis mellem sikkerhed og ydeevne.

CloudTrail-overvågning

Jeg vil nævne dette, fordi nogle mennesker ikke bruger roller, fordi de tror, ​​at de ikke kan revidere, hvad roller kan gøre. Sandheden er, at du kan, og du skal. Ved at aktivere Cloudtrail-overvågning kan du se alle handlinger, der udføres i din konto, så du altid kan vide, hvad der foregår.

Cross Account

Dette vil blive diskuteret mere detaljeret i en anden blog post, da vi fokuserer på enkeltkonti, men i øjeblikket skal du være opmærksom på, at IAM-roller kan bruges til at give adgang til andre IAM-roller eller IAM-brugere.

Og det er utroligt nyttigt.

Indgangspunkt krævet

Og nu for ulemperne. Desværre kan du ikke give direkte adgang til konsollen og midlertidige legitimationsoplysninger til en IAM-rolle. Først skal du have oprettet en bruger eller en sammensat rolle (mere om dette i et par afsnit) for at give adgang til en IAM-rolle.

Hvornår skal man bruge

Altid. Den eneste kendsgerning, at IAM-roller er ikke bundet med statiske legitimationsoplysninger gør dem til den bedste måde at få adgang til din sky. Kombiner dem med evnen til at overvåge IAM-rollehandlinger og håndhæve sikkerhed selv med MFA. Den eneste ulempe er, at det er lidt mere konfiguration, men det er en lav pris at betale efter min mening.

Udefra AWS

Og lad os nu se, hvad vi kan gøre, når vi gå ind i feltet af virksomhedsidentiteter. Jeg henviser til at bruge en identitetsudbyder som en identitetskilde og logge ind med vores virksomheds-e-mail og adgangskode.

Federation

Men hvad mener vi med føderation? På den ene side har vi identitetsudbyderen. Disse systemer indeholder et bibliotek med brugere og noget software, der kan kommunikere gennem specifikke føderationsprotokoller. Alle brugernes data ligger som Identiteter .

På den anden side er der din AWS Konti som en Identitetsforbruger . Den opretholder en henvisning til identiteterne uden at gemme dem. På denne side har vi generelt meget mere detaljerede autorisationsniveauer (tak, IAM!).

føderationen er det tillidsforhold, der gør identitetsforbrugeren i stand til at henvise til identiteterne i identitetsudbyderen.

SAML Federation

Den mest almindelige definition for Security Assertion Markup Language (SAML ) er en åben standard til udveksling af godkendelses- og autorisationsdata mellem parter. Dette betyder, at vi kan bruge vores identiteter til at logge ind på AWS og endda få midlertidige legitimationsoplysninger ved at påtage os roller. Det er en generalistisk tilgang, du kan anvende på næsten alle identitetsudbydere.

Tillidsforholdet

For at oprette sammenslutningen mellem de to parter er vi nødt til at oprette og administrere en IAM-identitetsudbyder . Dette er nødvendigt, fordi det repræsenterer den rigtige identitetsudbyder og holder den delte hemmelighed, der lader de to parter kommunikere. Desuden definerer vi inden for hver rolle, som vores brugere skal påtage sig, en tillidspolitik , der tillader enheder, der er relateret til IAM Identitetsudbyder til at påtage sig rollen:

Brugerdefineret styring

Sagen er, at det at administrere føderationen selv kan være udfordrende og tidskrævende i starten. Der er nogle begreber, der skal forstås godt, og du skal oprette en masse enheder, relationer og brugerdefinerede ting for at få dette til at ske. For at få en idé kan du finde et komplet tutorial eksempel her .

Hvornår skal du bruge

Generelt, dette er en fremragende og kamptestet tilgang, der fungerer i næsten alle tilfælde. Alligevel kan den brugerdefinerede administration af identiteter være vanskelig og tidskrævende for uerfarne mennesker.

Typiske brugssager er, hvis du selv vil administrere dette af sikkerheds- eller overholdelsesformål. Du har ikke adgang til din AWS-organisation, eller AWS SSO understøtter endnu ikke din identitetsudbyder.

AWS SSO

Dette er den skybaserede og administrerede SSO-tjeneste, der lader du forbinder din identitetsudbyder med din AWS-konto.

AWS-organisation

For at oprette AWS SSO skal du konfigurere AWS-organisationer, og indtil videre kan du tænke på det til administrere flere AWS-konti. For at holde tingene korte skal du vide, at opsætning af en AWS-organisation kræver omfattende tilladelser (nemlig rodbrugeren).

Intern identitetslagring

Som standard leverer AWS SSO et bibliotek at gemme dine brugeroplysninger og legitimationsoplysninger til at fungere som identitetsudbyder direkte. Det er dejligt, hvis du ikke allerede har en identitetsudbyder eller ikke vil gå i besvær med at opsætte en.

Ekstern identitetslagring

Men antag, at din organisation allerede bruger nogle Brugerkatalog, som Microsoft Active Directory. I så fald kan du forbinde det til AWS SSO, hvilket eliminerer behovet for at opretholde to forskellige mapper med automatisk klargøring .

Vær dog opmærksom på, at denne funktion kun understøttes af et begrænset sæt identitetsudbydere:

Flerfaktorautentificering

Med AWS SSO, du kan konfigurere en MFA-enhed til dine brugere i tjenesten. Lige nu understøtter den Authenticator-apps som Google Authenticator og sikkerhedsnøgler som Yubikey. Den interne løsning er spændende, men den mangler MFA-support, hvis den er konfigureret på en ekstern Identity Provider-side.

Hvornår skal man bruge

Det er den standard, som AWS foreslår, og det kan være standardvejen at gå, hvis man er usikker på, hvordan man fortsætter. Der er stadig mindst et par krav, som du har brug for, for at få mest muligt ud af denne løsning:

Du har allerede oprettet din AWS-organisation, og har du adgang til rodkontoen. Du vil beholde dine identiteter inden for AWS SSO eller bruge en identitetsudbyder, der understøttes af automatisk klargøring.

Afsluttende noter

Så vi har lagt grundlaget for at få adgang til en enkelt AWS-konto, og nu skal du have elementerne til at vælge den bedste metode til din specifikke brugssag. Vi vil bruge dette til at dække grundlaget for multikontostyring og AWS-organisationer i det næste blogindlæg.

Leapp

Som en sidste note anbefaler jeg alle at bruge et værktøj, der hjælper dem med at gemme alle de data, der er nødvendige for at oprette forbindelse til deres AWS-konto. Mit team og jeg udvikler et open source-værktøj, der understøtter alle disse brugssager, så er du velkommen til at tjekke ud:

Noovolari / leapp

Leapp er din daglige følgesvend for at få adgang til din sky; designet til at arbejde med Cloud Providers APIer, CLIer og SDKer. Det er …

github.com

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *