Så här får du tillgång till ditt AWS-konto

(Nicolo Marchesi) (3 dec 2020)

Hur du kommer åt ditt AWS-konto

Hej där. Du skapade just ditt första AWS-konto och du kan inte vänta med att dyka in i alla spännande tjänster och tekniker som AWS har att erbjuda dig för att börja bygga nästa stora sak. Men vänta en stund … ska du logga in med dina root-kontoinformation? Eller är det bättre att generera en ny användare? Eller kanske använda en roll?

Sakta ner en minut och i slutet av blogginlägget lovar jag att du kommer att kunna välja bästa sättet för att få åtkomst till ditt AWS-konto säkert .

Var dock uppmärksam på att vi kommer att överväga tillgång till ett enda aws-konto eftersom vi kommer att täcka flerkontostrategier nästa gång . Vi måste gå innan vi kan springa, eller hur?

Konton och resurser

Varje otrolig resa med AWS börjar med konton och resurser, och ett konto är precis som en tom ruta.

De saker du kan lägga in i ditt konto kan vara vad som helst relaterat till AWS tjänster, till exempel nätverk, virtuella maskiner, containrar och så vidare.

Men det viktigaste är att som standard delar inget konto någon resurs så att ingenting kan gå in eller ut mellan två olika AWS-konton. Och det här är fantastiskt att dela upp dina arbetsbelastningar och vara säker på att bara rätt personer får tillgång till allt.

IAM – Identitet & Access Management

Inom varje konto finns IAM för att skydda resurserna i ditt konto genom att hantera vilka enheter som kan utföra vissa åtgärder på dessa resurser:

  • VEM – vilka identiteter
  • VAD – kan göra några åtgärder
  • VAR – på vissa resurser
  • HUR – och uppfyllde vissa villkor

Jag definierar dessa som 4W , och för tillfället behöver vi bara fokusera på de första 3.

I början – rotanvändaren

När du loggade in efter att du skapade AWS-kontot använde du det kontot root-användare .

Det skiljer sig från de andra du kan skapa på grund av:

  • Skapad vid kontoregistreringen
  • Du kan logga in med e-postadressen och lösenordet som du använde för att skapa kontot
  • Du kan komma åt faktureringsinformationen
  • Det har obegränsad tillgång till alla resurser i ditt konto

Den här användaren är mycket viktig, och du bör skydda den på bästa sätt du kan. Det är en superadministratör på steroider eftersom den kan se faktureringsinformationen tillsammans med att kunna göra allt med alla dina resurser.

Så det första du ska göra bör vara:

  • Aktivera multifaktorautentisering (MFA) och spara QR-koden på ett säkert ställe
  • Ta bort alla åtkomstnycklar relaterade till den här användaren för att inaktivera programmatisk åtkomst (du skulle inte behöva detta ändå!)

Och nästa sak borde vara att bestämma hur du kommer åt detta konto från och med nu.

Inifrån AWS

Låt oss nu fokusera på vad AWS ger oss utan att förlita oss på tredje part. Detta är särskilt användbart om vi fokuserar på detta enskilda konto eftersom vi behöver behärska de tre IAM-byggstenarna: användare, grupper och roller.

Användare

Kom ihåg rotanvändaren? IAM-användare är av samma typ av enhet men skiljer sig från rotanvändaren. De har inte standardfaktureringstillstånd och administratörsbehörighet (såvida du inte ger dem … vilket du inte borde).

Med en användare kan vi skapa en enhet som kan logga in på AWS webbkonsol. eller med programmatisk åtkomst genom en uppsättning referenser (en åtkomstnyckel och en hemlig åtkomstnyckel) som är fasta och inte kommer att ändras över tiden. Tillsammans med SSH / HTTPS-nycklar för AWS CodeCommit eller autentiseringsuppgifter för Amazon-nyckelområden (för Apache Cassandra)

  • Inloggningsuppgifter för webbkonsolen
  • Åtkomst och hemliga nyckeluppgifter för programmatisk åtkomst för API: er, CLI och SDK
  • SSH / HTTPS-nycklar för AWS CodeCommit
  • Referenser för Amazon-nyckelområden (för Apache Cassandra)

Granulär åtkomst

Det är fullt möjligt med en IAM-användare att aktivera en eller flera åtkomstknappar beroende på hur du vill att den användaren ska bete sig.Till exempel:

  • En dataanalytiker som bara behöver kontrollera analyserna på webbkonsolen men utan att behöva programmatisk åtkomst
  • En serverlös DevOps som behöver utföra åtgärder på konsol och använda CLI för att tillhandahålla vissa resurser behöver båda dessa åtkomst
  • En utvecklare som arbetar på ett enda arkiv och behöver inte interagera med AWS-resurser kommer att ha SSH / HTTPS-nycklar för AWS CodeCommit.

