全体像: きめ細かなアクセスコントロールと OpenSearch サービスセキュリティ主要なコンセプトマスターユーザーについてきめ細かなアクセスコントロールの有効化マスターユーザーとしての OpenSearch Dashboards へのアクセス許可の管理推奨される設定制限事項マスターユーザーの変更追加のマスターユーザー手動スナップショット統合 REST API の相違点

Amazon OpenSearch Service でのきめ細かなアクセスコントロール

きめ細かなアクセスコントロールは、Amazon OpenSearch Service 上のデータへのアクセスを制御する追加の方法を提供します。例えば、リクエスト者によっては、検索で 1 つのインデックスのみから結果が返されるようにしたい場合があります。ドキュメント内の特定のフィールドを非表示にしたい場合や、特定のドキュメントをまとめて除外したい場合もあります。

きめ細かなアクセスコントロールには、以下の利点があります。

ロールベースアクセスコントロール
インデックスレベル、ドキュメントレベル、フィールドレベルのセキュリティ
OpenSearch Dashboards マルチテナンシー
OpenSearch および OpenSearch Dashboards の HTTP 基本認証

トピック

全体像: きめ細かなアクセスコントロールと OpenSearch サービスセキュリティ
主要なコンセプト
マスターユーザーについて
きめ細かなアクセスコントロールの有効化
マスターユーザーとしての OpenSearch Dashboards へのアクセス
許可の管理
推奨される設定
制限事項
マスターユーザーの変更
追加のマスターユーザー
手動スナップショット
統合
REST API の相違点
チュートリアル: IAM マスターユーザーと Amazon Cognito 認証を使用してドメインを設定する
チュートリアル: 内部ユーザーデータベースと HTTP 基本認証でドメインを設定する

全体像: きめ細かなアクセスコントロールと OpenSearch サービスセキュリティ

Amazon OpenSearch Service セキュリティには、主に次の 3 つのレイヤーがあります。

ネットワーク: 最初のセキュリティレイヤーはネットワークで、リクエストが OpenSearch サービスドメインに到達するかどうかを決定します。ドメインを作成するときに [パブリックアクセス] を選択した場合、インターネットに接続されたクライアントからのリクエストがドメインエンドポイントに到達できます。[VPC アクセス] を選択した場合、クライアントがエンドポイントに到達するためには、クライアントが VPC に接続する必要があります (かつ、関連するセキュリティグループがその接続を許可する必要があります)。詳細については、「VPC 内で Amazon OpenSearch Service ドメインを起動する」を参照してください。

ドメインアクセスポリシー: 2 番目のセキュリティレイヤーは、ドメインアクセスポリシーです。リクエストがドメインエンドポイントに到達すると、リソースベースのアクセスポリシーにより、指定された URI へのアクセスリクエストが許可または拒否されます。このアクセスポリシーにより、リクエストは OpenSearch 自体に到達する前に、ドメインの「エッジ」で許可または拒否されます。

きめ細かなアクセスコントロール: 最後の 3 番目のセキュリティレイヤーは、きめ細かなアクセスコントロールです。リソースベースのアクセスポリシーにより、リクエストがドメインエンドポイントに到達することが許可された後、きめ細かなアクセスコントロールにより、ユーザー認証情報が評価されて、ユーザーが認証されるか、リクエストが拒否されます。きめ細かなアクセスコントロールによりユーザーが認証された場合、そのユーザーにマッピングされているすべてのロールが取得され、付与されるすべての許可を使用してリクエストの処理方法が決定されます。

注記

リソースベースのアクセスポリシーに IAM ロールまたはユーザーが含まれている場合、クライアントは署名バージョン 4 を使用して AWS 署名付きリクエストを送信する必要があります。そのため、アクセスポリシーは、特に内部ユーザーデータベースと HTTP 基本認証を使用する場合、きめ細かなアクセスコントロールと競合することがあります。ユーザー名とパスワードで、かつ IAM 認証情報で、リクエストに署名することはできません。一般に、きめ細かなアクセスコントロールを有効にする場合は、署名付きリクエストを必須としないドメインアクセスポリシーを使用することをお勧めします。

以下の図表は、きめ細かなアクセスコントロールが有効な VPC アクセスドメイン、IAM ベースのアクセスポリシー、IAM マスターユーザーという、一般的な構成を示しています。

以下の図表は、きめ細かなアクセスコントロールが有効なパブリックアクセスドメイン、IAM プリンシパルを使用しないアクセスポリシー、内部ユーザーデータベース内のマスターユーザーという、別の一般的な構成を示しています。

例

movies/_search?q=thor への GET リクエストを考えてみます。ユーザーに movies インデックスを検索する許可があることを確認します。そうであれば、ユーザーにその内部のすべてのドキュメントを表示するアクセス許可があることを確認します。レスポンスで、フィールドを省略または匿名化するかを選択します。マスターユーザーの場合、レスポンスは以下のようになります。


