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 **Topics** + [Il quadro generale: controllo granulare degli accessi e sicurezza dei servizi OpenSearch](#fgac-access-policies) + [Concetti chiave](#fgac-concepts) + [Informazioni sull'utente principale](#fgac-master-user) + [Abilitazione del controllo granulare degli accessi](#fgac-enabling) + [Accesso alle OpenSearch dashboard come utente principale](#fgac-dashboards) + [Gestione delle autorizzazioni](#fgac-access-control) + [Configurazioni consigliate](#fgac-recommendations) + [Limitazioni](#fgac-limitations) + [Modifica dell'utente principale](#fgac-forget) + [Utenti principali aggiuntivi](#fgac-more-masters) + [Snapshot manuali](#fgac-snapshots) + [Integrazioni](#fgac-integrations) + [Differenze della REST API](#fgac-rest-api) + [Tutorial: configurazione di un dominio con un utente master IAM e autenticazione Amazon Cognito](fgac-iam.md) + [Tutorial: Configurare un dominio con il database utente interno e l'autenticazione di base HTTP](fgac-http-auth.md) ## 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 sceglie**Accesso 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](vpc.md). **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](ac.md#ac-types-resource) 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. ![\[Flusso di autorizzazione del controllo granulare degli accessi con un dominio VPC\]](http://docs.aws.amazon.com/it_it/opensearch-service/latest/developerguide/images/fgac-vpc-iam.png) 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\]](http://docs.aws.amazon.com/it_it/opensearch-service/latest/developerguide/images/fgac-public-basic.png) ### 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](https://opensearch.org/docs/latest/security/) 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](#fgac-more-masters). 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](https://opensearch.org/docs/latest/security/access-control/permissions/) 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](https://curl.haxx.se/), che supporta anche la versione 4 di AWS Signature con l'[opzione --aws-sigv4](https://curl.se/docs/manpage.html). 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](createupdatedomains.md). 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](encryption-at-rest.md). node-to-node ](ntn.md) 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**. 1. True per abilitare il **controllo granulare degli accessi**. 1. 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**. 1. (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](ac.md#ac-types-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](#fgac-access-control) 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. 1. Scegliere **Save changes** (Salva modifiche). Il cambiamento innesca una [implementazione blu/verde](managedomains-configuration-changes.md#bg) 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](#fgac-mapping). Se il tuo dominio utilizza [politiche di accesso basate sull'identità](ac.md#ac-types-identity), OpenSearch Service associa automaticamente gli utenti a un nuovo ruolo chiamato **default\$1role** 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\$1role](#fgac-enabling-defaultrole)** in modo che possano continuare ad accedere al dominio. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/opensearch-service/latest/developerguide/fgac.html) | | 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. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/opensearch-service/latest/developerguide/fgac.html) | | 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. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/opensearch-service/latest/developerguide/fgac.html) | ## 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](cognito-auth.md) per accedere a Dashboards. Altrimenti, Dashboards mostra una pagina di accesso non funzionale. Per informazioni, consultare [Limitazioni](#fgac-limitations). 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](cognito-auth.md#cognito-auth-granular) e [Tutorial: configurazione di un dominio con un utente master IAM e autenticazione Amazon Cognito](fgac-iam.md). ![\[Pagina di accesso di Cognito\]](http://docs.aws.amazon.com/it_it/opensearch-service/latest/developerguide/images/cognito-auth.png) + 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](fgac-http-auth.md). ![\[Pagina di accesso all'autenticazione di base\]](http://docs.aws.amazon.com/it_it/opensearch-service/latest/developerguide/images/basic-auth-dashboards.png) + 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](saml.md). ## Gestione delle autorizzazioni Come indicato in [Concetti chiave](#fgac-concepts), è 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](#fgac-dashboards). ![\[Home page di sicurezza in Dashboards\]](http://docs.aws.amazon.com/it_it/opensearch-service/latest/developerguide/images/dashboards-fgac-home.png) **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](https://en.wikipedia.org/wiki/Principle_of_least_privilege) 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](https://opensearch.org/docs/latest/security/access-control/users-roles/#create-roles). Il controllo granulare degli accessi include anche numerosi [ruoli predefiniti](https://opensearch.org/docs/latest/security/access-control/users-roles/#predefined-roles). 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](#fgac-mapping) 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](https://opensearch.org/docs/latest/security/access-control/permissions/#cluster-permissions). 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](https://opensearch.org/docs/latest/security/access-control/default-action-groups/#cluster-level). #### 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](https://opensearch.org/docs/latest/security/access-control/permissions/#index-permissions). 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](https://opensearch.org/docs/latest/security/access-control/default-action-groups/#index-level). #### 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](#fgac-example). Per ulteriori informazioni, consultare [Sicurezza a livello di documento](https://opensearch.org/docs/latest/security/access-control/document-level-security/). #### 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](#fgac-example). Per ulteriori informazioni, consultare [Sicurezza a livello di campo](https://opensearch.org/docs/latest/security/access-control/field-level-security/). #### 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](#fgac-example). **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/_security`operazione nell'API REST. Per ulteriori informazioni, consultare [Creazione di utenti](https://opensearch.org/docs/latest/security/access-control/users-roles/#create-users). 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/). ### 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**. ![\[Schermata di associazione dei ruoli\]](http://docs.aws.amazon.com/it_it/opensearch-service/latest/developerguide/images/role-mapping-edit.png) Puoi mappare i ruoli agli utenti utilizzando OpenSearch le dashboard o l'`_plugins/_security`operazione nell'API REST. Per ulteriori informazioni, consultare [Mappa utenti ai ruoli](https://opensearch.org/docs/latest/security/access-control/users-roles/#map-users-to-roles). ### 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/_security`operazione 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](https://opensearch.org/docs/latest/security/access-control/default-action-groups/). ### 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 ](https://opensearch.org/docs/latest/security/multi-tenancy/tenant-index/) **Per visualizzare il tenant corrente o modificare i tenant** 1. Vai alle OpenSearch dashboard e accedi. 1. Seleziona l'icona utente in alto a destra e sceglie **Cambia tenant**. 1. 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_template`indice, 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](#fgac-access-policies), consigliamo diverse configurazioni di controllo granulare degli accessi che funzionano bene per la maggior parte dei casi d'uso. | Description | 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.](saml.md) Gestire i ruoli del controllo granulare degli accessi utilizzando Dashboards o la REST API. | Utente o ruolo IAM | JSON **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/*" } ] } ``` | | 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 disponi di OpenSearch client che supportano solo l'autenticazione di base. Se si dispone di un provider di identità esistente, utilizzare [Autenticazione SAML](saml.md) per accedere a Dashboards. In caso contrario, gestire gli utenti di Dashboards nel database interno degli utenti. | Nome utente e password | JSON **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/*" } ] } ``` | | 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 | JSON **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/*" } ] } ``` | | 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 | JSON **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/*" }, { "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/_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](sql-support.md) 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](indexing.md#indexing-naming). 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_count` causa 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](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/direct-query-s3-creating.html#direct-query-s3-prereq) 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 a [https://console.aws.amazon.com/aos/casa/](https://console.aws.amazon.com/aos/home/). 1. Seleziona il dominio e scegli **Actions** (Operazioni) quindi **Edit security configuration** (Modifica configurazione di sicurezza). 1. 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. 1. 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_access` e `security_manager`. ![\[Pagina del mapping dei ruoli\]](http://docs.aws.amazon.com/it_it/opensearch-service/latest/developerguide/images/new-master-users.png) + 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](managedomains-snapshots.md#managedomains-snapshot-prerequisites). Utilizzare quindi il ruolo IAM per inviare una richiesta firmata al dominio, come descritto in [Registrazione di un repository di snapshot manuali](managedomains-snapshot-registerdirectory.md). ## Integrazioni Se utilizzi [altri AWS servizi](integrations.md) 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](#fgac-roles) e [mappare il ruolo IAM a tale ruolo](#fgac-mapping). 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 di controllo degli accessi a grana fine 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"] } ``` Su OpenSearch Elasticsearch 7.x, le richieste hanno questo aspetto (modificale 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 (da modificare se si utilizza 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.](https://opensearch.org/docs/latest/security/access-control/api/) **Suggerimento** Se si utilizza il database utente interno, è possibile utilizzare [curl](https://curl.haxx.se/) 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' ``` # Tutorial: configurazione di un dominio con un utente master IAM e autenticazione Amazon Cognito Questo tutorial illustra un popolare caso d'uso di Amazon OpenSearch Service per il [controllo granulare degli accessi](fgac.md): un utente master IAM con autenticazione Amazon Cognito for Dashboards. OpenSearch Nel tutorial configureremo un ruolo IAM *master* e un ruolo IAM *limitato*, che poi assoceremo agli utenti in Amazon Cognito. L'utente master può quindi accedere a OpenSearch Dashboards, mappare l'utente limitato a un ruolo e utilizzare un controllo granulare degli accessi per limitare le autorizzazioni dell'utente. ![\[IAM roles and Amazon Cognito integration with OpenSearch Dashboards access control.\]](http://docs.aws.amazon.com/it_it/opensearch-service/latest/developerguide/images/fgac-cognito.png) Sebbene questi passaggi utilizzino il bacino d'utenza di Amazon Cognito per l'autenticazione, questo stesso processo di base funziona per qualsiasi provider di autenticazione Cognito che consente di assegnare ruoli IAM differenti a utenti diversi. In questo tutorial completerai le seguenti fasi: 1. [Creazione di ruoli IAM master e limitati](#fgac-iam-roles) 1. [Creazione di un dominio con l'autenticazione Cognito](#fgac-iam-domain) 1. [Configurare un pool di utenti e un pool di identità di Cognito](#fgac-iam-cognito) 1. [Mappa i ruoli nelle dashboard OpenSearch ](#fgac-iam-dashboards) 1. [Test delle autorizzazioni](#fgac-iam-test) ## Fase1: Creazione di ruoli IAM master e limitati Passa alla console AWS Identity and Access Management (IAM) e crea due ruoli separati: + `MasterUserRole` - L'utente master, che disporrà di autorizzazioni complete per il cluster e gestirà ruoli e mappature dei ruoli. + `LimitedUserRole` - Un ruolo più limitato, a cui come utente master concederai un accesso limitato. Per istruzioni su come creare i ruoli, consulta [Creazione di un ruolo utilizzando policy di fiducia personalizzate](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html) nella *Guida per l'utente IAM*. Entrambi i ruoli devono disporre della seguente policy di attendibilità che consente al pool di identità Cognito di assumere i ruoli: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "Federated": "cognito-identity.amazonaws.com" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "cognito-identity.amazonaws.com:aud": "{identity-pool-id}" }, "ForAnyValue:StringLike": { "cognito-identity.amazonaws.com:amr": "authenticated" } } }] } ``` ------ **Nota** Sostituzione di `identity-pool-id` con l'identificatore univoco del pool di identità Amazon Cognito. Ad esempio, `us-east-1:0c6cdba7-3c3c-443b-a958-fb9feb207aa6`. ## Fase 2: Creazione di un dominio con l'autenticazione Cognito Accedi alla console di Amazon OpenSearch Service a [https://console.aws.amazon.com/aos/casa/](https://console.aws.amazon.com/aos/home/) e [crea un dominio](createupdatedomains.md) con le seguenti impostazioni: + OpenSearch 1.0 o versione successiva oppure Elasticsearch 7.8 o versione successiva + Accesso pubblico + Controllo granulare degli accessi abilitato con `MasterUserRole` come utente master (creato nella fase precedente) + Autenticazione Amazon Cognito abilitata per le OpenSearch dashboard. Per le istruzioni sull'abilitazione dell'autenticazione Cognito e la selezione di un pool di utenti e identità, consulta [Configurazione di un dominio per l'uso dell'autenticazione Amazon Cognito](cognito-auth.md#cognito-auth-config). + La seguente policy di accesso al dominio: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, "Action": [ "es:ESHttp*" ], "Resource": "arn:aws:es:us-east-1:111122223333:domain/{domain-name}/*" } ] } ``` ------ + HTTPS richiesto per tutto il traffico verso il dominio + Node-to-node crittografia + Crittografia dei dati a riposo ## Fase 3: Configurazione degli utenti di Cognito Durante la creazione del dominio, configura gli utenti master e limitati all'interno di Amazon Cognito seguendo la procedura [Crea un pool di utenti](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html) nella *Amazon Cognito* Developer Guide. Infine, configura il tuo pool di identità seguendo i passaggi descritti in [Creare un pool di identità in Amazon](https://docs.aws.amazon.com/cognito/latest/developerguide/getting-started-with-identity-pools.html#create-identity-pool) Cognito. Il bacino d'utenza e il pool di identità devono trovarsi nella stessa Regione AWS. ## Fase 4: Mappa i ruoli nelle dashboard OpenSearch Ora che gli utenti sono configurati, puoi accedere a OpenSearch Dashboards come utente principale e mappare gli utenti ai ruoli. 1. Torna alla console di OpenSearch servizio e vai all'URL delle OpenSearch dashboard per il dominio che hai creato. L'URL segue il seguente formato: `domain-endpoint/_dashboards/`. 1. Accedere con le credenziali `master-user`. 1. Scegliere **Add sample data** (Aggiungi dati di esempio) e aggiungere alcuni dati di volo di esempio. 1. Nel pannello di navigazione a sinistra, seleziona **Security** (Sicurezza), **Roles** (Ruoli) e **Create role** (Crea ruolo). 1. Denomina il ruolo `new-role`. 1. Per **Index** (Indice), specificare `opensearch_dashboards_sample_data_fli*` (`kibana_sample_data_fli*` sui domini Elasticsearch). 1. Per **Index permissions** (Autorizzazioni relative all'indice), scegliere **read** (lettura). 1. Per **Sicurezza a livello di documento**, specificare la seguente query: ``` { "match": { "FlightDelay": true } } ``` 1. Per la sicurezza a livello di campo, scegliere **Escludi** e specificare `FlightNum`. 1. Per **Anonimizzazione**, specificare `Dest`. 1. Scegliere **Create (Crea) **. 1. Scegliere **Utenti mappati**, **Gestisci mappatura**. Aggiungere il nome della risorsa Amazon (ARN) per `LimitedUserRole` come identità esterna e scegliere **Map** (Mappa). 1. Torna all'elenco di ruoli e scegli **opensearch\$1dashboards\$1user**. Scegliere **Utenti mappati**, **Gestisci mappatura**. Aggiungere l'ARN per `LimitedUserRole` come ruolo di back-end e scegliere **Mappa**. ## Fase 5: Test delle autorizzazioni Quando i ruoli sono mappati correttamente, puoi accedere come utente limitato e testare le autorizzazioni. 1. In una nuova finestra privata del browser, vai all'URL della OpenSearch dashboard per il dominio, accedi utilizzando le `limited-user` credenziali e scegli **Esplora** da solo. 1. Scegliere **Strumenti di sviluppo** ed eseguire la ricerca predefinita: ``` GET _search { "query": { "match_all": {} } } ``` Notare l'errore di autorizzazioni. `limited-user` non dispone delle autorizzazioni per eseguire ricerche a livello di cluster. 1. Esegui un'altra ricerca: ``` GET opensearch_dashboards_sample_data_flights/_search { "query": { "match_all": {} } } ``` Si noti che tutti i documenti corrispondenti hanno un campo `FlightDelay` di `true`, un campo `Dest` anonimizzato e nessun campo `FlightNum`. 1. Nella finestra del browser originale, accedere come `master-user`, scegliere **Strumenti di sviluppo**, e quindi eseguire le stesse ricerche. Nota la differenza tra autorizzazioni, numero di hit, documenti corrispondenti e campi inclusi. # Tutorial: Configurare un dominio con il database utente interno e l'autenticazione di base HTTP Questo tutorial tratta un altro popolare caso d'uso del [controllo granulare degli accessi](fgac.md): un utente principale nel database utenti interno e l'autenticazione di base HTTP per le dashboard. OpenSearch L'utente master può quindi accedere alle OpenSearch dashboard, creare un utente interno, mappare l'utente a un ruolo e utilizzare un controllo granulare degli accessi per limitare le autorizzazioni dell'utente. In questo tutorial completerai le seguenti fasi: 1. [Crea un dominio con un utente principale](#fgac-http-auth-domain) 1. [Configura un utente interno nei OpenSearch pannelli di controllo](#fgac-http-auth-dashboards-user) 1. [Mappa i ruoli nelle dashboard OpenSearch ](#fgac-http-auth-dashboards-map) 1. [Test delle autorizzazioni](#fgac-http-auth-test) ## Fase 1: Creazione di un dominio Accedi alla console di Amazon OpenSearch Service a [https://console.aws.amazon.com/aos/casa/](https://console.aws.amazon.com/aos/home/) e [crea un dominio](createupdatedomains.md) con le seguenti impostazioni: + OpenSearch 1.0 o versione successiva oppure Elasticsearch 7.9 o versione successiva + Accesso pubblico + Controllo granulare degli accessi con un utente principale nel database utente interno (`TheMasterUser` per il resto di questo tutorial) + Autenticazione Amazon Cognito per Dashboards *disabilitata* + La seguente policy di accesso: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, "Action": [ "es:ESHttp*" ], "Resource": "arn:aws:es:us-east-1:111122223333:domain/{domain-name}/*" } ] } ``` ------ + HTTPS richiesto per tutto il traffico verso il dominio + Node-to-node crittografia + Crittografia dei dati a riposo ## Fase 2: Creare un utente interno nei OpenSearch pannelli di controllo Ora che hai un dominio, puoi accedere alle OpenSearch dashboard e creare un utente interno. 1. Torna alla console di OpenSearch servizio e vai all'URL delle OpenSearch dashboard per il dominio che hai creato. L'URL segue il seguente formato: `domain-endpoint/_dashboards/`. 1. Accedi con. `TheMasterUser` 1. Scegliere **Add sample data** (Aggiungi dati di esempio) e aggiungere alcuni dati di volo di esempio. 1. Nel riquadro di navigazione a sinistra, scegli **Sicurezza**, **Utenti interni**, **Crea utente interno**. 1. Denominare l'utente `new-user` e specificare una password. Quindi, scegli **Create (Crea)**. ## Passaggio 3: mappare i ruoli nelle OpenSearch dashboard Ora che l'utente è configurato, puoi mappare l'utente a un ruolo. 1. Resta nella sezione **Sicurezza** delle OpenSearch dashboard e scegli **Ruoli**, **Crea ruolo**. 1. Denomina il ruolo `new-role`. 1. Per **Index**, specifica `opensearch_dashboards_sample_data_fli*` (`kibana_sample_data_fli*`sui domini Elasticsearch) il modello di indice. 1. Per il gruppo di operazioni, scegliere **read**. 1. Per **Sicurezza a livello di documento**, specificare la seguente query: ``` { "match": { "FlightDelay": true } } ``` 1. Per la sicurezza a livello di campo, scegliere **Escludi** e specificare `FlightNum`. 1. Per **Anonimizzazione**, specificare `Dest`. 1. Scegliere **Create (Crea) **. 1. Scegliere **Utenti mappati**, **Gestisci mappatura**. Quindi aggiungere `new-user` a **Utenti** e scegliere **Mappa**. 1. Torna all'elenco di ruoli e scegli **opensearch\$1dashboards\$1user**. Scegliere **Utenti mappati**, **Gestisci mappatura**. Quindi aggiungere `new-user` a **Utenti** e scegliere **Mappa**. ## Passaggio 4: Verifica le autorizzazioni Quando i ruoli sono mappati correttamente, puoi accedere come utente limitato e testare le autorizzazioni. 1. In una nuova finestra privata del browser, vai all'URL della OpenSearch dashboard per il dominio, accedi utilizzando le `new-user` credenziali e scegli **Esplora** da solo. 1. Scegliere **Strumenti di sviluppo** ed eseguire la ricerca predefinita: ``` GET _search { "query": { "match_all": {} } } ``` Notare l'errore di autorizzazioni. `new-user` non dispone delle autorizzazioni per eseguire ricerche a livello di cluster. 1. Esegui un'altra ricerca: ``` GET dashboards_sample_data_flights/_search { "query": { "match_all": {} } } ``` Si noti che tutti i documenti corrispondenti hanno un campo `FlightDelay` di `true`, un campo `Dest` anonimizzato e nessun campo `FlightNum`. 1. Nella finestra del browser originale, accedere come `TheMasterUser`, scegliere **Strumenti di sviluppo** ed eseguire le stesse ricerche. Nota la differenza tra autorizzazioni, numero di hit, documenti corrispondenti e campi inclusi.