More than 5 years have passed since last update.

Elasticsearchのプラグイン「Shield」を利用してELKをセキュアに！！Kibanaにおける認証・認可を実現してみた

Posted at 2015-12-13

本記事の概要

ログ収集・解析の基盤としてELK（Elasticsearch + Logstash + Kibana）の構成がよく知られていますが、
その中でもログの管理・可視化を担うElasticsearch + Kibanaがメインの記事となります。
このKibanaですが、現状、認証・認可やセキュリティ対策のような機能は実装されておらず、
本格的な運用を考えたときに何とかしたいと思ったのが事の発端です。
認証・認可がないということは、例えば管理者となる人がKibanaにてVisualization（グラフ）やDashboard（グラフの集合）を作成したとしても、Kibanaにアクセス可能な人であれば誰でもそれらを改ざんすることが可能となってしまいます。
今回はElasticsearchの有償セキュリティプラグインである「Shield」を用いて、Kibanaの認証・認可を実現し、
Visualization、Dashboardをユーザに応じてRead Onlyにしてみようと思います。

※Kibanaの認証機能は当初4.2で導入される予定でしたが、今のところ4.4で導入予定となっています。
https://github.com/elastic/kibana/issues/3904

環境情報

OS：CentOS6.5 on VirtualBox + Vagrant
Logstash 2.1.1
Elasticsearch 2.1.0
Kibana 4.3.0
Java 1.8.65

公式サイト

Elasticsearch
https://www.elastic.co/products/elasticsearch
Logstash
https://www.elastic.co/products/logstash
Kibana
https://www.elastic.co/products/kibana
Shield
https://www.elastic.co/products/shield

事前準備

ELKインストール

Logstash

wget -P /usr/local/src/ https://download.elastic.co/logstash/logstash/packages/centos/logstash-2.1.1-1.noarch.rpm
rpm -ivh /usr/local/src/logstash-2.1.1-1.noarch.rpm

Elasticsearch

wget -P /usr/local/src/ https://download.elasticsearch.org/elasticsearch/release/org/elasticsearch/distribution/rpm/elasticsearch/2.1.0/elasticsearch-2.1.0.rpm
rpm -ivh /usr/local/src/elasticsearch-2.1.0.rpm

Kibana

wget -P /usr/local/src/ https://download.elastic.co/kibana/kibana/kibana-4.3.0-linux-x64.tar.gz
tar xzvf /usr/local/src/kibana-4.3.0-linux-x64.tar.gz -C /opt

※ ELKを起動させるためには、Javaがインストール済みであることが前提となります。

ELK連携

Logstashのinput-twitter-pluginを利用してタイムラインをElasticsearchへ取り込み、Kibanaで可視化できるようにしておきます。
本旨ではないですがクリスマス目前ということで「Xmas」をキーワードにタイムラインを収集してみます。

Logstash設定

/etc/logstash/conf.d/twitter.conf

input {
    twitter {
        consumer_key => "<consumer_key>"
        consumer_secret => "<consumer_secret>"
        oauth_token => "<oauth_token>"
        oauth_token_secret => "<oauth_token_secret>"
        keywords => ["Xmas"]
        full_tweet => true
        ignore_retweets => true
    }
}
output {
    elasticsearch {
    }
    stdout {
        codec => rubydebug
    }
}

※ consumer_key、consumer_secret、oauth_token、oauth_token_secretには、Twitter Appsにて登録したアプリケーションのものを使用します。
参考：http://dev.classmethod.jp/cloud/aws/twitter-visualize-using-elastic/

Elasticsearch起動

service elasticsearch start

Kibana起動

/opt/kibana-4.3.0-linux-x64/bin/kibana &

Logstash起動

service logstash start

ログ連携確認

Kibana上からタイムラインが連携されていることを確認します。

セキュリティ設定

下準備ができたところで、いよいよKibanaに対する認証・認可を実現していきます。

Shieldインストール

まずはElasticsearchのセキュリティプラグイン「Shield」をインストールします。
このプラグインは有償のサブスクリプションとして提供されていますが、30日間は試用ライセンスとして試すことができます。

/usr/share/elasticsearch/bin/plugin install elasticsearch/license/latest
/usr/share/elasticsearch/bin/plugin install elasticsearch/shield/latest

認証（Authentication）

Shieldにおける認証の考え方

Shieldではユーザの資格情報を受け取りチェックする認証メカニズムを「レルム」と定義し、
4タイプの「レルム」をサポートしてます。

esusers
Shieldに組み込まれたネイティブの認証システムとなります。（デフォルト）
ファイルベースのレルムとなり、コマンドラインからユーザの追加・削除等を実行することができます。
LDAP
外部のLDAPサーバでユーザを認証するレルムとなります。
Active Directory
外部のActive Directoryサーバでユーザを認証するレルムとなります。
PKI
公開鍵を利用して認証を行うレルムとなります。

今回はデフォルトのままesusersレルムを利用したいと思います。

ユーザ追加

esusersレルムにおけるユーザの追加はesusersコマンドによって実施できますが、
ユーザの追加の前に、先に認可に触れておきたいと思います。

認可（Authorization）

Shieldにおける認可の考え方

Shiledではユーザ毎の権限管理を、ロールベースのアクセスコントロール（RBAC）モデルによって実現します。
端的言えば、各ロールにパーミッションの集合が定義されており、各ユーザはロールの集合に紐付くモデルとなります。

ロール定義

Shildのロールは roles.yml で定義されます。
デフォルトでも管理者用のロールadminなどいくつかのロールが定義されています。

/etc/elasticsearch/shield/roles.yml

# All cluster rights
# All operations on all indices
admin:
  cluster: all
  indices:
    '*':
      privileges: all

# Monitoring cluster privileges
# All operations on all indices
power_user:
  cluster: monitor
  indices:
    '*':
      privileges: all

# Only read operations on indices
user:
  indices:
    '*':
      privileges: read

# Only read operations on indices named events_*
events_user:
  indices:
    'events_*':
      privileges: read

ShieldではElasticsearchの権限をclusterとindicesという大きく2つのタイプで分類しています。
clusterはElasticsearchのクラスタ全体の管理・監視アクションに対する権限を定義します。
indicesはクラスタ内の特定のインデックスに対する管理・監視アクションに対する権限を定義します。

またclusterと各indexに対する権限は、all, monitor, read, writeなど予め定義された権限を設定することができますが、次のようにより細かく特定のロールに特定のアクションを指定することもできます。

user01:
  indices:
    '*':
      privileges: indices:admin/create, indices:admin/exists

ロール追加

前置きが長くなりましたが、今回Kibanaでは以下3つのロールを利用しようと思います。

kibana4_server：Kibanaサーバ用のロール
kibana4：Kibana管理ロール（Visualization、Dashboardの読取・作成・更新・削除可）
kibana4_monitor：Kibana監視ロール（Visualization、Dashboardは読取のみ可）

kibana4_serverロール、kibana4ロールはデフォルトの定義を利用し、kibana4_monitoringロールを新規に作成します。¹
roles.ymlを編集し、以下を追記します。

/etc/elasticsearch/shield/roles.yml

# The required permissions for the kibana 4 monitor
kibana4_monitoring:
  cluster:
      - cluster:monitor/nodes/info
      - cluster:monitor/health
  indices:
    'logstash-*':
      - indices:admin/get
      - indices:admin/mappings/fields/get
      - indices:admin/validate/query
      - indices:data/read/search
      - indices:data/read/msearch
      - indices:data/read/field_stats
    '.kibana':
      - indices:admin/exists
      - indices:admin/get
      - indices:admin/mapping/put
      - indices:admin/mappings/fields/get
      - indices:admin/refresh
      - indices:admin/validate/query
      - indices:data/read/mget
      - indices:data/read/search
      - indices:data/read/msearch
      - indices:data/read/field_stats