Var medveten om att delar IAM-användaruppgifter är ett stort nej-nej, eftersom det är det första steget att förlora referenser och styrning och lägga dig öppen för säkerhetshot.

Du behöver inte vill du inte att ditt produktionskonto ska raderas helt till förmån för en hel uppsättning bitcoin-gruvarbetare? komplexitet (som standard är ganska hög med en längd mellan 8–128 chara cters, minst 3 specialtecken och att inte vara identiska med ditt AWS-kontonamn eller e-postadress) och lösenordets utgångstid för att säkerställa att dina användare efter en viss tid kommer att ändra lösenordet.

På toppen av det kan du aktivera MFA med olika enheter:

  • En virtuell MFA-enhet med en autentiseringsapp installerad på din mobila enhet eller dator
  • En U2F-säkerhetsnyckel som en YubiKey eller någon annan kompatibel U2F-enhet
  • En annan maskinvara MFA-enhet som Gemalto-token

I allmänhet finns det en detaljerad metod eftersom du kan ha specifika medel för varje IAM-användare .

När ska du använda

Om du har väldigt få användare 1–5) med exakt behörighet knuten till var och en, kan IAM-användare spara lite tid på den ursprungliga konfigurationen och konsolåtkomst. Akta dig för statiska referenser eftersom de är väsentliga säkerhetsfrågor, så hantera med yttersta försiktighet. Eller använd AWS CLI-get-session-token för att generera tillfälliga referenser av statiska.

Grupper

Inte en enhet i sig, men IAM-grupper finns för att samla IAM-användare tillsammans och ge samma uppsättning behörigheter till en grupp användare. Detta släpper ut de ojämna kanterna hos IAM-användare, men totalt sett gäller samma saker som vi har sett för IAM-användare.

En trevlig sak att komma ihåg är att en IAM-användare fortfarande kan ha personliga policyer medan de är associerade med en grupp, med det resulterande tillståndet lika med sammanslagningen av gruppen och personliga.

Detta borde vara mer undantag än det typiska arbetsflödet. Med för många individuella behörigheter skapar vi många policyer som inte kan underhållas och förlorar den övergripande översikten över behörigheterna i kontot.

När ska du använda

Om du har få användare (mellan 5–15), IAM-grupper kan spara några problem med att hantera och konfigurera varje IAM-användare. Men samma överväganden som IAM-användare gäller, så om möjligt, undvik dem såvida du inte bara arbetar med ett enda konto.

Roller

Och här är vi för AWS-roller. IAM-roller kan ha behörigheter (precis som användare) och logga in på konsolen (igen som användare …). Istället för att vara unikt associerad med en person kan alla som behöver det ta en roll.

Så en person bär mössan för den roll som han vill ta, och

IAM-rolllogotypen precis fått mycket mer mening, eller hur?

Tillfälliga referenser

En annan viktig skillnad från IAM-användare är att IAM-roller inte har statiska referenser. När någon antar rollerna genereras och ges en uppsättning tillfälliga referenser . Det är möjligt att anpassa hur länge dessa referenser kommer att bestå och ytterligare begränsa åtkomsten om det behövs.

Tiden kan ställas in från 900 sekunder (15 minuter) upp till 12 timmar, men enligt min mening kan du ställa in en timme- lång utgång är den bästa avvägningen mellan säkerhet och prestanda.

CloudTrail-övervakning

Jag nämner detta eftersom vissa människor inte använder roller eftersom de tror att de inte kan granska vad roller kan göra. Sanningen är att du kan, och du borde. Genom att aktivera Cloudtrail-övervakning kan du se alla åtgärder som utförs i ditt konto, så att du alltid kan veta vad som händer.

Cross Account

Detta kommer att diskuteras mer detaljerat i en annan blogg posta, eftersom vi fokuserar på enskilda konton, men för närvarande, var medveten om att IAM-roller kan användas för att ge tillgång till andra IAM-roller eller IAM-användare.

Och det är otroligt användbart.

Ingångspunkt krävs

Och nu för nackdelarna. Tyvärr kan du inte ge direkt åtkomst till konsolen och tillfälliga referenser till en IAM-roll. Först måste du ha konfigurerat en användare eller en federerad roll (mer om detta i några stycken) för att ge åtkomst till en IAM-roll.

När ska jag använda

Alltid. Det enda faktum att IAM-roller är inte bundna med statiska referenser gör dem det bästa sättet att komma åt ditt moln. Kombinera dem med möjligheten att övervaka IAM-rollåtgärder och säkerställa säkerhet även med MFA. Den enda nackdelen är att det är lite mer konfiguration, men det är ett lågt pris att betala enligt min mening.

Utifrån AWS

Och nu, låt oss se vad vi kan göra när vi gå in på företagsidentitetsområdet. Jag hänvisar till att använda en identitetsleverantör som en identitetskälla och logga in med vår företags-e-postadress och lösenord.

Federation

