Controllo granulare degli accessi in Amazon Service OpenSearch - OpenSearch Servizio Amazon

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

Controllo granulare degli accessi in Amazon Service OpenSearch

Il controllo granulare degli accessi offre modi aggiuntivi per controllare l'accesso ai tuoi dati su Amazon Service. OpenSearch 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

  • OpenSearch Dashboard multi-tenancy

  • Autenticazione di base HTTP per e dashboard OpenSearch OpenSearch

Il quadro generale: controllo granulare degli accessi e sicurezza dei servizi OpenSearch

La sicurezza di Amazon OpenSearch Service ha tre livelli principali:

Rete

Il primo livello di sicurezza è la rete, che determina se le richieste raggiungono un dominio OpenSearch di servizio. 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 politica di accesso accetta o rifiuta le richieste nella «periferia» del dominio, prima che raggiungano OpenSearch se stesse.

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 ruoli o utenti IAM, i client devono inviare richieste firmate utilizzando AWS la versione 4 di Signature. 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 puoi firmare una richiesta con nome utente e 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

Per iniziare a utilizzare un controllo granulare degli accessi, considera i seguenti concetti:

  • Ruoli: 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.

  • Mappatura: dopo aver configurato un ruolo, lo si associa 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.

  • Utenti: persone o applicazioni che effettuano richieste al OpenSearch cluster. Gli utenti dispongono di credenziali, chiavi di accesso IAM o nome utente e password, che specificano quando effettuano richieste.

Informazioni sull'utente principale

L'utente principale in OpenSearch Service è una combinazione di nome utente e password o un principale IAM che dispone delle autorizzazioni complete per il OpenSearch cluster sottostante. Un utente è considerato un utente principale se ha tutti gli accessi al OpenSearch cluster e la possibilità di creare utenti interni, ruoli e mappature dei ruoli all'interno delle dashboard. OpenSearch

Un utente master creato nella console di OpenSearch servizio o tramite la CLI viene automaticamente mappato su due ruoli predefiniti:

  • all_access— Fornisce l'accesso completo a tutte le operazioni a livello di cluster, l'autorizzazione alla scrittura su tutti gli indici del cluster e l'autorizzazione alla scrittura a tutti i tenant.

  • security_manager— Fornisce l'accesso al plug-in di sicurezza e la gestione di utenti e autorizzazioni.

Con questi due ruoli, l'utente ottiene l'accesso alla scheda Sicurezza nelle OpenSearch dashboard, dove può gestire utenti e autorizzazioni. Se si crea un altro utente interno e lo si associa solo al all_access ruolo, l'utente non ha accesso alla scheda Sicurezza. È possibile creare utenti principali aggiuntivi mappandoli esplicitamente a entrambi all_access i security_manager ruoli. Per istruzioni, consulta Utenti principali aggiuntivi.

Quando crei un utente master per il tuo dominio, puoi specificare un principale IAM esistente o creare un utente master all'interno del database utenti interno. Considera quanto segue quando decidi quale usare:

  • Principal IAM: se scegli un principale IAM per il tuo utente principale, tutte le richieste al cluster devono essere firmate utilizzando AWS Signature Version 4.

    OpenSearch Il servizio non prende in considerazione nessuna delle autorizzazioni del responsabile IAM. L'utente o il ruolo IAM serve esclusivamente per l'autenticazione. Le politiche relative a quell'utente o ruolo non influiscono sull'autorizzazione dell'utente principale. L'autorizzazione viene gestita tramite le varie autorizzazioni del plug-in OpenSearch Security.

    Ad esempio, puoi assegnare zero autorizzazioni IAM a un principale IAM e, purché la macchina o la persona possa autenticarsi per quell'utente o ruolo, ha il potere dell'utente principale in Service. OpenSearch

    Ti consigliamo IAM se desideri utilizzare gli stessi utenti su più cluster, se desideri utilizzare Amazon Cognito per accedere alle dashboard o se OpenSearch disponi di client che supportano la firma Signature versione 4.

  • Database utenti interno: se crei un master nel database utenti interno (con una combinazione di nome utente e password), puoi utilizzare l'autenticazione di base HTTP (oltre alle credenziali IAM) per effettuare richieste al cluster. La maggior parte dei client supporta l'autenticazione di base, incluso curl, che supporta anche la versione 4 di AWS Signature con l'opzione --aws-sigv4. Il database utenti interno è memorizzato in un OpenSearch indice, 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 utenti interno è il modo più semplice per iniziare a usare OpenSearch Service.

