Az AWS-fiók elérése

(Nicolo Marchesi) (2020. december 3.)

Az AWS-fiók elérése

Hé, ott van. Nemrég hoztad létre az első AWS-fiókodat, és alig várod, hogy belevághass az összes olyan izgalmas szolgáltatásba és technológiába, amelyet az AWS kínál neked a következő nagy dolog felépítésének megkezdéséhez. De várjon egy percet … bejelentkezik a root fiók hitelesítő adataival? Vagy jobb új felhasználót generálni? Vagy esetleg szerepet használ?

Lassítson le egy percet, és a blogbejegyzés végére ígérem, hogy kiválaszthatja a legjobb módot hogy biztonságosan hozzáférhessen AWS-fiókjához .

Vigyázzon azonban, hogy megfontoljuk az egyetlen aws-fiókhoz való hozzáférést, mivel a következő alkalommal többfiókos stratégiákkal foglalkozunk . Sétálnunk kell, mielőtt futni tudnánk, igaz?

Fiókok és erőforrások

Minden hihetetlen utazás az AWS-sel a fiókoktól és az erőforrásoktól kezdődik, és egy fiók olyan, mint egy üres mező.

A fiókjában elhelyezhető dolgok bármi kapcsolatban lehetnek az AWS szolgáltatásaival, például hálózatokkal, virtuális gépekkel, tárolókkal és így tovább.

De a legfontosabb az, hogy alapértelmezés szerint egyetlen fiók sem oszt meg semmilyen erőforrást, így semmi sem mehet be vagy ki két különböző AWS-fiók között. Ez nagyszerű, ha megosztja a munkaterhelését, és biztos lehet abban, hogy csak a megfelelő emberek férnek hozzá mindenhez.

IAM – Identity & Hozzáférés-kezelés

Az egyes fiókokon belül az IAM megvédi a fiókjában lévő erőforrásokat azáltal, hogy kezeli, mely entitások hajthatnak végre bizonyos műveleteket az erőforrásokon:

  • WHO – mely identitások
  • MI – egyes műveletek elvégezhetők
  • WHERE – egyes forrásokon
  • HOGYAN – és teljesített bizonyos feltételeket

Ezeket úgy definiálom, hogy 4W , és egyelőre csak az első 3-ra kell összpontosítanunk.

Kezdetben – a root felhasználó

Amikor az AWS-fiók létrehozása után bejelentkezett, akkor ezt a fiókot használta root felhasználó .

Ez különbözik a többi által létrehozottaktól, mert:

  • A fiók regisztrációjánál jött létre
  • Ön bejelentkezhet a fiók létrehozásához használt e-mail címmel és jelszóval
  • Hozzáférhet a számlázási információkhoz
  • Korlátlan hozzáféréssel rendelkezik a fiók összes erőforrásához

Ez a felhasználó kiemelkedően fontos, és a lehető legjobb módon kell megvédenie. A szteroidok kiemelkedő rendszergazdája, mivel képes megtekinteni a számlázási információkat, és mindent meg tud tenni az összes erőforrással.

Tehát az első dolog a következő:

  • Engedélyezze a többtényezős hitelesítést (MFA), és mentse a QR-kódot biztonságos helyre.
  • Az automatizált hozzáférés letiltásához törölje az összes, ehhez a felhasználóhoz tartozó hozzáférési kulcsot (amúgy erre nincs szüksége!)

És a következő dolognak kell eldöntenie, hogy ezentúl hogyan fog hozzáférni ehhez a fiókhoz.

Az AWS belsejéből

Egyelőre arra összpontosítsunk, amit az AWS nyújt nekünk, anélkül, hogy harmadik felekre támaszkodnánk. Ez különösen akkor hasznos, ha erre az egyetlen fiókra összpontosítunk, mert el kell sajátítanunk a három IAM építőelemet: felhasználót, csoportokat és szerepeket.

Felhasználók

Emlékszik a root felhasználóra? Az IAM felhasználói azonos típusú entitások, de eltérnek a root felhasználóktól. Nincsenek alapértelmezett számlázási engedélyeik és rendszergazdai hozzáférésük (hacsak nem adsz meg nekik … amit nem szabad).

