Jak získat přístup k účtu AWS

(Nicolo Marchesi) (3. prosince 2020)

Jak získat přístup k účtu AWS

Hej. Právě jste vytvořili svůj první účet AWS a nemůžete se dočkat, až se ponoříte do všech vzrušujících služeb a technologií, které vám AWS nabízí, abyste mohli začít budovat další velkou věc. Ale počkejte chvilku … hodláte se přihlásit pomocí svých přihlašovacích údajů root účtu? Nebo je lepší vygenerovat nového uživatele? Nebo můžete použít roli?

Zpomalte minutu a na konci příspěvku na blogu slibuji, že budete moci zvolit nejlepší způsob pro bezpečný přístup k vašemu účtu AWS .

Pozor však, zvážíme přístup k jednomu účtu AWS, protože příště se budeme zabývat strategiemi více účtů . Než budeme moci běžet, musíme jít, ne?

Účty a zdroje

Každá neuvěřitelná cesta s AWS začíná účty a prostředky a účet je jako prázdné pole.

Věci, které můžete do svého účtu vložit, mohou být cokoli, co souvisí se službami AWS, například sítě, virtuální stroje, kontejnery atd.

Ale nejdůležitější je, že ve výchozím nastavení žádný účet nesdílí žádný zdroj, takže mezi dvěma různými účty AWS nemůže nic vstupovat ani vystupovat. A je skvělé rozdělit vaše pracovní vytížení a mít jistotu, že ke všemu mají přístup pouze správní lidé.

IAM – Identita & Správa přístupu

V každém účtu je IAM k ochraně zdrojů uvnitř vašeho účtu tím, že spravuje, které entity mohou s těmito prostředky provádět určité akce:

  • WHO – které identity
  • CO – může dělat nějaké akce
  • KDE – u některých zdrojů
  • JAK – a splnil některé podmínky

definuji je jako 4W a prozatím se budeme muset soustředit pouze na první 3.

Na začátku – uživatel root

Když jste se přihlásili po vytvoření účtu AWS, použili jste tento účet uživatel root .

To se liší od ostatních, které můžete vytvořit, protože:

  • Vytvořeno při registraci účtu
  • se můžete přihlásit pomocí e-mailové adresy a hesla, které jste použili k vytvoření účtu
  • Můžete získat přístup k fakturačním informacím
  • Má neomezený přístup ke všem zdrojům ve vašem účtu

Tento uživatel je velmi důležitý a měli byste ho chránit tím nejlepším způsobem, jak můžete. Je to superadministrátor na steroidech, protože je schopen zobrazit fakturační údaje a je schopen dělat vše se všemi vašimi prostředky.

Takže první věc, kterou musíte udělat, by měla být:

  • Povolte vícefaktorové ověřování (MFA) a uložte kód QR na bezpečném místě.
  • Chcete-li deaktivovat programový přístup, vymažte všechny přístupové klíče související s tímto uživatelem (stejně byste to nepotřebovali!)

A další věcí by mělo být rozhodnutí, jakým způsobem budete od nynějška přistupovat k tomuto účtu.

Zevnitř AWS

Zaměřme se nyní na to, co nám AWS dává, aniž bychom se museli spoléhat na třetí strany. To je obzvláště užitečné, pokud se zaměříme na tento jediný účet, protože musíme zvládnout tři stavební bloky IAM: uživatele, skupiny a role.

Uživatelé

Pamatujete si uživatele root? Uživatelé IAM jsou stejný typ entity, ale odlišně od uživatele root. Nemají výchozí fakturační oprávnění a přístup správce (pokud jim nedáte… což byste neměli).

S uživatelem můžeme vytvořit entitu, která se může přihlásit k webové konzole AWS. nebo s programovým přístupem prostřednictvím sady přihlašovacích údajů (přístupový klíč a tajný přístupový klíč), které jsou pevné a v průběhu času se nezmění. Spolu s klíči SSH / HTTPS pro AWS CodeCommit nebo pověřeními pro Amazon Keyspaces (pro Apache Cassandra)

  • Přihlašovací údaje pro webovou konzolu
  • Pověření pro přístup a tajný klíč pro programový přístup pro API, CLI a SDK
  • klíče SSH / HTTPS pro AWS CodeCommit
  • pověření pro Amazon Keyspaces (pro Apache Cassandra)

Podrobný přístup

Je zcela možné, aby uživatel IAM povolil jeden nebo více přístupových klíčů podle toho, jak se má daný uživatel chovat.Například:

  • Analytik dat, který potřebuje zkontrolovat pouze analytiku na webové konzoli, ale aniž by potřeboval programový přístup.
  • Bez serveru DevOps, který musí provádět akce na konzole a použití CLI k poskytnutí některých zdrojů bude potřebovat oba tyto přístupy.
  • Vývojář pracující na jediném úložišti a nemusí komunikovat se zdroji AWS bude mít klíče AWS CodeCommit pro SSH / HTTPS.

Uvědomte si, že sdílení pověření uživatele IAM je velké ne-ne, , protože je to první krok ke ztrátě pověření a správy a otevření se bezpečnostním hrozbám.