Abilitazione del controllo granulare degli accessi

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

Il controllo granulare degli accessi richiede OpenSearch Elasticsearch 6.7 o versione successiva. Richiede inoltre HTTPS per tutto il traffico verso il dominio, la crittografia dei dati inattivi e la crittografia. node-to-node A seconda di come configurate le funzionalità avanzate del controllo granulare degli accessi, l'ulteriore elaborazione delle richieste potrebbe richiedere risorse di calcolo e memoria su singoli nodi di dati. Dopo aver abilitato il controllo granulare degli accessi, non è più possibile disabilitarlo.

Abilitazione del controllo granulare degli accessi su domini esistenti

Puoi abilitare un controllo granulare degli accessi sui domini esistenti in esecuzione o su Elasticsearch 6.7 o versione successiva. OpenSearch

Per abilitare il controllo granulare 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 granulare 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 utenti 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 granulare degli accessi durante il periodo di migrazione. Ad esempio, se mappi i ruoli IAM con un controllo di accesso granulare, devi aggiornare i tuoi client per iniziare a firmare le richieste con AWS Signature Version 4. Se si configura l'autenticazione di base HTTP con un controllo granulare degli accessi, è 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 accederanno direttamente alla pagina Discover anziché alla 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 Il servizio disabilita 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 implementazione blu/verde durante la quale l'integrità del cluster diventa rossa, ma tutte le operazioni del cluster rimangono inalterate.

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

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

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 granulare degli accessi richiede una mappatura dei ruoli. Se il tuo dominio utilizza politiche di accesso basate sull'identità, OpenSearch Service associa automaticamente gli utenti 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 granulare degli accessi 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 Il servizio mappa automaticamente tutti gli utenti che soddisfano la policy IAM sul 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 alle OpenSearch dashboard 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 a OpenSearch Dashboards e il metodo di autenticazione sottostante differiscono, tuttavia, a seconda di come gestisci gli utenti e configuri 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 decidi quali autorizzazioni concedere ai tuoi utenti, assicurati di fare riferimento alle autorizzazioni per OpenSearch cluster e indice menzionate nelle sezioni seguenti e segui sempre il principio del privilegio minimo.

Creazione di ruoli

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

Il controllo granulare degli accessi include anche numerosi ruoli predefiniti. Client come OpenSearch Dashboards e Logstash inviano un'ampia varietà di richieste OpenSearch, il che può rendere difficile la creazione manuale di 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.

Amazon OpenSearch Service non offre i seguenti OpenSearch ruoli:

  • observability_full_access

  • observability_read_access

  • reports_read_access

  • reports_full_access

Amazon OpenSearch Service offre diversi ruoli che non sono disponibili con OpenSearch:

  • ultrawarm_manager

  • ml_full_access

  • cold_manager

  • notifications_full_access

  • notifications_read_access

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 crei un ruolo, specifica uno schema di indice e una OpenSearch query. 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 applichi 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 hai abilitato il database utenti interno, puoi creare utenti utilizzando le OpenSearch dashboard o l'_plugins/_securityoperazione 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 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 backend possono aiutare a semplificare il processo di mappatura dei ruoli. Invece di mappare lo stesso ruolo a 100 singoli utenti, puoi mappare il ruolo a un singolo ruolo di backend condiviso da tutti i 100 utenti. I ruoli di back-end possono essere ruoli IAM o stringhe arbitrarie.

  • Nella sezione Users (Utenti), specifica utenti, ARN di utenti 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

