AWS-tilisi käyttäminen

(Nicolo Marchesi) (3. joulukuuta 2020)

Kuinka päästä AWS-tilillesi

Hei. Olet juuri luonut ensimmäisen AWS-tilisi, etkä voi odottaa sukeltaa kaikkiin jännittäviin palveluihin ja tekniikoihin, joita AWS tarjoaa sinulle aloittaaksesi seuraavan suuren asian rakentamisen. Mutta odota hetki … aiotko kirjautua sisään pääkäyttäjätunnuksillasi? Vai onko parempi luoda uusi käyttäjä? Tai ehkä käyttää roolia?

Hidasta minuutti ja blogikirjoituksen loppuun mennessä lupaan, että voit valita parhaan tavan käyttääksesi AWS-tiliäsi turvallisesti .

Varo kuitenkin, että harkitsemme pääsyä yhdelle aws-tilille, koska katamme usean tilin strategiat seuraavalla kerralla . Meidän on käveltävä ennen kuin voimme juosta, eikö?

Tilit ja resurssit

Jokainen uskomaton matka AWS: n kanssa alkaa tileistä ja resursseista, ja tili on kuin tyhjä ruutu.

Tilisi sisällä olevat asiat voivat liittyä mihin tahansa AWS: n palveluihin, esimerkiksi verkkoihin, virtuaalikoneisiin, säilöihin ja niin edelleen.

Mutta tärkein osa on se, että oletusarvoisesti mikään tili ei jaa resursseja, joten mikään ei voi mennä sisään tai ulos kahden eri AWS-tilin välillä. Ja tämä on hienoa jakaa työmäärät ja olla varma, että vain oikeat ihmiset pääsevät kaikkeen.

IAM – Identity & Käyttöoikeuksien hallinta

Jokaisessa tilissä IAM suojelee tilisi sisällä olevia resursseja hallitsemalla, mitkä yksiköt voivat suorittaa joitain toimintoja näille resursseille:

  • WHO – mitkä identiteetit
  • MITÄ – voi tehdä joitain toimintoja
  • WHERE – joillakin resursseilla
  • MITEN – ja täytti jotkin ehdot

Määritän nämä nimellä 4W , ja toistaiseksi meidän on keskityttävä vain ensimmäiseen 3.

Alussa – pääkäyttäjä

Kun kirjauduit sisään AWS-tilin luomisen jälkeen, käytit kyseistä tiliä pääkäyttäjä .

Se eroaa muista luomistasi, koska:

  • Luotu tilin rekisteröinnissä
  • Sinä voi kirjautua sisään käyttämällä sähköpostiosoitetta ja salasanaa, jota käytit tilin luomiseen.
  • Voit käyttää laskutustietoja
  • Sillä on rajoittamaton pääsy kaikkiin tilisi resursseihin

Tämä käyttäjä on erittäin tärkeä, ja sinun tulee suojata sitä parhaalla mahdollisella tavalla. Se on steroidien pääkäyttäjä, koska se pystyy tarkastelemaan laskutustietoja ja pystyvän tekemään kaiken kaikilla resursseillasi.

Ensimmäisen tehtävän tulisi siis olla:

  • Ota käyttöön monivaiheinen todennus (MFA) ja tallenna QR-koodi turvalliseen paikkaan
  • Poista kaikki tähän käyttäjään liittyvät avaimet ohjelmoidun käytön poistamiseksi käytöstä (et tarvitse sitä joka tapauksessa!)

Ja aivan seuraavan asian pitäisi olla päättää, miten pääset tähän tiliin tästä lähtien.

AWS: n sisältä

Keskitymme nyt siihen, mitä AWS antaa meille turvautumatta kolmansiin osapuoliin. Tämä on erityisen hyödyllistä, jos keskitymme tähän yksittäiseen tiliin, koska meidän on hallittava kolme IAM: n rakennuspalikkaa: käyttäjä, ryhmät ja roolit.

Käyttäjät

Muistatko pääkäyttäjän? IAM-käyttäjät ovat samantyyppisiä entiteettejä, mutta erilaiset kuin pääkäyttäjä. Heillä ei ole oletusarvoisia laskutusoikeuksia ja järjestelmänvalvojan käyttöoikeuksia (ellet anna heille… mitä sinun ei pitäisi antaa).