Egy felhasználóval létrehozhatunk egy entitást, amely bejelentkezhet az AWS webkonzolba. vagy programozott hozzáféréssel olyan hitelesítő adatok (hozzáférési kulcs és titkos hozzáférési kulcs) révén, amelyek rögzítettek és idővel nem változnak. Az AWS CodeCommit SSH / HTTPS kulcsaival, vagy az Amazon Keyspaces hitelesítő adataival (az Apache Cassandra esetében)

  • Bejelentkezés a webkonzol hitelesítő adataival API-k, CLI és SDK programozott eléréséhez
  • SSH / HTTPS kulcsok az AWS CodeCommit számára
  • Hitelesítő adatok az Amazon Keyspaces számára (Apache Cassandra esetén)

Részletes hozzáférés

Az IAM felhasználóval teljesen lehetséges egy vagy több hozzáférési kulcs engedélyezése attól függően, hogy az adott felhasználó hogyan viselkedik.Például:

  • Olyan adatelemző, amelynek csak az elemzéseket kell ellenőriznie a webkonzolon, de programozási hozzáférés nélkül.
  • Szerver nélküli DevOps, amelynek műveleteket kell végrehajtania a konzolon és a CLI használatával bizonyos erőforrások biztosításához mindkét hozzáférésre szükség lesz.
  • Az egyetlen adattáron dolgozó fejlesztőnek, akinek nem kell interakcióba lépnie az AWS erőforrásokkal, SSH / HTTPS kulcsokkal rendelkezik az AWS CodeCommit számára.

Ne feledje, hogy megosztás IAM felhasználói hitelesítő adatok nagy nem-nem, , mivel ez az első lépés a hitelesítő adatok és az irányítás elvesztésére és a biztonsági fenyegetésekre való nyitottságra.

Nem teheti meg Nem akarja, hogy a termelési számláját teljesen kitörölje a bitcoin bányászok teljes csoportja érdekében, igaz? bonyolultság (ami alapértelmezés szerint elég magas, hossza 8–128 chara között van cters, minimum 3 speciális karakter, és hogy ne legyen azonos az AWS-fiók nevével vagy e-mail címével) és a jelszó lejárati ideje annak biztosítása érdekében, hogy a felhasználók egy bizonyos idő után megváltoztassák a jelszót.

Fent ebből az MFA-t különféle eszközökkel engedélyezheti:

  • virtuális MFA-eszköz hitelesítő alkalmazással a mobileszközére vagy számítógépére telepítve
  • U2F-biztonsági kulcs, mint például a YubiKey vagy bármely más kompatibilis U2F eszköz
  • Egy másik hardveres MFA eszköz, például a Gemalto token

Általánosságban szemléletes megközelítés létezik, mivel minden IAM felhasználóhoz rendelkezhet speciális eszközökkel .

Mikor kell használni

Ha nagyon kevés felhasználója van (között 1–5), mindegyikhez pontos engedélyekkel, az IAM-felhasználók időt spórolhatnak a kezdeti konfiguráció és a konzol-hozzáférés terén. Óvakodjon a statikus hitelesítési adatoktól , mert ezek jelentős biztonsági kérdések, ezért kezelje rendkívül körültekintően. Vagy használja az AWS CLI get-session-tokent ideiglenes hitelesítő adatok előállításához statikusakból.

Csoportok

Önmagában nem entitás, de az IAM-csoportok azért vannak, hogy az IAM-felhasználókat összecsomagolják. és ugyanazokat az engedélyeket adja meg a felhasználók egy csoportjának. Ez kissé simítja az IAM felhasználók durva széleit, de általánosságban ugyanazok vonatkoznak, amelyeket az IAM felhasználók számára láttunk.

Szép dolog, amit szem előtt kell tartani, hogy egy IAM felhasználónak továbbra is lehetnek személyes házirendjei, miközben társulnak hozzájuk. egy csoporttal, a kapott engedéllyel megegyezik a csoport és a személyes egyesítésével.

Ez inkább kivétel, mint a tipikus munkafolyamat. Túl sok egyéni engedély mellett sok fenntarthatatlan házirendet hozunk létre, és elveszítjük a fiók engedélyeinek átfogó áttekintését.

Mikor kell használni

Ha van kevés felhasználó (5–15 között), az IAM-csoportok menthetik az IAM-felhasználók kezelésének és konfigurálásának néhány problémáját. De az IAM-felhasználókkal megegyező szempont érvényes, ezért lehetőség szerint kerülje őket, hacsak nem csak egyetlen fiókkal dolgozik.

Szerepek

És itt állunk az AWS szerepkörökhöz. Az IAM szerepköröknek lehetnek engedélyei (csakúgy, mint a felhasználóknak), és bejelentkezhetnek a konzolra (ismét, mint a felhasználók …). Ahelyett, hogy egyedülállóan kapcsolódna egy személyhez, bárki, akinek szüksége van rá, szerepet vállalhat.

