Tipi di policy Creazione e firma di richieste OpenSearch Service Quando le policy entrano in collisione Riferimenti agli elementi della policy Opzioni avanzate e considerazioni sulle API Configurazione delle policy di accesso Altre policy di esempio

Gestione di accessi e identità nel servizio OpenSearch di Amazon

Il servizio OpenSearch di Amazon offre diversi modi per controllare l'accesso ai 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

Il supporto per VPC introduce alcune considerazioni aggiuntive per il controllo degli accessi di OpenSearch Service. Per ulteriori informazioni, consultare Informazioni sulle policy d'accesso nei domini VPC.

Tipi di policy

OpenSearch Service supporta tre tipi di policy 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 risorse secondarie includono gli indici e le API OpenSearch. 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.

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 all'API di configurazione richiede una policy basata su identità.

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


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

In questo caso, specificare l'uso di questo 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 policy fornisce l'accesso power-user-role ai metodi HTTP GET e PUT per tutti gli URI nell'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 dominio si trova in un VPC o utilizza un controllo granulare degli accessi, è possibile usare una policy di accesso al dominio aperto. 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 policy basate su risorse, che fanno parte di ogni dominio OpenSearch Service, è possibile collegare le policy basate su 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 regolamentano solo le operazioni delle API di configurazione che possono essere eseguite da un utente. Dopo aver impostato queste policy, è possibile usare policy basate sulle risorse (o controllo granulare degli accessi) in OpenSearch Service per offrire agli utenti accesso a indici e API di OpenSearch.

Nota

Gli utenti con la policy AmazonOpenSearchServiceReadOnlyAccess gestita da AWS non possono visualizzare lo stato di integrità del cluster nella console. Per consentire agli utenti di visualizzare lo stato di integrità del cluster (e altri dati OpenSearch), aggiunge l'operazione es:ESHttpGet a una policy di accesso e collegala ai relativi account o ruoli.

Poiché le policy basate su identità si collegano a utenti o ruoli (principali), il formato 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 può avere accesso completo a OpenSearch Service e a tutti i dati archiviati su tutti i domini:


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

Le policy basate sull'identità consentono di utilizzare i tag per controllare l'accesso all'API di configurazione. 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"
        ]
      }
    }
  }]
}

È possibile utilizzare i tag anche per controllare l'accesso alle API OpenSearch. Le policy basate su tag per l'API OpenSearch si applicano solo ai metodi HTTP. Ad esempio, la seguente policy consente ai principali collegati di inviare richieste GET e PUT all'API OpenSearch se il dominio ha il tag environment:production:


{
  "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 dell'API OpenSearch, prendere in considerazione l'utilizzo del controllo granulare degli accessi.

Nota

Dopo aver aggiunto una o più API OpenSearch a qualunque policy basata su tag, è necessario eseguire una singola operazione tag (ad esempio l'aggiunta, la rimozione o la modifica di un tag) per applicare le modifiche su un dominio. Per includere operazioni dell'API OpenSearch nelle policy basate sui tag, è necessario utilizzare il software di servizio R20211203 o versioni successive.

Il servizio OpenSearch supporta le chiavi di condizione globali RequestTag e TagKeys per l'API di configurazione, non per l'API OpenSearch. Queste condizioni si applicano solo alle chiamate API che includono tag all'interno della richiesta, ad esempio CreateDomain, AddTags e RemoveTags. 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 maggiori dettagli sull'utilizzo dei tag per il controllo degli accessi e sulle differenze tra policy basate sulle risorse e policy basate su identità, consultare la Guida per l'utente IAM.

Policy basate su IP

Le policy 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 caratteristica delle policy basate su IP è che consentono richieste non firmate a un dominio OpenSearch Service, il che permette di usare client come curl e OpenSearch Dashboards o accedere al dominio tramite un server proxy. Per ulteriori informazioni, consultare Utilizzo di un proxy per accedere a OpenSearch Service da Dashboards.

Nota

Se è stato abilitato l'accesso VPC al dominio, non è possibile 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, consultare Informazioni sulle policy d'accesso nei domini VPC.

La seguente policy concede a tutte le richieste HTTP che provengono dall'intervallo di 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 dominio dispone di un endpoint pubblico e non utilizza il controllo granulare degli accessi, è consigliabile combinare le entità IAM e gli indirizzi IP. Questa policy concede l'accesso HTTP test-user 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/*"
  }]
}

Creazione e firma di richieste OpenSearch Service

Anche se è possibile configurare una policy di accesso basata su una risorsa completamente aperta, tutte le richieste all'API di configurazione di OpenSearch Service devono essere firmate. Se la policy specifica gli utenti o i ruoli IAM, le richieste alle API OpenSearch devono essere firmate anche con AWS Signature Version 4. Il metodo della firma differisce in base alle API:

Per effettuare chiamate all'API di configurazione di OpenSearch Service, consigliamo di usare uno degli SDK AWS. Gli SDK semplificano enormemente il processo e permettono di risparmiare molto tempo rispetto alla creazione e alla firma delle richieste. Gli endpoint dell'API 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 utilizzi uno degli SDK, ad esempio Boto 3, questo gestisce 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 Uso degli SDK AWS per interagire con Amazon OpenSearch Service.
Per effettuare chiamate alle API OpenSearch, è necessario firmare le richieste. Per un codice di esempio in diversi linguaggi, vedi Firma di richieste HTTP in Amazon OpenSearch Service. Le API OpenSearch utilizzano 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 passati negli URL per le richieste HTTP POST che sono 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. Introduzione al funzionamento di IAM nella Guida per l'utente IAM fornisce un riepilogo conciso della logica di valutazione delle policy:

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 policy basata sulle risorse concede l'accesso a una risorsa secondaria del dominio (un indice o un'API OpenSearch), ma una policy basata sull'identità lo rifiuta, l'accesso verrà negato. 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	Deny	Allow
Denied in identity-based policy	Deny	Deny	Deny
Neither allowed nor denied in identity-based policy	Allow	Deny	Deny

Riferimenti agli elementi della policy

OpenSearch Service supporta la maggior parte degli elementi di policy riportati in Riferimento agli elementi della policy IAM, ad eccezione di NotPrincipal. La tabella riportata di seguito mostra gli elementi più comuni.

Elemento della policy JSON	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 l'Account AWS o l'utente o ruolo IAM a cui è consentito o negato l'accesso a una risorsa e può assumere diverse forme: Account AWS: `"Principal":{"AWS": ["123456789012"]}` o `"Principal":{"AWS": ["arn:aws:iam::123456789012:root"]}` Utenti IAM: `"Principal":{"AWS": ["arn:aws:iam::123456789012:user/test-user"]}` Ruoli IAM: `"Principal":{"AWS": ["arn:aws:iam::123456789012:role/test-role"]}` La specifica del carattere jolly `*` consente l'accesso anonimo al dominio, che non è consigliabile a meno che non si aggiunga una condizione basata su IP, non si usi il supporto VPC o non si abiliti il controllo granulare degli accessi.
`Action`	Il servizio OpenSearch utilizza le azioni seguenti per i metodi HTTP di OpenSearch: `es:ESHttpDelete` `es:ESHttpGet` `es:ESHttpHead` `es:ESHttpPost` `es:ESHttpPut` `es:ESHttpPatch` OpenSearch Service utilizza le seguenti operazioni per l'API di configurazione. Tenere presente che alcune operazioni sono state dichiarate come obsolete e sono state sostituite con nomi indipendenti dal motore. `es:AcceptInboundConnection` `es:AddTags` `es:AssociatePackage` `es:CancelServiceSoftwareUpdate` `es:CreateOutboundConnection` `es:CreateDomain` `es:CreatePackage` `es:CreateServiceRole` `es:DeleteDomain` `es:DeleteInboundConnection` `es:DeleteOutboundConnection` `es:DeletePackage` `es:DescribeDomain` `es:DescribeDomains` `es:DescribeDomainAutoTunes` `es:DescribeDomainConfig` `es:DescribeInboundConnections` `es:DescribeInstanceTypeLimits` `es:DescribeOutboundConnections` `es:DescribePackages` `es:DescribeReservedInstanceOfferings` `es:DescribeReservedInstances` `es:DissociatePackage` `es:ESCrossClusterGet` `es:GetCompatibleVersions` `es:GetPackageVersionHistory` `es:GetUpgradeHistory` `es:GetUpgradeStatus` `es:ListDomainNames` `es:ListDomainsForPackage` `es:ListInstanceTypeDetails` `es:ListInstanceTypes` `es:ListNotifications` `es:ListPackagesForDomain` `es:ListVersions` `es:ListTags` `es:PurchaseReservedInstanceOffering` `es:RemoveTags` `es:RejectInboundConnection` `es:StartServiceSoftwareUpdate` `es:UpdateDomainConfig` `es:UpdateNotificationStatus` `es:UpdatePackage` `es:UpgradeDomain` Suggerimento È possibile utilizzare i caratteri jolly per specificare un sottoinsieme di azioni, come `"Action":"es:"` o `"Action":"es:Describe"`. 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. Importante Le policy basate sulle risorse differiscono dalle autorizzazioni a livello di risorsa. Le policy basate sulle risorse sono policy JSON 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à. La seguente policy basata sull'identità elenca tutte le azioni `es:` e le raggruppa in base al fatto che si applicano alle risorse secondarie del dominio (`test-domain/`), alla configurazione del dominio (`test-domain`) oppure solo al servizio (``): { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "es:ESHttpDelete", "es:ESHttpGet", "es:ESHttpHead", "es:ESHttpPost", "es:ESHttpPut", "es:ESHttpPatch" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/" }, { "Effect": "Allow", "Action": [ "es:AddTags", "es:AssociatePackage", "es:CreateDomain", "es:CreateOutboundConnection", "es:DeleteDomain", "es:DescribeDomain", "es:DescribeDomainAutoTunes", "es:DescribeDomainConfig", "es:DescribeDomains", "es:DissociatePackage", "es:ESCrossClusterGet", "es:GetCompatibleVersions", "es:GetUpgradeHistory", "es:GetUpgradeStatus", "es:ListPackagesForDomain", "es:ListTags", "es:RemoveTags", "es:StartServiceSoftwareUpdate", "es:UpdateDomainConfig", "es:UpdateNotificationStatus", "es:UpgradeDomain" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain" }, { "Effect": "Allow", "Action": [ "es:AcceptInboundConnection", "es:CancelServiceSoftwareUpdate", "es:CreatePackage", "es:CreateServiceRole", "es:DeletePackage", "es:DescribeInboundConnections", "es:DescribeInstanceTypeLimits", "es:DescribeOutboundConnections", "es:DescribePackages", "es:DescribeReservedInstanceOfferings", "es:DescribeReservedInstances", "es:GetPackageVersionHistory", "es:ListDomainNames", "es:ListDomainsForPackage", "es:ListInstanceTypeDetails", "es:ListInstanceTypes", "es:ListNotifications", "es:ListVersions", "es:PurchaseReservedInstanceOffering", "es:RejectInboundConnection", "es:UpdatePackage" ], "Resource": "" } ] } Nota 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 Service supporta la maggior parte delle condizioni descritte in Chiavi di contesto delle condizioni globali di AWS nella Guida per l'utente IAM. Le eccezioni da considerare includono le chiavi `aws:SecureTransport` e `aws:PrincipalTag`, che non sono supportate da OpenSearch Service. Durante la configurazione di una policy basata su IP, è necessario specificare gli indirizzi IP o i blocchi CIDR come condizione, come ad esempio: `"Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/32" ] } }` Come riportato in Policy basate su identità, le chiavi di condizione `aws:ResourceTag`, `aws:RequestTag` e `aws:TagKeys` si applicano all'API di configurazione e alle API OpenSearch.
`Resource`	OpenSearch Service utilizza gli elementi `Resource` in tre modalità di base: Per le operazioni che si applicano a OpenSearch Service, come `es:ListDomainNames`, oppure per consentire l'accesso completo, utilizzare la sintassi seguente: `"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 carattere jolly. OpenSearch Service consente di definire una policy di accesso diverso per ogni indice o API OpenSearch. 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 a `test-index`, è preferibile limitare la policy all'API di ricerca: `"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"` Essenzialmente, se OpenSearch esprime la risorsa secondaria come URI, è possibile controllare l'accesso a esso utilizzando una policy di accesso. Per un controllo ancora maggiore sulle risorse a cui un utente può accedere, vedere Controllo granulare degli accessi nel servizio OpenSearch di Amazon. Per ulteriori informazioni su quali azioni supportano le autorizzazioni a livello di risorsa, fare riferimento all'elemento `Action` in questa tabella.

Opzioni avanzate e considerazioni sulle API

OpenSearch Service offre 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 policy concede l'accesso completo test-user a test-index e all'API bulk OpenSearch. 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'API dell'indice, l'API bulk consente la creazione, l'aggiornamento e l'eliminazione di molti documenti in una sola chiamata. Tuttavia spesso si specificano queste operazioni nel corpo della richiesta, anziché nell'URL della richiesta. Poiché OpenSearch Service usa gli URL per controllare l'accesso alle risorse secondarie del dominio, test-user può, infatti, utilizzare l'API bulk 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 è false, tutte le chiamate alle API bulk, mget, e msearch 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 Dashboards si avvale principalmente di mget e msearch, perciò è improbabile che funzioni correttamente dopo questa modifica. Per la correzione parziale, è possibile lasciare rest.action.multi.allow_explicit_index come true e negare a determinati utenti l'accesso a una o più di queste API.

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 alle operazioni OpenSearch, consultare Controllo granulare degli accessi nel servizio OpenSearch di Amazon.

Configurazione delle policy di accesso

Per istruzioni su come creare o modificare le policy basate sulle risorse e su IP in OpenSearch Service, consultare Configurazione delle policy di accesso.
Per istruzioni su come creare o modificare le policy basate sull'identità in IAM, consultare Creazione di policy IAM nella Guida per l'utente IAM.

Altre policy di esempio

Sebbene questo capitolo includa molte policy di esempio, il controllo degli accessi AWS è un tema complesso che è più semplice comprendere tramite esempi. Per ulteriori informazioni, consultare Esempi di policy IAM basate su identità nella Guida per l'utente di IAM.

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

Crittografia da nodo a nodo

Policy gestite da AWS