OpenSearch Dashboardsにおける利用ユーザーに応じた閲覧データ制御

坪内龍太

2025.11.4

はじめに

OpenSearchを活用してデータを様々な利用者がアクセス可能な形で提供する際、「誰がどのように情報へアクセスするのか」という点は、設計上の重要な論点となります。OpenSearchでは大きく分けて、APIベースでのデータアクセスとGUIベースの「OpenSearch Dashboards」という2つの利用形態が存在します。
たとえば、OpenSearch APIを用いれば、curlやPythonなどのクライアントから直接クエリを実行し、高度な条件検索や自動処理が可能です。一方で、こうした操作はある程度の技術的知識を前提とするため、非エンジニアにとってはハードルが高く、日常業務に即した利用には向きません。

一方、OpenSearch Dashboardsは直感的な操作でグラフや表を構成でき、非エンジニアの業務担当者でも利用しやすい点が特徴で、日常的な業務モニタリングやチーム内の情報共有など、部門横断での活用にも期待できます。
このように、多様な立場の利用者が共通のダッシュボードを閲覧する場面が増えるにつれ、「誰がどの情報を閲覧できるか」というアクセス制御の重要性が増しています。たとえば、経理部門と開発部門で同じインデックスを使っていても、見せたい情報や見せたくない情報は異なります。単なるダッシュボードの作成だけでなく、「利用者ごとの閲覧範囲の制御」まで設計に含めることが、OpenSearch Dashboardsを安全かつ効果的に運用するためには不可欠です。

この記事では、まず最もシンプルで導入しやすい「Basic認証」を通じて、OpenSearch Dashboardsにおける認証と認可の基本的な考え方を解説します。Basic認証では、あらかじめ定義されたユーザー名とパスワードを使ってログインし、それに紐づいた「ロール」によって、アクセス可能なインデックスや操作範囲が決まります。これは固定的で簡易なアクセス制御を実現する上で非常に有効です。
しかし、実際の業務では「所属部署によって見せるデータを変えたい」「同じダッシュボードでもユーザーごとに異なる範囲を見せたい」といった、よりきめ細かい制御のニーズが出てきます。そうした要件に対応するためには、単純なユーザー・ロールの固定割り当てでは限界があり、ユーザー属性（グループ・部門など）に応じた動的なアクセス制御が求められます。

そこで、特に柔軟なアクセス制御を実装しやすいのが、AWS Cognitoを利用した認証方式です。Cognitoでは、ユーザープールと呼ばれる仕組みを用いて、ユーザー情報とその属性を管理できます。さらに、OpenSearch側と連携することで、ログインユーザーの属性に応じてロールを動的に割り当てることが可能となり、より柔軟かつ安全な可視化環境を実現できます。
本記事では具体的な設定方法を交えながら、OpenSearch Dashboardsにおける利用ユーザーに応じた閲覧データ制御について深掘っていきたいと思います。

OpenSearch におけるアクセス制御レイヤー

OpenSearchのアクセス制御レイヤーは大きく2分すると、「OpenSearchに入るまでの制御」と「OpenSearch内部での制御」に分けられます。

OpenSearchに入るまでの制御

ネットワークおよびドメインポリシーベースのアクセス制御

このレイヤーは、OpenSearchドメイン^※1（クラスター）にリクエストが届くかどうかを制御するための仕組みであり、認証よりも前段階に位置します。アクセスの可否は、主にネットワーク構成とドメインレベルのポリシーによって決定されます。

制御手段としては、まずVPCアクセス設定が挙げられます。これは、クライアントが特定のVPC内部からのみアクセスできるように制限するもので、セキュリティグループやVPC Peeringなどを活用した構成が可能です。

また、OpenSearch Serviceではパブリックアクセスドメインもサポートしており、インターネット経由で任意のデバイスからリクエストを受け付ける構成を取ることもできます。ただし、公開性が高いため、厳格な制御が求められます。

さらに、ドメインポリシーによるアクセス制御では、IPアドレスやAWSアカウント単位でアクセス元を制限することができます。これにより、特定の組織・環境からの接続のみを許可し、外部からの不正アクセスリスクを軽減することが可能です。

※1：OpenSearch Service の「ドメイン」

本記事における「ドメイン」は OpenSearch Service における「ドメイン」＝論理的なクラスター単位を指します。これは「検索ノード群をまとめて管理する 1 つの単位」であり、インターネットで使われる「DNSドメイン名」とは異なります。
OpenSearchの管理コンソールや ARN でも…:domain/xxxという形式でこの「ドメイン」が表現されます。

認証

認証レイヤーは、アクセスを試みている主体（ユーザーまたはアプリケーション）が誰であるかを確認する役割を担います。OpenSearchでは、この認証に対応するために複数の方式が提供されています。
主な方法としては以下があります。

Basic認証：内部ユーザー／パスワードで Dashboards にログインする方式
Cognito認証：AWS Cognito UserPool/IdentityPoolと連携し、Cognito を IdP として利用、または外部 IdP とフェデレーションして Dashboards にログインする方式
SAML認証：外部 IdP と SAML 連携して Dashboards にシングルサインオンする方式
IAM認証：AWS IAMユーザーやロールと連携し、SigV4署名付きリクエストによりAPIアクセス向けに利用される認証方式（Dashboardsログインには非対応）

利用するのがOpenSearch APIなのかOpenSearch Dashboardsなのかによって利用可能な認証方式が異なり、OpenSearch DashboardsではBasic認証、Cognito認証、SAML認証が利用可能です。

OpenSearch内部での制御

ポリシーベースの認可

このレイヤーでは認証されたユーザーが「何を操作できるか」を制御します。
OpenSearchのポリシーベースのアクセス制御としてはアイデンティティ（IAM）ベースのアクセスポリシー、リソースベースのアクセスポリシーのポリシーの組み合わせにより認可制御します。

アイデンティティベースのアクセスポリシーはアイデンティティベースのポリシーをユーザーまたはロールにアタッチして扱えるリソースを制御するもので、サービスに誰がアクセスできるか、どのアクションキーを実行できるかを指定します。例えば以下のようなes:* 系アクション^※2を使用したポリシーにより、example-opensearch-domain というドメインに対して GET および POST リクエストを許可できます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "es:ESHttpGet",
                "es:ESHttpPost"
            ],
            "Resource": "arn:aws:es:ap-northeast-1:123456789012:domain/example-opensearch-domain/*",
            "Effect": "Allow"
        }
    ]
}

※2：OpenSearch のARNのサービスプレフィックス

OpenSearch Service は、もともと Amazon Elasticsearch Service から派生した経緯があります。そのため、IAMポリシーや ARN のサービスプレフィックスは現在もesのままとなっています。
（例：arn:aws:es:ap-northeast-1:123456789012:domain/example-opensearch-domain/*）

リソースベースのポリシーはOpenSearchドメインの側に設定する形式のポリシーで、「どのIAMエンティティがこのドメインにアクセスできるか」を制御します。例えば、以下のように記載することで、そのOpenSearchドメインは特定のロール（下の例ではexample-OpenSearchAdminRoleもしくはexample-OpenSearchUserRole）を介してのみ操作が可能といった形で制御できます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::123456789012:role/example-OpenSearchAdminRole",
          "arn:aws:iam::123456789012:role/example-OpenSearchUserRole"
        ]
      },
      "Action": "es:*",
      "Resource": "arn:aws:es:ap-northeast-1:123456789012:domain/example-opensearch-domain/*"
    }
  ]
}

アイデンティティベースのポリシーとリソースベースのポリシーはどちらか一方だけでも利用可能ですが、併用することでより細かな制御が可能になります。なお、両方のポリシーにおいて AllowとDenyがバッティングする場合はDenyが優先されます。また、明示的にAllowされていない操作もDenyされるという点にも注意が必要です。これは、IAMポリシー全般に共通する原則です。

きめ細やかなアクセスコントロール

OpenSearch内部では、インデックス、ドキュメント、フィールド単位での細かい権限設定を行い、ユーザーごとに適切なデータ操作や閲覧権限を実現することができます。きめ細やかなアクセスコントロールの主要コンセプトにはユーザー・ロール・マッピングがあります。

ここで扱う「ユーザー」は、OpenSearch Dashboards へのアクセスを行う人間ユーザーを指し、OpenSearch内部で定義されたユーザー情報です。IAMユーザーとは異なります。本節ではDashboardsからのアクセスのみを想定しているため、「OpenSearch内部ユーザー」として記述を統一します。

「ロール」は、特定のユーザーにどのような操作権限を与えるかを定義する単位であり、IAMロールとは異なります。混同を避けるため、本節では「バックエンドロール」と表記します。
バックエンドロールでは、以下のような階層ごとのセキュリティ設定が可能です。

クラスターレベルのセキュリティ：ヘルスのモニタリング、スナップショットの取得などを可能にするかどうかを制御します。
インデックスレベルのセキュリティ：新しいインデックスの作成、インデックスの検索、ドキュメントの読み取りと書き込み、ドキュメントの削除などを制御します。
ドキュメントレベルのセキュリティ：特定の条件に合致するドキュメントのみを検索・取得できるよう制御します。
フィールドレベルのセキュリティ：特定フィールドの非表示またはマスキングできるのかを制御します。

特にフィールドレベルのセキュリティでは、機密情報などを削除せずに非表示またはマスキングすることが可能です。フィールド単位で閲覧範囲を制限したい場合は、この機能を活用することで、情報の保護と柔軟なアクセスを両立できます。

マッピングでは、「OpenSearch内部ユーザー」と「バックエンドロール」を結びつけます。これにより、どのユーザーがどのロールを通じて何の操作権限を持つかを明示的に定義できます。マッピングの対象としては、ユーザー名だけでなく、CognitoやSAMLなどの認証経由で取得した属性（たとえば groups や custom:division claim）も利用可能です。これにより、ユーザー属性に応じた動的なアクセス制御も実現できます。

以降の章で扱うアクセス制御レイヤーの範囲

以上、OpenSearchではアクセス制御レイヤーを組み合わせることで目的に沿った権限コントロールを実装することができます。
ただし、本記事の主眼は「ユーザーごとに異なる閲覧範囲をどう実現するか」といった、OpenSearch Dashboards 利用時のきめ細やかなアクセス制御にあります。そのため、ネットワーク構成やIP制限、ドメインポリシーなどによるアクセスの前段階での制御（ネットワークおよびドメインポリシーベースのアクセス制御）については、本稿の趣旨からはやや逸れるため、詳細な解説は割愛します。これらの要素はインフラ設計やセキュリティ境界の観点では極めて重要ですが、「同じダッシュボードに対して誰が何を見られるか」といった運用上の視点とは少し異なる軸であるためです。

そこで次章では、OpenSearch Dashboards における閲覧権限の具体的な制御方法の一例として、最もシンプルな認証手段であるBasic認証を採用した場合の構成と設定方法を取り上げます。
この認証方式を用いた場合、どのようにユーザーごとの閲覧範囲を定義・適用していけるのかを、実装例を交えて解説していきます。

Basic認証を用いたOpenSearch Dashboardsでのアクセス制御

OpenSearch Dashboards でのBasic認証では、管理者がOpenSearch内部ユーザーを作成しID・パスワードを発行して利用します。ユーザーがログインする際には、ID・パスワードを入力し、発行済みのものと一致するかをもって認証する方式になります。OpenSearch内部ユーザーときめ細やかなアクセスコントロールによるシンプルなアクセス制御です。

OpenSearch内部ユーザーを作成するとユーザー情報は内部DBに保存されます。ログイン後は、きめ細やかなアクセスコントロールによってユーザーとマッピングされたロールに基づいてOpenSearchダッシュボードで表示されるコンテンツをコントロールすることができます。

Basic認証を用いた場合のアクセス制御の概略を図に示すと以下のようになります。

OpenSearch内部ユーザー・バックエンドロールとそのマッピングについて、具体例を挙げてみていきます。データにはOpenSearchで提供されているサンプルデータ（opensearch_dashboards_sample_data_ecommerce）を用いていきます。

事前準備として、管理者アカウントを用いてOpenSearch内部ユーザー”test-user“を作成しておきます。作成したOpenSearch内部ユーザーで利用するバックエンドロールをOpenSearch側で設定します。

バックエンドロールはOpenSearchでデフォルトで用意されているものを使う方法と、自分で作成したロールを作成する方法があります。ここではカスタマイズしたロールを利用する方法を例に見ていきます。ロールには上述の通り、クラスターレベルのセキュリティ／インデックスレベルのセキュリティ／ドキュメントレベルのセキュリティ／フィールドレベルのセキュリティが存在し、目的に応じてカスタマイズできます。ドキュメントレベルのセキュリティを例に挙げると、ドキュメントレベルのセキュリティでは特定の条件に合致するドキュメントのみを検索・取得できるよう制御することができます。

例えば、以下のように指定します。

{
  "term": {
    "email": "eddie@taylor-family.zzz"
    }
}

この例では”emailが’eddie@taylor-family.zzz’と一致するデータ”に合致するドキュメントに制御できます。このドキュメントレベルセキュリティに対してreadの権限を設定したロールを作成したイメージが以下になります。

このロールをユーザーに割り当てるには、ロールの『Mapped users』からマッピングを実施します。先ほど作成したtest-userに対してマッピングした例が以下になります。

以上の設定を通して、”test-user”は”emailが’eddie@taylor-family.zzz’と一致するデータ”に対して”read“の権限を持つ（それ以外のデータについては権限を持たない）という制御を実装することができます。実際にtest-userでログインした際のダッシュボードイメージが以下になりますが、データの中でも”emailが’eddie@taylor-family.zzz’と一致するデータ”だけ表示されているのがわかります※

※元のサンプルデータ（opensearch_dashboards_sample_data_ecommerce）に対して管理者権限でアクセスした場合はすべてのデータが見られるので、上記の制御が有効になっていることがわかります。

以上がBasic認証を用いた実装例になります。内部ユーザーを直接用いてロールにマッピングする方法になるので、非常にシンプルに実装でき、きめ細やかなアクセスコントロールでの実装方法はイメージしやすいケースかなと思います。次に、Cognitoを用いた認証の実装イメージを見ていきます。こちらはCognitoのユーザーとOpenSearch内部ユーザーとを紐づけて権限管理するまでがBasic認証と比べると複雑なケースになっています。

Cognitoを用いたOpenSearch Dashboardsでのアクセス制御

先にCognitoを用いた場合のアクセス制御の概略を図に示すと以下のようになります。

CognitoではユーザープールとIDプールの双方を用いて、1. ユーザープールとIDプールのIDプロバイダーを連携されて、2. IDプロバイダーとIAMロールをマッピングさせ、3. IAMロールとバックエンドロールを連携させるという構成が基本になります。以下に各構成要素を順に解説します。

1. ユーザープールとIDプールのIDプロバイダーの連携

OpenSearchでCognito認証を用いる場合、先にCognitoをセットアップします。 CognitoではユーザープールとID プールをどちらも用いる必要があるのでユーザープールとID プールを適当な設定で作成します。細かいパラメータはここでは割愛します。なお、ユーザープールのアプリケーションクライアントは作成しなくても問題ありません。（というのも、OpenSearchで認証方法をCognitoに設定する際にアプリケーションクライアントは自動で作成され、そちらが認証に利用されます。2025年7月現在、OpenSearchでCognito認証を用いる場合に手動作成したアプリケーションクライアントを指定して利用する方法はないとのことです）

Cognito作成後、OpenSearch Serviceのドメイン設定にて、認証方法としてCognitoを選択し、ユーザープールとIDプールを指定します。ユーザープールとIDプールには上記で作成したものを指定し、連携させます。

OpenSearchからの連携が完了すると、Cognitoユーザープールにアプリケーションクライアントが作成されます（下記のようなもの）。こちらに必要な認証情報を設定します。（ユースケースに応じて必要なスコープやリダイレクトURLを設定します。詳細はAWS公式ドキュメントを参照ください）

同様に、アイデンティティプロバイダーにもユーザープールと連携されたプロバイダーが作成されます。こちらを利用して IDプロバイダーとIAMロールをマッピングさせていきます。

2. IDプロバイダーとIAMロールのマッピング

IDプロバイダーとロールのマッピングにはいくつかパターンがあります。まず、IDプールにはデフォルトでのユーザーアクセスを設定することができます。

そこにさらにIDプロバイダーごとに、ロール設定することが可能です。

デフォルトの認証されたロールを使用
- 上記で設定したIDプロバイダーごとの認証されたロールを利用します。
ルールを使用してロールを選択
- クレームごとに合致条件を設定し、それに合致する場合に所定のロールをアタッチできます。
- ルールに合致しなかった場合の動作もデフォルトの認証されたロールを使用するか、拒否するかを選択できます。

トークンで preferred_role クレームを持つロールを選択する
- preferred_roleクレームに設定された IAM ロール ARN に基づいて、ユーザーを OpenSearch Service のロールにマッピングします。
  - preferred_role クレームに IAM ロール ARN を入れる方法としては、管理者が直接クレームを編集する仕組みはなく、Lambda トリガー（Pre Token Generation 等）を使って claimsOverrideDetails を設定し、preferred_role を挿入します。（なお、自分が OIDC や SAML の IdP を直接管理している場合は、発行するトークンに任意のクレームを追加できるため、IdP 側で preferred_role を含めることも可能です）
    
    例えば、以下のようなLambdaトリガーを設定すると、カスタム属性のグループに応じてpreferred_roleクレームにロールのARNを入れることが可能です。（Lambdaトリガーを用いたクレームの挿入については公式ブログがあるのでそちらもご参照ください→ Implement Role-based Access Control for .NET applications with Amazon Cognito | Amazon Web Services））※以下の例の場合はルールを使用したロールで代替可能ですが、Lambdaトリガーを用いたクレームの挿入の方が複雑な処理も実装できるのでより応用力は高いと言えます。
```
import os
def lambda_handler(event, context):
    group = event['request']['userAttributes'].get('custom:group', '')
    account_id = os.environ['AWS_ACCOUNT_ID']
    if group == 'admin':
        event['response']['claimsOverrideDetails'] = {
            'claimsToAddOrOverride': {
                'preferred_role': f'arn:aws:iam::{account_id}:role/example-OpenSearchAdminRole'
            }
        }
    elif group == 'user':
        event['response']['claimsOverrideDetails'] = {
            'claimsToAddOrOverride': {
                'preferred_role': f'arn:aws:iam::{account_id}:role/example-OpenSearchUserRole'
            }
        }

    return event
```
- preferred_roleクレームがなかった場合の動作もデフォルトの認証されたロールを使用するか、拒否するかを選択できます。

3. IAMロールとバックエンドロールを連携

2で作成したIAMロールをバックエンドロールに連携します。バックエンドロールロールのマッピングでは、公式ドキュメントの「Mapping roles to users」の項目に基づきロールをマッピングします。

以上のように、CognitoのIAMロールとOpenSearchのバックエンドロールをマッピングすることで、OpenSearch Dashboards内での閲覧範囲の制御が可能になります。これは、従来のBasic認証と異なり、ユーザー個別の設定ではなく、属性ベースの動的なロール付与によって実現されます。

マッピングはOpenSearch Dashboardsの「Security」メニューの「Roles」から設定可能です。たとえば、IAMロールtestrt-OpenSearchUserRoleを、OpenSearch内のlimited-data-viewerというバックエンドロールにマッピングすることで、当該IAMロールを持つすべてのユーザーは、定義された閲覧権限を得ます。

このマッピングにより、次のような制御が可能となります。

adminグループに所属するユーザーはtestrt-OpenSearchAdminRoleを割り当てられ、クラスタ全体の可視化や操作が可能
userグループに所属するユーザーはtestrt-OpenSearchUserRoleを割り当てられ、制限されたインデックスやフィールドのみ表示

また、OpenSearchのセキュリティ設定においては、ドキュメントレベル・フィールドレベルのセキュリティもCognitoベースの認証と組み合わせて利用可能です。たとえば、以下のようなシナリオを構成できます。

フィールドレベルで「売上金額」フィールドのみマスキング
ドキュメントレベルで「部署=営業部」のレコードのみ取得許可

これらの設定により、従業員の部署や役職に応じて表示内容を柔軟にコントロールすることができ、1つの共通ダッシュボードを複数部署で安全に共有することが可能になります。

まとめ

OpenSearch Dashboardsにおけるアクセス制御の設計では、目的に応じたデータ制御のアプローチ選択が重要になります。選択のポイントとしては以下になります。

OpenSearchのアクセス制御は「ネットワーク／認証／認可／表示制御」の多層構造
Basic認証は導入が容易できめ細やかなアクセスコントロールが導入できるので、ライトに小規模に離床するケースに適する
Cognito認証は柔軟性が高く、属性ベースのダッシュボード制御が可能なため、比較的大きな規模や条件に応じた複雑なカスタマイズが必要なケースで適する
IAMロールとバックエンドロールのマッピングにより、インデックスやフィールドの閲覧制御を精密に設定可能
Lambdaトリガーやpreferred_roleクレームを活用することで、ユーザー属性に基づいた高度な権限制御も可能

このように、ユースケースに応じて適切な認証・認可方式を選定することで、OpenSearch Dashboardsを安全かつ効率的に運用することが可能となります。特に、Cognitoなどの柔軟なIdPを活用したアクセス制御は、ゼロトラスト環境や部門別権限管理の実現において、極めて有効な選択肢と言えると思います。