Puoi mappare i ruoli agli utenti utilizzando OpenSearch le dashboard o l'_plugins/_securityoperazione 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 azioni utilizzando OpenSearch le dashboard o l'_plugins/_securityoperazione nell'API REST, sebbene i gruppi di azioni predefiniti siano sufficienti per la maggior parte dei casi d'uso. Per ulteriori informazioni sui gruppi di operazioni predefiniti, consultare Gruppi di operazioni predefiniti.

OpenSearch Dashboard multi-tenancy

I tenant sono spazi per salvare modelli di indici, visualizzazioni, pannelli di controllo e altri oggetti Dashboards. La funzionalità multi-tenancy di Dashboards ti consente di condividere in sicurezza il tuo lavoro con altri utenti di Dashboards (o di mantenerlo privato) e di configurare dinamicamente i tenant. È possibile controllare quali ruoli hanno accesso a un tenant e se tali ruoli hanno accesso in lettura o in scrittura. Il tenant globale è l'impostazione predefinita. Per ulteriori informazioni, consulta Dashboards multi-tenancy. OpenSearch

Per visualizzare il tenant corrente o modificare i tenant
  1. Vai alle OpenSearch dashboard 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 chiamato. tenant_template Non eliminate o modificate l'tenant_templateindice, poiché se la mappatura dell'indice dei tenant non è configurata correttamente, ciò potrebbe causare il malfunzionamento dei OpenSearch dashboard.

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

Utilizza le credenziali IAM per le chiamate alle OpenSearch API e utilizza l'autenticazione SAML per accedere alle dashboard. Gestire i ruoli del controllo granulare degli accessi utilizzando Dashboards o la REST API.

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

Utilizza 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 la REST API.

Questa configurazione offre molta flessibilità, soprattutto se hai OpenSearch client 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/*" } ] }

Usa le credenziali IAM per le chiamate alle OpenSearch API e usa Amazon Cognito per accedere alle dashboard. Gestire i ruoli del controllo granulare degli accessi utilizzando Dashboards o la REST API.

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

Utilizza le credenziali IAM per le chiamate alle OpenSearch API e blocca la maggior parte degli accessi alle dashboard. Gestire i ruoli del controllo granulare degli accessi utilizzando la REST API.

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*" } ] }

Limitazioni

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" }
  • Se la versione del tuo dominio è 2.3 o successiva e hai abilitato il controllo granulare degli accessi, l'impostazione su 1 causa problemi con max_clause_count il dominio. Ti consigliamo di impostare questo account su un numero più alto.

  • Se stai abilitando il controllo granulare degli accessi in un dominio in cui non è impostato il controllo granulare degli accessi, per le fonti di dati create per l'interrogazione diretta, devi configurare tu stesso ruoli di controllo degli accessi granulari. Per ulteriori informazioni su come configurare ruoli di accesso granulari, consulta Creazione di integrazioni di origini dati Amazon OpenSearch Service con Amazon S3.

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. Accedi alla console di Amazon OpenSearch Service all'indirizzo https://console.aws.amazon.com/aos/home/.

  2. Seleziona il dominio e scegli Actions (Operazioni) quindi Edit security configuration (Modifica configurazione di sicurezza).

  3. 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.

  4. Seleziona Salvataggio delle 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. Hai due opzioni: OpenSearch dashboard o 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 la REST API, 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. La REST API è 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 utilizzi altri AWS servizi con OpenSearch Service, devi fornire i ruoli IAM per tali servizi con le autorizzazioni appropriate. Ad esempio, i flussi di distribuzione di 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 AWS IoT regola o una AWS Lambda funzione che indicizza i dati richiede probabilmente autorizzazioni simili a quelle di Firehose, mentre una funzione Lambda che esegue solo ricerche può utilizzare un set più limitato.

Differenze della REST API

L'API REST per il controllo degli accessi a grana fine differisce leggermente a seconda della versione di /Elasticsearch. OpenSearch 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"] }

Su OpenSearch o Elasticsearch 7.x, le richieste hanno questo aspetto (cambia se usi Elasticsearch): _plugins _opendistro

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 Elasticsearch 7.x, sono oggetti con un proprio URI (modificalo se usi Elasticsearch):: _plugins _opendistro

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

Per la documentazione sull'API OpenSearch REST, consulta il riferimento all'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'