Nechcete, aby byl váš produkční účet zcela smazán ve prospěch celé sady bitcoinových těžařů, že?

Vynutit zabezpečení

Další skvělou funkcí uživatelů AWS IAM je schopnost vymáhat heslo složitost (která je ve výchozím nastavení docela vysoká s délkou mezi 8–128 znaků cters, minimálně 3 speciální znaky a nemusí být totožné s názvem vašeho účtu AWS nebo e-mailovou adresou) a časem vypršení platnosti hesla, aby bylo zajištěno, že po určité době vaši uživatelé heslo změní.

Nahoře z toho můžete povolit MFA na různých zařízeních:

  • Virtuální MFA zařízení s aplikací ověřovatele nainstalovanou ve vašem mobilním zařízení nebo počítači
  • Bezpečnostní klíč U2F jako YubiKey nebo jakékoli jiné kompatibilní zařízení U2F
  • Další hardwarové zařízení MFA, jako je token Gemalto

Obecně existuje granulární přístup, protože můžete mít specifické prostředky pro každého uživatele IAM .

Kdy použít

Pokud máte velmi málo uživatelů (mezi 1–5) s přesnými oprávněními spojenými s každým z nich mohou uživatelé IAM ušetřit čas při počáteční konfiguraci a přístupu ke konzole. Dávejte pozor na statická pověření , protože jde o zásadní bezpečnostní problémy, proto s nimi zacházejte s maximální opatrností. Nebo použijte AWS CLI get-session-token ke generování dočasných pověření ze statických.

Skupiny

Není to entita sama o sobě, ale skupiny IAM jsou tam, aby spojily uživatele IAM dohromady a udělit stejnou sadu oprávnění skupině uživatelů. To trochu vyhlazuje drsné hrany uživatelů IAM, ale celkově platí stejné věci, jaké jsme viděli pro uživatele IAM.

Pěkná věc, kterou je třeba mít na paměti, je, že uživatel IAM může mít při přidružení stále osobní zásady se skupinou se výsledné oprávnění rovná sloučení skupiny s osobními.

Mělo by to být spíše výjimkou než typickým pracovním postupem. S příliš mnoha individuálními oprávněními vytváříme mnoho neudržitelných zásad a ztrácíme celkový přehled oprávnění v účtu.

Kdy použít

Pokud máte několik uživatelů (mezi 5–15) mohou skupiny IAM ušetřit některé problémy se správou a konfigurací každého uživatele IAM. Platí však stejná úvaha jako u uživatelů IAM, takže pokud je to možné, vyhněte se jim, pokud právě nepracujete na jediném účtu.

Role

A jsme tady u rolí AWS. Role IAM mohou mít oprávnění (stejně jako uživatelé) a přihlásit se ke konzole (opět jako uživatelé…). Místo toho, aby byl jedinečně spojen s jednou osobou, může kdokoli, kdo to potřebuje, převzít roli.

Takže osoba nosí čepici role, kterou chce převzít, a

Logo role IAM právě jste získali mnohem větší smysl, že?

Dočasné pověření

Další klíčový rozdíl od uživatelů IAM je, že role IAM nemají statická pověření. Když někdo převezme role, je vygenerována a zadána sada dočasných pověření . Je možné upravit, jak dlouho tato pověření vydrží, a v případě potřeby dále omezit přístup.

Čas lze nastavit od 900 sekund (15 minut) do 12 hodin, ale podle mého názoru je nastavení hodinové- dlouhé vypršení platnosti je nejlepší kompromis mezi zabezpečením a výkonem.

Monitorování CloudTrail

Zmíním se o tom proto, že někteří lidé nepoužívají role, protože si myslí, že nemohou auditovat, co role mohou dělat. Pravda je, že můžete a měli byste. Když povolíte monitorování Cloudtrail, uvidíte všechny akce prováděné ve vašem účtu, abyste vždy věděli, o co jde.

Cross Account

Tomu se budeme podrobněji věnovat v jiném blogu příspěvek, protože se zaměřujeme na jednotlivé účty, ale zatím si uvědomte, že role IAM mohou být použity k poskytnutí přístupu k dalším rolím IAM nebo uživatelům IAM.

A to je neuvěřitelně užitečné.

Je vyžadován vstupní bod

A nyní nevýhody. Bohužel nemůžete poskytnout přímý přístup ke konzole a dočasná pověření roli IAM. Nejprve musíte nastavit uživatele nebo federovanou roli (více o tom v několika odstavcích), abyste měli přístup k roli IAM.

Kdy použít

Vždy. Jediný fakt, že role IAM jsou není svázáno se statickými pověřeními, což z nich dělá nejlepší způsob přístupu k vašemu cloudu. Zkombinujte je se schopností monitorovat akce rolí IAM a vynucovat zabezpečení i při MFA. Jedinou nevýhodou je, že jde o trochu více konfigurace, ale podle mého názoru je to nízká cena.

Z vnějšku AWS

A teď se podívejme, co můžeme dělat, když jít do oblasti corporate identity. Mám na mysli použití poskytovatele identity jako zdroje identit a přihlášení pomocí našeho firemního e-mailu a hesla.

