Skysikkerhet hos AWS har høyeste prioritet. Amazon SageMaker Studio tilbud ulike mekanismer for å beskytte data og kode ved å bruke integrasjon med AWS-sikkerhetstjenester som AWS identitets- og tilgangsadministrasjon (JEG ER), AWS nøkkelstyringstjeneste (AWS KMS), eller nettverksisolasjon med Amazon Virtual Private Cloud (Amazon VPC).
Kunder i sterkt regulerte bransjer, som finansielle tjenester, kan konfigurer Studio kun i VPC modus for å aktivere nettverksisolering og deaktivere internettilgang fra Studio-notatbøker. Du kan bruke IAM-integrasjon med Studio for å kontrollere hvilke brukere som har tilgang til ressurser som Studio-notatbøker, Studio IDE eller Amazon SageMaker treningsjobber.
En populær brukssak er å begrense tilgangen til Studio IDE kun til brukere fra et spesifisert nettverks-CIDR-område eller en utpekt VPC. Dette kan du oppnå ved å implementere IAM-identitetsbaserte SageMaker-policyer og knytte disse retningslinjene til IAM-brukere eller -grupper som krever disse tillatelsene. SageMaker-domenet må imidlertid konfigureres med IAM-autentiseringsmodus, fordi IAM-identitetsbaserte retningslinjer ikke støttes i AWS enkelt pålogging (SSO) autentiseringsmodus.
Mange kunder bruker AWS SSO for å aktivere sentralisert identitetskontroll for arbeidsstyrken og gi en konsistent brukerpåloggingsopplevelse. Dette innlegget viser hvordan du implementerer denne brukstilfellet mens du beholder AWS SSO-funksjoner for å få tilgang til Studio.
Løsningsoversikt
Når du setter opp et SageMaker-domene i kun VPC-modus og spesifiserer undernett og sikkerhetsgrupper, oppretter SageMaker elastiske nettverksgrensesnitt (ENI-er) som er knyttet til sikkerhetsgruppene dine i de angitte undernettene. ENI-er lar treningsbeholderne dine koble til ressurser i din VPC.
I denne modusen er den direkte internettilgangen fra bærbare datamaskiner fullstendig deaktivert, og all trafikken rutes gjennom en ENI i din private VPC. Dette inkluderer også trafikk fra Studio UI-widgeter og grensesnitt – som eksperimentadministrasjon, autopilot og modellmonitor – til deres respektive backend SageMaker API-er. AWS anbefaler å bruke kun VPC-modus for å utøve finmasket kontroll over nettverkstilgang til Studio.
Den første utfordringen er at selv om Studio er distribuert uten internettforbindelse, kan Studio IDE fortsatt nås fra hvor som helst, forutsatt tilgang til AWS-administrasjonskonsoll og Studio er gitt til en IAM-rektor. Denne situasjonen er ikke akseptabel hvis du ønsker å fullstendig isolere Studio fra et offentlig nettverk og inneholde all kommunikasjon innenfor en tett kontrollert privat VPC.
For å løse denne utfordringen og deaktivere all tilgang til Studio IDE unntatt fra en angitt VPC eller et CIDR-område, kan du bruke CreatePresignedDomainUrl SageMaker API. IAM-rollen eller brukeren som brukes til å kalle denne APIen definerer tillatelsene for å få tilgang til Studio. Nå kan du bruke IAM-identitetsbaserte retningslinjer for å implementere ønsket tilgangskonfigurasjon. For å aktivere tilgang bare fra en utpekt VPC, legg for eksempel til følgende betingelse i IAM-policyen, knyttet til en IAM-prinsipal, som brukes til å generere en forhåndsdefinert domene-URL:
For å aktivere tilgang bare fra et eller flere angitte VPC-endepunkter, spesifiser følgende betingelse:
Bruk følgende betingelse for å begrense tilgang fra et angitt CIDR-område:
Den andre utfordringen er at IAM-basert tilgangskontroll bare fungerer når SageMaker-domenet er konfigurert i IAM-autentiseringsmodus; du kan ikke bruke det når SageMaker-domenet er distribuert i AWS SSO-modus. Den neste delen viser hvordan du kan håndtere disse utfordringene og implementere IAM-basert tilgangskontroll med AWS SSO-tilgang til Studio.
Arkitekturoversikt
Studio er publisert som en SAML-applikasjon, som er tilordnet en spesifikk SageMaker Studio-brukerprofil. Brukere kan enkelt få tilgang til Studio direkte fra AWS SSO-portalen, som vist i følgende skjermbilde.
Løsningen integreres med en tilpasset SAML 2.0-applikasjon som mekanismen for å utløse brukerautentisering for Studio. Det krever at den tilpassede SAML-applikasjonen er konfigurert med Amazon API-gateway endepunkts-URL som sin Assertion Consumer Service (ACS), og trenger tilordningsattributter som inneholder AWS SSO-bruker-ID samt SageMaker-domene-ID.
API-gateway-endepunktet kaller en AWS Lambda funksjon som analyserer SAML-svaret for å trekke ut domene-IDen og bruker-IDen og bruke dem til å generere en Studio forhåndsdefinert URL. Lambda-funksjonen utfører til slutt en omdirigering via et HTTP 302-svar for å logge på brukeren i Studio.
En IAM-policy kontrollerer nettverksmiljøet som Studio-brukere har tillatelse til å logge på fra, som inkluderer begrensende forhold som beskrevet i forrige avsnitt. Denne IAM-policyen er knyttet til Lambda-funksjonen. IAM-policyen inneholder en tillatelse til å ringe sagemaker:CreatePresignedDomainURL
API kun for en spesifikk brukerprofil:
Følgende diagram viser løsningsarkitekturen.
Løsningen distribuerer et SageMaker-domene i din private VPC og VPC-endepunkter for å få tilgang til Studio, SageMaker runtime og SageMaker API via en privat tilkobling uten behov for en internettgateway. VPC-endepunktene er konfigurert med privat DNS aktivert (PrivateDnsEnabled=True
) å knytte en privat vertssone med din VPC. Dette gjør at Studio får tilgang til SageMaker API ved å bruke standard offentlige DNS-navn api.sagemaker.<Region>.amazonaws.com
løst til den private IP-adressen til endepunktet i stedet for å bruke VPC-endepunktets URL.
Du må legge til VPC-endepunkter til VPC-en din hvis du vil ha tilgang til andre AWS-tjenester som Amazon enkel lagringstjeneste (Amazon S3), Amazon Elastic Container Registry (Amazon ECR), AWS Security Token Service (AWS STS), AWS skyformasjoneller AWS CodeCommit.
Du kan fullt ut kontrollere tillatelser som brukes til å generere den forhåndsinnstilte URL-en og alle andre API-anrop med IAM-policyer knyttet til Lambda-funksjonsutføringsrollen eller kontrollere tilgangen til en hvilken som helst brukt AWS-tjeneste via VPC-endepunktspolicyer. For eksempler på bruk av IAM-policyer for å kontrollere tilgang til Studio og SageMaker API, se Kontroller tilgangen til SageMaker API ved å bruke identitetsbaserte retningslinjer.
Selv om løsningen krever at Studio-domenet distribueres i IAM-modus, tillater den at AWS SSO brukes som mekanismen for sluttbrukere å logge på Studio.
Følgende underavsnitt inneholder detaljerte beskrivelser av de viktigste løsningskomponentene.
API-gateway
API-gateway-endepunktet fungerer som målet for applikasjonens ACS-URL som er konfigurert i den tilpassede SAML 2.0-applikasjonen. Endepunktet er privat, og har en ressurs kalt /saml
og en POST-metode med integrasjonsforespørsel konfigurert som Lambda-proxy. Løsningen bruker et VPC-endepunkt med et konfigurert com.amazonaws.<region>.execute-api
DNS-navn for å kalle dette API-endepunktet fra VPC-en.
AWS SSO
En tilpasset SAML 2.0-applikasjon er konfigurert med API Gateway-endepunkt-URLen https:/{ restapi-id}.execute-api.amazonaws.com/saml
som applikasjonens ACS URL, og bruker attributttilordninger med følgende krav:
- Brukeridentifikator:
- Brukerattributt i applikasjonen – brukernavn
- Maps brukerattributt i AWS SSO -
${user:AD_GUID}
- SageMaker domene ID identifikator:
- Brukerattributt i applikasjonen -
domain-id
- Maps brukerattributt i AWS SSO – Domene-ID for Studio-forekomsten
- Brukerattributt i applikasjonen -
Applikasjonen implementerer tilgangskontrollen for en AWS SSO-bruker ved å klargjøre en Studio-brukerprofil med navnet lik AWS SSO-bruker-IDen.
Lambda funksjon
Løsningen konfigurerer en Lambda-funksjon som et påkallingspunkt for API-gatewayen /saml
ressurs. Funksjonen analyserer SAMLResponse
sendt av AWS SSO, trekker ut domain-id
samt brukernavnet, og kaller createPresignedDomainUrl
SageMaker API for å hente Studio URL og token og omdirigere brukeren til å logge på ved hjelp av et HTTP 302-svar. Lambda-funksjonen har en spesifikk IAM-policy knyttet til sin utførelsesrolle som tillater sagemaker:createPresignedDomainUrl
handling bare når det er forespurt fra et spesifikt nettverks CIDR-område ved hjelp av VpcSourceIp
tilstand.
Lambda-funksjonen har ingen logikk for å validere SAML-svaret, for eksempel for å sjekke en signatur. Men fordi API Gateway-endepunktet som fungerer som ACS er privat eller kun internt, er det ikke obligatorisk for dette proof of concept-miljøet.
Distribuere løsningen
De GitHub repository gir den fullstendige kildekoden for ende-til-ende-løsningen.
For å distribuere løsningen må du ha administratorrettigheter (eller superbruker) for en AWS-konto, og installere AWS kommandolinjegrensesnitt (AWS CLI) og AWS SAM CLI og minimum Python 3.8.
Løsningen støtter distribusjon til tre AWS-regioner: eu-west-1
, eu-central-1
og us-east-1
. Sørg for at du velger en av disse regionene for distribusjon.
For å begynne å teste løsningen, må du fullføre følgende distribusjonstrinn fra løsningens GitHub README-fil:
- Konfigurer AWS SSO hvis du ikke har den konfigurert.
- Distribuer løsningen ved å bruke SAM-applikasjonen.
- Opprett en ny tilpasset SAML 2.0-applikasjon.
Etter at du har fullført distribusjonstrinnene, kan du fortsette med løsningstesten.
Test løsningen
Løsningen simulerer to brukstilfeller for å demonstrere bruken av AWS SSO og SageMaker identitetsbaserte retningslinjer:
- Positiv brukssak – En bruker får tilgang til Studio fra et angitt CIDR-område gjennom et VPC-endepunkt
- Negativ brukssak – En bruker får tilgang til Studio fra en offentlig IP-adresse
For å teste disse brukstilfellene opprettet løsningen tre Amazon Elastic Compute Cloud (Amazon EC2)-forekomster:
- Privat vert – En EC2 Windows-forekomst i et privat undernett som har tilgang til Studio (ditt lokale sikrede miljø)
- Bastion vert – En EC2 Linux-forekomst i det offentlige undernettet som brukes til å etablere en SSH-tunnel inn i den private verten på det private nettverket
- Offentlig vertskap – En EC2 Windows-forekomst i et offentlig undernett for å demonstrere at brukeren ikke kan få tilgang til Studio fra en uautorisert IP-adresse
Test Studio-tilgang fra et autorisert nettverk
Følg disse trinnene for å utføre testen:
- For å få tilgang til EC2 Windows-forekomsten på det private nettverket, kjør kommandoen gitt som verdien av SAM-utdatanøkkelen
TunnelCommand
. Sørg for at den private nøkkelen til nøkkelparet spesifisert i parameteren er i katalogen der SSH-tunnelkommandoen kjører fra. Kommandoen oppretter en SSH-tunnel fra den lokale datamaskinen pålocalhost:3389
til EC2 Windows-forekomsten på det private nettverket. Se følgende eksempelkode: - Åpne en ny RDP-tilkobling (for eksempel ved å bruke Microsoft Remote Desktop) ved å bruke
localhost
som den eksterne målverten. Denne forbindelsen tunneleres via bastionverten til den private EC2 Windows-forekomsten. Bruk brukernavnetAdministrator
og passord fra stabelutgangenSageMakerWindowsPassword
. - Åpne nettleseren Firefox fra det eksterne skrivebordet.
- Naviger og logg på AWS SSO-portalen ved å bruke legitimasjonen knyttet til brukernavnet du spesifiserte som
ssoUserName
parameter. - Velg SageMaker Secure Demo AWS SSO-applikasjon fra AWS SSO-portalen.
Du blir omdirigert til Studio IDE i et nytt nettleservindu.
Test Studio-tilgang fra et uautorisert nettverk
Følg nå disse trinnene for å simulere tilgang fra et uautorisert nettverk:
- Åpne en ny RDP-tilkobling på IP-en som er angitt i
SageMakerWindowsPublicHost
SAML-utgang. - Åpne nettleseren Firefox fra det eksterne skrivebordet.
- Naviger og logg på AWS SSO-portalen ved å bruke legitimasjonen knyttet til brukernavnet som ble spesifisert som
ssoUserName
parameter. - Velg SageMaker Secure Demo AWS SSO-applikasjon fra AWS SSO-portalen.
Denne gangen mottar du en melding om uautorisert tilgang.
Rydd opp
For å unngå gebyrer, må du fjerne alle løsningstilordnede og manuelt opprettede ressurser fra AWS-kontoen din. Følg instruksjonene i løsningens README-fil.
konklusjonen
Vi demonstrerte at ved å introdusere et mellomvare-autentiseringslag mellom sluttbrukeren og Studio, kan vi kontrollere miljøet som brukeren får tilgang til Studio fra og eksplisitt blokkere alle andre uautoriserte miljøer.
For ytterligere å stramme sikkerheten, kan du legge til en IAM-policy til en brukerrolle for å forhindre tilgang til Studio fra konsollen. Hvis du bruker AWS organisasjoner, kan du implementere følgende tjenestekontrollpolicy for organisasjonsenhetene eller kontoene som trenger tilgang til Studio:
Selv om løsningen beskrevet i dette innlegget bruker API Gateway og Lambda, kan du utforske andre måter, for eksempel en EC2-instans med en instansrolle bruke den samme arbeidsflyten for tillatelsevalidering som beskrevet eller til og med et uavhengig system for å håndtere brukerautentisering og -autorisasjon og generere en Studio forhåndsdefinert URL.
Videre lesing
Å sikre tilgang til Studio er et aktivt forskningstema, og det er andre relevante innlegg om lignende tilnærminger. Se følgende innlegg på AWS Machine Learning Blog for å lære mer om andre tjenester og arkitekturer du kan bruke:
Om forfatterne
Jerome Bachelet er løsningsarkitekt hos Amazon Web Services. Han trives med å hjelpe kundene med å få mest mulig ut av AWS for å nå sine forretningsmål. Jerome har over 10 års erfaring med databeskyttelse og datasikkerhetsløsninger. Foruten å være i skyen, liker Jerome å reise og kvalitetstid med sin kone og 2 døtre i Geneve, Sveits-området.
Jevgenij Ilyin er løsningsarkitekt hos AWS. Han har over 20 års erfaring med å jobbe på alle nivåer av programvareutvikling og løsningsarkitektur og har brukt programmeringsspråk fra COBOL og Assembler til .NET, Java og Python. Han utvikler og koder cloud native løsninger med fokus på big data, analytics og data engineering.
- '
- "
- 100
- 7
- 9
- Om oss
- adgang
- Logg inn
- Handling
- aktiv
- adresse
- Alle
- Amazon
- Amazon EC2
- Amazon SageMaker
- Amazon Web Services
- analytics
- api
- APIer
- Søknad
- arkitektur
- AREA
- Autentisering
- autorisasjon
- autopilot
- AWS
- være
- Store data
- Blogg
- nett~~POS=TRUNC leseren~~POS=HEADCOMP
- virksomhet
- ring
- saker
- utfordre
- utfordringer
- avgifter
- Cloud
- sky innfødte
- kode
- Kommunikasjon
- Beregn
- Konfigurasjon
- tilkobling
- Tilkobling
- Konsoll
- forbruker
- Container
- Containere
- Credentials
- Kunder
- dato
- databeskyttelse
- datasikkerhet
- Utvikling
- dns
- ikke
- effekt
- Endpoint
- Ingeniørarbeid
- Miljø
- eksempel
- gjennomføring
- Øvelse
- erfaring
- eksperiment
- ekstrakter
- Endelig
- finansiell
- finansielle tjenester
- Firefox
- Først
- Fokus
- følge
- fullt
- funksjon
- generere
- gif
- Hvordan
- Hvordan
- HTTPS
- IAM
- Identitet
- iverksette
- implementere
- bransjer
- integrering
- Internet
- IP
- IP-adresse
- isolasjon
- IT
- Java
- Jobb
- holde
- nøkkel
- språk
- LÆRE
- læring
- linje
- linux
- lokal
- maskinlæring
- ledelse
- Microsoft
- modell
- nett
- nettverk
- Nettverkstilgang
- notatbøker
- Tilbud
- åpen
- Annen
- Passord
- Politikk
- politikk
- Populær
- Portal
- innlegg
- makt
- Principal
- privat
- private Key
- Profil
- Programmering
- programmerings språk
- bevis
- proof of concept
- beskytte
- beskyttelse
- gi
- gir
- proxy
- offentlig
- Python
- kvalitet
- område
- omdirigere
- Krav
- forskning
- ressurs
- Ressurser
- svar
- Kjør
- sagemaker
- sikkerhet
- Tjenester
- servering
- sett
- lignende
- Enkelt
- Software
- programvareutvikling
- Solutions
- Begynn
- Uttalelse
- lagring
- Støttes
- Støtter
- sveits
- system
- Target
- test
- Testing
- Gjennom
- tid
- token
- trafikk
- Kurs
- ui
- Brukere
- verdi
- virtuelle
- web
- nettleser
- webtjenester
- vinduer
- innenfor
- uten
- arbeidsflyt
- arbeidsstyrke
- virker
- år