Elasticsearchのインデックスに対するアクセス制御（Kibana上での動作確認）

はじめに
1. 対象者
2. できるようになること
ロール(Role)の作成
ユーザー(User)の作成
インデックスの作成
インデックスのフィールドの作成
インデックスへのエイリアスの作成
ドキュメントの登録
ユーザーごとの動作確認
まとめ

はじめに

Elasticsearchのインデックスに対するアクセス制御（概要）で Elasticsearch におけるロールベースのアクセス制御（RBAC）の概要について説明しました。

今回は、実際にロールとユーザーを作成して、Kibana上での実際の動作を確認していきます。

対象者

– Elasticsearch 熟練度 : 初級者～中級者

– Elasticsearch License : Basic 以上

– Elasticsearch Version : 筆者は、8.15.0 で動作確認

できるようになること

– Elasticsearch でインデックス単位でのアクセス制御を行える。

ロール(Role)の作成

まず、Elasticsearchのインデックスに対するアクセス制御（概要）のパターン1、パターン2 で示したようなロールを作成していきます。

作成するロールは、以下の3つです。

ロール名	対象インデックス	許可する操作
sales_user_role	sales_data*	read, view_index_metadata
hr_user_role	hr_data*	read, view_index_metadata
sales_and_hr_manager_role	sales_data, hr_data	all

elastic ユーザーで Kibana にログインし、Dev Tools の Console から以下のリクエストを発行して、上記の3つのロールを作成します。(*1)¹

POST /_security/role/sales_user_role
{
  "cluster": [ "all" ],
  "indices": [
    {
      "names": ["sales_data*"],
      "privileges": ["read","view_index_metadata"]
    }
  ],
  "applications": [
    {
      "application": "kibana-.kibana",
      "privileges": [
        "space_all"
      ],
      "resources": [
        "space:default"
      ]
    }
  ],
  "run_as": [],
  "metadata": {},
  "transient_metadata": {
    "enabled": true
  }
}

POST /_security/role/hr_user_role
{
  "indices": [
    {
      "names": ["hr_data*"],
      "privileges": ["read","view_index_metadata"]
    }
  ],
  "applications": [
    {
      "application": "kibana-.kibana",
      "privileges": [
        "space_all"
      ],
      "resources": [
        "space:default"
      ]
    }
  ],
  "run_as": [],
  "metadata": {},
  "transient_metadata": {
    "enabled": true
  }
}

POST /_security/role/sales_and_hr_manager_role
{
  "cluster": [ "all" ],
  "indices": [
    {
      "names": ["hr_data*", "sales_data*"],
      "privileges": ["all"]
    }
  ],
  "applications": [
    {
      "application": "kibana-.kibana",
      "privileges": [
        "space_all"
      ],
      "resources": [
        "space:default"
      ]
    }
  ],
  "run_as": [],
  "metadata": {},
  "transient_metadata": {
    "enabled": true
  }
}

ユーザー(User)の作成

Elasticsearchのインデックスに対するアクセス制御（概要）のパターン1、パターン2 で示したようなユーザーを作成していきます。

作成するユーザーは、以下の4人です。

ユーザー名	保持するロール
sales_user1	sales_user_role
hr_user2	hr_user_role
sales_and_hr_user3	sales_user_role, hr_user_role
sales_and_hr_manager6	sales_and_hr_manager_role

Dev Tools の Console から以下のリクエストを発行して、上記の4つのユーザーを作成します。(*2)²

PUT /_security/user/sales_user1
{
  "password": "secret_password",
  "roles": ["sales_user_role"] 
}

PUT /_security/user/hr_user2
{
  "password": "secret_password",
  "roles": ["hr_user_role"] 
}

PUT /_security/user/sales_and_hr_user3
{
  "password": "secret_password",
  "roles": ["sales_user_role", "hr_user_role"]
}

PUT /_security/user/sales_and_hr_manager6
{
  "password": "secret_password",
  "roles": ["sales_and_hr_manager_role"] 
}

“secret_password” については、適宜、適切なパスワードに置き換えてください。

インデックスの作成

Elasticsearchのインデックスに対するアクセス制御（概要）のパターン1、パターン2 で示したようなインデックスを作成していきます。

作成するインデックスは、下記の4つです。

インデックス名	説明
sales_data_2024	2024年分の営業データ
sales_data_2025	2025年分の営業データ
hr_data_2024	2024年分の人事データ
hr_data_2025	2025年分の人事データ

Dev Tools の Console から以下のリクエストを発行して、上記の4つのインデックスを作成します。

PUT /sales_data_2024
{
  "settings": {
    "index": {
      "number_of_shards": 1,
      "number_of_replicas": 1
    }
  }
}

PUT /sales_data_2025
{
  "settings": {
    "index": {
      "number_of_shards": 1,
      "number_of_replicas": 1
    }
  }
}

PUT /hr_data_2024
{
  "settings": {
    "index": {
      "number_of_shards": 1,
      "number_of_replicas": 1
    }
  }
}

PUT /hr_data_2025
{
  "settings": {
    "index": {
      "number_of_shards": 1,
      "number_of_replicas": 1
    }
  }
}

インデックスのフィールドの作成

さきほど作成したインデックスへフィールドを作成していきます。

今回は、あくまでもアクセス権の確認のためのインデックスなので、必要最低限のフィールドのみとし、形態素解析については省略します。

4つのインデックスそれぞれに、以下の2つのフィールドを作成します。

フィールド名	フィールドタイプ	説明
@timestamp	date	ドキュメントの登録日時
content	text	ドキュメントの内容

Dev Tools の Console から以下のリクエストを発行して、上記の2つのフィールドを作成します。

PUT /sales_data_2024/_mapping
{
  "properties": {
    "@timestamp": {
      "type": "date"
    },
    "content": {
      "type": "text"
    }
  }
}

PUT /sales_data_2025/_mapping
{
  "properties": {
    "@timestamp": {
      "type": "date"
    },
    "content": {
      "type": "text"
    }
  }
}

PUT /hr_data_2024/_mapping
{
  "properties": {
    "@timestamp": {
      "type": "date"
    },
    "content": {
      "type": "text"
    }
  }
}

PUT /hr_data_2025/_mapping
{
  "properties": {
    "@timestamp": {
      "type": "date"
    },
    "content": {
      "type": "text"
    }
  }
}

インデックスへのエイリアスの作成

sales_data_2024, sales_data_2025, hr_data_2024, hr_data_2025 という4つのインデックスを作成しました。

このままでも操作は可能ですが、さらに操作しやすくなるよう、インデックスに対するエイリアスを作成します。

作成するエイリアスは以下の2つです。

エイリアス	対象となるインデックス名
sales_data	sales_data_*
hr_data	hr_data_*

Dev Tools の Console から以下のリクエストを発行して、上記の2つのエイリアスを作成します。

POST _aliases
{
  "actions": [
    {
      "add": {
        "index": "sales_data_*",
        "alias": "sales_data"
      }
    },
    {
      "add": {
        "index": "hr_data_*",
        "alias": "hr_data"
      }
    }
  ]
}

※最初にロールを作成しました。そのロールの中で対象インデックスを “sales_data*”, “hr_data*” と指定しましたが、これには今回作成したエイリアスも含まれます。

“sales_data*” に対する read 権限、というのは、

– sales_data_2024 インデックスへの読み取り権限

– sales_data_2025 インデックスへの読み取り権限

に加えて、

– sales_data エイリアスに対する読み取り権限

があることを意味します。

ドキュメントの登録

インデックスを作成したので、次はインデックスへドキュメントを登録します。

sales_and_hr_manager6 ユーザーに sales_data* インデックス、および hr_data* インデックスへの all 権限を与えているので、動作確認も兼ねて sales_and_hr_manager6 ユーザーで Kibana にログインし、ドキュメントを登録していきます。

POST /sales_data_2024/_doc
{
  "@timestamp": "2024-01-10",
  "content": "これは 2024-01-10の営業資料です。"
}

POST /sales_data_2025/_doc
{
  "@timestamp": "2025-01-11",
  "content": "これは 2025-01-11の営業資料です。"
}

POST /hr_data_2024/_doc
{
  "@timestamp": "2024-01-12",
  "content": "これは 2024-01-12の人事の資料です。"
}

POST /hr_data_2025/_doc
{
  "@timestamp": "2025-01-13",
  "content": "これは 2025-01-13の人事の資料です。"
}

ドキュメントが問題なく登録されます。

ユーザーごとの動作確認

ドキュメントを登録したので、ユーザーごとに動作確認していきます。

1. sales_and_hr_manager6 ユーザー

sales_and_hr_manager6 ユーザーでログインしているので、引き続き、検索も実行してみます。

GET /sales_data,hr_data/_search

登録した4件すべてのドキュメントがヒットします。

2. sales_user1 ユーザー

次に、sales_user1 ユーザーでログインしなおします。

sales_data インデックスに対する検索クエリーを発行してみます。

GET /sales_data/_search

sales_data_2024, sales_data_2025 インデックスのドキュメントがヒットします。

次に hr_data インデックスに対する検索クエリーを発行してみます。

GET /hr_data/_search

すると、hr_data* インデックスへの読み取り権が不足しているため、以下のようなエラーが返却されます。

{
  "error": {
    "root_cause": [
      {
        "type": "security_exception",
        "reason": "action [indices:data/read/search] is unauthorized for user [sales_user1] with effective roles [sales_user_role] on indices [hr_data], this action is granted by the index privileges [read,all]"
      }
    ],
    "type": "security_exception",
    "reason": "action [indices:data/read/search] is unauthorized for user [sales_user1] with effective roles [sales_user_role] on indices [hr_data], this action is granted by the index privileges [read,all]"
  },
  "status": 403
}

ためしに、sales_data_2025 インデックスへのドキュメントの登録リクエストを発行してみます。

POST /sales_data_2025/_doc
{
  "@timestamp": "2025-06-13",
  "content": "これは 2025-06-13の営業資料です。"
}

sales_data* インデックスへの書き込み権がないので、以下のようなエラーとなります。

{
  "error": {
    "root_cause": [
      {
        "type": "security_exception",
        "reason": "action [indices:data/write/index] is unauthorized for user [sales_user1] with effective roles [sales_user_role] on indices [sales_data_2025], this action is granted by the index privileges [create_doc,create,index,write,all]"
      }
    ],
    "type": "security_exception",
    "reason": "action [indices:data/write/index] is unauthorized for user [sales_user1] with effective roles [sales_user_role] on indices [sales_data_2025], this action is granted by the index privileges [create_doc,create,index,write,all]"
  },
  "status": 403
}

3. hr_user2 ユーザー

同様に、hr_user2 ユーザーでログインし、検索リクエストを発行してみます。

GET /sales_data/_search

sales_data* インデックスへの読み取り権がないため、エラーとなります。

GET /hr_data/_search

こちらは、hr_data_2024 インデックス、hr_data_2025 インデックス内のドキュメントがヒットします。

ためしに、hr_data_2025 インデックスへのドキュメントの登録リクエストを発行してみます。

POST /hr_data_2025/_doc
{
  "@timestamp": "2025-06-13",
  "content": "これは 2025-06-13の人事の資料です。"
}

hr_data* インデックスへの書き込み権がないので、エラーとなります。

4. sales_and_hr_user3 ユーザー

最後に sales_and_hr_user3 ユーザーでログインし、検索リクエストを発行してみます。

GET /sales_data,hr_data/_search

sales_data_2024, sales_data_2025, hr_data_2024, hr_data_2025 インデックスのドキュメントすべてがヒットします。

ためしに、ドキュメントの登録リクエストを発行してみます。

POST /sales_data_2025/_doc"@timestamp": "2025-06-13",
  "content": "これは 2025-06-13の営業資料です。"
}

POST /hr_data_2025/_doc
{
  "@timestamp": "2025-06-13",
  "content": "これは 2025-06-13の人事の資料です。"
}

sales_data* インデックス、hr_data* インデックス、ともに書き込み権がないため、いずれもエラーとなります。

以上の4つのユーザーでの動作をまとめると以下の表になります。

ユーザー	sales_data* インデックスへの操作	hr_data* インデックスへの操作
sales_user1	〇読み取り可	×読み書き不可
hr_user2	×読み書き不可	〇読み取り可
sales_and_hr_user3	〇読み取り可	〇読み取り可
sales_and_hr_manager6	◎読み書き可	◎読み書き可

まとめ

このように、ロールベースのアクセス制御を活用することにより、インデックスごとのアクセス制御ができることが確かめられました。

実際の現場でも要件に合わせて、ロールを適切に設定することで、情報漏洩やデータの破損などのリスクを軽減できることをおわかりいただけたかと思います。

API からリクエストを発行する方法以外に、Kibana からロールを作成することも可能です。

このリクエスト内には、インデックスへの操作以外に、applications などの指定も行っています。
厳密には、これらのアクセス権についても、きちんと考慮する必要がありますが、
今回はインデックスへのアクセス権を確かめることを目的としているので、これらについては深く掘り下げません。
↩︎
API からリクエストを発行する方法以外に、Kibana からユーザーを作成することも可能です。
↩︎