Tehát egy személy viseli annak a szerepnek a sapkáját , amelyet vállalni akar, és

az IAM szereplogo csak sokkal több értelme lett, igaz?

Ideiglenes hitelesítő adatok

Az IAM-felhasználókkal szembeni másik fő különbség, hogy az IAM-szerepköröknek nincs statikus hitelesítő adatuk. Amikor valaki felveszi a szerepeket, ideiglenes hitelesítő adatok készlete keletkezik és megadódik. Lehetőség van testreszabni, hogy ezek a hitelesítő adatok mennyi ideig fognak tartani, és szükség esetén tovább korlátozza a hozzáférést.

Az idő 900 másodperc (15 perc) és 12 óra között állítható be, de véleményem szerint egy óra- a hosszú lejárat a legjobb kompromisszum a biztonság és a teljesítmény között.

CloudTrail figyelés

Ezt azért említem meg, mert egyesek nem használnak szerepeket, mert úgy gondolják, hogy nem tudják ellenőrizni szerepek megtehetik. Az igazság az, hogy lehet, és kell is. A Cloudtrail figyelés engedélyezésével láthatja a fiókjában végrehajtott összes műveletet, így mindig tudja, mi történik.

Fiókok közötti

Ezt részletesebben egy másik blog tárgyalja. bejegyzést, mivel egyetlen fiókra koncentrálunk, de egyelőre vegye figyelembe, hogy az IAM szerepkörökkel más IAM szerepkörök vagy IAM felhasználók is hozzáférhetővé válhatnak.

És ez hihetetlenül hasznos.

Belépési pont szükséges

És most a hátrányokról. Sajnos nem adhat közvetlen hozzáférést a konzolhoz és az IAM-szerepkör ideiglenes hitelesítő adataihoz. Először be kell állítania egy felhasználót vagy egy összevont szerepet (erről bővebben néhány bekezdésben olvashat), hogy hozzáférést biztosítson az IAM szerepkörhöz.

Mikor kell használni

Mindig. Az egyetlen tény, hogy az IAM szerepkörök nem statikus hitelesítő adatokkal kötik össze őket a felhő elérésének legjobb módjával. Kombinálja őket az IAM-szerepkörök műveleteinek figyelésével és a biztonság kikényszerítésével még az MFA-val is. Az egyetlen hátrány, hogy egy kicsit nagyobb konfigurációval rendelkezik, de véleményem szerint alacsony árat kell fizetni.

Az AWS kívülről

És most nézzük meg, mit tehetünk, ha menjen be a vállalati identitás területére. Arra hivatkozok, hogy Identitásszolgáltatót használok Identitásforrásként, és jelentkezzek be vállalati e-mailünkkel és jelszavunkkal.

Föderáció

De mit értünk föderáció alatt? Az egyik oldalon van az identitásszolgáltató. Ezek a rendszerek tartalmazzák a felhasználók könyvtárát és néhány szoftvert, amelyek képesek egyesített összevonási protokollokon keresztül kommunikálni. Felhasználóink ​​összes adata Identitás .

A másik oldalon ott van az AWS Fiók mint identitásfogyasztó . Megőrzi az identitásokra való hivatkozást anélkül, hogy mentené őket. Ezen az oldalon általában sokkal részletesebb engedélyezési szintünk van (köszönöm, IAM!).

Tehát a szövetség a bizalom kapcsolata, amely lehetővé teszi az identitásfogyasztó számára, hogy az identitásszolgáltatóban hivatkozhasson az identitásokra.

SAML összevonás

A biztonsági állítás jelölőnyelvének (SAML) leggyakoribb meghatározása ) egy nyílt szabvány a hitelesítési és engedélyezési adatok felek közötti cseréjéhez. Ez azt jelenti, hogy felhasználhatjuk Identitásunkat az AWS-be való bejelentkezéshez, és még szerepkörök felvállalásával ideiglenes hitelesítő adatokat is kaphatunk. Ez egy általános megközelítés, amelyet szinte az összes identitásszolgáltatóra alkalmazhat.

A bizalmi kapcsolat

A két fél közötti föderáció létrehozásához létre kell hoznunk és kezelnünk kell egy IAM-identitásszolgáltató . Erre azért van szükség, mert képviseli a valódi személyazonosság-szolgáltatót, és birtokolja a megosztott titkot, amely lehetővé teszi a két fél kommunikációját. Ezenkívül minden olyan szerepkörön belül, amelyet szeretnénk, hogy felhasználóink ​​vállaljanak, meghatározunk egy bizalmi házirendet , amely lehetővé teszi az IAM-hez kapcsolódó entitások számára A szerep felvállalására szolgáló identitásszolgáltató:

