Identity and Access Management in Amazon OpenSearch Service

Amazon OpenSearch Service offre diversi modi per controllare l'accesso ai tuoi domini. In questa sezione sono descritti i diversi tipi di policy, il modo in cui interagiscono tra loro ed è riportato come creare le policy personalizzate.

Importante

VPCil supporto introduce alcune considerazioni aggiuntive sul controllo degli accessi ai OpenSearch Servizi. Per ulteriori informazioni, consulta Informazioni sulle policy d'accesso nei domini VPC.

Tipi di policy

OpenSearch Il servizio supporta tre tipi di politiche di accesso:

• Policy basate su risorse

• Policy basate su identità

• Policy basate su IP

Policy basate su risorse

Quando si crea un dominio, viene aggiunta una policy basata su risorse, talvolta denominata policy di accesso al dominio. Queste policy specificano le operazioni che un principale può eseguire sulle risorse secondarie del dominio (con l'eccezione della ricerca tra cluster). Le sottorisorse includono OpenSearch indici e. APIs L'elemento Principal specifica l'account, gli utenti o i ruoli a cui è consentito l'accesso. L'elemento Resource specifica a quali risorse secondarie questi principali possono accedere.

Ad esempio, la seguente policy basata sulle risorse concede un accesso completo test-user (es:*) alle risorse secondarie in test-domain:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::123456789012:user/test-user"
        ]
      },
      "Action": [
        "es:*"
      ],
      "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*"
    }
  ]
}

Due considerazioni importanti si applicano a questa policy:

• Questi privilegi si applicano solo a questo dominio. A meno che non vengano create policy simili su altri domini, test-user può accedere solo a test-domain.

• I caratteri /* finali nell'elemento Resource sono significativi e indicano che le policy basate sulle risorse si applicano solo alle risorse secondarie del dominio e non al dominio stesso. Nelle policy basate sulle risorse, l'operazione es:* equivale a es:ESHttp*.

  Ad esempio, test-user può effettuare richieste su un indice (GET https://search-test-domain.us-west-1.es.amazonaws.com/test-index), ma non è in grado di aggiornare la configurazione del dominio (POST https://es.us-west-1.amazonaws.com/2021-01-01/opensearch/domain/test-domain/config). Nota la differenza tra i due endpoint. L'accesso alla configurazione API richiede una politica basata sull'identità.

È possibile specificare un nome di indice parziale aggiungendo un carattere jolly. Questo esempio identifica gli indici che iniziano con commerce:

arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce*

In questo caso, l'uso del carattere jolly significa che test-user può fare richieste agli indici nel dominio test-domain che hanno nomi che iniziano con commerce.

Per limitare ulteriormente test-user, è possibile applicare la seguente policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::123456789012:user/test-user"
        ]
      },
      "Action": [
        "es:ESHttpGet"
      ],
      "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce-data/_search"
    }
  ]
}

Ora test-user è in grado di eseguire un'unica operazione: effettua una ricerca sull'indice commerce-data. Tutti gli altri indici all'interno del dominio sono inaccessibili e senza le autorizzazioni necessarie per utilizzare le operazioni es:ESHttpPut o es:ESHttpPost, test-user non è in grado di aggiungere o modificare i documenti.

Quindi, è possibile decidere di configurare un ruolo per gli utenti avanzati. Questa politica consente power-user-role l'accesso ai PUT metodi HTTP GET e per tutti gli URIs elementi dell'indice:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::123456789012:role/power-user-role"
        ]
      },
      "Action": [
        "es:ESHttpGet",
        "es:ESHttpPut"
      ],
      "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce-data/*"
    }
  ]
}

Se il tuo dominio si trova in un VPC o utilizza un controllo di accesso granulare, puoi utilizzare una politica di accesso al dominio aperta. In caso contrario, la policy di accesso al dominio deve contenere alcune limitazioni, sia per principal che per indirizzo IP.

Per ulteriori informazioni su tutte le azioni disponibili, consultare Riferimenti agli elementi della policy. Per un controllo molto più dettagliato sui dati, utilizzare una policy di accesso al dominio aperto con il controllo granulare degli accessi.

Policy basate su identità

A differenza delle politiche basate sulle risorse, che fanno parte di ogni dominio di OpenSearch servizio, è possibile allegare politiche basate sull'identità agli utenti o ai ruoli utilizzando il servizio (). AWS Identity and Access Management IAM Proprio come le policy basate sulle risorse, le policy basate su identità specificano chi può accedere a un servizio, quali azioni può eseguire e, ove applicabile, le risorse su cui può eseguire tali operazioni.

Mentre le policy basate su identità tendono a essere più generiche. Spesso regolano solo le azioni di configurazione che un utente può eseguire. API Dopo aver implementato queste politiche, è possibile utilizzare le politiche basate sulle risorse (o il controllo granulare degli accessi) in OpenSearch Service per offrire agli utenti l'accesso agli indici e. OpenSearch APIs

Nota

Gli utenti con la AmazonOpenSearchServiceReadOnlyAccess policy AWS gestita non possono visualizzare lo stato di integrità del cluster sulla console. Per consentire loro di visualizzare lo stato di integrità del cluster (e altri OpenSearch dati), aggiungi l'es:ESHttpGetazione a una politica di accesso e allegala ai loro account o ruoli.

Poiché le politiche basate sull'identità si collegano a utenti o ruoli (responsabili), JSON non specifica un principale. La policy seguente consente di concedere l'accesso alle azioni che iniziano con Describe e List. Questa combinazione di azioni fornisce accesso in sola lettura alle configurazioni di dominio, ma non ai dati archiviati nel dominio:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "es:Describe*",
        "es:List*"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

Un amministratore potrebbe avere pieno accesso al OpenSearch servizio e a tutti i dati archiviati su tutti i domini:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "es:*"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

Le politiche basate sull'identità consentono di utilizzare i tag per controllare l'accesso alla configurazione. API La policy riportata di seguito, ad esempio, consente ai principal collegati di visualizzare e aggiornare la configurazione di un dominio se il dominio dispone del tag team:devops:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Action": [
      "es:UpdateDomainConfig",
      "es:DescribeDomain",
      "es:DescribeDomainConfig"
    ],
    "Effect": "Allow",
    "Resource": "*",
    "Condition": {
      "ForAnyValue:StringEquals": {
        "aws:ResourceTag/team": [
          "devops"
        ]
      }
    }
  }]
}

È inoltre possibile utilizzare i tag per controllare l'accesso a. OpenSearch API Le politiche basate sui tag si applicano OpenSearch API solo ai HTTP metodi. Ad esempio, la seguente politica consente ai principali allegati di inviare GET e PUT richiedere OpenSearch API se il dominio ha il environment:production tag:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Action": [
      "es:ESHttpGet",
      "es:ESHttpPut"
    ],
    "Effect": "Allow",
    "Resource": "*",
    "Condition": {
      "ForAnyValue:StringEquals": {
        "aws:ResourceTag/environment": [
          "production"
        ]
      }
    }
  }]
}

Per un controllo più granulare di OpenSearch API, prendi in considerazione l'utilizzo di un controllo granulare degli accessi.

Nota

Dopo averne aggiunto uno o più OpenSearch APIs a qualsiasi politica basata su tag, è necessario eseguire un'operazione su un singolo tag (ad esempio aggiungere, rimuovere o modificare un tag) affinché le modifiche abbiano effetto su un dominio. È necessario utilizzare il software di servizio R20211203 o versione successiva per includere OpenSearch API le operazioni nelle politiche basate su tag.

OpenSearch Il servizio supporta le chiavi RequestTag di condizione TagKeys globale per la configurazioneAPI, non la. OpenSearch API Queste condizioni si applicano solo alle API chiamate che includono tag all'interno della richiesta, ad esempio CreateDomainAddTags, eRemoveTags. La policy seguente consente ai principal collegati di creare domini, ma solo se includono il tag team:it nella richiesta:

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": [
      "es:CreateDomain",
      "es:AddTags"
    ],
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "aws:RequestTag/team": [
          "it"
        ]
      }
    }
  }
}

Per ulteriori dettagli sull'utilizzo dei tag per il controllo degli accessi e sulle differenze tra le politiche basate sulle risorse e quelle basate sull'identità, consulta la Guida per l'utente. IAM

Policy basate su IP

Le politiche basate su IP limitano l'accesso a un dominio a uno o più indirizzi IP o blocchi. CIDR Tecnicamente, le policy basate su IP non sono un tipo distinto di policy. Al contrario, sono solo policy basate sulle risorse che specificano un principale anonimo e includono un elemento Condition speciale.

La principale attrattiva delle politiche basate su IP è che consentono richieste non firmate a un dominio di OpenSearch servizio, il che consente di utilizzare client come curl e OpenSearch Dashboards o accedere al dominio tramite un server proxy. Per ulteriori informazioni, consulta Utilizzo di un proxy per accedere al servizio da dashboard OpenSearch OpenSearch .

Nota

Se hai abilitato VPC l'accesso per il tuo dominio, non puoi configurare una policy basata su IP. Invece è possibile utilizzare i gruppi di sicurezza per controllare gli indirizzi IP che possono accedere al dominio. Per ulteriori informazioni, consulta Informazioni sulle policy d'accesso nei domini VPC.

La seguente politica concede a tutte le HTTP richieste che provengono dall'intervallo IP specificato l'accesso a: test-domain

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": [
        "es:ESHttp*"
      ],
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "192.0.2.0/24"
          ]
        }
      },
      "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*"
    }
  ]
}

Se il tuo dominio ha un endpoint pubblico e non utilizza un controllo granulare degli accessi, ti consigliamo di combinare IAM i principali e gli indirizzi IP. Questa politica concede test-user HTTP l'accesso solo se la richiesta proviene dall'intervallo IP specificato:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": [
        "arn:aws:iam::987654321098:user/test-user"
      ]
    },
    "Action": [
      "es:ESHttp*"
    ],
    "Condition": {
      "IpAddress": {
        "aws:SourceIp": [
          "192.0.2.0/24"
        ]
      }
    },
    "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*"
  }]
}

Effettuazione e firma OpenSearch di richieste di servizio

Anche se si configura una politica di accesso completamente aperta basata sulle risorse, tutte le richieste di configurazione del OpenSearch Servizio API devono essere firmate. Se le politiche specificano IAM ruoli o utenti, OpenSearch APIs anche le richieste devono essere firmate utilizzando la versione 4 di AWS Signature. Il metodo di firma si differenzia perAPI:

• Per effettuare chiamate alla configurazione del OpenSearch servizioAPI, si consiglia di utilizzare uno dei AWS SDKs. Semplifica SDKs notevolmente il processo e consente di risparmiare una notevole quantità di tempo rispetto alla creazione e alla firma delle proprie richieste. Gli API endpoint di configurazione utilizzano il seguente formato:

  es.region.amazonaws.com/2021-01-01/

  Ad esempio, la seguente richiesta consente di apportare una modifica di configurazione al dominio movies, ma l'utente deve firmarla manualmente (scelta non consigliata):

  POST https://es.us-east-1.amazonaws.com/2021-01-01/opensearch/domain/movies/config
  {
    "ClusterConfig": {
      "InstanceType": "c5.xlarge.search"
    }
  }

  Se usi uno di questiSDKs, come Boto 3, gestisce SDK automaticamente la firma della richiesta:

  import boto3
  
  client = boto3.client(es)
  response = client.update_domain_config(
    DomainName='movies',
    ClusterConfig={
      'InstanceType': 'c5.xlarge.search'
    }
  )

  Per un esempio di codice Java, consulta Usando ilAWSSDK per interagire con AmazonOpenSearchServizio.

• Per effettuare chiamate verso OpenSearch APIs, è necessario firmare le proprie richieste. Quindi OpenSearch APIs usa il seguente formato:

  domain-id.region.es.amazonaws.com

  Ad esempio, la seguente richiesta esegue una ricerca nell'indice movies per thor:

  GET https://my-domain.us-east-1.es.amazonaws.com/movies/_search?q=thor

Nota

Il servizio ignora i parametri trasmessi URLs per HTTP POST le richieste firmate con Signature Version 4.

Quando le policy entrano in collisione

Sorgono problemi quando le policy dissentono o non effettuano alcuna menzione esplicita di un utente. La comprensione del IAM funzionamento nella Guida per l'IAMutente fornisce un riepilogo conciso della logica di valutazione delle politiche:

• Come impostazione predefinita, tutte le richieste vengono negate.

• Un permesso esplicito sostituisce questa impostazione di default.

• Un rifiuto esplicito sovrascrive tutti i consensi.

Ad esempio, se una politica basata sulle risorse ti concede l'accesso a una sottorisorsa di dominio (un OpenSearch indice oAPI), ma una politica basata sull'identità ti nega l'accesso, ti viene negato l'accesso. Se una policy basata sull'identità consente l'accesso e una policy basata sulle risorse non specifica se si dispone o meno dell'accesso, è consentito l'accesso. Consultare la seguente tabella di policy che si sovrappongono per un riepilogo dei risultati per le risorse secondarie del dominio.

	Consentito nella policy basata sulle risorse	Rifiutato nella policy basata sulle risorse	Non consentito né rifiutato nella policy basata sulle risorse
Allowed in identity-based policy	Consenso	Rifiuta	Consenso
Denied in identity-based policy	Rifiuta	Rifiuta	Rifiuta
Neither allowed nor denied in identity-based policy	Consenso	Rifiuta	Rifiuta

Riferimenti agli elementi della policy

OpenSearch Il servizio supporta la maggior parte degli elementi delle policy nel Policy Elements Reference, ad eccezione diIAM. NotPrincipal La tabella riportata di seguito mostra gli elementi più comuni.

JSONelemento politico	Riepilogo
Version	La versione corrente del linguaggio della policy è 2012-10-17. Tutte le policy d'accesso devono specificare questo valore.
Effect	L'elemento specifica se l'istruzione consente o nega l'accesso alle azioni specificate. I valori validi sono Allow e Deny.
Principal	Questo elemento specifica il IAM ruolo Account AWS o l'utente a cui è consentito o negato l'accesso a una risorsa e può assumere diverse forme: AWS account: "Principal":{"AWS": ["123456789012"]} o "Principal":{"AWS": ["arn:aws:iam::123456789012:root"]} IAMutenti: "Principal":{"AWS": ["arn:aws:iam::123456789012:user/test-user"]} IAMruoli: "Principal":{"AWS": ["arn:aws:iam::123456789012:role/test-role"]} Importante La specificazione del carattere * jolly consente l'accesso anonimo al dominio, operazione che sconsigliamo a meno che non si aggiunga una condizione basata su IP, non si utilizzi l'VPCassistenza o si abiliti il controllo granulare degli accessi. Inoltre, esamina attentamente le seguenti politiche per verificare che non garantiscano un accesso ampio: Politiche basate sull'identità associate ai AWS principali (ad esempio, ruoli) IAM Politiche basate sulle risorse allegate alle risorse associate AWS (ad esempio, chiavi) AWS Key Management Service KMS
Action	OpenSearch Il servizio utilizza ESHttp* azioni per i metodi. OpenSearch HTTP Il resto delle azioni si applica alla configurazioneAPI. Alcune azioni es: supportano le autorizzazioni a livello di risorsa. Ad esempio, è possibile assegnare a un utente autorizzazioni per eliminare un determinato dominio senza garantirgli le autorizzazioni per eliminare qualsiasi dominio. Altre azioni si applicano solo al servizio. Ad esempio, es:ListDomainNames non ha senso nel contesto di un singolo dominio e quindi richiede un carattere jolly. Per un elenco di tutte le azioni disponibili e se si applicano alle sottorisorse del dominio (test-domain/*), alla configurazione del dominio (test-domain) o solo al servizio (*), consulta Azioni, risorse e chiavi di condizione per Amazon OpenSearch Service nel Service Authorization Reference Le policy basate sulle risorse differiscono dalle autorizzazioni a livello di risorsa. Le politiche basate sulle risorse sono JSON politiche complete che si collegano ai domini. Le autorizzazioni a livello di risorsa consentono di limitare le azioni a particolari domini o risorse secondarie. In pratica, si possono considerare le autorizzazioni a livello di risorsa una parte opzionale di una policy basata sulle risorse o sull'identità. Mentre le autorizzazioni a livello di risorsa per es:CreateDomain potrebbero sembrare poco intuitive (dopo tutto, perché offrire a un utente le autorizzazioni per creare un dominio già esistente?) l'uso di un carattere jolly consente di implementare uno schema di denominazione semplice per i domini, ad esempio "Resource": "arn:aws:es:us-west-1:987654321098:domain/my-team-name-*". Naturalmente, è ugualmente possibile includere azioni insieme a elementi di risorse meno restrittivi, come i seguenti: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "es:ESHttpGet", "es:DescribeDomain" ], "Resource": "*" } ] } Per ulteriori informazioni sull'accoppiamento di azioni e risorse, fare riferimento all'elemento Resource in questa tabella.
Condition	OpenSearch Il servizio supporta la maggior parte delle condizioni descritte nelle chiavi di contesto delle condizioni AWS globali nella Guida per l'utente. IAM Le eccezioni più importanti includono la aws:PrincipalTag chiave, che OpenSearch Service non supporta. Quando si configura una politica basata su IP, si specificano gli indirizzi IP o il CIDR blocco come condizione, ad esempio: "Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/32" ] } } Come indicato inPolicy basate su identità, i tasti aws:ResourceTagaws:RequestTag, e aws:TagKeys condition si applicano sia alla configurazione API che a. OpenSearch APIs
Resource	OpenSearch Il servizio utilizza Resource gli elementi in tre modi fondamentali: Per azioni che si applicano al OpenSearch Servizio stessoes:ListDomainNames, come o per consentire l'accesso completo, usa la seguente sintassi: "Resource": "*" Per le azioni che implicano una configurazione del dominio, ad esempio es:DescribeDomain, è possibile utilizzare la sintassi seguente: "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name" Per le azioni che si applicano alle risorse secondarie di un dominio, ad esempio es:ESHttpGet, è possibile utilizzare la sintassi seguente: "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/*" Non è necessario utilizzare un jolly. OpenSearch Il servizio consente di definire una politica di accesso diversa per ogni OpenSearch indice oAPI. Ad esempio, è possibile limitare le autorizzazioni di un utente per l'indice test-index: "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/test-index" Invece dell'accesso completo atest-index, potresti preferire limitare la politica alla sola ricercaAPI: "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/test-index/_search" È possibile anche controllare l'accesso ai singoli documenti: "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/test-index/test-type/1" In sostanza, se OpenSearch esprime la sottorisorsa come unaURI, è possibile controllarne l'accesso utilizzando una politica di accesso. Per un controllo ancora maggiore sulle risorse a cui un utente può accedere, vedere Controllo granulare degli accessi in Amazon Service OpenSearch . Per ulteriori informazioni su quali azioni supportano le autorizzazioni a livello di risorsa, fare riferimento all'elemento Action in questa tabella.

Opzioni e considerazioni avanzate API

OpenSearch Il servizio ha diverse opzioni avanzate, una delle quali ha implicazioni sul controllo degli accessi:rest.action.multi.allow_explicit_index. Con l'impostazione predefinita true, consente agli utenti di ignorare le autorizzazioni a livello di risorsa secondaria in determinate circostanze.

Ad esempio, considerare la seguente policy basata sulle risorse:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::123456789012:user/test-user"
        ]
      },
      "Action": [
        "es:ESHttp*"
      ],
      "Resource": [
        "arn:aws:es:us-west-1:987654321098:domain/test-domain/test-index/*",
        "arn:aws:es:us-west-1:987654321098:domain/test-domain/_bulk"
      ]
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::123456789012:user/test-user"
        ]
      },
      "Action": [
        "es:ESHttpGet"
      ],
      "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/restricted-index/*"
    }
  ]
}

Questa politica garantisce l'accesso test-user completo test-index e alla OpenSearch maggior API parte. Consente inoltre GET le richieste a restricted-index.

La seguente richiesta di indicizzazione, come è prevedibile, ha esito negativo a causa di un errore delle autorizzazioni:

PUT https://search-test-domain.us-west-1.es.amazonaws.com/restricted-index/movie/1
{
  "title": "Your Name",
  "director": "Makoto Shinkai",
  "year": "2016"
}

A differenza dell'indiceAPI, la modalità collettiva API consente di creare, aggiornare ed eliminare molti documenti in un'unica chiamata. Tuttavia, spesso si specificano queste operazioni nel corpo della richiesta, anziché nella richiestaURL. Poiché OpenSearch Service utilizza URLs per controllare l'accesso alle sottorisorse del dominio, test-user può, in effetti, utilizzarne la massa API per apportare modifiche a. restricted-index Anche se l'utente non dispone di autorizzazioni POST per l'indice, la seguente richiesta ha esito positivo:

POST https://search-test-domain.us-west-1.es.amazonaws.com/_bulk
{ "index" : { "_index": "restricted-index", "_type" : "movie", "_id" : "1" } }
{ "title": "Your Name", "director": "Makoto Shinkai", "year": "2016" }

In questo caso, la policy d'accesso non riesce a soddisfare i suoi intenti. Per impedire agli utenti di aggirare questi tipi di restrizioni, è possibile modificare rest.action.multi.allow_explicit_index in false. Se questo valore è falso, tutte le chiamate a bulk, mget e msearch APIs che specificano i nomi degli indici nel corpo della richiesta smettono di funzionare. In altre parole, le chiamate a _bulk non funzionano, ma le chiamate a test-index/_bulk sì. Questo secondo endpoint contiene un nome dell'indice, perciò non è necessario specificarne uno nel corpo nella richiesta.

OpenSearch Le dashboard si basano molto su mget e msearch, quindi è improbabile che funzionino correttamente dopo questa modifica. Per una correzione parziale, puoi lasciare impostato rest.action.multi.allow_explicit_index come true e negare a determinati utenti l'accesso a uno o più di questi. APIs

Per informazioni su come modificare questa impostazione, consultare Impostazioni avanzate del cluster.

Analogamente, la seguente policy basata sulle risorse contiene due problemi di lieve entità:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/test-user"
      },
      "Action": "es:ESHttp*",
      "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*"
    },
    {
      "Effect": "Deny",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/test-user"
      },
      "Action": "es:ESHttp*",
      "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/restricted-index/*"
    }
  ]
}

• Nonostante il rifiuto esplicito, test-user può comunque effettuare chiamate come GET https://search-test-domain.us-west-1.es.amazonaws.com/_all/_search e GET https://search-test-domain.us-west-1.es.amazonaws.com/*/_search per accedere ai documenti in restricted-index.

• Poiché l'elemento Resource fa riferimento a restricted-index/*, test-user non dispone delle autorizzazioni per accedere direttamente ai documenti dell'indice. L'utente, tuttavia, dispone delle autorizzazioni necessarie per eliminare l'intero indice. Per prevenire l'accesso e l'eliminazione, la policy deve specificare restricted-index*.

Anziché combinare permessi ampi e negazioni strette, la soluzione più sicura è seguire il principio del privilegio minimo e concedere solo le autorizzazioni necessarie per eseguire un'operazione. Per ulteriori informazioni sul controllo dell'accesso a singoli indici o OpenSearch operazioni, vedere. Controllo granulare degli accessi in Amazon Service OpenSearch

Importante

Specificando il carattere jolly * si abilita l'accesso anonimo al dominio. Non è consigliabile utilizzare la jolly. Inoltre, esamina attentamente le seguenti politiche per verificare che non garantiscano un accesso ampio:

• Politiche basate sull'identità associate ai AWS principali associati (ad esempio, ruoli) IAM

• Politiche basate sulle risorse allegate alle risorse associate AWS (ad esempio, chiavi) AWS Key Management Service KMS

Configurazione delle policy di accesso

• Per istruzioni sulla creazione o la modifica di politiche basate su risorse e IP in Service, vedere. OpenSearch Configurazione delle policy di accesso

• Per istruzioni su come creare o modificare le politiche basate sull'identità inIAM, vedere Creazione IAM di politiche nella Guida per l'utente. IAM

Altre policy di esempio

Sebbene questo capitolo includa molti esempi di policy, il controllo degli AWS accessi è un argomento complesso che può essere compreso meglio attraverso esempi. Per ulteriori informazioni, consulta Esempi di politiche IAM basate sull'identità nella Guida per l'IAMutente.