Men vad menar vi med federation? På ena sidan har vi identitetsleverantören. Dessa system innehåller en katalog över användare och en del programvara som kan kommunicera via specifika federationsprotokoll. All information från våra användare finns som Identiteter .

På andra sidan finns din AWS Konto som en Identitetskonsument . Den upprätthåller en hänvisning till identiteterna utan att spara dem. På den här sidan har vi i allmänhet mycket mer detaljerade behörighetsnivåer (tack, IAM!).

federationen är förtroendeförhållandet som gör att Identity Consumer kan hänvisa till Identities i Identity Provider.

SAML Federation

Den vanligaste definitionen för Security Assertion Markup Language (SAML ) är en öppen standard för utbyte av autentiserings- och auktoriseringsdata mellan parter. Det betyder att vi kan använda våra identiteter för att logga in på AWS och till och med få tillfälliga referenser genom att anta roller. Det är ett generalistiskt tillvägagångssätt som du kan använda för nästan alla identitetsleverantörer.

Förtroendeförhållandet

För att ställa in federationen mellan de två parterna måste vi skapa och hantera ett IAM-identitetsleverantör . Detta är nödvändigt eftersom det representerar den verkliga identitetsleverantören och håller den delade hemligheten som låter de två parterna kommunicera. Dessutom definierar vi en förtroendepolicy i varje roll som vi vill att våra användare ska anta, för att tillåta enheter relaterade till IAM Identitetsleverantör som tar rollen:

Anpassad hantering

Saken är att hantera federationen själv kan vara utmanande och tidskrävande först. Det finns några begrepp att förstå väl, och du måste skapa en massa enheter, relationer och anpassade saker för att få detta att hända. För att få en idé kan du hitta ett fullständigt handledningsexempel här .

När ska du använda

I allmänhet, detta är ett utmärkt och stridstestat tillvägagångssätt som fungerar i nästan alla fall. Ändå kan anpassad hantering av identiteter vara svår och tidskrävande för oerfarna människor.

Typiska användningsfall är om du vill hantera detta själv för säkerhets- eller efterlevnadsändamål. Du har inte tillgång till din AWS-organisation, eller AWS SSO stöder ännu inte din identitetsleverantör.

AWS SSO

Detta är den molnbaserade och hanterade SSO-tjänsten som låter dig du ansluter din identitetsleverantör till ditt AWS-konto.

AWS-organisation

För att ställa in AWS SSO måste du konfigurera AWS-organisationer och för tillfället kan du tänka på det till hantera flera AWS-konton. För att hålla saker korta måste du veta att installation av en AWS-organisation kräver omfattande behörigheter (nämligen rotanvändaren).

Intern identitetslagring

Som standard tillhandahåller AWS SSO en katalog för att lagra din användarinformation och referenser för att fungera som identitetsleverantör direkt. Det är jättebra om du inte redan har en identitetsleverantör eller inte vill bry dig om att installera en.

Extern identitetslagring

Men antag att din organisation redan använder en del Användarkatalog, som Microsoft Active Directory. I så fall kan du ansluta den till AWS SSO, vilket eliminerar behovet av att ha två olika kataloger med automatisk provisionering .

Observera dock att den här funktionen endast stöds av en begränsad uppsättning identitetsleverantörer:

Flerfaktorautentisering

Med AWS SSO, du kan konfigurera en MFA-enhet för dina användare i tjänsten. Just nu stöder den Authenticator-appar som Google Authenticator och säkerhetsnycklar som Yubikey. Den interna lösningen är spännande, men den saknar MFA-stöd om den ställs in på en extern Identity Provider-sida.

När ska jag använda

Det är standarden som föreslås av AWS, och det kan vara standardvägen att gå om du är osäker på hur du ska gå vidare. Ändå finns det åtminstone ett par krav som du behöver för att kryssa för att få ut det mesta av den här lösningen:

du har redan konfigurerat din AWS-organisation, och har du tillgång till root-kontot. Du vill behålla dina identiteter inom AWS SSO eller använda en identitetsleverantör som stöds av automatisk provisionering.

Slutliga anteckningar

Så vi har lagt grunden för att få åtkomst till ett enda AWS-konto, och nu ska du ha elementen för att välja den bästa metoden för ditt specifika användningsfall. Vi kommer att använda detta för att täcka grunderna för hantering av flera konton och AWS-organisationer i nästa blogginlägg.

Leapp

Som en sista anmärkning rekommenderar jag alla att använda något verktyg som hjälper dem att lagra all data som behövs för att ansluta till deras AWS-konto. Mitt team och jag utvecklar ett verktyg för öppen källkod som stöder alla dessa användningsfall, så kolla gärna:

Noovolari / leapp

Leapp är din dagliga följeslagare för att komma åt ditt moln; utformad för att fungera med Cloud Providers API: er, CLI: er och SDK: er. Det är …

github.com

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *