Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Identity and Access Management in Amazon OpenSearch Service Amazon OpenSearch Service bietet verschiedene Möglichkeiten, den Zugriff auf Ihre Domains zu kontrollieren. Dieses Thema geht auf die verschiedenen Richtlinientypen, deren Interaktion miteinander und die Erstellung eigener, benutzerdefinierter Richtlinien ein. **Wichtig** Die VPC-Unterstützung führt zu einigen zusätzlichen Überlegungen zur OpenSearch Dienstzugriffskontrolle. Weitere Informationen finden Sie unter [Zugriffsrichtlinien für VPC-Domänen](vpc.md#vpc-security). ## Arten von Richtlinien OpenSearch Der Service unterstützt drei Arten von Zugriffsrichtlinien: + [Ressourcenbasierte Richtlinien](#ac-types-resource) + [Identitätsbasierte Richtlinien](#ac-types-identity) + [IP-basierte Richtlinien](#ac-types-ip) ### Ressourcenbasierte Richtlinien Beim Erstellen einer Domain fügen Sie eine ressourcenbasierte Richtlinie hinzu, die oft als Domain-Zugriffsrichtlinie bezeichnet wird. Diese Richtlinien legen fest, welche Aktionen ein Prinzipal auf den *Subressourcen* der Domain durchführen kann (mit Ausnahme der [clusterübergreifenden Suche](cross-cluster-search.md#cross-cluster-search-walkthrough)). Zu den Unterressourcen gehören OpenSearch Indizes und. APIs Das JSON-Richtlinienelement „[Principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)“ in IAM spezifiziert die Konten, Benutzer oder Rollen, denen Zugriff gewährt wird. Das JSON-Richtlinienelement [Resource](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_resource.html) gibt an, auf welche Unterressourcen diese Prinzipale zugreifen können. Beispielsweise gewährt die folgende ressourcenbasierte Richtlinie `test-user` vollen Zugriff (`es:*`) auf die Unterressourcen auf `test-domain`: ------ #### [ JSON ] **** ``` { "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/*" } ] } ``` ------ Zwei wichtige Überlegungen treffen auf diese Richtlinie zu: + Diese Berechtigungen gelten nur für diese Domain. Sofern Sie keine ähnlichen Richtlinien auf anderen Domains erstellen, kann `test-user` nur auf `test-domain` zugreifen. + Das nachgestellte `/*` im `Resource`-Element ist wichtig und weist darauf hin, dass ressourcenbasierte Richtlinien nur für die Unterressourcen der Domain gelten, nicht für die Domain selbst. In ressourcenbasierten Richtlinien entspricht die `es:*`-Aktion `es:ESHttp*`. Beispielsweise kann `test-user` zwar Anforderungen an einen Index (`GET https://search-test-domain.us-west-1.es.amazonaws.com/test-index`) richten, aber nicht die Konfiguration der Domain (`POST https://es.us-west-1.amazonaws.com/2021-01-01/opensearch/domain/test-domain/config`) aktualisieren. Beachten Sie den Unterschied zwischen den beiden Endpunkten. [Für den Zugriff auf die Konfigurations-API ist eine identitätsbasierte Richtlinie erforderlich.](#ac-types-identity) Sie können einen partiellen Indexnamen angeben, indem Sie einen Platzhalter hinzufügen. Dieses Beispiel identifiziert alle Indizes, die mit `commerce` beginnen: ``` arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce* ``` In diesem Fall bedeutet der Platzhalter, dass `test-user` Anfragen an Indizes innerhalb von `test-domain` stellen kann, deren Namen mit `commerce` beginnen. Um `test-user` weiter einzuschränken, können Sie die folgende Richtlinie anwenden: ------ #### [ JSON ] **** ``` { "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" } ] } ``` ------ Nun kann `test-user` nur noch eine Operation durchführen: die Suche nach dem Index `commerce-data`. Auf alle anderen Indizes innerhalb der Domain kann nicht zugegriffen werden, und ohne die Berechtigung, die Aktionen `es:ESHttpPut` oder `es:ESHttpPost` zu verwenden, kann `test-user` keine Dokumente hinzufügen oder ändern. Als nächstes möchten Sie vielleicht eine Rolle für Hauptbenutzer konfigurieren. Diese Richtlinie gewährt `power-user-role` Zugriff auf die HTTP-GET- und PUT-Methoden für alle URIs im Index: ------ #### [ JSON ] **** ``` { "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/*" } ] } ``` ------ Wenn sich Ihre Domain in einer VPC befindet oder eine differenzierte Zugriffssteuerung verwendet, können Sie eine offene Domain-Zugriffsrichtlinie verwenden. Andernfalls muss Ihre Domain-Zugriffsrichtlinie eine Einschränkung enthalten, entweder nach Prinzipal oder IP-Adresse. Weitere Informationen zu allen verfügbaren Aktionen finden Sie unter [Richtlinienelementreferenz](#ac-reference). Für eine weitaus detailliertere Kontrolle über Ihre Daten verwenden Sie eine offene Domain-Zugriffsrichtlinie mit [differenzierte Zugriffssteuerung](fgac.md). ### Identitätsbasierte Richtlinien Im Gegensatz zu ressourcenbasierten Richtlinien, die Teil jeder OpenSearch Dienstdomäne sind, hängen Sie identitätsbasierte Richtlinien an Benutzer oder Rollen an, die den AWS Identity and Access Management (IAM-) Dienst verwenden. Genauso wie [ressourcenbasierte Richtlinien](#ac-types-resource) legen identitätsbasierte Richtlinien fest, welche Personen auf einen Service zugreifen können, welche Aktionen sie ausführen können und, sofern zutreffend, für welche Ressourcen sie diese Aktionen ausführen können. Identitätsbasierte Richtlinien sind in der Regel allgemeiner, dies muss aber nicht unbedingt so sein. Sie regeln oft nur die Konfigurations-API-Aktionen, die ein Benutzer durchführen darf. Sobald Sie diese Richtlinien eingerichtet haben, können Sie ressourcenbasierte Richtlinien (oder eine [differenzierte Zugriffskontrolle) in OpenSearch Service verwenden, um Benutzern Zugriff auf Indizes](fgac.md) und zu gewähren. OpenSearch APIs **Anmerkung** Benutzer mit der AWS verwalteten `AmazonOpenSearchServiceReadOnlyAccess` Richtlinie können den Cluster-Integritätsstatus auf der Konsole nicht sehen. Damit sie den Cluster-Integritätsstatus (und andere OpenSearch Daten) sehen können, fügen Sie die `es:ESHttpGet` Aktion einer Zugriffsrichtlinie hinzu und fügen Sie sie ihren Konten oder Rollen hinzu. Da identitätsbasierte Richtlinien an Benutzer oder Rollen (Prinzipale) angefügt werden, gibt JSON keinen Prinzipal an. Die folgende Richtlinie gewährt Zugriff auf Aktionen, die mit `Describe` und `List` beginnen. Diese Kombination von Aktionen bietet schreibgeschützten Zugriff auf Domain-Konfigurationen, jedoch nicht direkt auf die in der Domain gespeicherten Daten: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "es:Describe*", "es:List*" ], "Effect": "Allow", "Resource": "*" } ] } ``` ------ Ein Administrator hat möglicherweise vollen Zugriff auf den OpenSearch Dienst und alle in allen Domänen gespeicherten Daten: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "es:*" ], "Effect": "Allow", "Resource": "*" } ] } ``` ------ Mit identitätsbasierten Richtlinien können Sie Tags verwenden, um den Zugriff auf die Konfigurations-API zu steuern. Die folgende Richtlinie ermöglicht es beispielsweise angehängten Prinzipalen, die Konfiguration einer Domain anzuzeigen und zu aktualisieren, wenn die Domain über das Tag `team:devops` verfügt: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Action": [ "es:UpdateDomainConfig", "es:DescribeDomain", "es:DescribeDomainConfig" ], "Effect": "Allow", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:ResourceTag/team": [ "devops" ] } } }] } ``` ------ Sie können auch Tags verwenden, um den Zugriff auf die OpenSearch API zu kontrollieren. Tag-basierte Richtlinien für die OpenSearch API gelten nur für HTTP-Methoden. Mit der folgenden Richtlinie können beispielsweise angehängte Principals GET- und PUT-Anfragen an die OpenSearch API senden, wenn die Domain über das `environment:production` Tag verfügt: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Action": [ "es:ESHttpGet", "es:ESHttpPut" ], "Effect": "Allow", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:ResourceTag/environment": [ "production" ] } } }] } ``` ------ Für eine detailliertere Steuerung der OpenSearch API sollten Sie eine [differenzierte](fgac.md) Zugriffskontrolle in Betracht ziehen. **Anmerkung** Nachdem Sie einer Tag-basierten Richtlinie eine oder mehrere OpenSearch APIs hinzugefügt haben, müssen Sie eine einzelne [Tag-Operation](managedomains-awsresourcetagging.md) durchführen (z. B. ein Tag hinzufügen, entfernen oder ändern), damit die Änderungen für eine Domain wirksam werden. Sie müssen die Servicesoftware R20211203 oder höher verwenden, um OpenSearch API-Operationen in tagbasierte Richtlinien aufnehmen zu können. OpenSearch Der Service unterstützt die `RequestTag` und die `TagKeys` globalen Bedingungsschlüssel für die Konfigurations-API, nicht für die API. OpenSearch Diese Bedingungen gelten nur für API-Aufrufe, die Tags in der Anfrage enthalten, z. B. `CreateDomain`, `AddTags` und `RemoveTags`. Mit der folgenden Richtlinie können angehängte Prinzipale Domains erstellen, jedoch nur, wenn sie das `team:it`-Tag in die Anfrage aufnehmen: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "es:CreateDomain", "es:AddTags" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/team": [ "it" ] } } } } ``` ------ *Weitere Informationen zur Verwendung von Tags für die Zugriffskontrolle und zu den Unterschieden zwischen ressourcenbasierten und identitätsbasierten Richtlinien finden Sie unter [Definieren von Berechtigungen auf der Grundlage von Attributen mit ABAC-Autorisierung](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) im IAM-Benutzerhandbuch.* ### IP-basierte Richtlinien IP-basierte Richtlinien beschränken den Zugriff auf eine Domain auf eine oder mehrere IP-Adressen oder CIDR-Blöcke. Aus technischer Sicht sind IP-basierte Richtlinien kein eigener Richtlinientyp. Stattdessen handelt es sich lediglich um ressourcenbasierte Richtlinien, die einen anonymen Prinzipal spezifizieren und eine spezielle Bedingung enthalten. Weitere Informationen finden Sie unter [IAM-JSON-Richtlinienelemente: Bedingung](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) im *IAM-Benutzerhandbuch*. Der Hauptvorteil IP-basierter Richtlinien besteht darin, dass sie unsignierte Anfragen an eine OpenSearch Service-Domain zulassen, sodass Sie Clients wie [Curl](https://curl.haxx.se/) und [OpenSearch Dashboards](dashboards.md) verwenden oder über einen Proxyserver auf die Domain zugreifen können. Weitere Informationen hierzu finden Sie unter [Verwenden eines Proxys für den Zugriff auf den Service über Dashboards OpenSearch](dashboards.md#dashboards-proxy). **Anmerkung** Wenn für die Domain VPC-Zugriff aktiviert wurde, können Sie keine IP-basierte Richtlinie konfigurieren. Stattdessen können Sie `security groups` damit steuern, welche IP-Adressen auf die Domain zugreifen können. Weitere Informationen finden Sie unter den folgenden Themen: [Zugriffsrichtlinien für VPC-Domänen](vpc.md#vpc-security) [Steuern Sie den Datenverkehr zu Ihren AWS Ressourcen mithilfe von Sicherheitsgruppen](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) im *Amazon VPC-Benutzerhandbuch* Die folgende Richtlinie gewährt allen HTTP-Anforderungen, die vom angegebenen IP-Bereich stammen, den Zugriff auf `test-domain`: ------ #### [ JSON ] **** ``` { "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/*" } ] } ``` ------ Wenn Ihre Domain über einen öffentlichen Endpunkt verfügt und keine [differenzierte Zugriffssteuerung](fgac.md) verwendet, empfehlen wir, IAM-Prinzipale und IP-Adressen zu kombinieren. Diese Richtlinie gewährt `test-user` HTTP-Zugriff nur, wenn die Anforderung aus dem angegebenen IP-Bereich stammt: ------ #### [ JSON ] **** ``` { "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/*" }] } ``` ------ ## Konflikte in Richtlinien Komplexitäten entstehen, wenn Richtlinien einander widersprechen oder den Benutzer nicht explizit erwähnen. [So funktioniert IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/intro-structure.html) Im *IAM-Benutzerhandbuch finden* Sie eine kurze Zusammenfassung der Bewertungslogik von Richtlinien: + Standardmäßig werden alle Anforderungen verweigert. + Dieser Standardwert kann durch eine explizite Zugriffserlaubnis überschrieben werden. + Eine explizite Zugriffsverweigerung überschreibt jedwede Zugriffserlaubnis. Wenn Ihnen beispielsweise eine ressourcenbasierte Richtlinie Zugriff auf eine Domain-Unterressource (einen OpenSearch Index oder eine API) gewährt, Ihnen aber eine identitätsbasierte Richtlinie den Zugriff verweigert, wird Ihnen der Zugriff verweigert. Wenn eine identitätsbasierte Richtlinien den Zugriff gewährt, eine ressourcenbasierte Richtlinie aber nicht festlegt, ob Ihnen Zugriff gewährt werden soll oder ob nicht, wird Ihnen der Zugriff gewährt. In der folgenden Tabelle sich überschneidender Richtlinien finden Sie eine vollständige Übersicht der Ergebnisse für Domains-Subressourcen. **** | | Zugelassen in ressourcenbasierter Richtlinie | Verweigert in ressourcenbasierter Richtlinie | Weder zugelassen noch verweigert in ressourcenbasierter Richtlinie | | --- |--- |--- |--- | | **Allowed in identity-based policy** | Sobald Sie die Details auf dieser Seite überprüft haben, klicken Sie auf | Deny | Sobald Sie die Details auf dieser Seite überprüft haben, klicken Sie auf | | --- |--- |--- |--- | | **Denied in identity-based policy** | Deny | Deny | Deny | | --- |--- |--- |--- | | **Neither allowed nor denied in identity-based policy** | Sobald Sie die Details auf dieser Seite überprüft haben, klicken Sie auf | Deny | Deny | | --- |--- |--- |--- | ## Richtlinienelementreferenz OpenSearch Der Service unterstützt die meisten Richtlinienelemente in der [IAM-Referenz für Richtlinienelemente](https://docs.aws.amazon.com/IAM/latest/UserGuide/AccessPolicyLanguage_ElementDescriptions.html), mit Ausnahme von. `NotPrincipal` Die folgende Tabelle zeigt die gängigsten Elemente. **** | JSON-Richtlinienelement | Zusammenfassung | | --- | --- | | Version | Die aktuelle Version der Richtliniensprache ist `2012-10-17`. Alle vordefinierten Zugriffsrichtlinien sollten diesen Wert angeben. | | Effect | Dieses Element legt fest, ob die Anweisung den Zugriff auf die angegebenen Aktionen zulässt oder verweigert. Gültige Werte sind `Allow` oder `Deny`. | | Principal | Dieses Element gibt die AWS-Konto oder die IAM-Rolle oder den Benutzer an, dem der Zugriff auf eine Ressource gewährt oder verweigert wird. Es kann verschiedene Formen annehmen: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/ac.html) Durch die Angabe des Platzhalters `*` wird der anonyme Zugriff auf die Domain ermöglicht. Dies wird nur empfohlen, wenn Sie eine [IP-basierte Bedingung](#ac-types-ip) hinzufügen, [VPC-Support](vpc.md) verwenden oder eine [feinkörnige Zugriffssteuerung](fgac.md) aktivieren. Prüfen Sie außerdem sorgfältig die folgenden Richtlinien, um sicherzustellen, dass sie keinen breiten Zugang gewähren: Identitätsbasierte Richtlinien, die mit zugehörigen AWS -Prinzipalen verknüpft sind (z. B. IAM-Rollen) Ressourcenbasierte Richtlinien, die mit zugehörigen AWS Ressourcen verknüpft sind (z. B. AWS Key Management Service KMS-Schlüssel) | | Action | OpenSearch Der Dienst verwendet `ESHttp*` Aktionen für OpenSearch HTTP-Methoden. Die restlichen Aktionen gelten für die Konfigurations-API.Bestimmte `es:`-Aktionen unterstützen Berechtigungen auf Ressourcenebene. Sie können einem Benutzer z. B. Berechtigungen zum Löschen einer bestimmten Domain erteilen, ohne ihn zum Löschen *beliebiger* Domains zu berechtigen. Andere Aktionen gelten nur für den Service selbst. `es:ListDomainNames` ist im Kontext einer einzelnen Domain ohne Bedeutung und benötigt folglich einen Platzhalter.Eine Liste aller verfügbaren Aktionen und ob sie für die Domain-Subressourcen (`test-domain/*`), für die Domain-Konfiguration () oder nur für den Service (`test-domain``*`) gelten, finden Sie unter [Aktionen, Ressourcen und Bedingungsschlüssel für Amazon OpenSearch Service in der Service Authorization](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonopensearchservice.html) *Reference*Ressourcenbasierte Richtlinien unterscheiden sich von Berechtigungen auf Ressourcenebene. [Ressourcenbasierte Richtlinien](#ac-types-resource) sind vollständige JSON-Richtlinien, die an Domains angefügt werden. Mithilfe von Berechtigungen auf Ressourcenebene können Sie Aktionen auf bestimmte Domains oder Unterressourcen einschränken. In der Praxis können Sie sich Berechtigungen auf Ressourcenebene als optionaler Teil einer ressourcen- oder identitätsbasierten Richtlinien vorstellen.Während Berechtigungen auf Ressourcenebene für `es:CreateDomain` nicht allzu sinnvoll erscheinen – denn warum sollte man einem Benutzer Berechtigungen zum Erstellen einer Domain gewähren, die bereits vorhanden ist? – können Sie mithilfe eines Platzhalters ein einfaches Benennungsschema für Ihre Domains (z. B. `"Resource": "arn:aws:es:us-west-1:987654321098:domain/my-team-name-*"`) erzwingen.Natürlich kann nichts Sie daran hindern, Aktionen zusammen mit weniger restriktiven Ressourcen einzuschließen, wie z. B. die folgenden Elemente: JSON **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "es:ESHttpGet", "es:DescribeDomain" ], "Resource": "*" } ] } ``` Weitere Informationen zum Kombinieren von Aktionen mit Ressourcen finden Sie unter dem Element `Resource` in dieser Tabelle. | | Condition | OpenSearch Der Service unterstützt die meisten Bedingungen, die im *IAM-Benutzerhandbuch* unter den [Kontextschlüsseln für AWS globale Bedingungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#AvailableKeys) beschrieben sind. Zu den nennenswerten Ausnahmen gehört der `aws:PrincipalTag` Schlüssel, den der OpenSearch Service nicht unterstützt. Bei der Konfiguration einer [IP-basierten Richtlinien](#ac-types-ip) geben Sie die IP-Adressen oder den CIDR-Block als Bedingung an, wie im folgenden Beispiel: 
"Condition": {
  "IpAddress": {
    "aws:SourceIp": [
      "192.0.2.0/32"
    ]
  }
}
Wie unter erwähnt[Identitätsbasierte Richtlinien](#ac-types-identity), gelten die Bedingungsschlüssel `aws:ResourceTag``aws:RequestTag`, und die `aws:TagKeys` Bedingungsschlüssel sowohl für die Konfigurations-API als auch für die OpenSearch APIs. | | Resource | OpenSearch Der Service verwendet `Resource` Elemente auf drei grundlegende Arten: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/ac.html) Weitere Informationen dazu, welche Aktionen Berechtigungen auf Ressourcenebene unterstützten, finden Sie unter dem Element `Action` in dieser Tabelle. | ## Erweiterte Optionen und Überlegungen zur API OpenSearch Der Dienst verfügt über mehrere erweiterte Optionen, von denen eine Auswirkungen auf die Zugriffskontrolle hat:. `rest.action.multi.allow_explicit_index` Bei ihrer Standardeinstellung „true" können Benutzer Unterressourcen-Berechtigungen unter bestimmten Bedingungen umgehen. Beachten Sie beispielsweise die folgende ressourcenbasierte Richtlinie: ------ #### [ JSON ] **** ``` { "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/*" } ] } ``` ------ Diese Richtlinie gewährt `test-user` vollen Zugriff auf `test-index` und die OpenSearch Bulk-API. Außerdem ermöglicht sie `GET`-Anforderungen an `restricted-index`. Wie zu erwarten, schlägt die folgende Indizierungsanforderung aufgrund eines Berechtigungsfehlers fehl: ``` PUT https://search-test-domain.us-west-1.es.amazonaws.com/restricted-index/movie/1 { "title": "Your Name", "director": "Makoto Shinkai", "year": "2016" } ``` Im Gegensatz zur Index-API ermöglicht Ihnen die Massen-API, in einem einzelnen Aufruf viele Dokumente zu erstellen, zu aktualisieren und zu löschen. Sie geben diese Operationen jedoch oft im Anforderungstext anstatt in der Anforderungs-URL an. Da OpenSearch Service URLs den Zugriff auf Domain-Subressourcen steuert, `test-user` kann er tatsächlich die Bulk-API verwenden, um Änderungen daran vorzunehmen. `restricted-index` Auch wenn der Benutzer über keine `POST`-Berechtigungen für den Index verfügt, ist die folgende Anforderung **erfolgreich**: ``` 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 diesem Fall funktioniert die Zugriffsrichtlinie nicht wie beabsichtigt. Um Benutzer daran zu hindern, diese Arten von Einschränkungen zu umgehen, können Sie `rest.action.multi.allow_explicit_index` in „false" ändern. Wenn dieser Wert falsch ist, funktionieren alle Aufrufe von bulk, mget und msearch, die Indexnamen im Hauptteil der Anfrage angeben APIs , nicht mehr. Mit anderen Worten: Aufrufe an `_bulk` funktionieren nicht mehr, aber Aufrufe an `test-index/_bulk` sind hiervon nicht betroffen. Da dieser zweite Endpunkt einen Indexnamen enthält, müssen Sie im Anforderungstext keinen angeben. [OpenSearch Dashboards](dashboards.md) sind stark von mget und msearch abhängig, weshalb es nach dieser Änderung unwahrscheinlich ist, dass es ordnungsgemäß funktioniert. Bei teilweiser Korrektur können Sie den Wert auf „true“ `rest.action.multi.allow_explicit_index` belassen und bestimmten Benutzern den Zugriff auf eine oder mehrere dieser Optionen verweigern. APIs Weitere Informationen zum Ändern dieser Einstellung finden Sie unter [Erweiterte Clustereinstellungen](createupdatedomains.md#createdomain-configure-advanced-options). Dementsprechend enthalt die folgende ressourcenbasierte Richtlinie zwei geringfügige Probleme: ------ #### [ JSON ] **** ``` { "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/*" } ] } ``` ------ + Trotz der expliziten Verweigerung kann `test-user` weiterhin Aufrufe wie `GET https://search-test-domain.us-west-1.es.amazonaws.com/_all/_search` und `GET https://search-test-domain.us-west-1.es.amazonaws.com/*/_search` für den Zugriff auf die Dokumente in `restricted-index` ausführen. + Da das `Resource`-Element auf `restricted-index/*` verweist, ist `test-user` nicht zum direkten Zugriff auf die Dokumente des Index berechtigt. Der Benutzer verfügt jedoch über Berechtigungen zum *Löschen des gesamten Index*. Damit der Zugriff und das Löschen verhindert werden, muss die Richtlinie stattdessen `restricted-index*` angeben. Anstatt großzügige Berechtigungen und gezielte Verweigerungen miteinander zu mischen, ist eine sicherere Strategie, der Regel der [geringsten Rechte](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) zu folgen und nur die Berechtigungen zu gewähren, die zum Ausführen einer Aufgabe erforderlich sind. Weitere Informationen zur Steuerung des Zugriffs auf einzelne Indizes oder OpenSearch Operationen finden Sie unter. [Feinkörnige Zugriffskontrolle in Amazon Service OpenSearch](fgac.md) **Wichtig** Die Angabe des Platzhalters\$1 ermöglicht den anonymen Zugriff auf Ihre Domain. Es wird nicht empfohlen, den Platzhalter zu verwenden. Überprüfen Sie außerdem sorgfältig die folgenden Richtlinien, um sicherzustellen, dass sie keinen umfassenden Zugriff gewähren: Identitätsbasierte Richtlinien, die mit zugehörigen AWS Prinzipalen verknüpft sind (z. B. IAM-Rollen) Ressourcenbasierte Richtlinien, die mit zugehörigen AWS Ressourcen verknüpft sind (z. B. KMS-Schlüssel) AWS Key Management Service ## Konfigurieren von Zugriffsrichtlinien + Anweisungen zum Erstellen oder Ändern von ressourcen- und IP-basierten Richtlinien in OpenSearch Service finden Sie unter. [Konfigurieren von Zugriffsrichtlinien](createupdatedomains.md#createdomain-configure-access-policies) + *Anweisungen zum Erstellen oder Ändern identitätsbasierter Richtlinien in IAM finden Sie im IAM-Benutzerhandbuch unter [Definieren benutzerdefinierter IAM-Berechtigungen mit vom Kunden verwalteten Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html).* ## Zusätzliche Beispielrichtlinien Obwohl dieses Kapitel viele Beispielrichtlinien enthält, ist die AWS Zugriffskontrolle ein komplexes Thema, das sich am besten anhand von Beispielen verstehen lässt. Weitere Informationen finden Sie unter [Beispiel für identitätsbasierte IAM-Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_examples.html) im *IAM-Benutzerhandbuch*.