Amazon prognose er en fuldt administreret tjeneste, der er baseret på den samme teknologi, der bruges til prognoser på Amazon.com. Forecast bruger maskinlæring (ML) til at kombinere tidsseriedata med yderligere variabler for at opbygge meget nøjagtige prognoser. Forecast kræver ingen ML-erfaring for at komme i gang. Du behøver kun at angive historiske data og eventuelle yderligere data, der kan påvirke prognoser.
Kunder vender sig mod at bruge en Software as Service-model (SaaS) til levering af multi-tenant-løsninger. Du kan bygge SaaS-applikationer med en række forskellige arkitektoniske modeller for at opfylde regulatoriske og overholdelseskrav. Afhængigt af SaaS-modellen deles ressourcer som Forecast på tværs af lejere. Prognosedataadgang, overvågning og fakturering skal tages i betragtning pr. lejer for at implementere SaaS-løsninger.
Dette indlæg beskriver, hvordan du bruger Forecast i en SaaS-applikation med flere lejere ved hjælp af Attributbaseret adgangskontrol (ABAC) i AWS identitets- og adgangsstyring (IAM) til at levere disse muligheder. ABAC er en kraftfuld tilgang, som du kan bruge til at isolere ressourcer på tværs af lejere.
I dette indlæg giver vi vejledning om opsætning af IAM-politikker for lejere ved hjælp af ABAC-principper og prognose. For at demonstrere konfigurationen har vi oprettet to lejere, TenantA
, TenantB
, og vis en use case i sammenhæng med en SaaS-applikation ved hjælp af Forecast. I vores anvendelsestilfælde, TenantB
kan ikke slette TenantA
ressourcer og omvendt. Følgende diagram illustrerer vores arkitektur.
TenantA
, TenantB
har tjenester, der kører som mikroservice indenfor Amazon Elastic Kubernetes Service (Amazon EKS). Lejerapplikationen bruger Forecast som en del af sit forretningsflow.
Prognostiseret dataindtagelse
Forecast importerer data fra lejerens Amazon Simple Storage Service (Amazon S3) spand til den Forecast-administrerede S3-spand. Data kan krypteres under transport og hvile automatisk ved hjælp af Forecast-administrerede nøgler eller lejerspecifikke nøgler via AWS Key Management Service (AWS KMS). Den lejerspecifikke nøgle kan oprettes af SaaS-applikationen som en del af onboarding, eller lejeren kan levere sin egen kundeadministrerede nøgle (CMK) ved hjælp af AWS KMS. Tilbagekaldelse af tilladelse på den lejerspecifikke nøgle forhindrer Forecast i at bruge lejerens data. Vi anbefaler at bruge en lejerspecifik nøgle og en IAM-rolle pr. lejer i et SaaS-miljø med flere lejere. Dette gør det muligt at sikre data på lejer-for-lejer basis.
Løsningsoversigt
Du kan partitionere data på Amazon S3 for at adskille lejers adgang på forskellige måder. Til dette indlæg diskuterer vi to strategier:
- Brug en S3-spand pr. lejer
- Brug en enkelt S3-bøtte og adskil lejerdata med et præfiks
For mere information om forskellige strategier, se Lagring af Multi-Tenant Data på Amazon S3 GitHub repo.
Når du bruger én bucket pr. lejer, bruger du en IAM-politik til at begrænse adgangen til en given lejer S3 bucket. For eksempel:
Der er en hård grænse for antallet af S3 buckets pr. konto. En strategi med flere konti skal overvejes for at overvinde denne grænse.
I vores anden mulighed blev lejerdata adskilt ved hjælp af et S3-præfiks i en enkelt S3-bøtte. Vi bruger en IAM-politik til at begrænse adgangen inden for et bucket-præfiks pr. lejer. For eksempel:
Til dette indlæg bruger vi den anden mulighed for at tildele S3-præfikser inden for en enkelt bucket. Vi krypterer lejerdata ved hjælp af CMK'er i AWS KMS.
Lejer onboarding
SaaS-applikationer er afhængige af en friktionsfri model til at introducere nye lejere i deres miljø. Dette kræver ofte orkestrering af flere komponenter for at kunne klargøre og konfigurere alle de nødvendige elementer for at oprette en ny lejer. Denne proces, i SaaS-arkitektur, omtales som lejer onboarding. Dette kan initieres direkte af lejere eller som en del af en udbyderstyret proces. Følgende diagram illustrerer strømmen af konfiguration af Forecast pr. lejer som en del af onboarding-processen.
Ressourcer er mærket med lejeroplysninger. Til dette indlæg tagger vi ressourcer med en værdi for lejer, f.eks. tenant_a
.
Opret en Forecast-rolle
Denne IAM-rolle påtages af Forecast pr. lejer. Du bør anvende følgende politik for at tillade Forecast at interagere med Amazon S3 og AWS KMS på kundekontoen. Rollen er tagget med tag-lejer. Se for eksempel følgende kode:
Opret politikkerne
I dette næste trin opretter vi politikker for vores Forecast-rolle. Til dette indlæg opdeler vi dem i to politikker for mere læsbarhed, men du kan oprette dem efter dine behov.
Politik 1: Prognostiseret skrivebeskyttet adgang
Følgende politik giver privilegier til at beskrive, liste og forespørge om prognoseressourcer. Denne politik begrænser Forecast til skrivebeskyttet adgang. Lejer-tag-valideringsbetingelsen i følgende kode sikrer, at lejer-tag-værdien matcher principalens lejer-tag. Der henvises til kode med fed skrift for detaljer.
Politik 2: Amazon S3 og AWS KMS adgangspolitik
Følgende politik giver privilegier til AWS KMS og adgang til S3-lejerpræfikset. Lejer-tag-valideringsbetingelsen i følgende kode sikrer, at lejer-tag-værdien matcher principalens lejer-tag. Der henvises til kode med fed skrift for detaljer.
Opret en lejerspecifik nøgle
Vi opretter nu en lejerspecifik nøgle i AWS KMS pr. lejer og tagger den med lejermærkeværdien. Alternativt kan lejer medbringe egen nøgle til AWS KMS. Vi giver de foregående roller (Forecast_TenantA_Role
or Forecast_TenantB_Role
) adgang til den lejerspecifikke nøgle.
For eksempel viser følgende skærmbillede nøgleværdi-parret af tenant
, tenant_a
.
Følgende skærmbillede viser de IAM-roller, der kan bruge denne nøgle.
Opret en ansøgningsrolle
Den anden rolle, vi opretter, påtages af SaaS-applikationen pr. lejer. Du bør anvende følgende politik for at tillade, at applikationen interagerer med Forecast, Amazon S3 og AWS KMS. Rollen er tagget med tag-lejer. Se følgende kode:
Opret politikkerne
Vi laver nu politikker for ansøgningsrollen. Til dette indlæg opdeler vi dem i to politikker for mere læsbarhed, men du kan oprette dem efter dine behov.
Politik 1: Prognoseadgang
Følgende politik giver privilegier til at oprette, opdatere og slette prognoseressourcer. Politikken håndhæver tagkravet under oprettelsen. Derudover begrænser det list
, describe
og delete
handlinger på ressourcer til den respektive lejer. Denne politik har IAM PassRole
for at tillade Forecast at påtage sig rollen.
tenant
tagvalideringsbetingelse i den følgende kode sikrer, at lejertagværdien matcher lejeren. Der henvises til kode med fed skrift for detaljer.
Politik 2: Amazon S3, AWS KMS, Amazon CloudWatch og ressourcegruppeadgang
Følgende politik giver privilegier til at få adgang til Amazon S3 og AWS KMS ressourcer, og også amazoncloudwatch. Det begrænser adgangen til det lejerspecifikke S3-præfiks og det lejerspecifikke CMK. Betingelsen for lejervalidering er i kode med fed skrift.
Opret en ressourcegruppe
Ressourcegruppen tillader, at alle taggede ressourcer kan forespørges af lejeren. Følgende eksempelkode bruger AWS kommandolinjegrænseflade (AWS CLI) for at oprette en ressourcegruppe for TenantA
:
Forecast ansøgningsflow
Følgende diagram illustrerer vores Forecast-applikationsflow. Applikationstjenesten påtager sig IAM-rollen for lejeren og påberåber sig som en del af dens forretningsflow Forecast API.
Opret en forudsigelse for TenantB
De oprettede ressourcer skal mærkes med lejer-tagget. Følgende kode bruger Python (Boto3) API til at oprette en forudsigelse for TenantB (se kode med fed skrift for detaljer):
Opret en prognose på forudsigeren for TenantB
Følgende kode bruger Python (Boto3) API til at oprette en prognose på den forudsigelse, du lige har oprettet:
Valider adgang til prognoseressourcer
I dette afsnit bekræfter vi, at kun den respektive lejer kan få adgang til Forecast-ressourcer. Adgang til, ændring eller sletning af prognoseressourcer, der tilhører en anden lejer, giver en fejl. Følgende kode bruger Python (Boto3) API til at demonstrere, at TenantA forsøger at slette en TenantB Forecast-ressource:
Liste og overvåge forudsigelser
Følgende eksempelkode bruger Python (Boto3) API til at forespørge prognoseprædiktorer for TenantA ved hjælp af ressourcegrupper:
Som AWS velstruktureret rammeværk forklarer, er det vigtigt at overvåge servicekvoter (som også kaldes servicegrænser). Forecast har grænser pr. konti; for mere information, se Retningslinjer og kvoter.
Følgende kode er et eksempel på at udfylde en CloudWatch-metrik med det samlede antal prædiktorer:
Andre overvejelser
Ressourcegrænser og drosling skal administreres af applikationen på tværs af lejere. Hvis du ikke kan rumme Prognosegrænser, bør du overveje en konfiguration med flere konti.
Forecast List API'er eller ressourcegruppesvar skal filtreres efter applikation baseret på tenant
tag værdi.
Konklusion
I dette indlæg demonstrerede vi, hvordan man isolerer prognoseadgang ved hjælp af ABAC-teknikken i en SaaS-applikation med flere lejere. Vi viste, hvordan man begrænser adgangen til Forecast af lejer ved hjælp af lejer-tagget. Du kan tilpasse politikker yderligere ved at anvende flere tags eller anvende denne strategi på andre AWS-tjenester.
For mere information om brug af ABAC som en godkendelsesstrategi, se Hvad er ABAC for AWS?
Om forfatterne
Gunjan Garg er Sr. Software Development Engineer i AWS Vertical AI-teamet. I sin nuværende rolle hos Amazon Forecast fokuserer hun på tekniske problemer og nyder at bygge skalerbare systemer, der giver mest værdi til slutbrugerne. I sin fritid nyder hun at spille Sudoku og minestryger.
Matias Battaglia er Technical Account Manager hos Amazon Web Services. I sin nuværende rolle nyder han at hjælpe kunder på alle stadier af deres cloud-rejse. I sin fritid nyder han at bygge AI/ML-projekter.
Rakesh Ramadas er en ISV Solution Architect hos Amazon Web Services. Hans fokusområder omfatter AI/ML og Big Data.
- adgang
- Konto
- Handling
- Yderligere
- AI
- Amazon
- Amazon prognose
- Amazon Web Services
- api
- API'er
- Anvendelse
- applikationer
- arkitektur
- tilladelse
- AWS
- fakturerings- og
- bygge
- Bygning
- virksomhed
- Cloud
- kode
- Compliance
- Nuværende
- Kunder
- data
- dataadgang
- Dekryptér
- levering
- Udvikling
- ingeniør
- Engineering
- Miljø
- flow
- Fokus
- Gratis
- GitHub
- gruppe
- Hvordan
- How To
- HTTPS
- IAM
- Identity
- KIMOs Succeshistorier
- oplysninger
- IT
- Nøgle
- nøgler
- Kubernetes
- læring
- Line (linje)
- Liste
- machine learning
- ledelse
- ML
- model
- overvågning
- onboarding
- Option
- Andet
- politikker
- politik
- projekter
- Python
- Krav
- ressource
- Ressourcer
- svar
- REST
- kører
- SaaS
- Series
- Tjenester
- sæt
- indstilling
- delt
- Simpelt
- Software
- softwareudvikling
- Løsninger
- delt
- påbegyndt
- Statement
- opbevaring
- Strategi
- Systemer
- Teknisk
- Teknologier
- tid
- transit
- Opdatering
- brugere
- værdi
- web
- webservices
- inden for