{
  "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
        }
      },
      ...
    ]
  }
}

許可がより制限されたユーザーが上記と同じリクエストを発行した場合、レスポンスは以下のようになります。


{
  "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"
        }
      },
      ...
    ]
  }
}

レスポンスでは、ヒット数、およびヒットあたりのフィールド数が少なくなっています。また、release_date フィールドは匿名化されています。許可のないユーザーが上記と同じリクエストを発行した場合、クラスターによってエラーが返されます。


{
  "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
}

ユーザーが無効な認証情報を提供した場合、クラスターによって Unauthorized 例外が返されます。

主要なコンセプト

きめ細かなアクセスコントロールの使用を開始する際には、以下の概念を考慮してください。

ロール – きめ細かなアクセスコントロールを使用するための中核的な方法です。この場合、ロールは IAM ロールとは異なります。ロールには、クラスター全体、インデックス固有、ドキュメントレベル、フィールドレベルの許可の任意の組み合わせが含まれます。
マッピング – ロールを設定したら、1 人以上のユーザーにマッピングします。例えば、3 つのロールを 1 人のユーザーにマッピングできます。1 つは Dashboards へのアクセスを許可し、1 つは index1 への読み取り専用アクセスを許可し、もう 1 つは index2 への書き込みアクセスを許可します。または、これらのすべての許可を 1 つのロールに含めることもできます。
ユーザー – OpenSearch クラスターにリクエストを行うユーザーまたはアプリケーション。ユーザーは、リクエストを行うときに指定する認証情報 (IAM アクセスキーまたはユーザー名とパスワードのいずれか) を持っています。

マスターユーザーについて

Service のマスターユーザーは、ユーザー名とパスワードの組み合わせ、または基盤となる OpenSearchクラスターに対する完全なアクセス許可を持つ IAM プリンシパルのいずれか OpenSearch です。ユーザーは、 OpenSearch Dashboards 内で内部ユーザー、ロール、ロールマッピングを作成する機能とともに、 OpenSearch クラスターへのすべてのアクセス権を持っている場合、マスターユーザーと見なされます。

OpenSearch サービスコンソールまたは CLI を使用して作成されたマスターユーザーは、2 つの事前定義されたロールに自動的にマッピングされます。

all_access – すべてのクラスター全体のオペレーションへのフルアクセス、すべてのクラスターインデックスへの書き込みアクセス許可、およびすべてのテナントへの書き込みアクセス許可を提供します。
security_manager – セキュリティプラグインへのアクセスと、ユーザーとアクセス許可の管理を提供します。

これら 2 つのロールを使用すると、ユーザーは OpenSearch Dashboards のセキュリティタブにアクセスでき、そこでユーザーとアクセス許可を管理できます。別の内部ユーザーを作成し、それを all_accessロールにのみマッピングする場合、そのユーザーはセキュリティ タブにアクセスできません。マスターユーザーと security_managerロールの両方に明示的にマッピングすることでall_access、追加のマスターユーザーを作成できます。手順については、「追加のマスターユーザー」を参照してください。

ドメインのマスターユーザーを作成するときは、既存の IAM プリンシパル を指定するか、内部ユーザーデータベース内にマスターユーザーを作成できます。使用するを決定するときは、次の点を考慮してください。

IAM プリンシパル – マスターユーザーの IAM プリンシパルを選択する場合、クラスターへのすべてのリクエストは AWS 、署名バージョン 4 を使用して署名する必要があります。

OpenSearch サービスは IAM プリンシパルのアクセス許可を考慮しません。IAM ユーザーまたはロールは、認証のために純粋に機能します。そのユーザーまたはロールのポリシーは、マスターユーザーの認可には関係ありません。認可は、 OpenSearch セキュリティプラグインのさまざまなアクセス許可を通じて処理されます。

例えば、IAM プリンシパルに IAM アクセス許可を割り当てたり、マシンまたはユーザーがそのユーザーまたはロールに対して認証できる限り、 OpenSearch サービス内のマスターユーザーの権限が与えられます。

複数のクラスターで同じユーザーを使用する場合、Amazon Cognito を使用して Dashboards にアクセスする場合、または署名バージョン 4 の署名をサポートする OpenSearch クライアントがある場合は、IAM をお勧めします。
内部ユーザーデータベース – 内部ユーザーデータベースにマスターを作成する場合 (ユーザー名とパスワードの組み合わせ）、HTTP 基本認証 (IAM 認証情報) を使用してクラスターにリクエストを行うことができます。ほとんどのクライアントは、curl を含む基本認証をサポートしています。curl は、--aws-sigv4 オプションを持つ AWS 署名バージョン 4 もサポートしています。内部ユーザーデータベースは OpenSearch インデックスに保存されるため、他のクラスターと共有することはできません。

複数のクラスター間でユーザーを再利用する必要がない場合、Dashboards へのアクセスに Amazon Cognito ではなく HTTP 基本認証を使用する場合、または基本認証のみをサポートするクライアントがある場合は、内部ユーザーデータベースをお勧めします。内部ユーザーデータベースは、 OpenSearch サービスの使用を開始する最も簡単な方法です。

きめ細かなアクセスコントロールの有効化

コンソール、、または設定 API を使用して AWS CLI、きめ細かなアクセスコントロールを有効にします。この手順については、「Amazon OpenSearch サービスドメインの作成と管理」を参照してください。

きめ細かなアクセスコントロールには、 OpenSearch または Elasticsearch 6.7 以降が必要です。また、ドメインへのすべてのトラフィックに HTTPS、保管中のデータの暗号化、およびnode-to-node 暗号化も必要です。きめ細かなアクセス制御の、高度な機能の設定方法によっては、さらに多くのリクエストを処理するために、個々のデータノードにコンピューティングリソースとメモリリソースが必要になる場合があります。きめ細かなアクセスコントロールを有効にした後、無効にすることはできません。

既存のドメインでのきめ細かなアクセスコントロールの有効化

OpenSearch または Elasticsearch 6.7 以降を実行している既存のドメインでは、きめ細かなアクセスコントロールを有効にできます。

既存のドメインに対してきめ細かなアクセスコントロールを有効にするには (コンソール)

ドメインを選択し、[アクション] および [セキュリティ設定の編集] を選択します。
[きめ細かなアクセスコントロールを有効にする] を選択します。
マスターユーザーの作成方法を選択します。
- ユーザー管理に IAM を使用する場合は、[IAM ARN をマスターユーザーとして設定] を選択し、IAM ロールの ARN を指定します。
- 内部ユーザーデータベースを使用する場合は、[Create master user] (マスターユーザーの作成) を選択し、ユーザー名とパスワードを指定します。
(オプション) [Open/IP ベースのアクセスポリシーの移行期間を有効にする] を選択します。この設定により、30 日間の移行期間が有効になります。この期間中、既存のユーザーが中断することなくドメインにアクセスできるようになり、IP ベースのアクセスポリシーは引き続きドメインで動作します。この移行期間中に、管理者が必要なロールを作成し、それらをドメインのユーザーにマップすることをお勧めします。オープンアクセスポリシーまたは IP ベースのアクセスポリシーの代わりに ID ベースのポリシーを使用している場合は、この設定を無効にすることができます。

また、移行期間中にきめ細かなアクセス制御を使用するようにクライアントを更新する必要があります。例えば、IAM ロールをきめ細かなアクセスコントロールにマッピングする場合は、クライアントを更新して AWS Signature Version 4 でリクエストの署名を開始する必要があります。きめ細かなアクセス制御を使用して HTTP 基本認証を構成する場合、リクエストに応じた基本認証資格情報を提供するようにクライアントを更新する必要があります。

移行期間中、ドメインの OpenSearch Dashboards エンドポイントにアクセスするユーザーは、ログインページではなく、Discover ページに直接アクセスします。管理者とマスターユーザーは、Login を選択して管理者の認証情報を使用してログインし、ロールのマッピングを設定できます。

重要
OpenSearch サービスは 30 日後に移行期間を自動的に無効にします。必要なロールを作成してユーザーにマップしたら、すぐに終了することをお勧めします。移行期間が終了した後、再度有効化することはできません。
[変更の保存] をクリックします。

この変更により、青/緑のデプロイがトリガーされ、その間にクラスターの状態が赤になりますが、すべてのクラスターオペレーションは影響を受けません。

既存のドメインに対してきめ細かなアクセスコントロールを有効にするには (CLI)

きめ細かなアクセスコントロールを使用して移行期間を有効にするには、AnonymousAuthEnabled を true に設定します。


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}'

default_role について

きめ細かなアクセスコントロールには、ロールマッピングが必要です。ドメインがアイデンティティベースのアクセスポリシーを使用している場合、既存のユーザーを適切に移行できるように、 OpenSearch サービスは自動的にユーザーを default_role という新しいロールにマッピングします。この一時的なマッピングにより、独自のロールマッピングを作成するまで、ユーザーは IAM 署名付き GET および PUT リクエストを正常に送信できます。

このロールは、セキュリティの脆弱性や欠陥を OpenSearch サービスドメインに追加しません。独自のロールを設定したら、すぐにデフォルトのロールを削除して、それに応じてマッピングすることをお勧めします。

移行シナリオ

次の表に、既存のドメインできめ細かなアクセス制御を有効にする前と後の各認証方式の動作と、管理者がユーザーをロールに適切にマッピングするために必要な手順について説明します。

認証方法	きめ細かなアクセスコントロールの有効化の前	きめ細かなアクセスコントロールの有効化の後	管理タスク
アイデンティティベースのポリシー	IAM ポリシーを満たすすべてのユーザーが、ドメインにアクセスできます。	移行期間を有効にする必要はありません。 OpenSearch サービスは、IAM ポリシーを満たすすべてのユーザーを default_role に自動的にマッピングし、ドメインに引き続きアクセスできるようにします。	ドメインでカスタムロールマッピングを作成します。 default_role を削除します。
IP ベースのポリシー	許可された IP アドレスまたは CIDR ブロックのすべてのユーザーがドメインにアクセスできます。	30 日間の移行期間中は、許可された IP アドレスまたは CIDR ブロックのすべてのユーザーが引き続きドメインにアクセスできます。	ドメインでカスタムロールマッピングを作成します。ロールマッピングの設定に応じて、基本認証情報または IAM 認証情報を提供するようにクライアントを更新します。移行期間を無効にします。許可された IP アドレスまたは CIDR ブロックからのユーザーは、基本認証または IAM 認証情報なしでリクエストを送信すると、ドメインへのアクセスが失われます。
オープンアクセスポリシー	インターネット上のすべてのユーザーがドメインにアクセスできます。	30 日間の移行期間中は、インターネット上のすべてのユーザーが引き続きドメインにアクセスできます。	ドメインでロールマッピングを作成します。ロールマッピングの設定に応じて、基本認証情報または IAM 認証情報を提供するようにクライアントを更新します。移行期間を無効にします。基本認証または IAM 認証情報なしでリクエストを送信するユーザーは、ドメインにアクセスできなくなります。

認証方法

きめ細かなアクセスコントロールの有効化の前

きめ細かなアクセスコントロールの有効化の後

管理タスク

アイデンティティベースのポリシー

IAM ポリシーを満たすすべてのユーザーが、ドメインにアクセスできます。

移行期間を有効にする必要はありません。

OpenSearch サービスは、IAM ポリシーを満たすすべてのユーザーを default_role に自動的にマッピングし、ドメインに引き続きアクセスできるようにします。

ドメインでカスタムロールマッピングを作成します。
default_role を削除します。

IP ベースのポリシー

許可された IP アドレスまたは CIDR ブロックのすべてのユーザーがドメインにアクセスできます。

30 日間の移行期間中は、許可された IP アドレスまたは CIDR ブロックのすべてのユーザーが引き続きドメインにアクセスできます。

ドメインでカスタムロールマッピングを作成します。
ロールマッピングの設定に応じて、基本認証情報または IAM 認証情報を提供するようにクライアントを更新します。
移行期間を無効にします。許可された IP アドレスまたは CIDR ブロックからのユーザーは、基本認証または IAM 認証情報なしでリクエストを送信すると、ドメインへのアクセスが失われます。

オープンアクセスポリシー

インターネット上のすべてのユーザーがドメインにアクセスできます。

30 日間の移行期間中は、インターネット上のすべてのユーザーが引き続きドメインにアクセスできます。

ドメインでロールマッピングを作成します。
ロールマッピングの設定に応じて、基本認証情報または IAM 認証情報を提供するようにクライアントを更新します。
移行期間を無効にします。基本認証または IAM 認証情報なしでリクエストを送信するユーザーは、ドメインにアクセスできなくなります。

マスターユーザーとしての OpenSearch Dashboards へのアクセス

きめ細かなアクセスコントロールには、管理タスクを簡素化する OpenSearch Dashboards プラグインがあります。Dashboards を使用して、ユーザー、ロール、マッピング、アクショングループ、テナントを管理できます。ただし、 OpenSearch Dashboards のサインインページと基盤となる認証方法は、ユーザーの管理方法とドメインの設定方法によって異なります。

ユーザー管理に IAM を使用する場合は、OpenSearch Dashboards の Amazon Cognito 認証の設定を使用して、Dashboards にアクセスします。それ以外の方法では、Dashboards の「機能しない」サインインページが表示されます。「制限事項」を参照してください。

Amazon Cognito 認証では、ID プールから引き受けたいずれかのロールが、マスターユーザーに指定した IAM ロールと一致する必要があります。この設定の詳細については、「(オプション) きめ細かなアクセスの設定」および「チュートリアル: IAM マスターユーザーと Amazon Cognito 認証を使用してドメインを設定する」を参照してください。
内部ユーザーデータベースを使用することを選択した場合は、マスターユーザー名とパスワードを使用して Dashboards にサインインできます。HTTPS 経由で Dashboards にアクセスする必要があります。このログイン画面は、Dashboards の Amazon Cognito 認証と SAML 認証の両方に置き換えられます。

この設定の詳細については、「チュートリアル: 内部ユーザーデータベースと HTTP 基本認証でドメインを設定する」を参照してください。
SAML 認証を使用することを選択した場合は、外部 ID プロバイダーからの認証情報を使用してサインインできます。詳細については、「ダッシュボードの OpenSearch SAML 認証」を参照してください。

許可の管理

「主要なコンセプト」で説明しているように、ロール、ユーザー、マッピングを使用してきめ細かなアクセスコントロールの許可を管理します。このセクションでは、これらのリソースを作成して適用する方法について説明します。これらの操作を実行するには、マスターユーザーとして Dashboards にサインインすることをお勧めします。

注記

ユーザーに付与するために選択する権限は、ユースケースによって大きく異なります。このドキュメントですべてのシナリオを実行可能にカバーすることはできません。ユーザーに付与するアクセス許可を決定するときは、次のセクションで説明する OpenSearch クラスターとインデックスのアクセス許可を参照し、常に最小特権の原則に従ってください。

ロールの作成

OpenSearch Dashboards または REST API の _plugins/_securityオペレーションを使用して、きめ細かなアクセスコントロール用の新しいロールを作成できます。詳細については、「ロールの作成」を参照してください。

きめ細かなアクセスコントロールには、多くの事前定義されたロールも含まれます。 OpenSearch Dashboards や Logstash などのクライアントは、に対してさまざまなリクエストを行うため OpenSearch、最小限のアクセス許可セットを持つロールを手動で作成することが困難になる可能性があります。例えば、opensearch_dashboards_user ロールには、ユーザーがインデックスパターン、可視化、ダッシュボード、およびテナントを操作するのに必要な許可が含まれます。このロールは、他のインデックスへのアクセスを許可する追加のロールと共に、Dashboards にアクセスするすべてのユーザーまたはバックエンドロールにマッピングすることをお勧めします。

Amazon OpenSearch Service では、次の OpenSearch ロールは提供されません。

observability_full_access
observability_read_access
reports_read_access
reports_full_access

Amazon OpenSearch Service には、では利用できないロールがいくつか用意されています OpenSearch。

ultrawarm_manager
ml_full_access
cold_manager
notifications_full_access
notifications_read_access

クラスターレベルのセキュリティ

クラスターレベルの許可により、_mget、_msearch、_bulk などの広範なリクエストの実施、ヘルスのモニタリング、スナップショットの取得などを可能にするかどうかを制御できます。ロールを作成するときに、[クラスター許可] セクションを使用してこれらの許可を管理します。クラスタレベルの権限の完全なリストについては、「クラスタ権限」を参照してください。

多くの場合、個別の権限ではなく、デフォルトのアクショングループの組み合わせを使用して、目的のセキュリティ体制を実現できます。クラスターレベルのアクショングループのリストについては、「クラスターレベル」を参照してください。

インデックスレベルのセキュリティ

インデックスレベルの許可により、新しいインデックスの作成、インデックスの検索、ドキュメントの読み取りと書き込み、ドキュメントの削除、エイリアスの管理などを可能にするかどうかを制御できます。ロールを作成するときに、[インデックス許可] セクションを使用してこれらのアクセス許可を管理します。インデックスレベルの権限の完全なリストについては、「インデックス権限」を参照してください。

多くの場合、個別の権限ではなく、デフォルトのアクショングループの組み合わせを使用して、目的のセキュリティ体制を実現できます。インデックスレベルのアクショングループのリストについては、「インデックスレベル」を参照してください。

ドキュメントレベルのセキュリティ

ドキュメントレベルのセキュリティにより、インデックス内のどのドキュメントをユーザーが表示できるかを制限できます。ロールを作成するときは、インデックスパターンと OpenSearch クエリを指定します。そのロールにマッピングされたすべてのユーザーは、クエリに一致するドキュメントのみを表示できます。ドキュメントレベルのセキュリティは、検索時に受け取るヒットの数に影響します。

詳細については、「ドキュメントレベルのセキュリティ」を参照してください。

フィールドレベルのセキュリティ

フィールドレベルのセキュリティにより、どのドキュメントフィールドをユーザーが表示できるかを制御できます。ロールを作成するときに、含めるフィールドと除外するフィールドのリストを追加します。フィールドを含めると、そのロールにマッピングされたユーザーはそれらのフィールドのみを表示できます。フィールドを除外すると、除外されたフィールドを除くすべてのフィールドを表示できます。フィールドレベルのセキュリティは、検索時にヒットに含まれるフィールドの数に影響します。

詳細については、「フィールドレベルのセキュリティ」を参照してください。

フィールドのマスキング

フィールドのマスキングは、フィールドレベルのセキュリティに代わるもので、フィールド内のデータを完全に削除するのではなく、匿名化できます。ロールを作成するときに、マスクするフィールドのリストを追加します。フィールドのマスキングは、検索時にフィールドの内容を表示できるかどうかに影響します。

ヒント

フィールドに標準マスキングを適用すると、 OpenSearch サービスは不正確な集計結果を引き起こす可能性のある安全でランダムなハッシュを使用します。マスキングされたフィールドで集計を実施するには、代わりにパターンベースのマスキングを使用します。

ユーザーの作成

内部ユーザーデータベースを有効にした場合は、Dashboards または REST API の _plugins/_securityオペレーションを使用して OpenSearchユーザーを作成できます。詳細については、「ユーザーの作成」を参照してください。

マスターユーザーに IAM を選択した場合は、Dashboards のこの部分は無視してください。その代わりに IAM ロールを作成します。詳細については、IAM ユーザーガイドを参照してください。

ユーザーへのロールのマッピング

ロールのマッピングは、きめ細かなアクセスコントロールの最も重要な側面です。きめ細かなアクセスコントロールには、使用の開始に役立ついくつかの事前定義されたロールがありますが、ロールをユーザーにマッピングしない限り、クラスターに対するすべてのリクエストは許可エラーという結果になります。

バックエンドロールを使用すると、ロールのマッピングプロセスを簡素化できます。このロールを使えば、同じロールを 100 人のユーザーに割り当てるのではなく、100 人のユーザーが共有している 1 つのバックエンドロールにロールをマッピングできます。バックエンドロールは、IAM ロールまたは任意の文字列にすることができます。

[Users] (ユーザー) セクションで、ユーザー、ユーザー ARN、および Amazon Cognito ユーザー文字列を指定します。Cognito ユーザー文字列の形式は Cognito/user-pool-id/username です。
[バックエンドロール] セクションで、バックエンドロールと IAM ロール ARN を指定します。

OpenSearch Dashboards または REST API の _plugins/_securityオペレーションを使用して、ロールをユーザーにマッピングできます。詳細については、「ユーザーをロールにマッピングする」を参照してください。

アクショングループの作成

アクショングループは、さまざまなリソースで再利用できる許可のセットです。 OpenSearch Dashboards または REST API の _plugins/_securityオペレーションを使用して新しいアクショングループを作成できますが、ほとんどのユースケースではデフォルトのアクショングループで十分です。デフォルトのアクショングループの詳細については、「デフォルトのアクショングループ」を参照してください。

OpenSearch Dashboards マルチテナンシー

テナントは、インデックスパターン、可視化、ダッシュボード、その他の Dashboards オブジェクトを保存するための領域です。Dashboards マルチテナンシーを使用すると、他の Dashboards ユーザーと作業を安全に共有できます (プライベートに保持できます)。また、テナントを動的に設定できます。どのロールがテナントにアクセスできるか、それらのロールに読み取りアクセスがあるか書き込みアクセスがあるかを制御できます。グローバルテナントがデフォルトです。詳細については、OpenSearch 「Dashboards マルチテナンシー」を参照してください。

現在のテナントを表示したりテナントを変更したりするには

OpenSearch Dashboards に移動してサインインします。
右上隅にあるユーザーアイコンを選択し、[テナントの切り替え] を選択します。
可視化またはダッシュボードを作成する前に、テナントを確認します。他のすべての Dashboards ユーザーと作業を共有する場合は、[グローバル] を選択します。一部の Dashboards ユーザーと作業を共有するには、別の共有テナントを選択します。それ以外の場合は、[プライベート] を選択します。

注記

OpenSearch Dashboards はテナントごとに個別のインデックスを保持し、というインデックステンプレートを作成しますtenant_template。テナントtenant_templateインデックスマッピングが誤って設定されている場合、 OpenSearch Dashboards が誤動作する可能性があるため、インデックスを削除または変更しないでください。

推奨される設定

きめ細かなアクセスコントロールは他のセキュリティ機能と連携するため、ここでは、ほとんどのユースケースで適切に機能するきめ細かなアクセスコントロールの推奨される設定を示します。

説明	マスターユーザー	ドメインアクセスポリシー
OpenSearch APIs への呼び出しに IAM 認証情報を使用し、SAML 認証を使用して Dashboards にアクセスします。Dashboards または REST API を使用して、きめ細かなアクセスコントロールのロールを管理します。	IAM ロールまたはユーザー	`{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "" }, "Action": "es:ESHttp", "Resource": "domain-arn/*" } ] }`
OpenSearch APIs。Dashboards または REST API を使用して、きめ細かなアクセスコントロールのロールを管理します。この設定は、特に基本認証のみをサポートするクライアントがある場合 OpenSearchに、多くの柔軟性を提供します。既存の ID プロバイダーがある場合は、SAML 認証を使用して、Dashboards にアクセスします。それ以外の場合は、内部ユーザーデータベースで Dashboards ユーザーを管理します。	ユーザー名とパスワード	`{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "" }, "Action": "es:ESHttp", "Resource": "domain-arn/*" } ] }`
OpenSearch APIs への呼び出しに IAM 認証情報を使用し、Amazon Cognito を使用して Dashboards にアクセスします。Dashboards または REST API を使用して、きめ細かなアクセスコントロールのロールを管理します。	IAM ロールまたはユーザー	`{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "" }, "Action": "es:ESHttp", "Resource": "domain-arn/*" } ] }`
OpenSearch APIs、Dashboards へのほとんどのアクセスをブロックします。REST API を使用して、きめ細かなアクセスコントロールのロールを管理します。	IAM ロールまたはユーザー	`{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "" }, "Action": "es:ESHttp", "Resource": "domain-arn/" }, { "Effect": "Deny", "Principal": { "AWS": "" }, "Action": "es:ESHttp", "Resource": "domain-arn/_dashboards" } ] }`

制限事項

きめ細かなアクセスコントロールには、いくつかの重要な制限があります。

hosts のロールマッピングの側面は、ロールをホスト名または IP アドレスにマッピングすることですが、ドメインが VPC 内にある場合は機能しません。ただし、ロールをユーザーとバックエンドロールにマッピングすることは可能です。
マスターユーザーに IAM を選択し、Amazon Cognito または SAML 認証を有効にしない場合、Dashboards の「機能しない」サインインページが表示されます。
マスターユーザーに IAM を選択しても、内部ユーザーデータベースにユーザーを作成することはできます。ただし、この設定では HTTP 基本認証が有効になっていないため、これらのユーザー認証情報で署名されたリクエストは拒否されます。
SQL を使用して、アクセスできないインデックスをクエリすると、「許可なし」のエラーが表示されます。インデックスが存在しない場合、「インデックスなし」のエラーが表示されます。このエラーメッセージの違いは、インデックスの名前を推測できれば、そのインデックスが存在していることがわかる点です。

この問題を最小限に抑えるために、インデックス名に機密情報を含めないでください。SQL へのすべてのアクセスを拒否するには、ドメインアクセスポリシーに以下の要素を追加します。
```
{
  "Effect": "Deny",
  "Principal": {
    "AWS": [
      "*"
    ]
  },
  "Action": [
    "es:*"
  ],
  "Resource": "arn:aws:es:us-east-1:123456789012:domain/my-domain/_plugins/_sql"
}
```
ドメインバージョンが 2.3 以上で、きめ細かいアクセス制御が有効になっている場合、max_clause_count を 1 に設定するとドメインで問題が発生します。このアカウントにはもっと高い数値を設定することをおすすめします。
きめ細かなアクセスコントロールが設定されていないドメインできめ細かなアクセスコントロールを有効にする場合、直接クエリ用に作成されたデータソースについては、きめ細かなアクセスコントロールロールを自分で設定する必要があります。きめ細かなアクセスロールを設定する方法の詳細については、「Amazon S3 との Amazon OpenSearch Service データソース統合の作成Amazon S3」を参照してください。

マスターユーザーの変更

マスターユーザーの詳細を忘れた場合は、コンソール、 AWS CLI、または configuration API を使用して再設定できます。

マスターユーザーを変更するには (コンソール)

https://console.aws.amazon.com/aos/home/ で Amazon OpenSearch Service コンソールに移動します。
ドメインを選択し、[Actions] (アクション)、[Edit security configuration] (セキュリティ設定の編集) を選択します。
[マスターユーザーとして IAM ARN を設定] または [マスターユーザーを作成] を選択します。
- 以前に IAM マスターユーザーを使用していた場合、きめ細かなアクセスコントロールにより、指定した新しい IAM ARN に all_access ロールが再マッピングされます。
- 以前に内部ユーザーデータベースを使用していた場合、きめ細かなアクセスコントロールにより、新しいマスターユーザーが作成されます。新しいマスターユーザーを使用して、古いマスターユーザーを削除できます。
- 内部ユーザーデータベースから IAM マスターユーザーへの切り替えでは、内部ユーザーデータベースからユーザーを削除しません。代わりに、HTTP 基本認証を無効にするだけです。内部ユーザーデータベースからユーザーを手動で削除するか、HTTP 基本認証を再度有効にする必要がある場合に備えて、ユーザーを保持します。
[変更の保存] をクリックします。

追加のマスターユーザー

ドメインの作成時にマスターユーザーを指定しますが、必要に応じて、このマスターユーザーを使用して追加のマスターユーザーを作成できます。 OpenSearch ダッシュボードと REST API の 2 つのオプションがあります。

Dashboards で [セキュリティ]、[ロール] の順に選択し、新しいマスターユーザーを all_access および security_manager ロールにマッピングします。

REST API を使用するには、以下のリクエストを送信します。


PUT _plugins/_security/api/rolesmapping/all_access
{
  "backend_roles": [
    "arn:aws:iam::123456789012:role/fourth-master-user"
  ],
  "hosts": [],
  "users": [
    "master-user",
    "second-master-user",
    "arn:aws:iam::123456789012:user/third-master-user"
  ]
}


PUT _plugins/_security/api/rolesmapping/security_manager
{
  "backend_roles": [
    "arn:aws:iam::123456789012:role/fourth-master-user"
  ],
  "hosts": [],
  "users": [
    "master-user",
    "second-master-user",
    "arn:aws:iam::123456789012:user/third-master-user"
  ]
}

これらのリクエストは現在のロールマッピングを置き換えるため、PUT リクエストに現在のすべてのロールを含めることができるように、最初に GET リクエストを実行します。REST API が特に役立つのは、Dashboards にアクセスできず、IAM ロールを Amazon Cognito から all_access ロールにマッピングする場合です。

手動スナップショット

きめ細かなアクセスコントロールにより、手動スナップショットの取得がいくらか複雑になります。スナップショットリポジトリを登録するには、HTTP 基本認証を他のすべての目的で使用する場合でも、前提条件で定義されるように、TheSnapshotRole を引き受けるための iam:PassRole 許可がある IAM ロールに manage_snapshots ロールをマッピングする必要があります。

次に、その IAM ロールを使用して、「手動スナップショットレポジトリの登録」に概説されているように、署名付きリクエストをドメインに送信します。

統合

AWS サービスで他の OpenSearch サービスを使用する場合は、それらのサービスの IAM ロールに適切なアクセス許可を付与する必要があります。例えば、Firehose 配信ストリームでは、多くの場合、という IAM ロールを使用しますfirehose_delivery_role。Dashboards で、きめ細かなアクセスコントロール用のロールを作成し、そのロールに IAM ロールをマッピングします。この場合、新しいロールには以下の許可が必要です。


{
  "cluster_permissions": [
    "cluster_composite_ops",
    "cluster_monitor"
  ],
  "index_permissions": [{
    "index_patterns": [
      "firehose-index*"
    ],
    "allowed_actions": [
      "create_index",
      "manage",
      "crud"
    ]
  }]
}

許可は、各サービスが実行するアクションによって異なります。データにインデックスを作成する AWS IoT ルールまたは AWS Lambda 関数には Firehose と同様のアクセス許可が必要になる可能性がありますが、検索のみを実行する Lambda 関数では、より限定的なセットを使用できます。

REST API の相違点

きめ細かなアクセスコントロール REST API は、 OpenSearch/Elasticsearch のバージョンによって若干異なります。PUT リクエストを行う前に、GET リクエストを行って、想定されるリクエスト本文を確認します。例えば、GET への _plugins/_security/api/user リクエストはすべてのユーザーを返すため、それらの結果を変更して使用して、有効な PUT リクエストを行うことができます。

Elasticsearch 6.x では、ユーザーの作成リクエストは以下のようになります。


PUT _opendistro/_security/api/user/new-user
{
  "password": "some-password",
  "roles": ["new-backend-role"]
}

OpenSearch または Elasticsearch 7.x _opendistroでは、リクエストは次のようになります (Elasticsearch を使用している場合は _pluginsに変更します）。


PUT _plugins/_security/api/user/new-user
{
  "password": "some-password",
  "backend_roles": ["new-backend-role"]
}

さらに、Elasticsearch 6.x では、テナントはロールのプロパティです。


GET _opendistro/_security/api/roles/all_access

{
  "all_access": {
    "cluster": ["UNLIMITED"],
    "tenants": {
      "admin_tenant": "RW"
    },
    "indices": {
      "*": {
        "*": ["UNLIMITED"]
      }
    },
    "readonly": "true"
  }
}

OpenSearch および Elasticsearch 7.x では、これらは独自の URI を持つオブジェクトです (Elasticsearch _opendistroを使用している場合は _pluginsに変更します）。


GET _plugins/_security/api/tenants

{
  "global_tenant": {
    "reserved": true,
    "hidden": false,
    "description": "Global tenant",
    "static": false
  }
}

OpenSearch REST API のドキュメントについては、「セキュリティプラグイン API リファレンス」を参照してください。

ヒント

内部ユーザーデータベースを使用する場合は、curl を使用してリクエストを行い、ドメインをテストできます。次のサンプルコマンドを試してください。


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'

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

サービス間での不分別な代理処理の防止

チュートリアル: Cognito 認証によるきめ細かなアクセスコントロール