Elasticsearchのインデックスに対するアクセス制御（概要）

はじめに
対象者
なぜインデックスレベルのアクセス制御が必要なのか？
Elasticsearchにおけるインデックスアクセス制御の仕組み
1. 1. ロール (Role) の定義
2. 2. ユーザー (User) の作成とロールの割り当て
主要な権限（Privileges）の種類
まとめ

はじめに

Elasticsearchは、その柔軟性とスケーラビリティから、多種多様なデータを扱うための中心的なプラットフォームとして多くの企業で利用されています。
しかし、データ量が増え、利用者が多様化するにつれて、「誰がどのデータにアクセスできるのか」というセキュリティの課題が極めて重要になります。

今回は、Elasticsearchにおけるインデックスに対するアクセス制御の概要について説明します。
これは、データのセキュリティを確保するための最も基本的な、しかし非常に強力な機能です。

対象者

Elasticsearch : 初級者～中級者

License : Basic 以上

Version : 筆者は、8.15 で確認

なぜインデックスレベルのアクセス制御が必要なのか？

Elasticsearchは、データを「インデックス」という単位で管理します。
このインデックスは、リレーショナルデータベースにおける「テーブル」のようなものと考えることができます。
複数のインデックスが存在する場合、それぞれのインデックスには異なる種類のデータや、異なる機密レベルのデータが含まれていることがほとんどです。

例えば、以下のようなケースが考えられます。

部門ごとのデータ
- 営業部門のデータ
- 人事部門のデータ
- 開発部門のデータ

これらがそれぞれ異なるインデックスに格納されているとします。

このような状況で、全てのユーザーが全てのインデックスにアクセスできるのは望ましくありません。
誤操作によるデータ破壊や、不正な情報漏洩のリスクを最小限に抑えるためには、適切なアクセス制御が不可欠です。

Elasticsearchにおけるインデックスアクセス制御の仕組み

Elasticsearchでは、主にロールベースのアクセス制御 (RBAC = Role bases access control) を用いて、インデックスに対するアクセスを管理します。

1. ロール (Role) の定義

ロールは、特定の権限の集合体です。例えば、「読み取り専用ユーザーロール」「管理者ロール」「人事部門データ閲覧ロール」など、業務や役割に基づいてロールを定義します。

ロール定義の際に、どのインデックスに対して、どのような操作（読み取り、書き込み、管理など）を許可するかを指定します。

PUT /_security/role/sales_user_role
{
  "indices": [
    {
      "names": ["sales_data*"],  # sales_dataで始まる全てのインデックス（複数指定可）
      "privileges": ["read", "view_index_metadata"] # 読み取りとインデックスメタデータの閲覧を許可（複数指定可）
    }
  ],
  ...
}

上記の例では、sales_user_role というロールを持つユーザーは、sales_data で始まる全てのインデックスに対して「読み取り」と「インデックスメタデータの閲覧」のみが許可されます。(*1)¹

2. ユーザー (User) の作成とロールの割り当て

次に、実際にElasticsearchにアクセスするユーザーを作成し、作成したロールをそのユーザーに割り当てます。

POST /_security/user/sales_user1
{
  "password": "your_secure_password",
  "roles": ["sales_user_role"] # ロールを割り当て（複数指定可）
}

sales_user1は、sales_user_role の権限を持つことになります。(*2)²

ロールとユーザーとインデックスの関係を表した概念図を以下に記載します。

ロールとユーザーとンデックスの関係を図式化した例を２つ下記に挙げます。

ロールとユーザーの関係図（パターン1）

sales_user1 は、sales_user_role を持ちます。sales_user_role があるため、sales_data* のインデックスの読み取りが可能です。

hr_user2 は hr_user_role を持ちます。hr_user_role があるため、hr_data* のインデックスの読み取りが可能です。

sales_and_hr_user3 は、sales_user_role と hr_user_role を持ちます。sales_user_role と hr_user_role があるため、sales_data* および hr_data* インデックスの読み取りが可能です。

2. ロールとユーザーの関係図（パターン2）

sales_user4 は、sales_user_role を持ちます。sales_user_role があるため、sales_data* のインデックスの読み取りが可能です。

hr_user5 は hr_user_role を持ちます。hr_user_role があるため、hr_data* のインデックスの読み取りが可能です。

sales_and_hr_manager6 は、hr_and_sales_manager_role を持ちます。hr_and_sales_manager_role があるため、sales_data* および hr_data* インデックスへの読み書きが可能です。

主要な権限（Privileges）の種類

インデックスに対して割り当てられる主な権限には、以下のようなものがあります。(*3)³

read: ドキュメントの検索、取得を許可します。
write: ドキュメントの追加、更新、削除を許可します。
delete: ドキュメントの削除を許可します。
create_index: 新しいインデックスの作成を許可します。
manage: インデックス設定の変更、エイリアスの管理など、インデックスレベルの管理操作を許可します。
all: そのインデックスに対する全ての操作を許可します（管理者権限）。
view_index_metadata: インデックスのメタデータ（マッピングなど）の閲覧を許可します。

これらの権限を適切に組み合わせることで、きめ細やかなアクセス制御を実現できます。

アクセス制御におけるベストプラクティス

最小権限の原則 (Principle of Least Privilege): ユーザーには、その業務を遂行するために必要最小限の権限のみを付与するべきです。安易に all 権限や広範なインデックスへのアクセスを許可しないようにしましょう。
明確なロールの定義: ロールは、そのロールが持つべき権限を明確に反映するように命名し、定義します。
定期的なレビュー: アクセス制御の設定は、組織の変更やデータ要件の変更に合わせて定期的にレビューし、必要に応じて更新することが重要です。
ワイルドカードの活用: sales_data* のようにワイルドカードを使用することで、将来的に追加される類似のインデックスに対しても自動的にアクセス制御を適用できます。
X-Packセキュリティの活用: これらのアクセス制御機能は、ElasticsearchのX-Packセキュリティ（有償ライセンスが必要）によって提供されます。本番環境での利用には必須の機能と言えるでしょう。