AWS krijgt ondersteuning voor passkeys en maakt 2fa verplicht voor rootaccounts

Amazon Web Services voegt ondersteuning toe voor passkeys. Rootaccounts zijn vanaf volgende maand verplicht om multifactorauthenticatie in te schakelen.

Amazon schrijft in een blogpost dat het de mogelijkheden voor tweefactorauthenticatie voor AWS-gebruikersaccounts uitbreidt naar FIDO2-passkeys. Dat zijn cryptografische sleutels die op een apparaat worden opgeslagen en gesynchroniseerd. Tweakers schreef er eerder een achtergrondartikel over. AWS maakt het voor gewone gebruikers en beheerders niet verplicht om passkeys of zelfs tweefactorauthenticatie te gebruiken, maar raadt dat wel aan. Gebruikers die al een vorm van 2fa hebben ingeschakeld, kunnen daar een passkey van maken, maar ook dat is niet verplicht.

Het wordt wel verplicht om 2fa in te stellen voor zogenaamde rootaccounts. Dat zijn de hoofdgebruikers van AWS-accounts die niet door een organisatie worden beheerd. Zij moeten vanaf juli van dit jaar multifactorauthenticatie inschakelen als ze inloggen op de AWS Management Console. Amazon wil dat geleidelijk uitrollen. Er komt een korte periode waarin rootgebruikers een waarschuwing krijgen bij het inloggen. Rootgebruikers binnen AWS Organizations krijgen die verplichting niet.

Reacties (19)

[pOZOR jED]

Mooi dat ze passkey toevoegen! Het aanmelden was altijd een paar keer klikken met 1password, hopelijk nu in 1 klik klaar.

En 2FA op je root account, dat was eigenlijk een nobrainer toch?

[SirDarkAngel]

Als je een nieuw account aanmaakt via Organizations, krijg je geen credentials te zien. In 99% van de gevallen log je niet in op je root account, maar via SSO. Een root account is dan alleen nodig om je account te verwijderen, wat niet mogelijk is via het hoofdaccount. Dit probleem wordt verergerd als je een typfout maakt in het e-mailadres van het nieuwe account, omdat je het account dan niet kunt verwijderen of beheren. Ondertussen kan de persoon met het foutief ingevoerde e-mailadres wel resources aanmaken op jouw kosten.

Idealiter zou er een mogelijkheid moeten zijn om het root account volledig uit te schakelen, maar voor zover ik weet, bestaat deze optie niet of ben ik er niet van op de hoogte. Mijn huidige oplossing is om een account aan te maken, het wachtwoord te resetten en vervolgens MFA in te schakelen. Dit moet toch beter kunnen.

[Hatsjoe]

Een root account is dan alleen nodig om je account te verwijderen, wat niet mogelijk is via het hoofdaccount.

Dat is gelukkig tegenwoordig wel mogelijk, zie: https://docs.aws.amazon.c...anage_accounts_close.html

Idealiter zou er een mogelijkheid moeten zijn om het root account volledig uit te schakelen, maar voor zover ik weet, bestaat deze optie niet of ben ik er niet van op de hoogte.

Er is wel een manier om dat te doen, namelijk met SCPs. Zo kan je een SCP maken waarin je een Deny All op alle services instelt voor het root account, zie ook: https://docs.aws.amazon.c...tml#example-scp-root-user

Mijn huidige oplossing is om een account aan te maken, het wachtwoord te resetten en vervolgens MFA in te schakelen. Dit moet toch beter kunnen.

Dat is wel het beste om momenteel te doen. Zo is de kans op een hack van het root account zo dicht bij de 0% als je kan komen.

[Anonymoussaurus]

Je kan het root account wel gebruiken om role-swaps uit te voeren als je heel veel accounts hebt onder het root account. Binnen het root account wil je alleen geen resources, behalve IAM/Organizations e.d.

[Hatsjoe]

Ik denk dat je "root account" nu verward met het "organizational master" account. Het root account in deze context is het root account waarmee je zou kunnen inloggen in de AWS console met "root" toegang. Iets dat je alleen in hele uitzonderlijke gevallen zal moeten doen, en nooit voor role swaps.

[Anonymoussaurus]

Ik heb even gekeken en ik denk dat je gelijk hebt. Ik kijk nu binnen https://us-east-1.console...izations/v2/home/accounts en zie dat bovenaan idd root staat, maar een van onze accounts heet ook "<bedrijfsnaam>-root", dat helpt niet bepaald mee. Dáár log ik op in en vanuit daar swap ik weer naar test of productie.

