De 2FA van een gedeeld AWS-account beheren

Niemand hoort met een gedeelde inlog op AWS in te loggen. Dagelijkse toegang hoort bij identiteiten per persoon via IAM Identity Center, en automatisering hoort bij rollen en niet bij iets wat een mens intypt.

Blijft de rootgebruiker over, en dat is werkelijk één inlog per account. Nuttig om te weten is dat je ook diens tweede factor niet hoeft te delen: AWS staat toe meerdere MFA-toestellen op de rootgebruiker te registreren, dus twee of drie beheerders kunnen elk het hunne inschrijven. Een TOTP-geheim kopiëren is een terugvaloptie voor de gevallen waarin dat niet kan, niet de standaardkeuze.

Drie verschillende inloggegevens

„Ons AWS-account” betekent meestal een van deze drie dingen, en die hebben verschillende antwoorden.

De rootgebruiker. Eén per account, aangeduid met een e-mailadres, in staat tot alles, inclusief het account sluiten en de facturatie wijzigen. Niet gemaakt voor dagelijks werk.

De identiteiten per persoon. Gebruikers van IAM Identity Center, of IAM-gebruikers in oudere opzetten. Daar wordt het werk echt gedaan, en daar heeft iedereen zijn eigen tweede factor.

De toegangssleutels. Langlevende inloggegevens voor programmatische toegang. Het is geen aanmelding, het is niet door MFA beschermd zoals mensen aannemen, en het is wat je het vaakst in een oude repository terugvindt.

De meeste vragen over „gedeelde AWS-2FA” gaan in werkelijkheid over het eerste, en komen op omdat de andere twee nooit zijn opgezet.

Dagelijks werk: identiteiten per persoon

IAM Identity Center geeft iedereen een eigen aanmelding, een eigen MFA, en tijdelijke inloggegevens op de accounts en rollen waar hij recht op heeft. Toegang wordt per toewijzing verleend in plaats van door iets af te geven, en iemand verwijderen is één handeling op één plek, hoeveel AWS-accounts je ook draait.

Zit je nog op IAM-gebruikers, dan is het minimum één gebruiker per persoon, elk met een eigen MFA-toestel, en geen gedeelde gebruiker voor het team. Een gedeelde IAM-gebruiker heeft alle problemen van een gedeelde rootgebruiker zonder één van diens bestaansredenen.

Voor een bureau dat in het account van een klant werkt, is het equivalent van „nodig me uit” een rol over accounts heen: de klant houdt het eigendom en kan hem op één plek intrekken, en niemand mailt inloggegevens.

Automatisering: rollen, geen aanmeldingen

Alles wat onbewaakt draait zou een rol moeten aannemen in plaats van in te loggen. Op AWS zelf betekent dat instantieprofielen, taakrollen of OIDC-federatie vanuit je CI-aanbieder. Dat zijn tijdelijke inloggegevens, zonder geheim om te bewaren en zonder iets wat een mens moet intypen.

Vraagt een script iemand om een zescijferige code, dan gebruikt het de identiteit van een mens, en het breekt op de dag dat die mens vertrekt.

Langlevende toegangssleutels zijn de andere helft van het onderwerp. Ze zijn afzonderlijk intrekbaar en vernieuwbaar, wat een echt voordeel is boven een TOTP-geheim, maar het zijn ook de inloggegevens die in commits lekken. Houd er weinig en roteer ze volgens een schema dat je echt aanhoudt.

De rootgebruiker: het echte gedeelde account

Root bestaat, meerdere mensen moeten erbij kunnen, en het mag niet afhangen van de telefoon van één persoon.

Registreer meer dan één MFA-toestel

Dit is het eigen antwoord van AWS, en het schrapt de kwestie van het delen helemaal. Schrijf de app of de hardwaresleutel in van elke beheerder die als root moet kunnen handelen. Elk toestel houdt zijn eigen geheim, en geen enkel geheim wordt ooit gekopieerd. Een vertrek is het afmelden van een toestel, niet het resetten van de 2FA van het account en iedereen opnieuw inschrijven.

Waar een hardwaresleutel haalbaar is, is dit de plek waar hij zijn prijs waard is: de tweede factor kan niet gefotografeerd, niet overgedragen en niet gesynchroniseerd worden.

