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

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

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

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

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

以下の図表は、きめ細かなアクセスコントロールが有効な 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 例外が返されます。

主要なコンセプト

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

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

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

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

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

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

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

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

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

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

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

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

既存のドメインに対してきめ細かなアクセスコントロールを有効にするには (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 Service は、既存のユーザーを適切に移行できるように、ユーザーを default_role と呼ばれる新しいロールに自動的にマップします。この一時的なマッピングにより、独自のロールマッピングを作成するまで、ユーザーは IAM 署名付き GET および PUT リクエストを正常に送信できます。

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

移行シナリオ

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

マスターユーザーとして OpenSearch Dashboards にアクセスする

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

許可の管理

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

ロールの作成

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

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

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

Amazon OpenSearch Service には、OpenSearch では利用できないロールがいくつかあります。

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

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

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

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

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

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

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

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

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

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

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

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

フィールドのマスキング

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

ユーザーの作成

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

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

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

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

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

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

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

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

OpenSearch Dashboards マルチテナンシー

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

推奨される設定

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

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:ESHttp*",
      "Resource": "domain-arn/*"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:ESHttp*",
      "Resource": "domain-arn/*"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:ESHttp*",
      "Resource": "domain-arn/*"
    }
  ]
}

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

制約事項

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

マスターユーザーの変更

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

追加のマスターユーザー

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

手動スナップショット

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

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

統合

その他のAWSサービスを OpenSearch Service と併用する場合は、それらのサービスの IAM ロールに適切な許可を提供する必要があります。例えば、Firehose の配信ストリームでは、firehose_delivery_role という名前の IAM ロールがよく使用されます。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 では、リクエストは次のようになります (Elasticsearch を使用している場合は、_plugins を _opendistro に変更してください)。

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 を使用している場合は、_plugins を _opendistro に変更してください)。

GET _plugins/_security/api/tenants

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

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

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'