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
Argomenti
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. Il criterio di accesso accetta o rifiuta le richieste al «bordo» 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 politica di accesso basata sulle risorse contiene ruoli o utenti IAM, i client devono inviare richieste firmate utilizzando 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 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.
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.
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
index1e uno che fornisce l'accesso in scrittura aindex2. 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 sicurezzae 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)
-
Seleziona il dominio e scegli Operazioni quindi Modifica configurazione di sicurezza.
-
True per abilitare il controllo granulare degli accessi.
-
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.
-
-
(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.
-
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-nametest-domain--regionus-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 sull'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. |
|
| 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. |
|
| 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. |
|
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.
-
Se si desidera utilizzare IAM per la gestione degli utenti, utilizzare Configurazione dell'autenticazione Amazon Cognito per dashboard OpenSearch per accedere a Dashboards. Altrimenti, Dashboards mostra una pagina di accesso non funzionale. Per informazioni, consultare Limitazioni.
Con l'autenticazione di Amazon Cognito, uno dei ruoli assunti dal pool di identità deve corrispondere al ruolo IAM specificato per l'utente principale. Per ulteriori informazioni su questa configurazione, consulta (Facoltativo) Configurazione dell'accesso granulare e Tutorial: configurazione di un dominio con un utente master IAM e autenticazione Amazon Cognito.
-
Se scegli di utilizzare il database utenti interno, puoi accedere a Dashboards con il nome utente e la password principali. È necessario accedere a Dashboards tramite HTTPS. L'autenticazione Amazon Cognito e SAML per Dashboards sostituiscono entrambe questa schermata di accesso.
Per ulteriori informazioni su questa configurazione, consulta Tutorial: Configurare un dominio con il database utente interno e l'autenticazione di base HTTP.
-
Se si decide di utilizzare l'autenticazione SAML, è possibile accedere utilizzando le credenziali di un provider di identità esterno. Per ulteriori informazioni, consultare Autenticazione SAML per dashboard OpenSearch .
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.
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
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 predefinitiopensearch_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.
-
Specificare gli utenti ARNs, gli utenti e le stringhe utente di Amazon Cognito nella sezione Utenti. Le stringhe utente di Cognito assumono la forma di
Cognito/.user-pool-id/username -
Specificate i ruoli di backend e il ruolo IAM ARNs nella sezione Ruoli di backend.
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
-
Vai alle OpenSearch dashboard e accedi.
-
Seleziona l'icona utente in alto a destra e sceglie Cambia tenant.
-
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 a e utilizza l'autenticazione SAML OpenSearch APIs per accedere alle dashboard. Gestire i ruoli del controllo granulare degli accessi utilizzando Dashboards o la REST API. |
Utente o ruolo IAM |
|
|
Utilizza le credenziali IAM o l'autenticazione di base per le chiamate a. OpenSearch APIs 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 |
|
|
Usa le credenziali IAM per le chiamate verso e usa Amazon Cognito per accedere alle dashboard. OpenSearch APIs Gestire i ruoli del controllo granulare degli accessi utilizzando Dashboards o la REST API. |
Utente o ruolo IAM |
|
|
Utilizza le credenziali IAM per le chiamate e blocca la OpenSearch APIs maggior parte degli accessi alle dashboard. Gestire i ruoli del controllo granulare degli accessi utilizzando la REST API. |
Utente o ruolo IAM |
|
Limitazioni
Il controllo granulare degli accessi presenta diverse limitazioni importanti:
-
L'aspetto
hostsdelle 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
max_clause_countcausa problemi con 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 di 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)
-
Accedi alla console di Amazon OpenSearch Service a https://console.aws.amazon.com/aos/casa/
. -
Seleziona il dominio e scegli Actions (Operazioni) quindi Edit security configuration (Modifica configurazione di sicurezza).
-
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_accessal 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.
-
-
Scegli 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. Hai due opzioni: OpenSearch dashboard o API REST.
-
In Dashboards scegliere Sicurezza, Ruoli, quindi associare il nuovo utente principale ai ruoli
all_accessesecurity_manager.
-
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
GETin modo da poter includere tutti i ruoli correnti nelle richiestePUT. La REST API è particolarmente utile se non è possibile accedere a Dashboards e si desidera mappare un ruolo IAM da Amazon Cognito al ruoloall_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 } }
Suggerimento
Se si utilizza il database utente interno, è possibile utilizzare curl
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'