Käyttäjällä voimme luoda entiteetin, joka voi kirjautua sisään AWS-verkkokonsoliin. tai ohjelmallisella käyttöoikeudella joukon tunnistetietoja (pääsyavain ja salainen pääsyavain), jotka ovat kiinteitä eivätkä muutu ajan myötä. Yhdessä SSH / HTTPS-avainten kanssa AWS CodeCommit tai Credentials for Amazon Keyspaces (Apache Cassandra)

  • Kirjautumistiedot verkkokonsolille
  • Pääsy ja salaisen avaimen tunnistetiedot sovellusliittymien, CLI: n ja SDK: n ohjelmalliseen käyttöön
  • SSH / HTTPS-avaimet AWS CodeCommitille
  • Tunnistetiedot Amazon Keyspaceille (Apache Cassandra)

Rakeinen käyttöoikeus

IAM-käyttäjän kanssa on täysin mahdollista ottaa käyttöön yksi tai useampi pääsyavain sen mukaan, miten haluat käyttäjän käyttäytyvän.Esimerkiksi:

  • data-analyytikko, jonka on tarkistettava vain verkkokonsolin analytiikka tarvitsematta ohjelmallista pääsyä
  • palvelimeton DevOps, jonka on suoritettava toimintoja konsoli ja käytä CLI: tä joidenkin resurssien tarjoamiseen tarvitaan molemmat käyttöoikeudet.
  • Kehittäjällä, joka työskentelee yhdessä arkistossa ja jonka ei tarvitse olla vuorovaikutuksessa AWS-resurssien kanssa, on SSH / HTTPS-avaimet AWS CodeCommitille.

Huomaa, että jakaminen IAM-käyttäjän tunnistetiedot on iso ei-ei, , koska se on ensimmäinen askel menettää valtakirjat ja hallinto sekä asettaa itsesi avoimeksi turvallisuusuhkille.

Et Etkö halua, että tuotantotilisi poistetaan kokonaan kaikkien bitcoin-kaivostyöläisten hyväksi, vai mitä?

Suojaa turvallisuus

AWS IAM -käyttäjien toinen hieno ominaisuus on pystyä pakottamaan salasana monimutkaisuus (joka on oletusarvoisesti melko korkea ja pituus välillä 8–128 chara cters, vähintään 3 erikoismerkkiä ja olemaan identtinen AWS-tilisi nimen tai sähköpostiosoitteen kanssa) ja salasanan vanhentumisaika sen varmistamiseksi, että tietyn ajan kuluttua käyttäjät vaihtavat salasanan.

Alkuun tästä voit ottaa MFA: n käyttöön useilla laitteilla:

  • virtuaalinen MFA-laite, jossa todennusohjelma on asennettu mobiililaitteeseesi tai tietokoneellesi
  • U2F-suojausavain, kuten YubiKey tai mikä tahansa muu yhteensopiva U2F-laite
  • Toinen laitteiston MFA-laite, kuten Gemalto-tunnus.

Yleensä on rakeinen lähestymistapa, koska sinulla voi olla erityisiä keinoja jokaiselle IAM-käyttäjälle .

Milloin käyttää

Jos sinulla on hyvin vähän käyttäjiä (välillä 1–5), kun jokaiselle on sidottu tarkat käyttöoikeudet, IAM-käyttäjät voivat säästää aikaa alkuperäisessä kokoonpanossa ja konsolin käytössä. Varo staattisia tunnistetietoja , koska ne ovat merkittäviä turvallisuusongelmia, joten käsittele niitä erittäin huolellisesti. Tai käytä AWS CLI: n get-session-tunnusta tilapäisten tunnistetietojen luomiseen staattisista tunnuksista.

Ryhmät

Ei ole yksikkö sinänsä, mutta IAM-ryhmät on tarkoitettu niputtamaan IAM-käyttäjät yhteen ja anna samat käyttöoikeusjoukot käyttäjäryhmälle. Tämä tasoittaa hieman IAM-käyttäjien karkeita reunoja, mutta kaiken kaikkiaan sovelletaan samoja asioita, jotka olemme nähneet IAM-käyttäjille.

Kiva asia pitää mielessä, että IAM-käyttäjällä voi silti olla henkilökohtaisia ​​käytäntöjä, kun hän on yhteydessä ryhmän kanssa, jolloin saatu lupa on yhtä suuri kuin ryhmän ja henkilökohtaisten yhdistäminen.

Tämän pitäisi olla enemmän poikkeus kuin tyypillinen työnkulku. Liian monilla yksittäisillä käyttöoikeuksilla luomme monia ylläpitämättömiä käytäntöjä ja menetämme tilin yleiskatsauksen.

Milloin käyttää

Jos sinulla on harvat käyttäjät (välillä 5–15), IAM-ryhmät voivat tallentaa joitain vaivoja jokaisen IAM-käyttäjän hallinnassa ja määrityksessä. Mutta sama huomio kuin IAM-käyttäjillä, niin jos mahdollista, vältä niitä, ellet työskentele vain yhdellä tilillä.

Roolit