Egyéni kezelés

Az a helyzet, hogy az összevonás önálló kezelése eleinte kihívást és időigényes lehet. Vannak olyan fogalmak, amelyek a megértéshez szükségesek, és ennek megvalósításához létre kell hoznia egy csomó entitást, relációt és egyéni dolgot. Ötlet megszerzéséhez talál egy teljes oktató példát itt .

Mikor kell használni

Általában ez egy kiváló és csatában bevált megközelítés, amely szinte minden esetben működik. Ennek ellenére a személyazonosságok egyedi kezelése nehéz és időigényes lehet a tapasztalatlan emberek számára.

Jellemző felhasználási esetek, ha ezt saját maga szeretné kezelni biztonsági vagy megfelelőségi célokból. Nincs hozzáférése az AWS szervezetéhez, vagy az AWS SSO még nem támogatja az Ön identitásszolgáltatóját.

AWS egyszeri bejelentkezés

Ez a felhőalapú és felügyelt egyszeri bejelentkezési szolgáltatás, amely lehetővé teszi összekapcsolja identitásszolgáltatóját az AWS-fiókjával.

AWS-szervezet

Az AWS SSO beállításához be kell állítania az AWS-szervezeteket, és egyelőre átgondolhatja, hogy több AWS-fiók kezelése. Ahhoz, hogy a dolgok rövidek legyenek, tudnia kell, hogy az AWS-szervezet létrehozásához kiterjedt engedélyekre van szükség (nevezetesen a root felhasználóra).

Belső identitás-tároló

Alapértelmezés szerint az AWS SSO könyvtárat biztosít felhasználói adatok és hitelesítő adatok tárolásához, hogy közvetlenül az identitásszolgáltatóként szolgálhassanak. Nagyon jó, ha még nincs identitásszolgáltatója, vagy nem akarja a telepítésével járni.

Külső személyazonosító-tároló

De tegyük fel, hogy szervezete már használ valamennyit Felhasználói könyvtár, például a Microsoft Active Directory. Ebben az esetben csatlakoztathatja az AWS SSO-hoz, így nincs szükség különálló könyvtárak fenntartására automatikus létesítéssel .

Vigyázzon, hogy ezt a funkciót csak korlátozott számú identitásszolgáltató támogatja:

Többtényezős hitelesítés

AWS SSO-val, konfigurálhat egy MFA eszközt a felhasználók számára a szolgáltatáson belül. Jelenleg támogatja a Hitelesítő alkalmazásokat, például a Google Hitelesítőt, és a biztonsági kulcsokat, például a Yubikey-t. A belső megoldás izgalmas, de hiányzik az MFA-támogatás, ha külső identitásszolgáltatói oldalon állítják be.

Mikor kell használni

Ez az AWS által javasolt szabvány, és ez lehet az alapértelmezett út, ha nem tudja, hogyan tovább. Ennek ellenére legalább néhány követelményt be kell jelölnie, hogy a legtöbbet hozza ki a megoldásból:

már létrehozta az AWS szervezetet, és hozzáféréssel rendelkezik a root fiókhoz. Szeretné az identitását az AWS SSO-ban tartani, vagy az automatikus kiépítés által támogatott identitásszolgáltatót használnia.

Végső megjegyzések

Tehát lefektettük az alapokat az egyetlen AWS-fiók eléréséhez, Most pedig rendelkeznie kell azokkal az elemekkel, amelyekkel kiválaszthatja a legjobb módszert az adott felhasználási esethez. Ezt felhasználjuk a többfiók-kezelés és az AWS-szervezetek terepének lefedésére a következő blogbejegyzésben.

Leapp

Utolsó megjegyzésként mindenkinek nagyon ajánlom, hogy használjon valamilyen eszközt, amely segít tárolni az AWS-fiókjukhoz való csatlakozáshoz szükséges összes adatot. Csapatommal egy nyílt forráskódú eszközt fejlesztünk, amely támogatja ezeket a felhasználási eseteket, ezért nyugodtan nézze meg:

Noovolari / leapp

A Leapp mindennapi társa a felhő eléréséhez; Cloud Providers API-kkal, CLI-kkel és SDK-kkal való együttműködésre tervezték. Ez…

github.com

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük