Previsioni Amazon è un servizio completamente gestito basato sulla stessa tecnologia utilizzata per le previsioni su Amazon.com. Forecast utilizza il machine learning (ML) per combinare i dati delle serie temporali con variabili aggiuntive per creare previsioni altamente accurate. Forecast non richiede alcuna esperienza di machine learning per iniziare. Devi solo fornire dati storici ed eventuali dati aggiuntivi che potrebbero influire sulle previsioni.
I clienti si stanno orientando verso l'utilizzo di un modello Software as Service (SaaS) per la fornitura di soluzioni multi-tenant. Puoi creare applicazioni SaaS con una varietà di diversi modelli architetturali per soddisfare i requisiti normativi e di conformità. A seconda del modello SaaS, le risorse come Forecast sono condivise tra i tenant. L'accesso ai dati, il monitoraggio e la fatturazione previsti devono essere considerati per tenant per l'implementazione di soluzioni SaaS.
Questo post illustra come utilizzare Forecast all'interno di un'applicazione SaaS multi-tenant utilizzando Controllo degli accessi basato sugli attributi (ABAC) dentro Gestione dell'identità e dell'accesso di AWS (IAM) per fornire queste funzionalità. ABAC è un approccio potente che puoi usare per isolare le risorse tra i tenant.
In questo post, forniamo indicazioni sull'impostazione dei criteri IAM per i tenant utilizzando i principi ABAC e le previsioni. Per dimostrare la configurazione, abbiamo impostato due tenant, TenantA
ed TenantB
e mostra un caso d'uso nel contesto di un'applicazione SaaS utilizzando Forecast. Nel nostro caso d'uso, TenantB
non è possibile eliminare TenantA
risorse e viceversa. Il seguente diagramma illustra la nostra architettura.
TenantA
ed TenantB
avere servizi in esecuzione come microservizio all'interno Servizio Amazon Elastic Kubernetes (Amazon EKS). L'applicazione tenant usa Forecast come parte del proprio flusso aziendale.
Inserimento di dati di previsione
Forecast importa i dati da quelli del tenant Servizio di archiviazione semplice Amazon (Amazon S3) al bucket S3 gestito di previsione. I dati possono essere crittografati in transito e inattivi automaticamente utilizzando chiavi gestite di previsione o chiavi specifiche del tenant tramite Servizio di gestione delle chiavi AWS (AWSKMS). La chiave specifica del tenant può essere creata dall'applicazione SaaS come parte dell'onboarding oppure il tenant può fornire la propria chiave gestita dal cliente (CMK) utilizzando AWS KMS. La revoca dell'autorizzazione sulla chiave specifica del tenant impedisce a Forecast di usare i dati del tenant. Si consiglia di utilizzare una chiave specifica del tenant e un ruolo IAM per tenant in un ambiente SaaS multi-tenant. Ciò consente di proteggere i dati tenant per tenant.
Panoramica della soluzione
Puoi partizionare i dati su Amazon S3 per separare l'accesso dei tenant in diversi modi. Per questo post, discutiamo di due strategie:
- Usa un bucket S3 per tenant
- Utilizza un singolo bucket S3 e separa i dati del tenant con un prefisso
Per ulteriori informazioni sulle varie strategie, vedere il Archiviazione di dati multi-tenant su Amazon S3 Repository GitHub.
Quando utilizzi un bucket per tenant, utilizzi una policy IAM per limitare l'accesso a un determinato bucket S3 tenant. Per esempio:
Esiste un limite rigido al numero di bucket S3 per account. Per superare questo limite è necessario prendere in considerazione una strategia multi-account.
Nella nostra seconda opzione, i dati del tenant sono stati separati utilizzando un prefisso S3 in un singolo bucket S3. Utilizziamo una policy IAM per limitare l'accesso all'interno di un prefisso di bucket per tenant. Per esempio:
Per questo post, utilizziamo la seconda opzione di assegnazione di prefissi S3 all'interno di un singolo bucket. Crittografiamo i dati dei tenant utilizzando CMK in AWS KMS.
Inquilino onboarding
Le applicazioni SaaS si basano su un modello senza attriti per introdurre nuovi tenant nel loro ambiente. Ciò richiede spesso l'orchestrazione di diversi componenti per eseguire correttamente il provisioning e configurare tutti gli elementi necessari per creare un nuovo tenant. Questo processo, nell'architettura SaaS, è indicato come onboarding degli inquilini. Questo può essere avviato direttamente dai tenant o come parte di un processo gestito dal provider. Il diagramma seguente illustra il flusso di configurazione della previsione per tenant come parte del processo di onboarding.
Le risorse sono contrassegnate con informazioni sul tenant. Per questo post, contrassegniamo le risorse con un valore per tenant, ad esempio, tenant_a
.
Crea un ruolo Previsione
Questo ruolo IAM viene assunto da Forecast per tenant. Devi applicare la seguente policy per consentire a Forecast di interagire con Amazon S3 e AWS KMS nell'account del cliente. Il ruolo è contrassegnato con il tag tenant. Ad esempio, vedere il codice seguente:
Crea le politiche
In questo passaggio successivo, creiamo criteri per il nostro ruolo di previsione. Per questo post, le abbiamo suddivise in due policy per una maggiore leggibilità, ma puoi crearle in base alle tue esigenze.
Criterio 1: prevedere l'accesso in sola lettura
La seguente policy fornisce i privilegi per descrivere, elencare ed eseguire query sulle risorse di previsione. Questo criterio limita Forecast all'accesso in sola lettura. La condizione di convalida del tag tenant nel codice seguente garantisce che il valore del tag tenant corrisponda al tag tenant dell'entità. Fare riferimento al codice in grassetto per specifiche.
Policy 2: policy di accesso Amazon S3 e AWS KMS
La seguente policy concede privilegi ad AWS KMS e l'accesso al prefisso del tenant S3. La condizione di convalida del tag tenant nel codice seguente garantisce che il valore del tag tenant corrisponda al tag tenant dell'entità. Fare riferimento al codice in grassetto per specifiche.
Creare una chiave specifica del tenant
Ora creiamo una chiave specifica del tenant in AWS KMS per tenant e la contrassegniamo con il valore del tag tenant. In alternativa, il tenant può portare la propria chiave in AWS KMS. Diamo i ruoli precedenti (Forecast_TenantA_Role
or Forecast_TenantB_Role
) accesso alla chiave specifica del tenant.
Ad esempio, lo screenshot seguente mostra la coppia chiave-valore di tenant
ed tenant_a
.
Lo screenshot seguente mostra i ruoli IAM che possono utilizzare questa chiave.
Creare un ruolo applicazione
Il secondo ruolo che creiamo è assunto dall'applicazione SaaS per tenant. Devi applicare la seguente policy per consentire all'applicazione di interagire con Forecast, Amazon S3 e AWS KMS. Il ruolo è contrassegnato con il tag tenant. Vedere il seguente codice:
Crea le politiche
Ora creiamo criteri per il ruolo dell'applicazione. Per questo post, le abbiamo suddivise in due policy per una maggiore leggibilità, ma puoi crearle in base alle tue esigenze.
Criterio 1: previsione dell'accesso
La seguente policy fornisce i privilegi per creare, aggiornare ed eliminare le risorse di previsione. La policy applica il requisito del tag durante la creazione. Inoltre, limita il list
, describe
e delete
azioni sulle risorse al rispettivo inquilino. Questa politica ha IAM PassRole
per consentire a Forecast di assumere il ruolo.
Il tenant
la condizione di convalida del tag nel codice seguente assicura che il valore del tag del tenant corrisponda al tenant. Fare riferimento al codice in grassetto per specifiche.
Policy 2: Amazon S3, AWS KMS, Amazon CloudWatch e accesso al gruppo di risorse
La seguente policy fornisce i privilegi per accedere alle risorse Amazon S3 e AWS KMS e anche Amazon Cloud Watch. Limita l'accesso al prefisso S3 specifico del tenant e alla CMK specifica del tenant. La condizione di convalida del tenant è attiva codice in grassetto.
Creare un gruppo di risorse
Il gruppo di risorse consente al tenant di eseguire query su tutte le risorse con tag. Il codice di esempio seguente usa il Interfaccia della riga di comando di AWS (AWS CLI) per cui creare un gruppo di risorse TenantA
:
Prevedere il flusso delle applicazioni
Il seguente diagramma illustra il nostro flusso di applicazione Forecast. Il servizio dell'applicazione assume il ruolo IAM per il tenant e come parte del suo flusso aziendale richiama l'API di previsione.
Creare un predittore per TenantB
Le risorse create devono essere contrassegnate con il tag tenant. Il codice seguente usa l'API Python (Boto3) per creare un predittore per TenantB (fare riferimento a codice in grassetto per le specifiche):
Creare una previsione sul predittore per TenantB
Il codice seguente utilizza l'API Python (Boto3) per creare una previsione sul predittore appena creato:
Convalida l'accesso alle risorse di previsione
In questa sezione, confermiamo che solo il rispettivo tenant può accedere alle risorse di previsione. L'accesso, la modifica o l'eliminazione delle risorse di previsione appartenenti a un tenant diverso genera un errore. Il codice seguente utilizza l'API Python (Boto3) per dimostrare che TenantA tenta di eliminare una risorsa TenantB Forecast:
Elenca e monitora i predittori
Il codice di esempio seguente usa l'API Python (Boto3) per eseguire query sui predittori di previsione per TenantA usando i gruppi di risorse:
Il Framework ben progettato di AWS spiega, è importante monitorare le quote di servizio (che sono anche denominate limiti di servizio). La previsione ha limiti per account; Per ulteriori informazioni, vedere Linee guida e quote.
Il codice seguente è un esempio di popolamento di un parametro CloudWatch con il numero totale di predittori:
Altre considerazioni
I limiti e la limitazione delle risorse devono essere gestiti dall'applicazione tra i tenant. Se non puoi accogliere il Limiti di previsione, dovresti prendere in considerazione una configurazione con più account.
Le API dell'elenco previsioni o la risposta del gruppo di risorse devono essere filtrate per applicazione in base a tenant
valore del tag.
Conclusione
In questo post, abbiamo dimostrato come isolare l'accesso Forecast utilizzando la tecnica ABAC in un'applicazione SaaS multi-tenant. Abbiamo mostrato come limitare l'accesso a Forecast da parte del tenant utilizzando il tag tenant. Puoi personalizzare ulteriormente le policy applicando più tag o applicando questa strategia ad altri servizi AWS.
Per ulteriori informazioni sull'utilizzo di ABAC come strategia di autorizzazione, vedere Che cos'è ABAC per AWS?
Informazioni sugli autori
Gunjan Garg è un Sr. Software Development Engineer nel team AWS Vertical AI. Nel suo ruolo attuale in Amazon Forecast, si concentra sui problemi di ingegneria e ama costruire sistemi scalabili che offrano il massimo valore agli utenti finali. Nel tempo libero le piace giocare a Sudoku e Minesweeper.
Matias Battaglia è un Technical Account Manager presso Amazon Web Services. Nel suo ruolo attuale, ama aiutare i clienti in tutte le fasi del loro viaggio verso il cloud. Nel tempo libero si diverte a realizzare progetti AI/ML.
Rakesh Ramada è un architetto di soluzioni ISV presso Amazon Web Services. Le sue aree di interesse includono AI/ML e Big Data.
- accesso
- Il mio account
- Action
- aggiuntivo
- AI
- Amazon
- Previsioni Amazon
- Amazon Web Services
- api
- API
- Applicazioni
- applicazioni
- architettura
- autorizzazione
- AWS
- fatturazione
- costruire
- Costruzione
- affari
- Cloud
- codice
- conformità
- Corrente
- Clienti
- dati
- l'accesso ai dati
- decrypt
- consegna
- Mercato
- ingegnere
- Ingegneria
- Ambiente
- flusso
- Focus
- Gratis
- GitHub
- Gruppo
- Come
- Tutorial
- HTTPS
- IAM
- Identità
- Impact
- informazioni
- IT
- Le
- Tasti
- kubernetes
- apprendimento
- linea
- Lista
- machine learning
- gestione
- ML
- modello
- monitoraggio
- Procedura di Onboarding
- Opzione
- Altro
- Termini e Condizioni
- politica
- progetti
- Python
- Requisiti
- risorsa
- Risorse
- risposta
- REST
- running
- SaaS
- Serie
- Servizi
- set
- regolazione
- condiviso
- Un'espansione
- Software
- lo sviluppo del software
- Soluzioni
- dividere
- iniziato
- dichiarazione
- conservazione
- Strategia
- SISTEMI DI TRATTAMENTO
- Consulenza
- Tecnologia
- tempo
- transito
- Aggiornanento
- utenti
- APPREZZIAMO
- sito web
- servizi web
- entro