Ja tässä olemme AWS-rooleissa. IAM-rooleilla voi olla käyttöoikeudet (aivan kuten käyttäjillä) ja ne voivat kirjautua konsoliin (taas kuten käyttäjät …). Sen sijaan, että se olisi yksilöllisesti yhteydessä yhteen henkilöön, kuka tahansa sitä tarvitseva voi ottaa roolin.

Joten henkilö käyttää päällikkö roolista, jonka hän haluaa ottaa, ja

IAM-roolilogo sait juuri paljon enemmän järkeä, eikö?

Väliaikaiset tunnistetiedot

Toinen keskeinen ero IAM-käyttäjiin verrattuna on, että IAM-rooleilla ei ole staattisia tunnistetietoja. Kun joku ottaa roolit, joukko väliaikaisia ​​tunnistetietoja luodaan ja annetaan. On mahdollista muokata, kuinka kauan nämä tunnistetiedot kestävät, ja rajoittaa pääsyä tarvittaessa.

Aika voidaan asettaa 900 sekunnista (15 minuuttia) – 12 tuntiin, mutta mielestäni asettamalla yksi tunti – pitkä vanhentuminen on paras kompromissi turvallisuuden ja suorituskyvyn välillä.

CloudTrail -seuranta

Mainitsen tämän, koska jotkut ihmiset eivät käytä rooleja, koska heidän mielestään he eivät voi tarkastaa mitä roolit voivat tehdä. Totuus on, että voit, ja sinun pitäisi. Kun otat Cloudtrail-seurannan käyttöön, näet kaikki tilisi sisällä tehdyt toiminnot, joten voit aina tietää, mitä tapahtuu.

Tilien välinen

Tästä keskustellaan tarkemmin toisessa blogissa. postitse, koska keskitymme yksittäisiin tileihin, mutta toistaiseksi, muista, että IAM-rooleja voidaan käyttää pääsyn antamiseen muille IAM-rooleille tai IAM-käyttäjille.

Ja se on uskomattoman hyödyllistä.

Tarvitaan lähtökohta

Ja nyt haittapuolista. Valitettavasti et voi antaa IAM-roolille suoraa pääsyä konsoliin ja väliaikaisia ​​kirjautumistietoja. Ensinnäkin sinun on määritettävä käyttäjä tai yhdistetty rooli (lisätietoja tästä muutamassa kappaleessa), jotta pääset IAM-rooliin.

Milloin käyttää

Aina. Ainoa tosiasia, että IAM-roolit ovat ei sidottu staattisiin tunnuksiin tekee niistä parhaan tavan käyttää pilviäsi. Yhdistä ne kykyyn seurata IAM-roolitoimintoja ja varmistaa turvallisuus jopa MFA: n avulla. Ainoa haittapuoli on, että se on hieman enemmän kokoonpanoa, mutta mielestäni se on alhainen hinta.

AWS: n ulkopuolelta

Ja nyt katsotaan, mitä voimme tehdä, kun mennä yritysidentiteetin kentälle. Tarkoitan Identity Providerin käyttöä Identities-lähteenä ja kirjautumista yrityksen sähköpostiosoitteella ja salasanalla.

federaatio

Mutta mitä tarkoitamme federaatiolla? Toisella puolella meillä on henkilöllisyyden tarjoaja. Nämä järjestelmät sisältävät hakemiston käyttäjistä ja joitain ohjelmistoja, jotka voivat kommunikoida tiettyjen federaatioprotokollien kautta. Kaikki käyttäjiemme tiedot ovat Identiteetit .

Toisella puolella on AWS Tili henkilöllisyyden kuluttajana . Se ylläpitää viittausta identiteetteihin tallentamatta niitä. Tällä puolella meillä on yleensä paljon tarkemmat valtuutustasot (kiitos, IAM!).

Joten federaatio on luottamussuhde, joka saa Identity Consumer -palvelun viittaamaan Identity Providerin identiteetteihin.

SAML Federation

Yleisin tietoturvavarmennuskielen (SAML) määritelmä ) on avoin standardi todennus- ja valtuutustietojen vaihtamiseen osapuolten välillä. Tämä tarkoittaa, että voimme käyttää henkilöllisyyttämme kirjautumalla AWS: ään ja jopa saada väliaikaiset tunnistetiedot ottamalla rooleja. Se on yleinen lähestymistapa, jota voit käyttää melkein kaikkiin henkilöllisyyden tarjoajiin.

Luottamussuhde

