Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Identity and Access Management in Amazon OpenSearch Service
Amazon OpenSearch Service offre diversi modi per controllare l'accesso ai tuoi domini. In questa sezione sono descritti i diversi tipi di policy, il modo in cui interagiscono tra loro ed è riportato come creare le policy personalizzate.
Importante
Il supporto VPC introduce alcune considerazioni aggiuntive sul controllo degli accessi ai OpenSearch servizi. Per ulteriori informazioni, consulta Informazioni sulle policy d'accesso nei domini VPC.
Tipi di policy
OpenSearch Il servizio supporta tre tipi di politiche di accesso:
Policy basate su risorse
Quando si crea un dominio, viene aggiunta una policy basata su risorse, talvolta denominata policy di accesso al dominio. Queste policy specificano le operazioni che un principale può eseguire sulle risorse secondarie del dominio (con l'eccezione della ricerca tra cluster). Le sottorisorse includono OpenSearch indici e API. L'elemento Principal specifica l'account, gli utenti o i ruoli a cui è consentito l'accesso. L'elemento Resource specifica a quali risorse secondarie questi principali possono accedere.
Ad esempio, la seguente policy basata sulle risorse concede un accesso completo test-user
(es:*
) alle risorse secondarie in test-domain
:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:*" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" } ] }
Due considerazioni importanti si applicano a questa policy:
-
Questi privilegi si applicano solo a questo dominio. A meno che non vengano create policy simili su altri domini,
test-user
può accedere solo atest-domain
. -
I caratteri
/*
finali nell'elementoResource
sono significativi e indicano che le policy basate sulle risorse si applicano solo alle risorse secondarie del dominio e non al dominio stesso. Nelle policy basate sulle risorse, l'operazionees:*
equivale aes:ESHttp*
.Ad esempio,
test-user
può effettuare richieste su un indice (GET https://search-test-domain.us-west-1.es.amazonaws.com/test-index
), ma non è in grado di aggiornare la configurazione del dominio (POST https://es.us-west-1.amazonaws.com/2021-01-01/opensearch/domain/test-domain/config
). Nota la differenza tra i due endpoint. L'accesso all'API di configurazione richiede una policy basata sull'identità.
È possibile specificare un nome di indice parziale aggiungendo un carattere jolly. Questo esempio identifica gli indici che iniziano con commerce
:
arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce*
In questo caso, l'uso del carattere jolly significa che test-user
può fare richieste agli indici nel dominio test-domain
che hanno nomi che iniziano con commerce
.
Per limitare ulteriormente test-user
, è possibile applicare la seguente policy:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:ESHttpGet" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce-data/_search" } ] }
Ora test-user
è in grado di eseguire un'unica operazione: effettua una ricerca sull'indice commerce-data
. Tutti gli altri indici all'interno del dominio sono inaccessibili e senza le autorizzazioni necessarie per utilizzare le operazioni es:ESHttpPut
o es:ESHttpPost
, test-user
non è in grado di aggiungere o modificare i documenti.
Quindi, è possibile decidere di configurare un ruolo per gli utenti avanzati. Questa policy fornisce l'accesso power-user-role
ai metodi HTTP GET e PUT per tutti gli URI nell'indice:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:role/power-user-role" ] }, "Action": [ "es:ESHttpGet", "es:ESHttpPut" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce-data/*" } ] }
Se il dominio si trova in un VPC o utilizza un controllo granulare degli accessi, è possibile usare una policy di accesso al dominio aperto. In caso contrario, la policy di accesso al dominio deve contenere alcune limitazioni, sia per principal che per indirizzo IP.
Per ulteriori informazioni su tutte le azioni disponibili, consultare Riferimenti agli elementi della policy. Per un controllo molto più dettagliato sui dati, utilizzare una policy di accesso al dominio aperto con il controllo granulare degli accessi.
Policy basate su identità
A differenza delle politiche basate sulle risorse, che fanno parte di ogni dominio del OpenSearch servizio, è possibile allegare politiche basate sull'identità a utenti o ruoli utilizzando il servizio (IAM). AWS Identity and Access Management Proprio come le policy basate sulle risorse, le policy basate su identità specificano chi può accedere a un servizio, quali azioni può eseguire e, ove applicabile, le risorse su cui può eseguire tali operazioni.
Mentre le policy basate su identità tendono a essere più generiche. Spesso regolamentano solo le operazioni delle API di configurazione che possono essere eseguite da un utente. Dopo aver implementato queste politiche, puoi utilizzare le politiche basate sulle risorse (o il controllo granulare degli accessi) in Service per offrire agli utenti l'accesso a indici e API. OpenSearch OpenSearch
Nota
Gli utenti con la AmazonOpenSearchServiceReadOnlyAccess
policy AWS gestita non possono visualizzare lo stato di integrità del cluster sulla console. Per consentire loro di visualizzare lo stato di integrità del cluster (e altri OpenSearch dati), aggiungi l'es:ESHttpGet
azione a una politica di accesso e allegala ai loro account o ruoli.
Poiché le policy basate su identità si collegano a utenti o ruoli (principali), il formato JSON non specifica un principale. La policy seguente consente di concedere l'accesso alle azioni che iniziano con Describe
e List
. Questa combinazione di azioni fornisce accesso in sola lettura alle configurazioni di dominio, ma non ai dati archiviati nel dominio:
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "es:Describe*", "es:List*" ], "Effect": "Allow", "Resource": "*" } ] }
Un amministratore potrebbe avere pieno accesso al OpenSearch servizio e a tutti i dati archiviati su tutti i domini:
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "es:*" ], "Effect": "Allow", "Resource": "*" } ] }
Le policy basate sull'identità consentono di utilizzare i tag per controllare l'accesso all'API di configurazione. La policy riportata di seguito, ad esempio, consente ai principal collegati di visualizzare e aggiornare la configurazione di un dominio se il dominio dispone del tag team:devops
:
{ "Version": "2012-10-17", "Statement": [{ "Action": [ "es:UpdateDomainConfig", "es:DescribeDomain", "es:DescribeDomainConfig" ], "Effect": "Allow", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:ResourceTag/team": [ "devops" ] } } }] }
Puoi anche utilizzare i tag per controllare l'accesso all' OpenSearch API. Le politiche basate su tag per l' OpenSearch API si applicano solo ai metodi HTTP. Ad esempio, la seguente politica consente ai principali collegati di inviare richieste GET e PUT all' OpenSearch API se il dominio ha il environment:production
tag:
{ "Version": "2012-10-17", "Statement": [{ "Action": [ "es:ESHttpGet", "es:ESHttpPut" ], "Effect": "Allow", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:ResourceTag/environment": [ "production" ] } } }] }
Per un controllo più granulare dell' OpenSearch API, prendi in considerazione l'utilizzo di un controllo granulare degli accessi.
Nota
Dopo aver aggiunto una o più OpenSearch API a qualsiasi policy basata su tag, devi eseguire un'unica operazione di tag (ad esempio aggiungere, rimuovere o modificare un tag) affinché le modifiche abbiano effetto su un dominio. È necessario utilizzare il software di servizio R20211203 o versione successiva per includere OpenSearch le operazioni API nelle politiche basate su tag.
OpenSearch Il servizio supporta le chiavi RequestTag
di condizione TagKeys
globali per l'API di configurazione, non l'API. OpenSearch Queste condizioni si applicano solo alle chiamate API che includono tag all'interno della richiesta, ad esempio CreateDomain
, AddTags
e RemoveTags
. La policy seguente consente ai principal collegati di creare domini, ma solo se includono il tag team:it
nella richiesta:
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "es:CreateDomain", "es:AddTags" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/team": [ "it" ] } } } }
Per maggiori dettagli sull'utilizzo dei tag per il controllo degli accessi e sulle differenze tra policy basate sulle risorse e policy basate su identità, consultare la Guida per l'utente IAM.
Policy basate su IP
Le policy basate su IP limitano l'accesso a un dominio a uno o più indirizzi IP o blocchi CIDR. Tecnicamente, le policy basate su IP non sono un tipo distinto di policy. Al contrario, sono solo policy basate sulle risorse che specificano un principale anonimo e includono un elemento Condition speciale.
L'attrattiva principale delle politiche basate su IP è che consentono richieste non firmate a un dominio di OpenSearch servizio, il che consente di utilizzare client come curl
Nota
Se è stato abilitato l'accesso VPC al dominio, non è possibile configurare una policy basata su IP. Invece è possibile utilizzare i gruppi di sicurezza per controllare gli indirizzi IP che possono accedere al dominio. Per ulteriori informazioni, consultare Informazioni sulle policy d'accesso nei domini VPC.
La seguente policy concede a tutte le richieste HTTP che provengono dall'intervallo di IP specificato l'accesso a test-domain
:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": [ "es:ESHttp*" ], "Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/24" ] } }, "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" } ] }
Se il dominio dispone di un endpoint pubblico e non utilizza il controllo granulare degli accessi, è consigliabile combinare le entità IAM e gli indirizzi IP. Questa policy concede l'accesso HTTP test-user
solo se la richiesta proviene dall'intervallo IP specificato:
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::987654321098:user/test-user" ] }, "Action": [ "es:ESHttp*" ], "Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/24" ] } }, "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" }] }
Effettuazione e firma di richieste di servizio OpenSearch
Anche se configuri una politica di accesso completamente aperta basata su risorse, tutte le richieste all'API di configurazione del OpenSearch servizio devono essere firmate. Se le tue policy specificano ruoli o utenti IAM, anche le richieste alle OpenSearch API devono essere firmate utilizzando AWS Signature Version 4. Il metodo della firma differisce in base alle API:
-
Per effettuare chiamate all'API OpenSearch di configurazione del servizio, ti consigliamo di utilizzare uno degli AWS SDK
. Gli SDK semplificano enormemente il processo e permettono di risparmiare molto tempo rispetto alla creazione e alla firma delle richieste. Gli endpoint dell'API di configurazione utilizzano il seguente formato: es.
region
.amazonaws.com/2021-01-01/Ad esempio, la seguente richiesta consente di apportare una modifica di configurazione al dominio
movies
, ma l'utente deve firmarla manualmente (scelta non consigliata):POST https://es.
us-east-1
.amazonaws.com/2021-01-01/opensearch/domain/movies
/config { "ClusterConfig": { "InstanceType": "c5.xlarge.search" } }Se utilizzi uno degli SDK, ad esempio Boto 3
, questo gestisce automaticamente la firma della richiesta: import boto3 client = boto3.client(es) response = client.update_domain_config( DomainName='
movies
', ClusterConfig={ 'InstanceType': 'c5.xlarge.search' } )Per un esempio di codice Java, consulta Usando ilAWSSDK per interagire con AmazonOpenSearchServizio.
-
Per effettuare chiamate alle OpenSearch API, devi firmare le tue richieste. Le OpenSearch API utilizzano il seguente formato:
domain-id
.region
.es.amazonaws.comAd esempio, la seguente richiesta esegue una ricerca nell'indice
movies
per thor:GET https://
my-domain
.us-east-1
.es.amazonaws.com/movies/_search?q=thor
Nota
Il servizio ignora i parametri passati negli URL per le richieste HTTP POST che sono firmate con Signature Version 4.
Quando le policy entrano in collisione
Sorgono problemi quando le policy dissentono o non effettuano alcuna menzione esplicita di un utente. Introduzione al funzionamento di IAM nella Guida per l'utente IAM fornisce un riepilogo conciso della logica di valutazione delle policy:
-
Come impostazione predefinita, tutte le richieste vengono negate.
-
Un permesso esplicito sostituisce questa impostazione di default.
-
Un rifiuto esplicito sovrascrive tutti i consensi.
Ad esempio, se una policy basata sulle risorse ti concede l'accesso a una sottorisorsa di dominio (un OpenSearch indice o un'API), ma una policy basata sull'identità ti nega l'accesso, ti viene negato l'accesso. Se una policy basata sull'identità consente l'accesso e una policy basata sulle risorse non specifica se si dispone o meno dell'accesso, è consentito l'accesso. Consultare la seguente tabella di policy che si sovrappongono per un riepilogo dei risultati per le risorse secondarie del dominio.
Consentito nella policy basata sulle risorse | Rifiutato nella policy basata sulle risorse | Non consentito né rifiutato nella policy basata sulle risorse | |
---|---|---|---|
Allowed in identity-based policy |
Consenso |
Rifiuta | Consenso |
Denied in identity-based policy | Rifiuta | Rifiuta | Rifiuta |
Neither allowed nor denied in identity-based policy | Consenso | Rifiuta | Rifiuta |
Riferimenti agli elementi della policy
OpenSearch Il servizio supporta la maggior parte degli elementi delle policy nello IAM Policy Elements Reference, ad eccezione di. NotPrincipal
La tabella riportata di seguito mostra gli elementi più comuni.
Elemento della policy JSON | Riepilogo |
---|---|
Version |
La versione corrente del linguaggio della policy è |
Effect |
L'elemento specifica se l'istruzione consente o nega l'accesso alle azioni specificate. I valori validi sono |
Principal |
Questo elemento specifica il ruolo Account AWS o l'utente IAM a cui è consentito o negato l'accesso a una risorsa e può assumere diverse forme:
ImportanteLa specifica del carattere jolly
|
Action
|
OpenSearch Il servizio utilizza Alcune azioni Per un elenco di tutte le azioni disponibili e se si applicano alle sottorisorse del dominio ( Mentre le autorizzazioni a livello di risorsa per Naturalmente, è ugualmente possibile includere azioni insieme a elementi di risorse meno restrittivi, come i seguenti:
Per ulteriori informazioni sull'accoppiamento di azioni e risorse, fare riferimento all'elemento |
Condition |
OpenSearch Il servizio supporta la maggior parte delle condizioni descritte nelle chiavi di contesto delle condizioni AWS globali nella IAM User Guide. Le eccezioni più importanti includono la Durante la configurazione di una policy basata su IP, è necessario specificare gli indirizzi IP o i blocchi CIDR come condizione, come ad esempio:
Come indicato inPolicy basate su identità, le chiavi |
Resource |
OpenSearch Il servizio utilizza
Per ulteriori informazioni su quali azioni supportano le autorizzazioni a livello di risorsa, fare riferimento all'elemento |
Opzioni avanzate e considerazioni sulle API
OpenSearch Il servizio ha diverse opzioni avanzate, una delle quali ha implicazioni sul controllo degli accessi:. rest.action.multi.allow_explicit_index
Con l'impostazione predefinita true, consente agli utenti di ignorare le autorizzazioni a livello di risorsa secondaria in determinate circostanze.
Ad esempio, considerare la seguente policy basata sulle risorse:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:ESHttp*" ], "Resource": [ "arn:aws:es:us-west-1:987654321098:domain/test-domain/test-index/*", "arn:aws:es:us-west-1:987654321098:domain/test-domain/_bulk" ] }, { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:ESHttpGet" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/restricted-index/*" } ] }
Questa politica garantisce l'accesso test-user
completo test-index
e alla OpenSearch massa delle API. Consente inoltre GET
le richieste a restricted-index
.
La seguente richiesta di indicizzazione, come è prevedibile, ha esito negativo a causa di un errore delle autorizzazioni:
PUT https://search-test-domain.us-west-1.es.amazonaws.com/restricted-index/movie/1 { "title": "Your Name", "director": "Makoto Shinkai", "year": "2016" }
A differenza dell'API dell'indice, l'API bulk consente la creazione, l'aggiornamento e l'eliminazione di molti documenti in una sola chiamata. Tuttavia spesso si specificano queste operazioni nel corpo della richiesta, anziché nell'URL della richiesta. Poiché OpenSearch Service utilizza gli URL per controllare l'accesso alle sottorisorse del dominio, test-user
può, di fatto, utilizzare l'API in blocco per apportare modifiche. restricted-index
Anche se l'utente non dispone di autorizzazioni POST
per l'indice, la seguente richiesta ha esito positivo:
POST https://search-test-domain.us-west-1.es.amazonaws.com/_bulk { "index" : { "_index": "restricted-index", "_type" : "movie", "_id" : "1" } } { "title": "Your Name", "director": "Makoto Shinkai", "year": "2016" }
In questo caso, la policy d'accesso non riesce a soddisfare i suoi intenti. Per impedire agli utenti di aggirare questi tipi di restrizioni, è possibile modificare rest.action.multi.allow_explicit_index
in false. Se questo valore è false, tutte le chiamate alle API bulk, mget, e msearch che specificano i nomi degli indici nel corpo della richiesta smettono di funzionare. In altre parole, le chiamate a _bulk
non funzionano, ma le chiamate a test-index/_bulk
sì. Questo secondo endpoint contiene un nome dell'indice, perciò non è necessario specificarne uno nel corpo nella richiesta.
OpenSearch Dashboards si basa molto su mget e msearch, quindi è improbabile che funzioni correttamente dopo questa modifica. Per la correzione parziale, è possibile lasciare rest.action.multi.allow_explicit_index
come true e negare a determinati utenti l'accesso a una o più di queste API.
Per informazioni su come modificare questa impostazione, consultare Impostazioni avanzate del cluster.
Analogamente, la seguente policy basata sulle risorse contiene due problemi di lieve entità:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/test-user" }, "Action": "es:ESHttp*", "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" }, { "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam::123456789012:user/test-user" }, "Action": "es:ESHttp*", "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/restricted-index/*" } ] }
-
Nonostante il rifiuto esplicito,
test-user
può comunque effettuare chiamate comeGET https://search-test-domain.us-west-1.es.amazonaws.com/_all/_search
eGET https://search-test-domain.us-west-1.es.amazonaws.com/*/_search
per accedere ai documenti inrestricted-index
. -
Poiché l'elemento
Resource
fa riferimento arestricted-index/*
,test-user
non dispone delle autorizzazioni per accedere direttamente ai documenti dell'indice. L'utente, tuttavia, dispone delle autorizzazioni necessarie per eliminare l'intero indice. Per prevenire l'accesso e l'eliminazione, la policy deve specificarerestricted-index*
.
Anziché combinare permessi ampi e negazioni strette, la soluzione più sicura è seguire il principio del privilegio minimo e concedere solo le autorizzazioni necessarie per eseguire un'operazione. Per ulteriori informazioni sul controllo dell'accesso a singoli indici o operazioni, vedere. OpenSearch Controllo granulare degli accessi in Amazon Service OpenSearch
Importante
Specificando il carattere jolly * si abilita l'accesso anonimo al dominio. Non è consigliabile utilizzare il carattere jolly. Inoltre, esamina attentamente le seguenti politiche per verificare che non garantiscano un accesso ampio:
-
Politiche basate sull'identità collegate ai AWS principali associati (ad esempio, ruoli IAM)
-
Politiche basate sulle risorse collegate alle AWS risorse associate (ad esempio, chiavi KMS) AWS Key Management Service
Configurazione delle policy di accesso
-
Per istruzioni sulla creazione o la modifica di politiche basate su risorse e IP in Service, vedere. OpenSearch Configurazione delle policy di accesso
-
Per istruzioni su come creare o modificare le policy basate sull'identità in IAM, consultare Creazione di policy IAM nella Guida per l'utente IAM.
Altre policy di esempio
Sebbene questo capitolo includa molti esempi di policy, il controllo degli AWS accessi è un argomento complesso che può essere compreso meglio attraverso esempi. Per ulteriori informazioni, consultare Esempi di policy IAM basate su identità nella Guida per l'utente di IAM.