[Anonymoussaurus]

Dat zou je wel zeggen ja. Ik vind het ook vreemd dat dat nu pas enforced wordt. Bij IAM users kan je het iig ook enforcen.

Nu is het trouwens nog steeds lacking omdat het binnen AWS Organizations (altijd verstandig om het op die manier in te delen als je meerdere accounts hebt) niet enforced wordt:

Rootgebruikers binnen AWS Organizations krijgen die verplichting niet.

[Reactie gewijzigd door Anonymoussaurus op 23 juli 2024 06:03]

[david-v]

Dat is vreemd, ik dacht dat dat wel verplicht was bij AWS. Bij Azure gaan ze dat voor alle gebruikers die op de portal inloggen verplichte instellen vanaf juli en later ook voor gebruik van cli, powershell en terraform (er is ook veel kritiek hierover). Ik vond dat het best wel lang heeft geduurd voordat Azure dat verplicht stelde maar bij AWS is het blijkbaar ook nog niet (overal) doorgevoerd.

[Anonymoussaurus]

Ik snap de kritiek niet zo om eerlijk te zijn. Het 'assumen' van rollen binnen AWS (ik gebruik Terraform) gaat ook gewoon vlug met een tool als awsume. Daarbij geef ik mijn 2FA-code in en dan is de role-assume X aantal minuten geldig. Als ik dan opnieuw assume door middel van awsume is de rol weer opnieuw geldig.

[david-v]

De kritiek komt vooral vanuit opleidingen waarbij studenten bijvoorbeeld met een "[e-mail]" account inloggen. Je moet dan ook 2fa regelen voor die studenten van de opleiding. Dat vinden ze gedoe.

Ik geef je overigens gelijk, want dit zou juist onderdeel moeten zijn van die opleidingen. Beveiliging moet een basis kennis zijn en moet je niet proberen te omzeilen omdat het alleen maar gedoe is.

[Anonymoussaurus]

Tja, dat is de verkeerde instelling inderdaad. Disappointed, but not surprised. Op mijn opleiding waren er ook veel studenten die gewoon zelfbedachte wachtwoorden (her)gebruiken en geen 2FA gebruiken, dus daarom maar lekker forceren.

[supersnathan94]

Je moet dan ook 2fa regelen voor die studenten van de opleiding. Dat vinden ze gedoe.

Tsja. Zo moeilijk is het niet. Windows hello ondersteund dit toch ook al? Of is dat alleen een macos dingetje die het in de keychain kan doen zodat je alleen biometrics hoeft te doen?

[Sito]

Zijn er ook manieren waarop je dit non-interactive kan doen, zoals in CI/CD pipelines? Zo niet, dan snap ik de kritiek wel.

[Anonymoussaurus]

Ja, idealiter wil je daar een aparte user (of role) voor hebben en vervolgens kan je de access key (met secret) daarvoor gebruiken. Die sla je dan op in GitLab welke je vervolgens aanroept in je CI/CD pipeline.

[Sito]

Dat is inderdaad wat ik verwacht en hoe het zou moeten, maar dat blijven ze dus gewoon toestaan?

[Anonymoussaurus]

Lijkt mij wel ja. In feite is 2FA namelijk ook gewoon een short-living token als je geauthentiseerd bent.

[david-v]

CI/CD pipelines moet je nooit met persoonlijke accounts of tokens doen. Zodra iemand uit dienst gaat heb je een probleem .

Daar heb je andere oplossingen voor. In AWS weet ik niet hoe dat geregeld is, maar in Azure heb je bijvoorbeeld service principals die je gebruikt voor het uitrollen naar Azure.

[Sito]

Nee, 100% eens hoor! Misschien heb ik het niet goed verwoord, maar ik was in de overtuiging dat AWS ook voor die constructie MFA zou forceren omdat er werd aangegeven dat er vanuit de Terraform hoek kritiek op was. Maar non-interactive MFA kan natuurlijk niet.

[FrostyPeet]

Kan het alleen maar toejuichen. Sommige game hosters, b.v. GPortal, bieden het ook aan, QR code met je favoriete authenticatie app.

Is Amazon van een hoop gedoe af bij die gebruikers die doodleuk "admin12345" gebruiken en raar opkijken dat ze binne 1 week gehackt zijn. Wat dan weer de schuld is van Amazon want die hebben de beveiliging niet op orde.

Yubikey is leuk, ze adviseren wel om er twee te kopen voor als er één kwijt raakt of kapot gaat. Moet je die andere wel weer veilig opbergen - en terug weten te vinden