Fine-grained controllo degli accessi in Amazon OpenSearch Service

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

Fine-grained il controllo degli accessi offre i seguenti vantaggi:

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

La sicurezza di Amazon OpenSearch Service ha tre livelli principali:

Il diagramma seguente illustra una configurazione comune: un dominio di accesso VPC con controllo degli accessi granulare abilitato, una policy di accesso e un IAM-based utente master 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

Quando inizi a usare un controllo granulare degli accessi, considera i seguenti concetti:

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:

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:

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.

Fine-grained il controllo degli accessi richiede Elasticsearch OpenSearch 6.7 o versione successiva. Richiedere inoltre HTTPS per tutto il traffico verso il dominio, Crittografia dei dati a riposo, e crittografia da nodo a nodo. 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

La modifica attiva una blue/green distribuzione durante la quale lo stato del cluster diventa rosso, 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

Fine-grained il controllo degli accessi richiede la 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 assicura che gli utenti possano ancora inviare correttamente le richieste IAM-signed GET e PUT finché non crei le tue mappature dei ruoli.

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:

Accesso ai OpenSearch dashboard come utente principale

Fine-grained access control dispone di 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.

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.

Fine-grained il controllo degli accessi include anche una serie di 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:

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

Cluster-level sicurezza

Cluster-level le autorizzazioni includono la possibilità di effettuare richieste generiche come_mget, e_msearch, monitorare lo stato_bulk, scattare istantanee 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 azione a livello di cluster, consulta. Cluster-level

Index-level sicurezza

Index-level le autorizzazioni includono la possibilità di creare nuovi indici, cercare indici, 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 azioni a livello di indice, consulta. Index-level

Document-level sicurezza

Document-level la sicurezza consente di limitare i documenti di un indice che un utente può visualizzare. Quando create un ruolo, specificate un modello di indice e una OpenSearch query. Tutti gli utenti mappati a quel ruolo possono vedere solo i documenti che corrispondono alla query. Document-level la sicurezza influisce sul numero di risultati che ricevi durante la ricerca.

Per ulteriori informazioni, consulta la sezione Document-level sicurezza.

Field-level sicurezza

Field-level la sicurezza consente di controllare quali campi del documento un utente può visualizzare. 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 escludi dei campi, possono vedere tutti i campi tranne quelli esclusi. Field-levella sicurezza influisce sul numero di campi inclusi nei risultati durante la ricerca.

Per ulteriori informazioni, consulta la sezione Field-level sicurezza.

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.

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ù importante del controllo granulare degli accessi. Fine-grainedil controllo degli accessi ha alcuni ruoli predefiniti per aiutarti a iniziare, ma a meno che non mappi i ruoli agli utenti, ogni richiesta al cluster termina con un errore di autorizzazione.

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.

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

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.

Limitazioni

Fine-grained il controllo degli accessi presenta diverse limitazioni importanti:

Modifica dell'utente principale

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

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.

Snapshot manuali

Fine-grained il controllo degli accessi introduce alcune complicazioni aggiuntive legate all'acquisizione di istantanee 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 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 (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.

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'