Last updated
In AWS is daar 'n hoofrekening, wat die ouerhouer vir al die rekeninge vir jou organisasie is. Jy hoef egter nie daardie rekening te gebruik om hulpbronne te implementeer nie, jy kan ander rekeninge skep om verskillende AWS-infrastrukture van mekaar te skei.
Dit is baie interessant vanuit 'n sekuriteits-oogpunt, aangesien een rekening nie toegang sal hê tot hulpbronne van 'n ander rekening (behalwe as brûe spesifiek geskep word), sodat jy op hierdie manier grense tussen implementasies kan skep.
Daarom is daar twee soorte rekeninge in 'n organisasie (ons praat van AWS-rekeninge en nie Gebruikersrekeninge nie): 'n enkele rekening wat as die bestuursrekening aangewys is, en een of meer lidrekeninge.
Die bestuursrekening (die hoofrekening) is die rekening wat jy gebruik om die organisasie te skep. Vanuit die bestuursrekening van die organisasie kan jy die volgende doen:
Rekeninge in die organisasie skep
Ander bestaande rekeninge na die organisasie nooi
Rekeninge uit die organisasie verwyder
Uitnodigings bestuur
Beleide toepas op entiteite (wortels, OUs, of rekeninge) binne die organisasie
Integrasie met ondersteunde AWS-diens aktiveer om diensfunksionaliteit regoor al die rekeninge in die organisasie te voorsien.
Dit is moontlik om as die hoofgebruiker in te teken met die e-pos en wagwoord wat gebruik is om hierdie hoofrekening/organisasie te skep.
Die bestuursrekening het die verantwoordelikhede van 'n betalingsrekening en is verantwoordelik vir die betaling van alle koste wat deur die lidrekeninge aangegaan word. Jy kan nie 'n organisasie se bestuursrekening verander nie.
Lidrekeninge maak al die res van die rekeninge in 'n organisasie uit. 'n Rekening kan op enige gegewe tyd net 'n lid van een organisasie wees. Jy kan 'n beleid aan 'n rekening koppel om beheer slegs op daardie een rekening toe te pas.
Lidrekeninge moet 'n geldige e-posadres gebruik en kan 'n naam hê, oor die algemeen sal hulle nie die fakturering kan bestuur nie (maar hulle kan toegang daartoe verkry).
Rekeninge kan gegroepeer word in Organisasie Eenhede (OU). Op hierdie manier kan jy beleide vir die Organisasie Eenheid skep wat op alle kinderrekeninge toegepas sal word. Let daarop dat 'n OU ander OUs as kinders kan hê.
'n Diensbeheerbeleid (SCP) is 'n beleid wat spesifiseer watter dienste en aksies gebruikers en rolle kan gebruik in die rekeninge wat deur die SCP beïnvloed word. SCP's is soortgelyk aan IAM-toestemmingsbeleide behalwe dat hulle geen toestemmings verleen nie. In plaas daarvan spesifiseer SCP's die maksimum toestemmings vir 'n organisasie, organisatoriese eenheid (OU), of rekening. Wanneer jy 'n SCP aan jou organisasie-wortel of 'n OU heg, beperk die SCP toestemmings vir entiteite in lidrekeninge.
Dit is die ENIGSTE manier waarop selfs die hoofgebruiker gestop kan word om iets te doen. Byvoorbeeld, dit kan gebruik word om te keer dat gebruikers CloudTrail uitskakel of rugsteune verwyder. Die enigste manier om hierdie te omseil is om ook die hoofrekening te kompromiteer wat die SCP's instel (die hoofrekening kan nie geblokkeer word nie).
Let daarop dat SCPs slegs die beginsels in die rekening beperk, so ander rekeninge word nie geraak nie. Dit beteken dat 'n SCP wat s3:GetObject ontken, nie mense sal stop om 'n openbare S3-emmer in jou rekening te benader nie.
SCP-voorbeelde:
Ontken die hoofrekening heeltemal
Laat slegs spesifieke streke toe
Laat slegs witlys-dienste toe
Ontken dat GuardDuty, CloudTrail, en S3 Openbare Bloktoegang van
word uitgeskakel
Ontken dat sekuriteit/insidentreaksie-rolle verwyder of
gewysig word.
Ontken dat rugsteune verwyder word.
Ontken die skep van IAM-gebruikers en toegangssleutels
Vind JSON-voorbeelde in https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html
Amazon Resource Name is die unieke naam wat elke hulpbron binne AWS het, dit is saamgestel soos dit:
Let wel dat daar 4 partisies in AWS is, maar slegs 3 maniere om hulle te noem:
AWS Standaard: aws
AWS China: aws-cn
AWS US openbare Internet (GovCloud): aws-us-gov
AWS Geheim (VS Geklassifiseer): aws
IAM is die diens wat jou in staat stel om Identifikasie, Outorisasie en Toegangsbeheer binne jou AWS-rekening te bestuur.
Identifikasie - Proses van die definisie van 'n identiteit en die verifikasie van daardie identiteit. Hierdie proses kan onderverdeel word in: Identifikasie en verifikasie.
Outorisasie - Bepaal wat 'n identiteit binne 'n stelsel kan toegang kry nadat dit daaraan geoutentiseer is.
Toegangsbeheer - Die metode en proses van hoe toegang tot 'n veilige hulpbron verleen word.
IAM kan gedefinieer word deur sy vermoë om die outentisering, ouotorisasie en toegangsbeheer meganismes van identiteite tot jou hulpbronne binne jou AWS-rekening te bestuur, te beheer en te regeer.
Wanneer jy 'n Amazon Web Services (AWS)-rekening skep, begin jy met 'n enkele aanmeldingsidentiteit wat volledige toegang tot alle AWS-diens en hulpbronne in die rekening het. Dit is die AWS-rekening hoofgebruiker en word benader deur aan te meld met die e-posadres en wagwoord wat jy gebruik het om die rekening te skep.
Let daarop dat 'n nuwe administrateurgebruiker minder regte sal hê as die hoofgebruiker.
Vanuit 'n sekuriteits-oogpunt word dit aanbeveel om ander gebruikers te skep en hierdie een te vermy.
'n IAM-gebruiker is 'n entiteit wat jy in AWS skep om die persoon of toepassing te verteenwoordig wat dit gebruik om met AWS te interakteer. 'n Gebruiker in AWS bestaan uit 'n naam en geloofsbriewe (wagwoord en tot twee toegangssleutels).
Wanneer jy 'n IAM-gebruiker skep, verleen jy dit regte deur dit 'n lid van 'n gebruikersgroep te maak wat toepaslike toestemmingsbeleide geheg het (aanbeveel), of deur beleide direk aan die gebruiker te heg.
Gebruikers kan MFA geaktiveer hê om aan te meld deur die konsole. API-tokens van MFA-geaktiveerde gebruikers word nie deur MFA beskerm nie. As jy die toegang van 'n gebruikers-API-sleutels met MFA wil beperk, moet jy in die beleid aandui dat MFA teenwoordig moet wees om sekere aksies uit te voer (voorbeeld hier).
Toegangssleutel-ID: 20 lukrake hoofletter alfanumeriese karakters soos AKHDNAPO86BSHKDIRYT
Geheime toegangssleutel-ID: 40 lukrake hoof- en kleinletterkarakters: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Dit is nie moontlik om verlore geheime toegangssleutel-IDs te herwin nie).
Wanneer jy die Toegangssleutel wil verander is hierdie die proses wat jy moet volg: *Skep 'n nuwe toegangssleutel -> Pas die nuwe sleutel toe op die stelsel/toepassing -> merk die oorspronklike een as onaktief -> Toets en verifieer dat die nuwe toegangssleutel werk -> Verwyder die ou toegangssleutel_
Dit word gebruik om 'n bykomende faktor vir verifikasie te skep bo-op jou bestaande metodes, soos wagwoord, en skep dus 'n multi-faktor-vlak van verifikasie. Jy kan 'n gratis virtuele toepassing of 'n fisiese toestel gebruik. Jy kan programme soos Google-verifikasie gratis gebruik om 'n MFA in AWS te aktiveer.
Beleide met MFA-voorwaardes kan geheg word aan die volgende:
'n IAM-gebruiker of -groep
'n hulpbron soos 'n Amazon S3-emmer, Amazon SQS-ry, of Amazon SNS-onderwerp
Die vertrouensbeleid van 'n IAM-rol wat deur 'n gebruiker aangeneem kan word
As jy toegang via CLI tot 'n hulpbron wil hê wat vir MFA kontroleer, moet jy GetSessionToken noem. Dit sal jou 'n token gee met inligting oor MFA.
Let daarop dat AssumeRole geloofsbriewe hierdie inligting nie bevat nie.
Soos hier gestel, is daar baie verskillende gevalle waar MFA nie gebruik kan word nie.
'n IAM gebruikersgroep is 'n manier om beleide aan meervoudige gebruikers te koppel op een slag, wat dit makliker kan maak om die toestemmings vir daardie gebruikers te bestuur. Rolle en groepe kan nie deel wees van 'n groep nie.
Jy kan 'n identiteitsgebaseerde beleid aan 'n gebruikersgroep koppel sodat al die gebruikers in die gebruikersgroep die beleid se toestemmings ontvang. Jy kan nie 'n gebruikersgroep identifiseer as 'n Prinsipaal in 'n beleid (soos 'n hulpbrongebaseerde beleid) omdat groepe verband hou met toestemmings, nie met outentisering nie, en prinsipale is geoutentiseerde IAM-entiteite.
Hier is 'n paar belangrike eienskappe van gebruikersgroepe:
'n gebruikers groep kan baie gebruikers bevat, en 'n gebruiker kan tot verskeie groepe behoort.
Gebruikersgroepe kan nie genestel word nie; hulle kan slegs gebruikers bevat, nie ander gebruikersgroepe nie.
Daar is geen verstek gebruikersgroep wat outomaties alle gebruikers in die AWS-rekening insluit nie. As jy 'n gebruikersgroep soos dit wil hê, moet jy dit skep en elke nuwe gebruiker daaraan toewys.
Die aantal en grootte van IAM-hulpbronne in 'n AWS-rekening, soos die aantal groepe, en die aantal groepe waarvan 'n gebruiker 'n lid kan wees, is beperk. Vir meer inligting, sien IAM en AWS STS kwotas.
'n IAM rol is baie soortgelyk aan 'n gebruiker, in die sin dat dit 'n identiteit met toestemmingsbeleide is wat bepaal wat dit in AWS kan en nie kan doen nie. 'n Rol het egter geen geloofsbriewe (wagwoord of toegangssleutels) wat daarmee verband hou nie. In plaas daarvan om uniek verband te hou met een persoon, is 'n rol bedoel om deur enigiemand wat dit nodig het (en genoeg perms het) oorgeneem te word. 'n IAM-gebruiker kan 'n rol aanneem om tydelik ander toestemmings vir 'n spesifieke taak oor te neem. 'n Rol kan aan 'n gefedereerde gebruiker toegewys word wat aanmeld deur 'n eksterne identiteitsverskaffer te gebruik in plaas van IAM.
'n IAM-rol bestaan uit twee soorte beleide: 'n vertrouensbeleid, wat nie leeg kan wees nie, wat bepaal wie die rol kan aanneem, en 'n toestemmingsbeleid, wat nie leeg kan wees nie, wat bepaal waartoe dit toegang kan hê.
AWS-sekuriteitstokendiens (STS) is 'n webdiens wat die uitreiking van tydelike, beperkte-voorreggelde geloofsbriewe fasiliteer. Dit is spesifiek ontwerp vir:
Tydelike geloofsbriewe word hoofsaaklik met IAM-rolle gebruik, maar daar is ook ander gebruike. Jy kan tydelike geloofsbriewe aanvra wat 'n meer beperkte stel toestemmings het as jou standaard IAM-gebruiker. Dit voorkom dat jy per ongeluk take uitvoer wat nie toegelaat word deur die meer beperkte geloofsbriewe. 'n Voordeel van tydelike geloofsbriewe is dat hulle outomaties verval na 'n bepaalde tydperk. Jy het beheer oor die tydsduur wat die geloofsbriewe geldig is.
Word gebruik om toestemmings toe te ken. Daar is 2 soorte:
AWS-bestuurde beleide (vooraf gekonfigureer deur AWS)
Klantbestuurde beleide: Deur jou gekonfigureer. Jy kan beleide skep gebaseer op AWS-bestuurde beleide (een daarvan wysig en jou eie skep), die beleidopwekker gebruik ( 'n GUI-aansig wat jou help om toestemmings te verleen en te ontken) of jou eie skryf.
Standaardtoegang is ontken, toegang sal verleen word as 'n eksplisiete rol gespesifiseer is. As 'n enkele "Ontken" bestaan, sal dit die "Toelaat" oorskryf, behalwe vir versoek wat die AWS-rekening se hoofsekuriteitsgelde (wat standaard toegelaat word) gebruik.
Die globale velde wat gebruik kan word vir voorwaardes in enige diens is hier gedokumenteer. Die spesifieke velde wat gebruik kan word vir voorwaardes per diens is hier gedokumenteer.
Hierdie soort beleide word direk toegewys aan 'n gebruiker, groep of rol. Dan verskyn hulle nie in die Lys van Beleide nie aangesien enige ander een dit kan gebruik. Inline beleide is nuttig as jy 'n streng een-tot-een verhouding tussen 'n beleid en die identiteit wat dit toegepas word, wil handhaaf. Byvoorbeeld, jy wil seker maak dat die toestemmings in 'n beleid nie per ongeluk aan 'n identiteit toegewys word wat nie vir hulle bedoel is nie. Wanneer jy 'n inline beleid gebruik, kan die toestemmings in die beleid nie per ongeluk aan die verkeerde identiteit geheg word nie. Daarbenewens, wanneer jy die AWS-bestuurskonsol gebruik om daardie identiteit te verwyder, word die beleide wat in die identiteit ingebed is, ook verwyder. Dit is omdat hulle deel is van die hoofentiteit.
Dit is beleide wat in hulpbronne gedefinieer kan word. Nie alle hulpbronne van AWS ondersteun hulle nie.
As 'n hoofsaak nie 'n uitdruklike ontkenning daarop het nie, en 'n hulpbronbeleid hulle toegang verleen, dan word hulle toegelaat.
IAM-grense kan gebruik word om die toestemmings wat 'n gebruiker of rol toegang tot moet hê, te beperk. Op hierdie manier, selfs al word 'n ander stel toestemmings aan die gebruiker verleen deur 'n verskillende beleid, sal die operasie misluk as hy probeer om dit te gebruik.
'n Grens is net 'n beleid wat aan 'n gebruiker geheg is wat die maksimum vlak van toestemmings wat die gebruiker of rol kan hê, aandui. So, selfs al het die gebruiker Administrateurtoegang, as die grens aandui dat hy slegs S·-emmers kan lees, is dit die maksimum wat hy kan doen.
Dit, SCPs en om die beginsel van die minste bevoegdheid te volg is die maniere om te beheer dat gebruikers nie meer toestemmings het as wat hulle nodig het nie.
'n Sessiebeleid is 'n beleid wat ingestel word wanneer 'n rol aanvaar word op een of ander manier. Dit sal soos 'n IAM-grens vir daardie sessie wees: Dit beteken dat die sessiebeleid nie toestemmings verleen nie, maar hulle beperk tot diegene wat in die beleid aangedui word (waar die maksimum toestemmings diegene is wat die rol het).
Dit is nuttig vir sekuriteitsmaatreëls: Wanneer 'n administrateur 'n baie bevoorregte rol gaan aanvaar, kan hy die toestemming beperk tot slegs diegene wat in die sessiebeleid aangedui word in geval die sessie gekompromitteer word.
Merk op dat AWS standaard sessiebeleide kan byvoeg tot sessies wat gegenereer gaan word as gevolg van derde redes. Byvoorbeeld, in ongeauthentiseerde cognito aangeneemde rolle standaard (met verbeterde outentifikasie), AWS sal sessiekredensiale met 'n sessiebeleid genereer wat die dienste beperk wat die sessie kan toegang tot die volgende lys.
Daarom, as jy op 'n punt die fout teëkom "... omdat geen sessiebeleid die toelaat nie ...", en die rol het toegang om die aksie uit te voer, is dit omdat daar 'n sessiebeleid is wat dit voorkom.
Identiteitsfederasie laat gebruikers van identiteitsverskaffers wat ekstern is tot AWS toe om AWS-bronne veilig te benader sonder om AWS-gebruikerskredensiale van 'n geldige IAM-gebruikersrekening te voorsien. 'N Voorbeeld van 'n identiteitsverskaffer kan jou eie korporatiewe Microsoft Active Directory(via SAML) of OpenID-diens (soos Google) wees. Gefedereerde toegang sal dan die gebruikers binne dit toelaat om AWS te benader.
Om hierdie vertroue te konfigureer, word 'n IAM-identiteitsverskaffer gegenereer (SAML of OAuth) wat die ander platform sal vertrou. Dan, word ten minste een IAM-rol toegewys (wat vertrou) aan die identiteitsverskaffer. As 'n gebruiker van die vertroude platform AWS benader, sal hy as die genoemde rol toegang hê.
Gewoonlik wil jy egter 'n verskillende rol gee, afhangende van die groep van die gebruiker in die derde party platform. Dan kan verskeie IAM-rolle die derde party Identiteitsverskaffer vertrou en die derde party platform sal die een of die ander rol aan gebruikers toelaat om aan te neem.
AWS IAM Identiteitsentrum (opvolger van AWS Enkelinvoer) brei die moontlikhede van AWS Identiteits- en Toegangsbestuur (IAM) uit om 'n sentrale plek te bied wat administrasie van gebruikers en hul toegang tot AWS-rekeninge en wolktoepassings saambring.
Die aanmeldingsdomein gaan iets soos <user_input>.awsapps.com wees.
Om gebruikers aan te meld, kan daar van 3 identiteitsbronne gebruik gemaak word:
Identiteitsentrum-gids: Gewone AWS-gebruikers
Aktiewe Gids: Ondersteun verskillende koppelvlakke
Eksterne Identiteitsverskaffer: Alle gebruikers en groepe kom van 'n eksterne Identiteitsverskaffer (IdP)
In die eenvoudigste geval van Identiteitsentrum-gids, sal die Identiteitsentrum 'n lys van gebruikers & groepe hê en sal in staat wees om beleide aan hulle toe te ken vir enige van die rekeninge van die organisasie.
Om toegang te gee aan 'n Identiteitsentrum-gebruiker/groep tot 'n rekening, sal 'n SAML-identiteitsverskaffer wat die Identiteitsentrum vertrou, geskep word, en 'n rol wat die Identiteitsverskaffer vertrou met die aangeduide beleide, sal in die bestemmingsrekening geskep word.
Dit is moontlik om toestemmings via inline-beleide aan rolle wat deur IAM Identiteitsentrum geskep is, te gee. Die rolle wat in die rekeninge geskep word en inline-beleide in AWS Identiteitsentrum kry, sal hierdie toestemmings in 'n inline-beleid genaamd AwsSSOInlinePolicy hê.
Daarom, selfs as jy 2 rolle sien met 'n inline-beleid genaamd AwsSSOInlinePolicy, beteken dit nie dat dit dieselfde toestemmings het nie.
'N Gebruiker (wat vertrou) kan 'n Kruisrekeningrol met sekere beleide skep en dan, 'n ander gebruiker (wat vertrou word) toelaat om sy rekening te benader maar slegs die toegang te hê wat in die nuwe rolbeleide aangedui word. Om dit te skep, skep net 'n nuwe Rol en kies Kruisrekeningrol. Rolle vir Kruisrekenings-toegang bied twee opsies. Om toegang te bied tussen AWS-rekeninge wat jy besit, en om toegang te bied tussen 'n rekening wat jy besit en 'n derde party AWS-rekening. Dit word aanbeveel om die gebruiker wat vertrou word te spesifiseer en nie iets generies te plaas nie omdat as dit nie gedoen word nie, sal ander geauthentiseerde gebruikers soos gefedereerde gebruikers ook hierdie vertroue kan misbruik.
Nie ondersteun nie:
Vertrouensverhoudings
AD-adminsentrum
Volle PS-API-ondersteuning
AD-herwinbin
Groep Bestuurde Diensrekeninge
Skema-uitbreidings
Geen Direkte toegang tot OS of Instansies
Die program gebruik die AssumeRoleWithWebIdentity om tydelike kredensiale te skep. Dit gee egter nie toegang tot die AWS-konsole nie, net toegang tot bronne binne AWS.
Jy kan 'n wagwoordbeleid instel met opsies soos minimum lengte en wagwoordvereistes.
Jy kan 'n "Credential Report" aflaai met inligting oor huidige kredensiale (soos gebruiker-skeppingstyd, is wagwoord geaktiveer...). Jy kan 'n kredensiaalverslag genereer so dikwels as een keer elke vier ure.
AWS Identiteits- en Toegangsbestuur (IAM) bied fynkorrelige toegangsbeheer regoor alle AWS. Met IAM kan jy spesifiseer wie toegang tot watter dienste en bronne kan hê, en onder watter toestande. Met IAM-beleide bestuur jy toestemmings tot jou werksmag en stelsels om minste-privilege-toestemmings te verseker.
Op hierdie bladsy kan jy die IAM-ID-voorvoegsels van sleutels vind afhangende van hul aard:
ABIA | |
ACCA | Konteks-spesifieke geloofsbriewe |
AGPA | Gebruikersgroep |
AIDA | IAM-gebruiker |
AIPA | Amazon EC2-instansieprofiel |
AKIA | Toegangssleutel |
ANPA | Bestuurde beleid |
ANVA | Weergawe in 'n bestuurde beleid |
APKA | Publieke sleutel |
AROA | Rol |
ASCA | Sertifikaat |
ASIA | Tydelike (AWS STS) toegangssleutel-ID's](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) gebruik hierdie voorvoegsel, maar is uniek slegs in kombinasie met die geheime toegangssleutel en die sessietoken. |
Die volgende bevoegdhede gee verskeie leestoegang tot metadata:
arn:aws:iam::aws:policy/SecurityAudit
arn:aws:iam::aws:policy/job-function/ViewOnlyAccess
codebuild:ListProjects
config:Describe*
cloudformation:ListStacks
logs:DescribeMetricFilters
directconnect:DescribeConnections
dynamodb:ListTables
Om 'n gewone gebruiker te laat outentifiseer na AWS via CLI, het jy plaaslike kredensiale nodig. Standaard kan jy hulle handmatig konfigureer in ~/.aws/credentials of deur aws configure te hardloop.
In daardie lêer kan jy meer as een profiel hê, as geen profiel gespesifiseer word nie met die aws cli, sal die een genaamd [default] in daardie lêer gebruik word.
Voorbeeld van kredensiale-lêer met meer as 1 profiel:
Indien jy toegang tot verskillende AWS-rekeninge benodig en jou profiel toegang gekry het om 'n rol binne daardie rekeninge aan te neem, hoef jy nie elke keer handmatig STS te roep (aws sts assume-role --role-arn <role-arn> --role-session-name sessname) en die geloofsbriewe te konfigureer nie.
Jy kan die ~/.aws/config lêer gebruik om aan te dui watter rolle aangeneem moet word, en dan die --profile parameter soos gewoonlik te gebruik (die assume-role sal op 'n deursigtige manier vir die gebruiker uitgevoer word).
'N Voorbeeld van 'n konfigurasie lêer:
Met hierdie konfigurasie lêer kan jy dan die aws cli soos volg gebruik:
Indien jy iets soortgelyks soek vir die blaaier kan jy die uitbreiding AWS Extend Switch Roles nagaan.
