Elastic StackのX-Packを試す（Security編）

藤本 真司

2016.10.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

検証時のX-Packのバージョンはrc1です。
GAリリース時は仕様が変わっている可能性もございますのでご注意ください。

こんにちは、藤本です。
Elastic Stackもrc1までリリースされました。これからはGAリリースに向けてバグフィックスが主なアップデートとなっていくことでしょう。

全6回で X-Pack をおさらいがてら機能を試しつつ、新機能を確認していきます。

今回はSecurityを試してみました。

X-Packを試すシリーズのその他のエントリは以下をご参照ください。

Security

ElasticsearchはWeb APIによるアクセスを提供していますが、標準機能ではユーザー認証や通信の暗号化を提供していません。今まではElasticsearchにこれらセキュリティ機能を実装したい場合、前段にApache httpdやNginxなどのWebサーバーを配置して構成していました。それがX-PackのSecurity（旧Shield）の登場によりElastic Stackだけでセキュリティ機能を実現することができるようになりました。更には、ユーザーへのRole割り当てにより、ユーザーに応じた結果を返すことができ、マルチテナント化して活用することができるようになります。私はこれが一番の魅力に感じました。

user-authentication(1)

ユーザー認証

Elastic StackのX-Packを試す（インストール編）でもご紹介しましたが、ElasticsearchのWeb APIにベーシック認証、Kibanaにログイン認証を提供します。ユーザー認証により登録されたユーザー名、パスワードを持った特定の利用者、アプリケーションのみのアクセスが可能となります。

ユーザー管理はインデックスによる管理、Elasticsearchサーバー上の設定ファイルによる管理、LDAP、Active Directoryといった外部認証との連携、PKIによる認証が可能となっています。

IPフィルタによる認証

ホワイトリスト、ブラックリストベースで送信元IPアドレスによるフィルタができます。

ロールによる認可

ユーザーへRoleを割り当てることにより、ユーザーが可能な操作を絞り込むことができます。絞り込み可能な権限は以下となります。

  • クラスタ権限：Elasticsearchクラスタに対しての操作権限
  • インデックス権限
    • 対象となるインデックス：操作可能なインデックス
    • 権限：インデックスに対して可能な操作権限。例えば読み取りのみ、読み書き、インデックスの作成/削除といった権限を指定可能です。
    • フィールド：取得可能なフィールド名
    • クエリ：デフォルトクエリ。_searchAPIを発行した時に必ず絞り込まれるクエリ

role-based(3)

またロールによるマルチテナント的な活用はElastic社の公式ブログにエントリがありますのでご参照ください。

Shieldを使用してユーザーの権限に応じた検索結果を取得する

通信の暗号化

Web API、KibanaへのアクセスをHTTPからHTTPSに変更することができます。

メッセージの整合性チェック

ノード間通信においてメッセージの改ざん、破損がないかチェックすることができます。

監査ログ

Elasticsearch、Kibanaへのアクセス状況を残すことができます。それにより不正アクセスや攻撃を分析することが可能です。ログ出力先はファイル、インデックスを指定可能です。インデックス指定することでKibanaでグラフ化できます。

Kibana_

監査ログはデフォルト設定では無効となっています。有効化する場合、elasticsearch.ymlファイルで有効設定、ログ出力先設定を行う必要があります。

# vi /etc/elasticsearch/elasticsearch.yml
以下を追記
xpack.security.audit.enabled: true
xpack.security.audit.outputs: [ index, logfile ]

インデックスは.security_audit_log-YYYY.MM.DDの命名規則でインデキシングされます。
ログファイルはRedHat系OSの場合、/var/log/elasticsearch/elasticsearch_access.logに出力されます。

新機能

ここからはX-Packから追加された新機能をご紹介します。

Kibanaによるユーザー管理

Kibanaの管理画面からユーザー管理を行えるようになりました。ユーザー管理、ロール管理を行えます。

ロール作成

まずロールを作成します。
Kibanaの管理画面へ遷移し、Roleを選択します。

Kibana 2

管理者用RoleやKibanaが利用するRoleなどがデフォルトで用意されています。

ロールを作成する場合、New Roleを選択します。

Kibana 3

設定項目を入力します。今回は特定インデックスからドキュメントを参照可能なRoleを作成します。

インデックス名はlogstash-*、権限はreadのみです。

Kibana 5

ロールが作成されました。

Kibana 4

ユーザー作成

次にユーザーを作成します。画面上部のUsersを選択します。

デフォルトでは管理者ユーザーのelastic、Kibana用ユーザーのkibanaが登録されています。ユーザーを作成する場合、New Userを選択します。

Kibana_5

設定項目を入力します。Roleには作成したUsersを追加します。

Kibana_5 2

ユーザーが作成されました。

動作確認

作成したユーザーでAPI発行が可能なことを確認します。

まずは権限を付与したインデックスへ、権限を与えているSearch API（read権限）を実行します。

# curl -u fujimoto "localhost:9200/logstash-*/_search?pretty"
Enter host password for user 'fujimoto':
{
  "took" : 50,
  "timed_out" : false,
  "_shards" : {
    "total" : 15,
    "successful" : 15,
    "failed" : 0
  },
  "hits" : {
    "total" : 14005,
    "max_score" : 1.0,
    "hits" : [

正常にクエリ結果が返ってきました。

次に権限を与えていないインデックスへアクセスしてみます。

# curl -u fujimoto "localhost:9200/noaccess/_search?pretty"
Enter host password for user 'fujimoto':
{
  "error" : {
    "root_cause" : [
      {
        "type" : "security_exception",
        "reason" : "action [indices:data/read/search] is unauthorized for user [fujimoto]"
      }
    ],
    "type" : "security_exception",
    "reason" : "action [indices:data/read/search] is unauthorized for user [fujimoto]"
  },
  "status" : 403
}

エラーが返ってきました。

次に権限を与えているインデックスへ、権限を与えていないDocs作成APIを実行します。

# curl -u fujimoto -XPOST "localhost:9200/logstash-20161001/log?pretty" -d '{"message":"testmessage"}'
Enter host password for user 'fujimoto':
{
  "error" : {
    "root_cause" : [
      {
        "type" : "security_exception",
        "reason" : "action [indices:data/write/index] is unauthorized for user [fujimoto]"
      }
    ],
    "type" : "security_exception",
    "reason" : "action [indices:data/write/index] is unauthorized for user [fujimoto]"
  },
  "status" : 403
}

エラーが返ってきました。

このようにKibanaから簡単にSecurityのユーザー管理を行えるようになりました。

フィールドレベルセキュリティの細やかな設定

Shield2系まではRoleに割り当てるフィールドは許可の指定しかできませんでした。

Shield2系の構文
{
  "indices": [
    {
      "names": [ "logstash-*" ],
      "privileges": ["read"],
      "fields": [
            "timestamp",
            "name",
            "message.*"
      ]
    }
  ]
}

X-Packからは除外設定ができるようになり、より細やかな設定が可能となりました。

X-Pack5系 Securityの構文
{
  "indices" : [
    {
      "names" : [ "logstash-*" ],
      "privileges" : [ "read" ],
      "field_security" : {
        "grant" : [ "*"],
        "except": [ "password" ]
      }
    }
  ]
}

まとめ

いかがでしたでしょうか？

Securityはセキュリティ要件が高いプロダクトには重要な機能を提供します。セキュリティ要件の壁を超えることができず、Elasticsearch導入が見送りになったり、力づくでセキュリティ機能を加えて複雑になってしまった環境があれば、X-Packの導入を検討してみてはいかがでしょうか？

スキルアップ|初心者向け|書評|デベキャン|AWS認定|スキルアップ|デベキャンだより|勉強会|コミュニティ

関連記事

ElasticSearchのDemo環境で、Kibana DevToolsのConsoleからcat APIを一通り叩いてみた。

横山嵩人

2023.05.19

ElasticSearchのDemo環境で、cat APIについて学んでみた

横山嵩人

2023.05.19