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.

Tipi di policy

OpenSearch Il servizio supporta tre tipi di politiche di accesso:

Resource-based politiche

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 della policy JSON principale in IAM specifica gli account, gli utenti o i ruoli a cui è consentito l'accesso. L'elemento della policy Resource JSON specifica a quali sottorisorse possono accedere questi principali.

Ad esempio, la seguente policy basata sulle risorse concede un accesso completo test-user (es:*) alle risorse secondarie in test-domain:

Due considerazioni importanti si applicano a questa policy:

È 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:

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:

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.

Identity-based politiche

A differenza delle politiche basate sulle risorse, che fanno parte di ogni dominio del OpenSearch servizio, è possibile associare 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

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:

Un amministratore potrebbe avere pieno accesso al OpenSearch servizio e a tutti i dati archiviati su tutti i domini:

Identity-based le politiche 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:

Puoi anche utilizzare i tag per controllare l'accesso all' OpenSearch API. Tag-basedle politiche per l' OpenSearch API si applicano solo ai metodi HTTP. Ad esempio, la seguente politica consente ai principali allegati di inviare richieste GET e OpenSearch PUT all'API se il dominio ha il environment:production tag:

Per un controllo più granulare dell' OpenSearch API, prendi in considerazione l'utilizzo di un controllo granulare degli accessi.

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:

Per ulteriori informazioni sull'utilizzo dei tag per il controllo degli accessi e sulle differenze tra le politiche basate sulle risorse e quelle basate sull'identità, consulta la sezione Definizione delle autorizzazioni in base agli attributi con autorizzazione ABAC nella IAM User Guide.

IP-based politiche

IP-based le politiche limitano l'accesso a un dominio a uno o più indirizzi IP o blocchi CIDR. Tecnicamente, IP-based le politiche non sono un tipo distinto di politica. Sono invece solo politiche basate sulle risorse che specificano un principio anonimo e includono una condizione speciale. Per informazioni, consulta IAM JSON Policy elements: Condition nella IAM User Guide.

L'attrattiva principale delle IP-based policy è che consentono richieste non firmate a un dominio di OpenSearch servizio, il che consente di utilizzare client come curl e OpenSearch Dashboards o accedere al dominio tramite un server proxy. Per ulteriori informazioni, consulta Utilizzo di un proxy per accedere a OpenSearch Service from Dashboards.

La seguente policy concede a tutte le richieste HTTP che provengono dall'intervallo di IP specificato l'accesso a 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:

Quando le policy entrano in collisione

Sorgono problemi quando le policy dissentono o non effettuano alcuna menzione esplicita di un utente. Il funzionamento di IAM nella IAM User Guide fornisce un riepilogo conciso della logica di valutazione delle policy:

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.

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.

"Condition": {
  "IpAddress": {
    "aws:SourceIp": [
      "192.0.2.0/32"
    ]
  }
}

"Condition": { "Bool": { "aws:SecureTransport": "true" } }

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:

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à:

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 Fine-grained controllo degli accessi in Amazon OpenSearch Service

Configurazione delle policy di accesso

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.