kibana4ロールの定義と比較するとわかりますが、
.kibanaインデックスのデータに対するwrite権限が除外されている形になります。

/etc/elasticsearch/shield/roles.yml

# The required permissions for kibana 4 users.
kibana4:
  cluster:
      - cluster:monitor/nodes/info
      - cluster:monitor/health
  indices:
    '*':
      privileges: indices:admin/mappings/fields/get, indices:admin/validate/query, indices:data/read/search, indices:data/read/msearch, indices:admin/get
    '.kibana':
      privileges: indices:admin/exists, indices:admin/mapping/put, indices:admin/mappings/fields/get, indices:admin/refresh, indices:admin/validate/query, indices:data/read/get, indices:data/read/mget, indices:data/read/search, indices:data/write/delete, indices:data/write/index, indices:data/write/update

各種ユーザ作成

上記で作成したロールに紐付くユーザをそれぞれ作成します。
esusersコマンドのuseraddオプションに「作成するユーザ名」、-rオプションに「紐付けるロール名」を指定します。
コマンド実行後にパスワードの入力を求められます。

# Kibanaサーバ用ユーザ
/usr/share/elasticsearch/bin/shield/esusers useradd kibana4_server -r kibana4_server
# Kibana管理用ユーザ
/usr/share/elasticsearch/bin/shield/esusers useradd kibana4 -r kibana4
# Kibana監視用ユーザ
/usr/share/elasticsearch/bin/shield/esusers useradd kibana4_monitor -r kibana4_monitoring

Kibana設定

Kibanaの設定ファイル/config/kibana.ymlを編集し、Kibanaサーバユーザの定義を追加します。

/opt/kibana-4.3.0-linux-x64/config/kibana.yml

elasticsearch.username: "kibana4_server"
elasticsearch.password: "password"

上記の設定まで完了しましたらElasticsearch、Kibanaともに再起動し、Kibana画面上から確認してみます。²

確認

Kibana管理ユーザでログイン

Kibanaにアクセスすると、ユーザ名・パスワードのの入力を求められますので、Kibana管理者ユーザでログインします。

Visualization、Dashboard作成

適当にVisualizationを作成してDashboardに設定し、「dashboard_twitter」という名前で保存します。
管理者なので問題なく保存できます。

Kibana4.2から黒Dashboardが再び選択できるようになりましたが、やはり黒の方がカッコいい！！

Kibana監査ユーザでログイン

ブラウザを立ち上げ直し再度Kibanaにアクセスし、今度はKibana監視ユーザでログインします。

Visualization、Dashboard読込

先ほど管理ユーザで作成したDashboard「dashboard_twitter」を開きます。
ここまでは問題ないですね。

Visualization、Dashboard編集・保存

ここからが本題です。Dashboardを編集して保存してみましょう。
ここではVisualizationを2つ削ってみました。

権限エラー

キターーーー(・∀・)ーーー！！ばっちり権限エラーとなってますね。
別途Visualizationの新規作成等も試してみましたがこちらも想定通りエラーとなりました。

まとめ

いかがでしたでしょうか。
ビジネスでELKを利用するとなると、ここら辺のセキュリティに対する考慮は避けて通れない部分かと思います。
有償プラグインとなりますが利用価値は大きいと考えています。
「Shield」では本日紹介した「認証」「認可」以外にも「監査証跡ログ出力」や「暗号化通信」、「IPフィルタリング」等もサポートしていますので機会があれば試してみようと思います。

また、本日紹介した方法以外のベストプラクティスがあればご教示ください。

参考（公式サイト以外）

厳密にはデフォルトの設定にindices:data/read/field_statsを追加しています。 ↩
当記事では割愛してますがShield設定後に、LogstashからElasticsearchに連携するためにはLogstash用のユーザを設定（esusersコマンドでのlogstashユーザ追加、elasticsearch-output-pluginへのユーザ設定追加）する必要があります。 ↩

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up