Federace

Ale co máme na mysli federací? Na jedné straně máme poskytovatele identity. Tyto systémy obsahují adresář uživatelů a nějaký software, který může komunikovat prostřednictvím specifických federačních protokolů. Všechna data našich uživatelů jsou umístěna jako Identity .

Na druhé straně je váš AWS Účet jako Spotřebitel identity . Udržuje odkaz na identity bez jejich uložení. Na této straně máme obecně mnohem podrobnější úrovně autorizace (díky, IAM!).

Takže federace je vztah důvěryhodnosti, díky kterému je spotřebitel identity schopen odkazovat na identity v poskytovateli identity.

federace SAML

nejběžnější definice pro Security Assertion Markup Language (SAML ) je otevřený standard pro výměnu údajů o ověřování a autorizaci mezi stranami. To znamená, že se můžeme pomocí našich identit přihlásit k AWS a dokonce získat dočasná pověření převzetím rolí. Je to obecný přístup, který můžete použít téměř u všech poskytovatelů identity.

Vztah důvěryhodnosti

Chcete-li nastavit federaci mezi oběma stranami, musíme vytvořit a spravovat Poskytovatel identity IAM . To je nutné, protože to představuje skutečného poskytovatele identity a uchovává sdílené tajemství, které umožňuje oběma stranám komunikovat. Kromě toho v každé roli, kterou chceme, aby naši uživatelé převzali, definujeme zásady důvěryhodnosti , které umožní entitám související s IAM Poskytovatel identity pro převzetí role:

Vlastní správa

Věc je, že vlastní správa federace může být zpočátku náročná a časově náročná. Existuje několik konceptů, kterým je třeba dobře rozumět, a abyste toho dosáhli, musíte vytvořit spoustu entit, vztahů a vlastních věcí. Chcete-li získat představu, kompletní ukázkový návod najdete zde .

Kdy použít

Obecně jedná se o vynikající a vyzkoušený přístup, který bude fungovat téměř ve všech případech. Vlastní správa identit může být pro nezkušené lidi stále obtížná a časově náročná.

Typickými případy použití jsou případy, kdy si je chcete spravovat sami pro účely zabezpečení nebo dodržování předpisů. Nemáte přístup ke své organizaci AWS nebo AWS SSO dosud nepodporuje vašeho poskytovatele identity.

AWS SSO

Toto je cloudová a spravovaná služba SSO, která umožňuje připojíte svého poskytovatele identity k vašemu účtu AWS.

Organizace AWS

Chcete-li nastavit jednotné přihlášení AWS, budete muset nakonfigurovat organizace AWS a zatím si můžete představit, že spravovat více účtů AWS. Abychom byli struční, musíte vědět, že nastavení organizace AWS vyžaduje rozsáhlá oprávnění (zejména uživatele root).

Interní úložiště identity

Ve výchozím nastavení poskytuje AWS SSO adresář ukládat vaše uživatelské informace a pověření, aby sloužily přímo jako poskytovatel identity. Je skvělé, pokud ještě nemáte poskytovatele identity nebo si nepřejete potíže s nastavením.

Externí úložiště identit

Ale předpokládejme, že vaše organizace již některé používá Uživatelský adresář, jako je Microsoft Active Directory. V takovém případě jej můžete připojit k AWS SSO, což eliminuje potřebu udržovat dva odlišné adresáře s automatickým zajišťováním .

Mějte však na paměti, že tato funkce je podporována pouze u omezené sady poskytovatelů identity:

Vícefaktorové ověřování

S AWS SSO, můžete nakonfigurovat zařízení MFA pro vaše uživatele uvnitř služby. Právě teď podporuje aplikace Authenticator jako Google Authenticator a bezpečnostní klíče jako Yubikey. Interní řešení je vzrušující, ale postrádá podporu MFA, pokud je nastaveno na straně externího poskytovatele identity.

Kdy použít

Je to standard navržený AWS a může být výchozím způsobem, pokud si nejste jisti, jak postupovat. Přesto je potřeba zaškrtnout alespoň několik požadavků, abyste toto řešení využili na maximum:

Svou organizaci AWS jste již nastavili, a máte přístup ke kořenovému účtu. Chcete zachovat své identity v rámci jednotného přihlášení AWS nebo použít poskytovatele identity podporovaného automatickým zajišťováním.

Závěrečné poznámky

Takže jsme položili základy pro přístup k jednomu účtu AWS, a teď byste měli mít prvky pro výběr nejlepší metody pro váš konkrétní případ použití. Použijeme to k pokrytí základů správy více účtů a organizací AWS v příštím příspěvku na blogu.

Leapp

Jako poslední poznámku všem důrazně doporučuji použít nějaký nástroj, který pomáhá jim ukládat všechna data potřebná pro připojení k jejich účtu AWS. Můj tým a já vyvíjíme nástroj s otevřeným zdrojovým kódem, který podporuje všechny tyto případy použití, takže se můžete podívat na:

Noovolari / leapp

Leapp je váš každodenní společník pro přístup do vašeho cloudu; navrženo pro práci s API, CLI a SDK Cloud Providers. Je to …

github.com

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *