Controllo granulare degli accessi nel servizio OpenSearch di Amazon - Amazon OpenSearch Service

Controllo granulare degli accessi nel servizio OpenSearch di Amazon

Il controllo granulare degli accessi offre ulteriori modi per controllare l'accesso ai dati nel servizio OpenSearch di Amazon. Ad esempio, a seconda di chi effettua la richiesta, è possibile che una ricerca restituisca risultati da un solo indice. Potresti voler nascondere determinati campi nei tuoi documenti o escludere del tutto determinati documenti. Il controllo granulare degli accessi offre i seguenti vantaggi:

  • Controllo degli accessi basato sui ruoli

  • Sicurezza a livello di indice, documento e campo

  • Multi-locazione di OpenSearch Dashboards

  • Autenticazione di base HTTP per OpenSearch e OpenSearch Dashboards

Il quadro generale: controllo granulare degli accessi e sicurezza OpenSearch Service

Il servizio OpenSearch di Amazon ha tre livelli di sicurezza principali:

Rete

Il primo livello di sicurezza è la rete, che determina se le richieste raggiungono un dominio OpenSearch Service. Se sceglisi sceglieAccesso pubblico quando creisi crea un dominio, le richieste provenienti da qualunquequalsiasi client connesso a Internet possono raggiungere l'endpoint del dominio. Se si sceglie Accesso VPC, i client devono connettersi al VPC (e i gruppi di sicurezza associati devono consentirlo) affinché una richiesta raggiunga l'endpoint. Per ulteriori informazioni, consultare Avvio dei domini Amazon OpenSearch Service all'interno di un VPC.

Policy di accesso al dominio

Il secondo livello di protezione è la policy di accesso al dominio. Dopo che una richiesta raggiunge un endpoint di dominio, la policy di accesso basato sulle risorse consente o nega la richiesta di accesso a un determinato URI. La policy di accesso accetta o rifiuta le richieste "edge" del dominio, prima che raggiungano OpenSearch stesso.

Controllo granulare degli accessi

Il terzo e ultimo livello di sicurezza è il controllo granulare degli accessi. Dopo che una policy di accesso basata sulle risorse consente a una richiesta di raggiungere un endpoint di dominio, il controllo granulare degli accessi valuta le credenziali utente e autentica l'utente o nega la richiesta. Se il controllo granulare degli accessi autentica l'utente, recupera tutti i ruoli mappati a tale utente e utilizza il set completo di autorizzazioni per determinare come gestire la richiesta.

Nota

Se una policy di accesso basata sulle risorse contiene utenti o ruoli IAM, i client devono inviare richieste firmate utilizzando la AWS Signature Version 4. Pertanto, le policy di accesso possono entrare in conflitto con il controllo granulare degli accessi, soprattutto se si utilizza il database utente interno e l'autenticazione di base HTTP. Non è possibile firmare una richiesta con un nome utente, una password e credenziali IAM. In generale, se si abilita il controllo granulare degli accessi, si consiglia di utilizzare una policy di accesso al dominio che non richiede richieste firmate.

Questo primo diagramma illustra una configurazione comune: un dominio di accesso VPC con controllo granulare degli accessi abilitato, una policy di accesso basata su IAM e un utente principale IAM.


        Flusso di autorizzazione del controllo granulare degli accessi con un dominio VPC

Il seguente diagramma illustra un'altra configurazione comune: un dominio di accesso pubblico con controllo granulare degli accessi abilitato, una policy di accesso che non utilizza i principal IAM e un utente master nel database utente interno.


        Flusso di autorizzazione del controllo granulare degli accessi con un dominio di accesso pubblico

Esempio

Considera una richiesta GET a movies/_search?q=thor. L'utente dispone delle autorizzazioni per cercare l'indice movies? In tal caso, l'utente dispone delle autorizzazioni per visualizzare tutti i documenti al suo interno? La risposta dovrebbe omettere o anonimizzare dei campi? Per l'utente master, la risposta potrebbe essere simile a questa:

{ "hits": { "total": 7, "max_score": 8.772789, "hits": [{ "_index": "movies", "_type": "_doc", "_id": "tt0800369", "_score": 8.772789, "_source": { "directors": [ "Kenneth Branagh", "Joss Whedon" ], "release_date": "2011-04-21T00:00:00Z", "genres": [ "Action", "Adventure", "Fantasy" ], "plot": "The powerful but arrogant god Thor is cast out of Asgard to live amongst humans in Midgard (Earth), where he soon becomes one of their finest defenders.", "title": "Thor", "actors": [ "Chris Hemsworth", "Anthony Hopkins", "Natalie Portman" ], "year": 2011 } }, ... ] } }

Se un utente con autorizzazioni più limitate emette esattamente la stessa richiesta, la risposta potrebbe essere simile a questa:

{ "hits": { "total": 2, "max_score": 8.772789, "hits": [{ "_index": "movies", "_type": "_doc", "_id": "tt0800369", "_score": 8.772789, "_source": { "year": 2011, "release_date": "3812a72c6dd23eef3c750c2d99e205cbd260389461e19d610406847397ecb357", "plot": "The powerful but arrogant god Thor is cast out of Asgard to live amongst humans in Midgard (Earth), where he soon becomes one of their finest defenders.", "title": "Thor" } }, ... ] } }

La risposta ha meno hit e meno campi per ogni hit. Inoltre, il campo release_date è anonimizzato. Se un utente senza autorizzazioni effettua la stessa richiesta, il cluster restituisce un errore:

{ "error": { "root_cause": [{ "type": "security_exception", "reason": "no permissions for [indices:data/read/search] and User [name=limited-user, roles=[], requestedTenant=null]" }], "type": "security_exception", "reason": "no permissions for [indices:data/read/search] and User [name=limited-user, roles=[], requestedTenant=null]" }, "status": 403 }

Se un utente fornisce credenziali non valide, il cluster restituisce un'eccezione Unauthorized.

Concetti chiave

I ruoli sono il modo principale di utilizzare il controllo granulare degli accessi. In questo caso, i ruoli sono distinti dai ruoli IAM. I ruoli contengono qualsiasi combinazione di autorizzazioni: a livello di cluster, a livello di indice, a livello di documento e a livello di campo.

Dopo aver configurato un ruolo, è possibile eseguire il mapping a uno o più utenti. Ad esempio, è possibile mappare tre ruoli a un singolo utente: un ruolo che fornisce l'accesso a Dashboards, uno che fornisce l'accesso in sola lettura a index1 e uno che fornisce l'accesso in scrittura a index2. In alternativa, è possibile includere tutte queste autorizzazioni in un singolo ruolo.

Gli utenti sono persone o applicazioni che effettuano richieste al cluster OpenSearch. Gli utenti dispongono di credenziali, chiavi di accesso IAM o nome utente e password, che specificano quando effettuano le richieste. Con il controllo granulare degli accessi sul servizio OpenSearch di Amazon, puoi scegliere l'uno o l'altro per l'utente principale quando configuri un dominio. L'utente master dispone di autorizzazioni complete per il cluster e gestisce ruoli e mapping dei ruoli.

  • Se si sceglie IAM per l'utente principale, tutte le richieste al cluster devono essere firmate utilizzando AWS Signature Version 4. Per il codice di esempio, consulta Firma di richieste HTTP in Amazon OpenSearch Service.

    Si consiglia di utilizzare IAM se si desidera utilizzare gli stessi utenti su più cluster, se si desidera utilizzare Amazon Cognito per accedere a Dashboards o se si dispone di client OpenSearch che supportano la firma di Signature Version 4.

  • Se sceglisi sceglie il database utente interno, puoiè possibile utilizzare l'autenticazione di base HTTP (nonché le credenziali IAM) per effettuare richieste al cluster. La maggior parte dei client supporta l'autenticazione di base, incluso il curl, che supporta anche AWS Signature Version 4 con l'opzione --aws-sigv4. Il database utente interno è archiviato in un indice OpenSearch, quindi non è possibile condividerlo con altri cluster.

    È consigliabile utilizzare il database utente interno se non è necessario riutilizzare gli utenti in più cluster, se si desidera utilizzare l'autenticazione di base HTTP per accedere a Dashboards (anziché ad Amazon Cognito) o se si dispone di client che supportano solo l'autenticazione di base. Il database utente interno è il modo più semplice per iniziare a utilizzare OpenSearch Service.

Abilitazione del controllo granulare degli accessi

Abilitare il controllo granulare degli accessi utilizzando la console, la AWS CLI o l'API di configurazione. Per le fasi, consulta Creazione e gestione di domini Amazon OpenSearch Service.

Il controllo dettagliato degli accessi richiede OpenSearch o Elasticsearch 6.7 o versioni successive. Richiedere inoltre HTTPS per tutto il traffico verso il dominio, Crittografia dei dati a riposo, e crittografia da nodo a nodo. Dopo aver abilitato il controllo granulare degli accessi, non è più possibile disabilitarlo.

Abilitazione del controllo dettagliato degli accessi

È possibile abilitare il controllo dettagliato degli accessi sui domini esistenti che eseguono OpenSearch o Elasticsearch 6.7 e versioni successive.

Per abilitare il controllo dettagliato degli accessi su un dominio esistente (console)

  1. Seleziona il dominio e scegli Operazioni quindi Modifica configurazione di sicurezza.

  2. True per abilitare il controllo dettagliato degli accessi.

  3. Scegli come creare l'utente master:

    • Se si desidera utilizzare IAM per la gestione degli utenti, scegliere Imposta ARN IAM come utente principale e specificare l'ARN per un ruolo IAM.

    • Se desideri utilizzare il database utente interno, scegli Crea utente principale e specifica un nome utente e una password.

  4. (Opzionale) Seleziona Enable migration period for open/IP-based access policy (Abilita il periodo di migrazione per le policy di accesso open/basati su IP). Questa impostazione consente un periodo di transizione di 30 giorni durante il quale gli utenti esistenti possono continuare ad accedere al dominio senza interruzioni e Policy di accesso basate su IP aperte e esistenti continueranno a lavorare con il tuo dominio. Durante questo periodo di migrazione, consigliamo agli amministratori creare i ruoli necessari e mapparli agli utenti per il dominio. Se si utilizzano policy basate su identità anziché un criterio di accesso aperto o basato su IP, è possibile disabilitare questa impostazione.

    È inoltre necessario aggiornare i client per lavorare con un controllo degli accessi dettagliato durante il periodo di migrazione. Ad esempio, se mappi gli utenti IAM con un controllo di accesso dettagliato, è necessario aggiornare i client per iniziare a firmare le richieste con AWSSignature Version 4. Se si configura l'autenticazione di base HTTP con un controllo di accesso dettagliato, è necessario aggiornare i client per fornire le credenziali di autenticazione di base appropriate nelle richieste.

    Durante il periodo di migrazione, gli utenti che accedono all'endpoint OpenSearch Dashboards per il dominio atterreranno direttamente sulla pagina Scopri anziché la pagina di accesso. Gli amministratori e gli utenti master possono scegliere Login per accedere con le credenziali di amministratore e configurare i mapping dei ruoli.

    Importante

    OpenSearch Service disattiva automaticamente il periodo di migrazione dopo 30 giorni. Si consiglia di terminarlo non appena crei i ruoli necessari e li mappi agli utenti. Al termine del periodo di migrazione, non è possibile riattivarlo.

  5. Scegliere Save changes (Salva modifiche).

Il cambiamento innesca una distribuzione blu/verde durante la quale l’integrità del cluster diventa rossa, ma tutte le operazioni del cluster rimangono inalterate.

Per abilitare il controllo dettagliato degli accessi su un dominio esistente (CLI)

Imposta AnonymousAuthEnabled su true per abilitare il periodo di migrazione con un controllo degli accessi dettagliato:

aws opensearch update-domain-config --domain-name test-domain --region us-east-1 \ --advanced-security-options '{ "Enabled": true, "InternalUserDatabaseEnabled":true, "MasterUserOptions": {"MasterUserName":"master-username","MasterUserPassword":"master-password"},"AnonymousAuthEnabled": true}'

Informazioni sul ruolo default

Un controllo dettagliato degli accessi richiede una mappatura dei ruoli. Se il tuo dominio utilizza policy di accesso basate su identità, OpenSearch Service mappa automaticamente gli utenti IAM a un nuovo ruolo chiamato default_role per aiutarti a migrare correttamente gli utenti esistenti. Questa mappatura temporanea garantisce che gli utenti possano ancora inviare correttamente le richieste GET e PUT firmate IAM fino a quando non crei i tuoi mapping dei ruoli personalizzati.

Il ruolo non aggiunge vulnerabilità o difetti di sicurezza al dominio del servizio OpenSearch. Ti consigliamo di eliminare il ruolo predefinito non appena configuri i tuoi ruoli e di mapparli di conseguenza.

Scenari di migrazione

Nella tabella seguente viene descritto il comportamento di ciascun metodo di autenticazione prima e dopo aver abilitato il controllo di accesso dettagliato su un dominio esistente e i passaggi che gli amministratori devono adottare per mappare correttamente i propri utenti ai ruoli:

Metodo di autenticazione Prima dell’abilitazione del controllo dettagliato degli accessi Dopo l’abilitazione del controllo dettagliato degli accessi Attività amministrative
Policy basate su identità

Tutti gli utenti IAM che soddisfano la policy IAM possono accedere al dominio.

Non è necessario abilitare il periodo di migrazione.

OpenSearch Service mappa automaticamente tutti gli utenti IAM che soddisfano la policy IAM al default_role in modo che possano continuare ad accedere al dominio.

  1. Crea mappature di ruolo personalizzate sul dominio.

  2. Elimina il default_role.

Policy basate su IP

Tutti gli utenti degli indirizzi IP o dei blocchi CIDR consentiti possono accedere al dominio.

Durante il periodo di migrazione di 30 giorni, tutti gli utenti degli indirizzi IP o dei blocchi CIDR consentiti possono continuare ad accedere al dominio.

  1. Crea mappature di ruolo personalizzate sul dominio.

  2. Aggiorna i tuoi client per fornire credenziali di autenticazione di base o credenziali IAM, a seconda della configurazione della mappatura dei ruoli.

  3. Disabilitare il periodo di migrazione. Gli utenti degli indirizzi IP consentiti o dei blocchi CIDR che inviano richieste senza autenticazione di base o credenziali IAM perderanno l'accesso al dominio.

Policy di accesso aperto

Tutti gli utenti su Internet possono accedere al dominio.

Durante il periodo di migrazione di 30 giorni, tutti gli utenti su Internet possono continuare ad accedere al dominio.

  1. Crea mappature dei ruoli sul dominio.

  2. Aggiorna i tuoi client per fornire credenziali di autenticazione di base o credenziali IAM, a seconda della configurazione della mappatura dei ruoli.

  3. Disabilitare il periodo di migrazione. Gli utenti che inviano richieste senza autenticazione di base o credenziali IAM perderanno l'accesso al dominio.

Accesso a OpenSearch Dashboards come utente principale

Il controllo granulare degli accessi ha un plug-in OpenSearch Dashboards che semplifica le attività di gestione. È possibile utilizzare Dashboards per gestire utenti, ruoli, mappature, gruppi di operazioni e tenant. La pagina di accesso di OpenSearch Dashboards e il metodo di autenticazione sottostante differiscono, tuttavia, a seconda di come è stato configurato il dominio.

Gestione delle autorizzazioni

Come indicato in Concetti chiave, è possibile gestire le autorizzazioni del controllo granulare degli accessi a utilizzando ruoli, utenti e mappature. In questa sezione viene descritto come creare e applicare tali risorse. Per eseguire queste operazioni si consiglia di accedere a Dashboards come utente principale.


        Home page di sicurezza in Dashboards
Nota

Le autorizzazioni che scegli di concedere agli utenti variano ampiamente in base al caso d'uso. Non possiamo coprire in maniera fattibile tutti gli scenari contenuti in questa documentazione. Mentre determini le autorizzazioni da concedere agli utenti, fai riferimento al cluster OpenSearch e alle autorizzazioni di indice menzionate nelle sezioni seguenti e segui sempre il principio del privilegio minimo.

Creazione di ruoli

È possibile creare nuovi ruoli per il controllo granulare degli accessi utilizzando OpenSearch Dashboards o l'operazione _plugins/_security nell'API REST. Per ulteriori informazioni, consulta Creazione di ruoli.

Il controllo granulare degli accessi include anche numerosi ruoli predefiniti. Client come OpenSearch Dashboards e Logstash eseguono un'ampia varietà di richieste a OpenSearch, il che può rendere difficile la creazione manuale dei ruoli con il set minimo di autorizzazioni. Ad esempio, il ruolo opensearch_dashboards_user include le autorizzazioni necessarie a un utente per utilizzare modelli di indice, visualizzazioni, dashboard e tenant. Si consiglia di associarlo a qualsiasi ruolo utente o back-end che accede a Dashboards, insieme a ruoli aggiuntivi che consentono l'accesso ad altri indici.

Sicurezza a livello di cluster

Le autorizzazioni a livello di cluster includono la possibilità di eseguire richieste generiche quali _mget, _msearch, e _bulk, monitorare l'integrità, acquisire snapshot e altro ancora. Gestire queste autorizzazioni utilizzando la sezione Autorizzazioni cluster durante la creazione di un ruolo. Per l'elenco completo delle autorizzazioni a livello di cluster, consulta Autorizzazioni cluster.

Invece delle autorizzazioni individuali, spesso puoi ottenere la posizione di sicurezza desiderata utilizzando una combinazione di gruppi di azioni predefiniti. Per un elenco dei gruppi di operazioni a livello di cluster, consultare Livello di cluster.

Sicurezza a livello di indice

Le autorizzazioni a livello di indice includono la possibilità di creare nuovi indici, indici di ricerca, leggere e scrivere documenti, eliminare documenti, gestire alias e altro ancora. Gestire queste autorizzazioni utilizzando la sezione Autorizzazioni indice durante la creazione di un ruolo. Per l'elenco completo delle autorizzazioni a livello di indice, consulta Autorizzazioni indice.

Invece delle autorizzazioni individuali, spesso puoi ottenere la posizione di sicurezza desiderata utilizzando una combinazione di gruppi di azioni predefiniti. Per un elenco dei gruppi di operazioni a livello di indice, consultare Livello di indice.

Sicurezza a livello di documento

La sicurezza a livello di documento consente di limitare i documenti in un indice che un utente può visualizzare. Quando si crea un ruolo, specificare un modello di indice e una query OpenSearch. Tutti gli utenti che si associano a tale ruolo possono visualizzare solo i documenti corrispondenti alla query. La sicurezza a livello di documento influisce sul numero di visite ricevute durante la ricerca.

Per ulteriori informazioni, consultare Sicurezza a livello di documento.

Sicurezza a livello di campo

La sicurezza a livello di campo consente di controllare quali campi di documento possono essere visualizzati dall'utente. Quando si crea un ruolo, aggiungere un elenco di campi da includere o escludere. Se si includono campi, gli utenti per cui si esegue il mapping a tale ruolo possono visualizzare solo i campi. Se si escludono i campi, possono visualizzare tutti i campi tranne quelli esclusi. La sicurezza a livello di campo influisce sul numero di campi inclusi negli hit durante la ricerca.

Per ulteriori informazioni, consultare Sicurezza a livello di campo.

Mascheramento del campo

Il mascheramento dei campi è un'alternativa alla sicurezza a livello di campo che consente di anonimizzare i dati in un campo anziché rimuoverli del tutto. Quando si crea un ruolo, aggiungere un elenco di campi da mascherare. Il mascheramento dei campi influisce sulla possibilità di visualizzare il contenuto di un campo durante la ricerca.

Suggerimento

Se si applica il mascheramento standard a un campo, OpenSearch Service utilizza un hash sicuro e casuale che può causare risultati di aggregazione imprecisi. Per eseguire aggregazioni su campi mascherati, utilizzare invece il mascheramento basato su modello.

Creazione di utenti

Se è stato attivato il database utente interno, è possibile creare utenti utilizzando OpenSearch Dashboards o l'operazione _plugins/_security nell'API REST. Per ulteriori informazioni, consultare Creazione di utenti.

Se è stato scelto IAM per l'utente principale, ignorare questa parte di Dashboards. Creare invece utenti e ruoli IAM. Per ulteriori informazioni, consultare la Guida per l'utente IAM.

Mappatura dei ruoli agli utenti

La mappatura dei ruoli è l'aspetto più critico del controllo granulare degli accessi. Il controllo granulare degli accessi dispone di alcuni ruoli predefiniti che consentono di iniziare, ma a meno che non si esegua la mappatura dei ruoli agli utenti, ogni richiesta al cluster termina con un errore di autorizzazioni.

I ruoli di back-end offrono un altro modo di associare i ruoli agli utenti. Anziché associare lo stesso ruolo a dozzine di utenti diversi, è possibile mappare il ruolo a un singolo ruolo di back-end e quindi assicurarsi che tutti gli utenti abbiano quel ruolo di back-end. I ruoli di back-end possono essere ruoli IAM o stringhe arbitrarie.

  • Nella sezione Utenti, specificare utenti, ARN di utenti IAM e stringhe utente di Amazon Cognito. Le stringhe utente di Cognito assumono la forma di Cognito/user-pool-id/username.

  • Specificare i ruoli di back-end e gli ARN del ruolo IAM nella sezione Ruoli di back-end .


                    Schermata di associazione dei ruoli

È possibile mappare i ruoli agli utenti utilizzando OpenSearch Dashboards o l'operazione _plugins/_security nell'API REST. Per ulteriori informazioni, consultare Mappa utenti ai ruoli.

Creazione di gruppi di operazioni

I gruppi di azioni sono insiemi di autorizzazioni che è possibile riutilizzare in diverse risorse. È possibile creare nuovi gruppi di operazioni utilizzando OpenSearch Dashboards o l'operazione _plugins/_security nell'API REST, sebbene i gruppi di operazioni predefiniti siano sufficienti per la maggior parte dei casi d'uso. Per ulteriori informazioni sui gruppi di operazioni predefiniti, consultare Gruppi di operazioni predefiniti.

Multi-locazione di OpenSearch Dashboards

I tenant sono spazi per salvare modelli di indici, visualizzazioni, pannelli di controllo e altri oggetti Dashboards. La multi-locazione di Dashboards consente di condividere in modo sicuro il lavoro con altri utenti di Dashboards (o mantenerlo privato). È possibile controllare quali ruoli hanno accesso a un tenant e se tali ruoli hanno accesso in lettura o in scrittura. Per ulteriori informazioni, consultare Multi-locazione di OpenSearch Dashboards.

Per visualizzare il tenant corrente o modificare i tenant

  1. Apri OpenSearch Dashboards e accedi.

  2. Seleziona l'icona utente in alto a destra e sceglie Cambia tenant.

  3. Verificare il tenant prima di creare visualizzazioni o dashboard. Se si desidera condividere il proprio lavoro con tutti gli altri utenti di Dashboards, scegliere Globale. Per condividere il lavoro con un sottoinsieme di utenti di Dashboards, scegliere un tenant condiviso diverso. Altrimenti, scegli Privato.

Nota

OpenSearch Dashboards mantiene un indice separato per ogni tenant e crea un modello di indice denominato tenant_template. Non eliminare o modificare l'indice tenant_template, in quanto potrebbe causare un malfunzionamento dei OpenSearch Dashboards se la mappatura dell'indice tenant è configurata in maniera errata.

Configurazioni consigliate

A causa del modo in cui il controllo granulare degli accessi interagisce con altre funzionalità di sicurezza, consigliamo diverse configurazioni di controllo granulare degli accessi che funzionano bene per la maggior parte dei casi d'uso.

Descrizione Utente principale Policy di accesso al dominio

Utilizzare le credenziali IAM per le chiamate alle API OpenSearch e utilizzare Autenticazione SAML per accedere a Dashboards. Gestire i ruoli del controllo granulare degli accessi utilizzando Dashboards o l'API REST.

Utente o ruolo IAM
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" } ] }

Utilizzare le credenziali IAM o l'autenticazione di base per le chiamate alle API OpenSearch. Gestire i ruoli del controllo granulare degli accessi utilizzando Dashboards o l'API REST.

Questa configurazione offre molta flessibilità, soprattutto se si dispone di client OpenSearch che supportano solo l'autenticazione di base.

Se si dispone di un provider di identità esistente, utilizzare Autenticazione SAML per accedere a Dashboards. In caso contrario, gestire gli utenti di Dashboards nel database interno degli utenti.

Nome utente e password
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" } ] }

Utilizzare le credenziali IAM per le chiamate alle API OpenSearch e utilizzare Amazon Cognito per accedere a Dashboards. Gestire i ruoli del controllo granulare degli accessi utilizzando Dashboards o l'API REST.

Utente o ruolo IAM
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" } ] }

Utilizzare le credenziali IAM per le chiamate alle API OpenSearch e bloccare la maggior parte degli accessi a Dashboards. Gestire i ruoli del controllo granulare degli accessi utilizzando l'API REST.

Utente o ruolo IAM
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" }, { "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/_dashboards*" } ] }

Restrizioni

Il controllo granulare degli accessi presenta diverse limitazioni importanti:

  • L'aspetto hosts delle mappature dei ruoli, che associa i ruoli a nomi host o indirizzi IP, non funziona se il dominio è all'interno di un VPC. È comunque possibile mappare i ruoli agli utenti e ai ruoli di back-end.

  • Se sceglisi sceglie IAM per l'utente principale e non abilitisi abilita l'autenticazione Amazon Cognito o SAML, Dashboards visualizza una pagina di accesso non funzionante.funzionale.

  • Se si sceglie IAM per l'utente master, è comunque possibile creare utenti nel database utente interno. Poiché l'autenticazione di base HTTP non è abilitata in questa configurazione, tutte le richieste firmate con tali credenziali utente vengono rifiutate.

  • Se si utilizza SQL per eseguire una query su un indice a cui non si ha accesso, viene visualizzato un errore "no permissions". Se l'indice non esiste, viene visualizzato un errore «tale indice è inesistente». Questa differenza nei messaggi di errore significa che puoi confermare l'esistenza di un indice se ti capita di indovinare il suo nome.

    Per ridurre al minimo il problema, non includere informazioni riservate nei nomi degli indici. Per negare tutti gli accessi a SQL, aggiungere il seguente elemento alla policy di accesso del dominio:

    { "Effect": "Deny", "Principal": { "AWS": [ "*" ] }, "Action": [ "es:*" ], "Resource": "arn:aws:es:us-east-1:123456789012:domain/my-domain/_plugins/_sql" }

Modifica dell'utente principale

Se si dimenticano i dettagli dell'utente master, è possibile riconfigurarlo utilizzando la console, AWS CLI o l'API di configurazione.

Per modificare l'utente master (console)

  1. Andare all'indirizzo https://aws.amazon.com e quindi scegliere Sign In to the Console (Accedi alla console).

  2. In Analisi, sceglie Servizio OpenSearch di Amazon.

  3. Scegli il tuo dominio.

  4. Scegli Operazioni quindi Modifica configurazione di sicurezza.

  5. Scegliere Imposta ARN IAM come utente principale o Crea utente principale.

    • Se in precedenza è stato utilizzato un utente master IAM, il controllo granulare degli accessi esegue nuovamente la mappatura del ruolo all_access al nuovo ARN IAM specificato.

    • Se in precedenza è stato utilizzato il database utente interno, il controllo granulare degli accessi crea un nuovo utente principale. È possibile utilizzare il nuovo utente master per eliminare quello vecchio.

    • Il passaggio dal database utente interno a un utente principale IAM non elimina gli utenti dal database utente interno. Invece, disabilita semplicemente l'autenticazione di base HTTP. Eliminare manualmente gli utenti dal database utente interno o conservarli nel caso in cui sia necessario riabilitare l'autenticazione di base HTTP.

  6. Scegliere Save changes (Salva modifiche).

Utenti principali aggiuntivi

Si designa un utente master quando si crea un dominio, ma se si desidera, è possibile utilizzare questo utente master per creare ulteriori utenti master. Sono disponibili due opzioni: OpenSearch Dashboards o l'API REST.

  • In Dashboards scegliere Sicurezza, Ruoli, quindi associare il nuovo utente principale ai ruoli all_access e security_manager.

    
            Pagina del mapping dei ruoli
  • Per utilizzare l'API REST, inviare le seguenti richieste:

    PUT _plugins/_security/api/rolesmapping/all_access { "backend_roles": [ "arn:aws:iam::123456789012:role/fourth-master-user" ], "hosts": [], "users": [ "master-user", "second-master-user", "arn:aws:iam::123456789012:user/third-master-user" ] }
    PUT _plugins/_security/api/rolesmapping/security_manager { "backend_roles": [ "arn:aws:iam::123456789012:role/fourth-master-user" ], "hosts": [], "users": [ "master-user", "second-master-user", "arn:aws:iam::123456789012:user/third-master-user" ] }

    Queste richieste sostituiscono le mappature dei ruoli correnti, quindi eseguire prima le richieste GET in modo da poter includere tutti i ruoli correnti nelle richieste PUT. L'API REST è particolarmente utile se non è possibile accedere a Dashboards e si desidera mappare un ruolo IAM da Amazon Cognito al ruolo all_access.

Snapshot manuali

Il controllo granulare degli accessi introduce alcune complicazioni aggiuntive con l'acquisizione di snapshot manuali. Per registrare un repository di snapshot, anche se si utilizza l'autenticazione di base HTTP per tutti gli altri scopi, è necessario associare il ruolo manage_snapshots a un ruolo IAM che dispone delle autorizzazioni iam:PassRole per assumere TheSnapshotRole, come definito in Prerequisiti.

Utilizzare quindi il ruolo IAM per inviare una richiesta firmata al dominio, come descritto in Registrazione di un repository di snapshot manuali.

Integrazioni

Se si utilizzano altri servizi AWS con OpenSearch Service, è necessario fornire i ruoli IAM per tali servizi con le autorizzazioni appropriate. Ad esempio, i flussi di consegna Kinesis Data Firehose utilizzano spesso un ruolo IAM chiamato firehose_delivery_role. In Dashboards, creare un ruolo per il controllo granulare degli accessi e mappare il ruolo IAM a tale ruolo. In questo caso, il nuovo ruolo richiede le seguenti autorizzazioni:

{ "cluster_permissions": [ "cluster_composite_ops", "cluster_monitor" ], "index_permissions": [{ "index_patterns": [ "firehose-index*" ], "allowed_actions": [ "create_index", "manage", "crud" ] }] }

Le autorizzazioni variano in base alle azioni eseguite da ciascun servizio. Una regola AWS IoT o una funzione AWS Lambda che indicizza i dati richiede probabilmente autorizzazioni simili a Kinesis Data Firehose, mentre una funzione Lambda che esegue solo ricerche può utilizzare un set più limitato.

Differenze dell'API REST

L'API REST del controllo granulare degli accessi differisce leggermente a seconda della versione di OpenSearch/Elasticsearch. Prima di effettuare una richiesta PUT, effettuare una richiesta GET per verificare il corpo della richiesta previsto. Ad esempio, una richiesta GET per _plugins/_security/api/user restituisce tutti gli utenti, che è possibile modificare e utilizzare per effettuare richieste PUT valide.

In Elasticsearch 6.x, le richieste per creare utenti hanno il seguente aspetto:

PUT _opendistro/_security/api/user/new-user { "password": "some-password", "roles": ["new-backend-role"] }

In OpenSearch o Elasticsearch 7.x, le richieste sono simili a questa (cambia _plugins in _opendistro se utilizzi Elasticsearch):

PUT _plugins/_security/api/user/new-user { "password": "some-password", "backend_roles": ["new-backend-role"] }

Inoltre, i tenant sono proprietà dei ruoli in Elasticsearch 6.x:

GET _opendistro/_security/api/roles/all_access { "all_access": { "cluster": ["UNLIMITED"], "tenants": { "admin_tenant": "RW" }, "indices": { "*": { "*": ["UNLIMITED"] } }, "readonly": "true" } }

In OpenSearch ed Elasticsearch 7.x, sono oggetti con il proprio URI (cambia _plugins in _opendistro se utilizzi Elasticsearch):

GET _plugins/_security/api/tenants { "global_tenant": { "reserved": true, "hidden": false, "description": "Global tenant", "static": false } }

Per la documentazione sull'API REST OpenSearch, consultare la Documentazione di riferimento dell'API del plug-in di sicurezza.

Suggerimento

Se si utilizza il database utente interno, è possibile utilizzare curl per effettuare richieste e testare il dominio. Provare i seguenti comandi di esempio:

curl -XGET -u 'master-user:master-user-password' 'domain-endpoint/_search' curl -XGET -u 'master-user:master-user-password' 'domain-endpoint/_plugins/_security/api/user'