Richt het rootadres op een mailbox die twee mensen kunnen lezen

Het herstel van root loopt via dat adres. De persoonlijke mailbox van een oprichter maakt het account onherstelbaar op de dag dat hij er niet meer is: gebruik een distributielijst of een gedeelde mailbox, en zorg dat wie hem kan lezen mensen zijn aan wie je het herstel van het account zou toevertrouwen, want functioneel is dat wat dit adres verleent.

Verwijder de root-toegangssleutels

Die horen er niet te zijn. Bestaan ze, dan zijn het gedeelde inloggegevens zonder enige MFA ervoor, wat erger is dan al het andere in dit artikel.

Bewaak de rootaanmeldingen

CloudTrail legt ze vast, en een alarm op rootgebruik is gangbare praktijk. Op een gezond account zijn rootaanmeldingen zeldzaam en verklaarbaar, wat ze goedkoop maakt om te bewaken en waardevol om te zien.

Wanneer een gedeeld TOTP-geheim toch het antwoord blijft

Meerdere MFA-toestellen dekken de meeste gevallen. Enkele blijven over:

• Het account van een klant dat je niet beheert, waar je inloggegevens krijgt zonder dat je iets kunt herbouwen.
• Oude of externe consoles rond AWS (een facturatieportaal, een resellerpaneel, een monitoringleverancier) die precies één TOTP-inschrijving accepteren.
• Een noodinlog waarvan je procedure eist dat meerdere mensen hem snel kunnen gebruiken, waar individuele toestellen niet werkbaar zijn.

Daarvoor gelden de eisen van elk gedeeld account: één bewaarplaats voor het geheim, toegang tot de codes per persoon verleend, een logboek van wie een code las, en herstelcodes buiten het account dat ze herstellen. De redenering staat in hoe je 2FA-codes veilig met je team deelt, en de vergelijking van mechanismen in de beste manieren om de 2FA van een gedeeld account te beheren. Dezelfde redenering toegepast op een betaaldienstverlener staat in de 2FA van een gedeeld Stripe-account beheren.

Een noodprocedure die het waard is opgeschreven te worden

Voor root, en voor alles wat alleen in geval van nood dient:

1. Wie hem mag gebruiken, met naam, en wat hem in werking stelt.
2. Waar de inlog en de tweede factor wonen, en hoeveel mensen elk daarvan kunnen bereiken.
3. Waar de herstelcodes zijn, buiten het account dat ze herstellen.
4. Wat bij gebruik een waarschuwing afvuurt, dus het CloudTrail-alarm hierboven.
5. Wat er daarna gebeurt: wie wordt gewaarschuwd, wat wordt nagekeken, wat wordt eventueel vernieuwd.
6. Wanneer ze voor het laatst getest is. Een nooit geoefende procedure wordt ontdekt op de avond dat iemand haar nodig heeft.

Wanneer iemand een AWS-account verlaat

1. Trek zijn Identity Center-toewijzingen in of verwijder zijn IAM-gebruiker.
2. Schakel zijn toegangssleutels uit en verwijder ze, ook die zijn tools gebruikten.
3. Meld zijn root-MFA-toestel af, als hij er een had.
4. Heeft hij ooit een gedeeld TOTP-geheim gehad, reset dan die 2FA en wijzig het bijbehorende wachtwoord. Het geheim verlaat zijn telefoon niet uit zichzelf.
5. Controleer of hij het root-e-mailadres nog kan lezen.
6. Lees CloudTrail terug rond zijn vertrek, op zoek naar het onverwachte.

Stap 5 is degene die men vergeet. Toegang tot de rootmailbox is toegang tot het rootaccount, wat je verder ook hebt ingetrokken.

Waar Share Auth staat

Smal, en bewust. Voor de accounts uit de vorige paragraaf, dus de console van een klant, een extern paneel dat maar één inschrijving accepteert, of een noodinlog: het geheim wordt één keer ingevoerd en versleuteld opgeslagen, de mensen die de codes nodig hebben zien de code en het aftellen in plaats van het geheim, de rechten gelden per lid, en elke raadpleging wordt gelogd.

Voor een AWS-rootgebruiker die je zelf beheert, is een tweede geregistreerd MFA-toestel beter dan alles wat een kluis kan doen, de onze inbegrepen. Doe dat eerst.