Osapuolten välisen liiton luomiseksi meidän on luotava ja hallinnoitava IAM-tunnuksen tarjoaja . Tämä on tarpeen, koska se edustaa todellista henkilöllisyyden tarjoajaa ja sillä on yhteinen salaisuus, jonka avulla osapuolet voivat kommunikoida. Lisäksi jokaisessa roolissa, jonka haluamme käyttäjiemme ottavan, määritämme luottamuskäytännön , joka sallii IAM: ään liittyvät entiteetit Identiteetin tarjoaja ottamaan roolin:

Mukautettu hallinta

Asia on, että federaation hallinta itse voi olla aluksi haastavaa ja aikaa vievää. On joitain käsitteitä ymmärtämään hyvin, ja sinun on luotava joukko entiteettejä, suhteita ja mukautettuja asioita, jotta tämä tapahtuu. Saadaksesi idean, löydät täydellisen opetusesimerkin täältä .

Milloin käyttää

Yleensä tämä on erinomainen ja taistelutestattu lähestymistapa, joka toimii lähes kaikissa tapauksissa. Silti identiteettien mukautettu hallinta voi olla vaikeaa ja aikaa vievää kokemattomille ihmisille.

Tyypillisiä käyttötapauksia ovat, jos haluat hallita tätä itse turvallisuuden tai vaatimustenmukaisuuden vuoksi. Sinulla ei ole pääsyä AWS-organisaatioosi, tai AWS SSO ei vielä tue Identity Provideriasi.

AWS SSO

Tämä on pilvipohjainen ja hallittu SSO-palvelu, jonka avulla yhdistät Identity Providerin AWS-tiliisi.

AWS-organisaatio

AWS-kertakirjautumisen määrittämiseksi sinun on määritettävä AWS-organisaatiot ja toistaiseksi voit ajatella sitä hallita useita AWS-tilejä. Jotta asiat pysyisivät lyhyinä, sinun on tiedettävä, että AWS-organisaation asettaminen vaatii laajoja käyttöoikeuksia (nimittäin pääkäyttäjän).

Sisäinen henkilötallennus

Oletusarvoisesti AWS SSO tarjoaa hakemiston tallentaa käyttäjätietosi ja kirjautumistietosi toimimaan suoraan henkilöllisyyden tarjoajana. On hienoa, jos sinulla ei vielä ole henkilöllisyyden tarjoajaa tai et halua joutua vaikeuksiin sellaisen määrittämisessä.

Ulkoinen henkilöllisyyden tallennus

Mutta oletetaan, että organisaatiosi käyttää jo joitain Käyttäjähakemisto, kuten Microsoft Active Directory. Siinä tapauksessa voit liittää sen AWS SSO -palveluun, jolloin ei tarvitse ylläpitää kahta erillistä hakemistoa automaattisella -hakemistolla. p>

Varo kuitenkin, että tätä ominaisuutta tuetaan vain rajoitetuilla henkilöllisyystarjoajilla:

Monitekijätodennus

AWS-kertakirjautumisen kanssa voit määrittää MFA-laitteen käyttäjille palvelun sisällä. Tällä hetkellä se tukee Authenticator-sovelluksia, kuten Google Authenticator, ja suojausavaimia, kuten Yubikey. Sisäinen ratkaisu on jännittävä, mutta sillä ei ole MFA-tukea, jos se on asetettu ulkopuoliselle henkilöllisyyden tarjoajan puolelle.

Milloin käyttää

Se on AWS: n ehdottama standardi, ja se voi olla oletustapa, jos et ole varma, miten edetä. Silti on olemassa ainakin pari vaatimusta, jotka sinun on valittava, jotta saat kaiken irti ratkaisusta:

olet jo määrittänyt AWS-organisaation, ja sinulla on pääsy root-tiliin. Haluat säilyttää henkilöllisyytesi AWS SSO: ssa tai käyttää automaattisen valmistelun tukemaa identiteettipalvelua.

Loppuhuomautukset

Joten olemme luoneet perustan yhdelle AWS-tilille, ja nyt sinulla pitäisi olla elementtejä, jotta voit valita parhaan menetelmän omaan käyttötapaukseesi. Käytämme tätä kattamaan kentän usean tilin hallinnalle ja AWS-organisaatioille seuraavassa blogiviestissä.

Leapp

Viimeisenä huomautuksena kehotan kaikkia käyttämään jotain työkalua, joka auttaa heitä tallentamaan kaikki tiedot, joita tarvitaan yhteyden muodostamiseen AWS-tiliin. Tiimini ja minä kehitämme avoimen lähdekoodin työkalua, joka tukee kaikkia näitä käyttötapoja, joten voit tarkistaa:

Noovolari / leapp

Leapp on jokapäiväinen kumppanisi pääsyäksesi pilveesi; suunniteltu toimimaan pilvipalveluntarjoajien sovellusliittymien, CLI: n ja SDK: n kanssa. Se on…

github.com

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *