...

Splunk Enterprise 6.3.0 Splunk Enterprise のセキュリティ

by user

on
Category: Documents
1121

views

Report

Comments

Transcript

Splunk Enterprise 6.3.0 Splunk Enterprise のセキュリティ
Splunk Enterprise 6.3.0
Splunk Enterprise のセキュリティ
作成⽇時:9/15/2015 10:22 am
Copyright (c) 2016 Splunk Inc. All Rights Reserved
Table of Contents
Splunk Enterpri se のセキュリティについて
Splunk Enterprise のセキュリティについて
Splunk の保護
5
5
5
Splunk の安全なインストール
Splunk Enterprise の安全なインストール
ネットワーク上の Splunk Enterprise の保護
サーバーとオペレーティングシステムのベストプラクティス例
設定の保護強化
不要な Splunk Enterprise コンポーネントの無効化
5
5
6
6
6
7
ユーザーおよびロールベースのアクセス制御
Splunk データを保護するための、アクセス制御の使⽤
ユーザー認証について
ロールベースのユーザーアクセスの設定について
権限を持つロールの定義について
Splunk Web を使ったロールの追加と編集
authorize.conf を使ったロールの追加と編集
管理コンソールと App へのアクセスの設定
既存のユーザーやロールの検索
すべてのユーザーアカウントの削除
Splunk ナレッジオブジェクトへのアクセスの保護
7
7
7
8
9
10
11
13
14
14
14
Splunk Enterpri se のビルトイン認証を使ったユーザーの設定
Splunk Enterprise のネイティブ認証を使ったユーザー認証の設定
Splunk Web を使ったユーザーの設定
CLI を使ったユーザーの設定
Splunk Web によるロールへのユーザーの追加
15
15
15
15
16
LDAP によるユーザー認証の設定
LDAP によるユーザー認証の設定
LDAP を使った Splunk ユーザーロールの管理
LDAP の前提条件と検討事項
Splunk が複数の LDAP サーバーと連携する仕組み
Splunk Web による LDAP の設定
Splunk Web を使った LDAP グループの Splunk ロールへのマップ
設定ファイルによる LDAP の設定
設定ファイルでの LDAP グループ/ユーザーの Splunk ロールへの
マップ
LDAP 設定のテスト
Splunk のビルトイン認証から LDAP への変換
LDAP ユーザー削除のベストプラクティス
16
16
17
17
17
18
21
21
23
外部システムによるユーザー認証の設定
外部システムによるユーザー認証の設定
認証スクリプトの作成
authentication.conf の編集
PAM 認証の使⽤
サーチ時の getSearchFilter 関数を使ったフィルタリング
24
24
25
27
28
28
SAML によるシングルサインオン設定
SAML によるシングルサインオンについて
Splunk Web における SAML SSO の設定
28
28
29
23
23
24
グループのロールへのマップ
設定ファイルにおける SAML SSO の設定
SAML SSO のトラブルシューティング
30
31
32
リバースプロキシによるシングルサインオンの設定
リバースプロキシによるシングルサインオンについて
リバースプロキシによるシングルサインオンの設定
リバースプロキシ SSO のトラブルシューティング
33
33
35
36
SSL を使った Splunk Enterpri se の保護について
SSL を使った Splunk の保護について
Windows および Linux での SSL ツールの使⽤について
許可/制限する SSL バージョンの設定
37
37
38
39
SSL 証明書の取得
証明書の⾃⼰署名⽅法
次のステップ
サードパーティが署名した証明書の⼊⼿⽅法
Splunk ⽤の署名された証明書の準備⽅法
Splunk Web ⽤の⾃⼰署名証明書
Splunk Web ⽤のサードパーティが署名した証明書の⼊⼿
暗号スイートの決定
40
40
42
42
44
45
48
49
SSL による ブラウザから Splunk Web への通信の保護
Splunk Web の保護について
Splunk Web で暗号化 (https) を有効にする
web.conf で暗号化 (https) を有効にする
独⾃の証明書を使った Splunk Web の保護
Splunk Web 認証のトラブルシューティング
50
50
50
51
51
52
SSL による Splunk フォワーダーからインデクサーへの通信の保護
フォワーダーからのデータの保護について
デフォルトの証明書を使⽤する Splunk 転送の設定
独⾃の証明書を使⽤するための、Splunk 転送の設定
その他の設定オプション
設定の検証
フォワーダー/インデクサー認証のトラブルシューティング
52
53
53
54
55
56
57
SSL を使った Splunk 間通信の保護
Splunk 間通信の保護について
Splunk Web と splunkd 間の通信の保護
分散サーチヘッドとピアの保護
デプロイサーバーとクライアントの保護
クラスタの保護について
デフォルト値を使った Splunk 間通信について
57
57
58
58
58
59
59
Splunk Enterpri se アクティビティの監査
Splunk を使ったシステムアクティビティの監査
Splunk アクティビティの監査
監査イベントのサーチ
データ統合性の管理
60
60
60
60
61
Splunk Enterpri se のパスワードとアクセスのセキュリティ
複数のサーバーへの保護パスワードのデプロイ
サービスアカウントの保護
Splunk Enterprise のアクセス制御リストの使⽤
62
62
62
62
Splunk Enterprise のセキュリティについて
Splunk Enterprise のセキュリティについて
新しくインストールまたはアップグレードした Splunk Enterprise の設定が完了し、使⽤を開始したらすぐに、
Splunk Enterprise とデータを保護するためにいくつかの作業を実施する必要があります。適切な⼿順を踏んで
Splunk Enterprise を保護すれば、攻撃の⼿がかりを減らし、脆弱性のリスクや影響を低減することができます。
Splunk の保護
このマニュアルは、ご利⽤の Splunk 設定の保護、および以下の設定⽅法について説明しています。
ユーザー認証 の設定によるユーザーの作成と、ロール の割り当てによるユーザーアクセスの管理。
SSL を使った、Splunk 設定の通信の保護。
監査 を使ったデータの保護。
脆弱性やリスクを減らすための、Splunk インスタンスの強化。
ユーザー認証とロールベースのアクセス制御
ユーザーを設定して、アクセスを制御するためにロールを使⽤します。Splunk では 3 種類の⽅法でユーザーを設
定できます。
Splunk にビルトインされている独⾃のシステム、「Splunk 認証システムを使ったユーザー認証の設定」を
参照してください。
LDAPに関する説明は「LDAP によるユーザー認証の設定」を参照してください。
外部認証システム (PAM や RADIUS など) を使⽤するためのスクリプトによる認証 API、「外部システム
を使ったユーザー認証の設定」を参照してください。
ユーザーを設定したら、権限やアクセスレベルを決定、制御するロールを割り当てられます。ロールと権限の詳細
は、「ロールベースのユーザーアクセスについて」を参照してください。
SSL を使った暗号化と認証
Splunk にはデフォルトの証明書とキーのセットが⽤意されており、これを有効にするとデータの暗号化とデータ
圧縮機能を利⽤することができます。また独⾃の証明書とキーを使って、ブラウザと Splunk Web 間の通信や
フォワーダーからレシーバー (インデクサーなど) に送信されるデータを保護することができます。
特定の条件下では、分散サーチ環境での通信、デプロイサーバーからクライアントに送信される設定データ、
Splunk Web から splunkd への通信などを保護することもできます。
SSL を使った Splunk 通信の保護⽅法の詳細は、このマニュアルの「SSL を使った Splunk の保護について」を
参照してください。
監査
Splunk 内のアクティビティに注意してください (例えば、サーチや設定変更など)。
モニター
モニター機能とホワイトリストを使ってすべての .conf ファイルのインデックスを作成することができま
す。また、Splunk がサポートしている⼤部分の OS で、システムベースのモニター機能を利⽤して、ユー
ザー属性の変更をモニターできます。
モニターの詳細は、『データの取り込み』マニュアルの「ファイルとディレクトリのモニター」を参照して
ください。
監査イベント
監査イベントをモニターして、Splunk インスタンスを監視することができます。監査イベントは、サー
チ、設定の変更、管理作業などを⽬的に、誰かが Splunk インスタンスにアクセスした時に⽣成されます。
各監査イベントには、どこの何がいつ変更され、誰が変更を⾏ったかに関する情報が記録されています。監
査イベントは、分散 Splunk 環境で、多数の Splunk サーバーに対する設定やアクセス制御の変更を検出す
る場合に特に役⽴ちます。
詳細は、このマニュアルの「Splunk Enterprise アクティビティの監査」を参照してください。
Splunk の安全なインストール
Splunk Enterprise の安全なインストール
Splunk のダウンロード、インストール時には、以下の⼿順に従ってください。
整合性の検証
MD5 や SHA-512 などのハッシュ機能を使ってハッシュを⽐較して、Splunk Enterprise ダウンロードを検証し
ます。信頼できるバージョンの OpenSSL を使⽤してください。例:
./openssl dgst -md5 <filename-splunk-downloaded.zip>
または
./openssl dgst -sha512 <filename-splunk-downloaded.zip>
5
署名の検証
ダウンロードした RPM パッケージの信頼性は、以下のように GnuPG 公開鍵を使って検証することができます。
1. GnuPG 公開鍵ファイル (このリンクは TLS 経由) をダウンロードします。
2. 鍵のインストールには、以下のコマンドを使⽤します。
rpm --import <filename>
3. 次のコマンドでパッケージの署名を検証します:
rpm -K <filename>
ネットワーク上の Splunk Enterprise の保護
ある状況下では、Splunk Enterprise ポートが攻撃の影響を受けやすくなることがあります。Splunk Enterprise
設定をインターネットから遮断して、アクセスを防⽌しましょう。
可能ならば、ホストベースのファイアウォールを使って、Splunk Web、管理ポート、データポートへのアクセス
を制限してください。Splunk Enterprise をホストベースのファイアウォール内で保護してください。リモート
ユーザーは、VPN 上の Splunk Enterprise にアクセスさせるようにしてください。
次の⽅法で、Splunk Enterprise を外部の攻撃から防ぐことも可能です。
ホストファイアウォールの背後に配置して、このポートをローカル呼び出し専⽤に制限するように、CLI セ
キュリティを制限します。
必要ではない限り、フォワーダーのポートへのアクセスは許可しないでください。
Splunk Enterprise は、信頼できるマシンのみがアクセスできる、分離されているネットワークセグメント
にインストールしてください。
ポートへのアクセスを、必要な接続のみに制限します。必要な接続を以下に⽰します。
エンドユーザーと管理者には、Splunk Web へのアクセスが必要です (デフォルトでは TCP ポート
8000)。
サーチヘッドは、管理ポート (デフォルトでは TCP ポート 8089) でサーチピアにアクセスする必要が
あります。
デプロイクライアントは、管理ポート (デフォルトでは TCP ポート 8089) でデプロイサーバーにアク
セスする必要があります。
フォワーダーは、インデックスサーバーデータポート (デフォルトでは TCP ポート 9997) にアクセス
する必要があります。
リモート CLI 呼び出しは、管理ポートを使⽤します。
サーバーとオペレーティングシステムのベストプラクティス例
オペレーティングシステム
すべての Splunk サーバーの OS のセキュリティを強化することを強くお勧めします。
社内セキュリティ標準ガイドラインがない場合は、CIS セキュリティ強化規則をお勧めします。
最低でも、Splunk サーバーへのシェル/コマンドラインアクセスを制限してください。
Splunk
Splunk インスタンスを冗⻑構成にして、両⽅に同じデータコピーのインデックスを作成させます。
Splunk のデータと設定を定期的にバックアップしてください。
定期的にバックアップから Splunk を復元して、正常に復元できるかどうかをテストしてください。
MD5 などのハッシュ機能を使ってハッシュを⽐較して、Splunk ダウンロードを検証します。例:
./openssl dgst md5 <filename-splunk-downloaded.zip>
クライアントのブラウザ
Firefox や Internet Explorer などの、サポートしているブラウザの最新バージョンを使⽤してください。
Firefox の noscript や Internet Explorer 8 のフィルタどの、クライアントサイド JavaScript ブロック機能
を利⽤して、XSS、XSRF、その他類似の不正使⽤を防⽌してください。
ユーザーには、最新版の Flash をインストールしていることを確認させてください。
物理的なセキュリティ
すべての Splunk サーバーへの物理的なアクセスを制限してください。
Splunk エンドユーザーに、物理セキュリティとエンドポイントセキュリティについて教育してください。
Splunk Web のユーザーセッションタイムアウトに短めの時間を設定してください。詳細は、「タイ
ムアウトの設定」を参照してください。
設定の保護強化
6
設定を保護するために、以下の事項を検討してください。
subversion などの設定管理ツールを使って、Splunk 設定のバージョンコントロールを⾏ってください。
Splunk 設定の変更を、既存の変更管理フレームワークと統合してください。
Splunk に⾃⼰の設定ファイルをモニターさせて、変更時にはアラートを⽣成するようにしてください。
不要な Splunk Enterprise コンポーネントの無効化
単⼀サーバー Splunk Enterprise デプロイ環境:
フォワーダーでは、Splunk Web を実⾏しないでください。また、TCP または UDP ポート、または他の
Splunk Enterprise インスタンスからデータを受信するように設定しないでください。
マルチサーバー Splunk Enterprise デプロイ環境:
サーチヘッドは、TCP/UDP ポートまたは他の Splunk Enterprise インスタンスからデータを受信しないよ
うにしてください。
ユーザーが分散環境のインデクサー上の Splunk Web にログインしない場合は、インデクサーの Splunk
Web を無効にしてください。
フォワーダーでは、Splunk Web を実⾏しないでください。また、TCP または UDP ポート、または他の
Splunk インスタンスからデータを受信するように設定しないでください。
ユーザーおよびロールベースのアクセス制御
Splunk データを保護するための、アクセス制御の使⽤
このページは現在作業中で、まもなく更新される予定です。
Splunk のロールベースのアクセス制御を利⽤すれば、柔軟で効率的に Splunk データを保護することができま
す。場合によっては、ロールベースのアクセス制御によるデータ保護の⽅が、暗号化や SSL 証明書よりも効果的
(かつ設定が簡単) なこともあります。
Splunk がユーザーのデータへのアクセスを制御する⽅法は、リレーショナルデータベースのロールベースのアク
セス制御のように考えることができます。場合によっては、データのセグメント化が必要な場合もあります。ただ
し、それ以外の場合は、プレゼンテーション層でサーチと結果を制御することで (Splunk App の⼤半でできる対
処)、セキュリティニーズを満たせることもあります。
設定⽅法を考慮して、ロールベースのアクセスがご⾃分のニーズを満たすかどうかを判断する場合の使⽤事例を検
討してみましょう。例:
機密データを持つ可能性があるシステムへのアクセスを許可するだけでも法的な危険が伴う、とても機密性
の⾼いデータの場合、複数の Splunk インスタンスをインストールして、それぞれのインスタンスに対象と
するユーザー⽤のデータを提供するように設定することを検討してください。
意図的または意図しないで機密データを不適切なユーザーに暴露した場合、法的な問題が発⽣する可能性が
あります。そのような場合は、権限のあるアカウント⽤および権限のないアカウント⽤のインデックスを作
成し、それを各アクセスレベルに対応したロールに割り当てることを検討してください。
セキュリティ上の考慮事項があるけれども、法的な危険性がさほど⾼くない場合は、App を使ってアクセス
を制限することができます。たとえば、静的ダッシュボードを持つ App を作成し、それらのダッシュボー
ドで参照できる情報が少ないロールを割り当てて、そのロールを持つユーザーがアクセスできる情報の種類
を制限することができます。
編集済みデータのフィールド暗号化、サーチ除外、およびフィールドのエイリアス化も、サーチ対象を制限
するための有益な⼿段です。
ユーザー認証について
Splunk Enterprise 認証機能により、追加したユーザーにロール を割り当てて、必要に応じてそれらのロールに
独⾃のアクセス権を与えることができます。
Splunk では、3 種類の認証システムがサポートされています。
Splunk 独⾃のビルトインシステム:Splunk のデフォルトロール、Admin 、Power 、または User に加え
て、権限 のリストを使って独⾃のロールを定義することができます。Enterprise ライセンスの Splunk で
は、デフォルトでビルトインの認証が有効になっています。詳細は、「Splunk ビルトインシステムのユー
ザー認証の設定」を参照してください。
LDAP:Splunk は、その内部認証サービスまたは既存の LDAP サーバーによる認証をサポートしていま
す。詳細は、「LDAP によるユーザー認証の設定」を参照してください。
スクリプトによる認証 API:スクリプトによる認証を利⽤して、Splunk の認証機能と RADIUS や PAM な
どの外部認証システムを統合することができます。詳細は、「外部システムによるユーザー認証の設定」を
参照してください。
注意: ネイティブ認証、LDAP 、およびスクリプト認証を含めた認証機能は、Splunk Free では利⽤できませ
ん。
Splunk Web を使って、または authorize.conf を編集することで、ユーザーを柔軟に作成したり、ロールに割り
7
当てたりすることができます。ロールと権限の詳細は、「ロールベースのユーザーアクセスについて」を参照して
ください。
重要: Splunk のビルトインシステムは、他の外部システムよりも常に優先されます。Splunk によるユーザーの
認証順序を以下に⽰します。
1. Splunk ビルトイン認証
2. LDAP またはスクリプト認証 (有効な場合)。
ロールベースのユーザーアクセスの設定について
Splunk Enterprise を利⽤している場合、パスワードを持つユーザーを作成して、それにロール を割り当てるこ
とができます。ユーザーのアクセス権限 は、割り当てられているロールによって決まります。
ユーザーの詳細は、「ユーザー認証について」を参照してください。
デフォルトで、Splunk には以下のロールがあらかじめ定義されています。
admin:このロールは、ユーザー、オブジェクト、設定のすべて (または⼤部分) を管理する管理者向けに⽤
意されており、ほぼすべての権限 が割り当てられています。
power (パワー):このロールはすべての共有オブジェクト (保存済みサーチなど)、アラート、タグイベント
の編集、およびその他の類似の作業を⾏うことができます。
user (ユーザー):このロールは、⾃⼰の保存済みサーチの作成と編集、サーチの実⾏、⾃⼰の基本設定の編
集、イベントタイプの作成と編集、およびその他の類似の作業を⾏うことができます。
can_delete:このロールは、ユーザーにキーワードによる削除を許可します。この権限は、delete サーチコ
マンドを使⽤する場合に必要になります。
独⾃のロールを作成して、それをユーザーに割り当てることも可能です。独⾃のロール (カスタムロール) を作成
する場合は、以下の事項を決定します。
許可するサーチ:ロールを割り当てるユーザーが実施できるサーチを定義することができます。
ロールの継承:あるロールに既存の 1 つまたは複数のロールからの、特定のプロパティを継承させることが
できます。ロールの継承については、このトピックの後半で説明しています。
権限の割り当て:ロールを割り当てるユーザーに許可するアクション (パスワードの変更、フォワーダー設
定の変更など) を指定することができます。詳細は、「権限を持つロールの定義について」を参照してくだ
さい。
許可するインデックスとデフォルトインデックスの設定:特定のインデックスにアクセスを制限し、デフォ
ルトでサーチ対象とするインデックスを設定することができます。
Splunk Web を使ってロールを作成する⽅法については、「Splunk Web を使ったロールの追加と編集」を参照
してください。authorize.conf を編集してロールを作成する⽅法については、「authorize.conf を使ったロールの
追加と編集」を参照してください。
継承
原則的に、複数のロールに割り当てられたメンバーは、もっとも幅広い権限を持つロールからプロパティを継承し
ます。
ユーザーのサーチフィルタ制限の継承⽅法
他のロールの特性を継承するロールを作成することができます。複数のロールに割り当てられたユーザーは、それ
らのロールのプロパティを継承します。
サーチフィルタの場合、ユーザーが異なるサーチフィルタを持つ複数のロールに割り当てられた場合、すべての
フィルタが結合され、各ロールの制限が適⽤されます。
たとえばデフォルトでは、Power および User ロールには、サーチを制限するサーチフィルタが定義されていませ
ん。ユーザーがこれらのロールと⼀緒に他のフィルタが定義されているロール (例:srchFilter=x) に割り当てら
れた場合、フィルタ設定のないロールにも割り当てられていますが、ユーザーはフィルタが定義されているロール
の制限を継承します。
ユーザーに許可されているインデックスの継承⽅法
許可されているインデックスの場合、ユーザーには割り当てられているロールの中で最⾼レベルのアクセスが許可
されているロールのアクセス権が与えられます。
たとえば、ユーザーが特定の 1 つのインデックスのみへのアクセスが許可されているロール「⼀般ユーザー」に
割り当てられている場合に、より多くの権限が許可されておりすべてのインデックスにアクセスできるロール「⾼
度なユーザー」にも割り当てられていると、そのユーザーはすべてのインデックスにアクセスすることができま
す。「⾼度なユーザー」の権限を与えながら、「⼀般ユーザー」に定義されている 1 つのインデックスへのアク
セスのみに制限したい場合は、そのような設定を持つロールを新たに作成する必要があります。
ユーザーの権限の継承⽅法
権限の場合、ユーザーには各ロールに許可されている最⾼レベルの権限が与えられます。
たとえば、ほぼすべての権限が与えられている「Admin」ロールに割り当てられているユーザーが、別の権限
セットが与えられている「⾼度なユーザー」ロールにも割り当てられている場合、ユーザーは両⽅のロールの権限
を持つことになります。
8
権限を持つロールの定義について
Splunk Web でユーザーを作成する場合、ユーザーを 1 つのロールに割り当てます。詳細は、「ロールベースの
ユーザーアクセスについて」を参照してください。
各ロールには、⼀連の権限 が含まれています。新たな、既存の、またはデフォルトのロールの権限を追加、編集
することができます。たとえば、データ⼊⼒の追加または保存済みサーチの編集を⾏うための権限をロールに追加
することができます。
Splunk Web を使ったロールへの権限の追加、変更⽅法については、「Splunk Web を使ったロールの追加と編
集」を参照してください。authorize.conf を編集してロールを作成する⽅法については、「authorize.conf を使っ
たロールの追加と編集」を参照してください。
利⽤可能な権限の⼀覧
このリストには、任意のロールに追加できる権限が記載されています。このリストの最新版については、
authorize.conf を確認してください。Admin ロールには、「delete_by_keyword」を除く、このリスト内のすべ
ての権限が与えられています。
権限名
できること
accelerate_datamodel
データモデルの⾼速化を有効または無効にします。
accelerate_search
レポートの⾼速化を有効または無効にします。ロールがこれを使⽤するに
は、schedule_search 権限も必要です。
admin_all_objects
システム内の任意のオブジェクトにアクセス、変更します (ユーザーオブジェク
ト、サーチジョブなど)。(オブジェクトに設定された任意の制限に優先します。)
change_authentication
認証設定の変更と認証の再読込を⾏います。
change_own_password
ユーザーが各⾃のパスワードを変更できます。
delete_by_keyword
サーチで削除演算⼦ (delete) を使⽤します。
edit_deployment_client
デプロイクライアント設定を変更します。
edit_deployment_server
デプロイサーバー設定を変更します。
edit_dist_peer
分散サーチ⽤のピアを追加、編集します。
edit_forwarders
フォワーダー設定を変更します。
edit_httpauths
ユーザーセッションを編集、終了します。
edit_input_defaults
データ取り込みのデフォルトホスト名を変更します。
edit_monitor
データ⼊⼒を追加したり、監視対象ファイルの設定を編集したりします。
edit_roles
ロールの編集とユーザー/ロールのマッピングの変更を⾏います。
edit_scripted
スクリプトを使⽤したデータ取り込みを作成、編集します。
edit_search_head_clustering
サーチヘッドクラスタリング設定を編集します。
edit_search_server
タイムアウト、ハートビート、ブラックリストなどの、全般的な分散サーチを編集
します。
edit_server
サーバー名やログレベルなどの、全般的なサーバー設定を編集します。
edit_splunktcp
他の Splunk インスタンスからの TCP ⼊⼒の受信設定を変更します。
edit_splunktcp_ssl
Splunk TCP ⼊⼒の、SSL 固有の任意の設定を表⽰、編集できます。
edit_tcp
⼀般的な TCP ⼊⼒の受信設定を変更します。
edit_udp
UDP ⼊⼒の設定を変更します。
edit_user
ユーザーを作成、編集、または削除します。
edit_view_html
HTML ベースのビューを作成、編集、または変更します。
edit_web_settings
web.conf の設定を変更します。
embed_reports
レポートを埋め込んで、埋め込みレポートの埋め込みを無効にします。
get_diag
Splunk Enterprise インスタンスからリモートダイアログを取得するには、
/streams/diag endpoint を使⽤します。
get_metadata
「metadata」サーチプロセッサを使⽤します。
get_typeahead
先⾏⼊⼒を使⽤します。
indexes_edit
ファイルサイズやメモリー制限などのインデックス設定を変更します。
input_file
ファイルを⼊⼒として追加します。
9
license_tab
ライセンスにアクセス、変更します。
license_edit
ライセンスを編集します。
list_deployment_client
デプロイクライアント設定を表⽰します。
list_deployment_server
デプロイサーバー設定を表⽰します。
list_forwarders
フォワーダー設定を表⽰します。
list_httpauths
ユーザーセッションを表⽰します。
list_inputs
ファイル、TCP、UDP、スクリプトからの⼊⼒などの、各種⼊⼒を⼀覧表⽰しま
す。
output_file
ファイルを出⼒として追加します。
pattern_detect
[サーチ] ビューの [パターン] タブの表⽰と使⽤を制御します。
request_remote_tok
リモート認証トークンを取得します。
rest_apps_management
Python リモート App ハンドラの設定を編集します。
rest_apps_view
Python リモート App ハンドラのプロパティを⼀覧表⽰します。
rest_properties_get
サービス/プロファイルエンドポイントから情報を取得できます。
rest_properties_set
サービス/プロパティエンドポイントを編集します。
restart_splunkd
サーバーコントロールハンドラ経由で Splunk を再起動します。
rtsearch
リアルタイムサーチを実⾏します。
run_debug_commands
debug コマンドを実⾏します。
schedule_search
保存済みサーチのスケジュール、アラートの作成と更新、および⽣成されたアラー
ト情報の確認を⾏います。
schedule_rtsearch
リアルタイム保存済みサーチのスケジュールを⾏います。この権限を使⽤するに
は、当該ユーザーが schedule_search 権限も保有している必要があります。
search
サーチを実⾏します。
use_file_operator
file サーチ演算⼦を使⽤します。
Splunk Web を使ったロールの追加と編集
ユーザーを作成する場合、それをロールに割り当てることで Splunk Enterprise へのアクセスレベルとユーザー
が⾏える作業を設定します。Splunk Enterprise にはそのまま利⽤できるデフォルトのロールが⽤意されていま
す。独⾃のロールを作成することもできます。
ロールの詳細および権限の継承⽅法については、「ロールベースのユーザーアクセスについて」を参照してくださ
い。
注意: Admin または Power ユーザーから継承されたカスタムロールが、管理アクセスを⾃動的に継承すること
はありません。カスタムロールへの管理アクセスの割り当ての詳細は、「カスタムロールへのアクセス制御の追
加」を参照してください。
ロールの追加または編集
Splunk Web でロールを作成または編集するには:
1. [設定] > [アクセス制御] をクリックします。
2. [アクセス制御] ページで、[ロール] をクリックします。
3. [新規] をクリックするか、または選択して既存のロールを編集します。ロール名には⼩⽂字しか使⽤できませ
ん。また、スペース、コロン、スラッシュを使⽤することはできません。
4. このロールの [サーチの制限] を指定します。サーチの制限を指定することで、データのアクセス制御および
サーチ能⼒を作成、制限します。
サーチ単語の制限: ロールに割り当てられたユーザーに表⽰する (または表⽰しない) データを決定する
サーチ⽂字列を作成することができます。このトピックの「サーチフィルタのフォーマット」を参照してく
ださい。
サーチ時範囲の制限: このロールがサーチできる期間ウィンドウの⼤きさの制限を指定します。
ユーザーレベルの同時サーチジョブ数の制限 :このロールのユーザーが⼀度に実⾏できるサーチジョブの
最⼤数を指定します。
ユーザーレベルの同時リアルタイムサーチジョブ数の制限: このロールのユーザーが同時に実⾏できる
リアルタイムサーチジョブの数を指定します。
ロールレベルの同時サーチジョブ数の制限 :このロールが⼀度に実⾏できるサーチジョブの最⼤数を指定
します。
ロールレベルの同時リアルタイムサーチジョブ数の制限: このロールが同時に実⾏できるリアルタイム
サーチジョブの数を指定します。
合計ジョブディスククォータの制限: このロールに割り当てた各ユーザーのサーチジョブ専⽤の、合計
10
ディスクスペースを指定します。
5. [継承] セクションで、新しいロールが権限とプロパティを継承するロールを選択します。複数のロールに割り
当てられたユーザーは、もっとも幅広い権限を持つロールからプロパティを継承します。詳細は、「ロールベース
のユーザーアクセスについて」の「ロールの継承」を参照してください。
6. [権限] セクションで、このロールに適⽤する個別の権限を選択します。詳細は、「権限を持つロールの定義に
ついて」を参照してください。
7. [デフォルトでサーチするインデックス] で、サーチにインデックスが指定されていない場合に、このロール
が⾃動的にサーチするインデックスを指定します。
8. [インデックス] で、ユーザーにサーチを許可するインデックスを選択します。インデックスを最低 1 つ追加す
ると、このロールを持つユーザーは、選択されているインデックスに対してのみサーチを⾏うことができます。イ
ンデックスを何も指定しない場合、このロールに割り当てられているユーザーはすべてのインデックスをサーチで
きます。
9. [保存 ] をクリックします。
サーチフィルタのフォーマット
[サーチフィルタ] フィールドには、以下のサーチ⽤語を⼊れることができます。
source=
host=
index=
eventtype=
sourcetype=
サーチフィールド
ワイルドカード
複数の⽤語を使⽤する場合は
OR
を、サーチ結果をより限定するには
AND
を使⽤します。
サーチ⽤語に以下の項⽬を⼊れることはできません。
保存済みサーチ
時間演算⼦
正規表現
Splunk Web が上書きできる任意のフィールドまたは修飾⼦
authorize.conf を使ったロールの追加と編集
authorize.conf を編集することで、ロールを追加または編集することができます。ユーザーを割り当てるロールに
より、Splunk へのアクセスレベルや、そのユーザーが Splunk を使って⾏える操作が決まります。ロールと権限
の詳細は、「ロールベースのユーザーアクセスについて」を参照してください。
警告: $SPLUNK_HOME/etc/system/default/authorize.conf でロールを編集、削除しないようにしてください。直接編集
をしてしまうと、管理者権限に⽀障が出る可能性があります。$SPLUNK_HOME/etc/system/local/ 内、またはカスタム
アプリケーションディレクトリ $SPLUNK_HOME/etc/apps/ 内にあるこのファイルを編集してください。設定ファイル
の⼀般情報については、『管理』マニュアルの「設定ファイルについて」を参照してください。
注意: 分散サーチ設定の場合、権限のニーズが多少異なります。サーチヘッドプーリングを使⽤する場合、サー
チヘッドとサーチピアすべてが同じ authorize.conf ファイルセットを使⽤する必要があります。サーチヘッド
プーリング⽤に正しく権限を設定するには、「分散サーチでの権限の動作」を参照してください。
ロールの追加
$SPLUNK_HOME/etc/system/local/authorize.conf
を使ってロールを追加するための構⽂を以下に⽰します。
[role_<roleName>]
<attribute> = <value>
<attribute> = <value>
...
スタンザの⾒出しにある
<roleName>
は、ロールに与える名前です。例:security、compliance、ninja。
ロール名には⼩⽂字しか使⽤できません。また、スペース、コロン、スラッシュを使⽤することはできません。
ロールのスタンザには、これらの属性を指定できます。
<capability> = enabled
ロールには、任意の数の権限を追加できます。詳細は、「権限を持つロールの定義について」を参照
してください。
デフォルトでは、権限は無効になっています。ロールに権限を追加するには、その権限に「enabled」
を設定します。
importRoles = <role>;<role>;...
設定すると、現在のロールは <role> からすべての権限を継承します。複数のロールに割り当てられた
メンバーは、もっとも幅広い権限を持つロールからプロパティを継承します。詳細は、「ロールと
ユーザーについて」の「ロールの継承」を参照してください。
複数のロールを指定する場合は、セミコロンで区切ります。
11
srchFilter = <search_string>
このフィールドは、きめ細かくアクセス制御を⾏う場合に使⽤します。ロールのサーチは、この式で
フィルタリングされます。詳細は、このトピックの「サーチフィルタのフォーマット」を参照してく
ださい。
srchTimeWin = <string>
このロールが実⾏するサーチの最⼤期間 (秒)。
srchDiskQuota = <int>
このロールに所属するユーザーのサーチジョブが利⽤できる最⼤ディスクスペース (MB)。
cumulativeSrchJobsQuota = <number>
このロールのすべてのメンバーが保有できる同時実⾏履歴サーチの最⼤数。
注意: ユーザーが複数のロールに属している場合、そのユーザーはまず累積サーチクォータがもっと
も⼤きいロールからのサーチを最初に使⽤します。そのロールのクォータがすべて消費されると、次
にクォータが⼩さいロールが使⽤されます。
cumulativeRTSrchJobsQuota = <number>
このロールのすべてのメンバーが保有できる同時実⾏リアルタイムサーチの最⼤数。
注意: ユーザーが複数のロールに属している場合、そのユーザーはまず累積サーチクォータがもっと
も⼤きいロールからのサーチを最初に使⽤します。そのロールのクォータが完全に消費されると、そ
れより少ないクォータを持つロールが使⽤されます。* srchJobsQuota = <int>
このロールが利⽤できる同時実⾏サーチの最⼤数。
rtSrchJobsQuota = <number>
このロールが利⽤できる同時実⾏リアルタイムサーチの最⼤数。
srchIndexesDefault = <string>
インデックスが指定されていない場合にサーチ対象とするインデックスを、セミコロンで区切ったリ
スト。
これらのインデックスにワイルドカードを使⽤できますが、「*」は内部インデックスには⼀致しませ
ん。
内部インデックスと⼀致させるためには、先頭に「_」を指定します。すべての内部インデックスは
「_*」で表されます。
srchIndexesAllowed = <string>
このロールによるサーチを許可するインデックスを、セミコロンで区切ったリスト。
srchIndexesDefault と同じ⽅法でワイルドカードを使⽤できます。
注意: authorize.conf を変更した後は、設定情報を再読み込みするか、Splunk を再起動する必要があります。そ
うしないと、[ロール] リストに新しいロールが表⽰されません。設定情報を再ロードするには、Splunk Web の
[管理] > [認証] に移動します。こうすることにより、認証キャッシュが更新されますが、現在のユーザーはブー
トされません。
サーチフィルタのフォーマット
[srchFilter] フィールドには、以下のサーチ⽤語を⼊れることができます。
source=
およびホストタグ
およびインデックス名
eventtype= およびイベントタイプタグ
host=
index=
sourcetype=
サーチフィールド
ワイルドカード
複数の⽤語を使⽤する場合は
OR
を、サーチ結果をより限定するには
AND
を使⽤します。
サーチ⽤語に以下の項⽬を⼊れることはできません。
保存済みサーチ
時間演算⼦
正規表現
Splunk Web が上書きできる任意のフィールドまたは修飾⼦
authorize.conf でのロールの作成例
この例ではロール「ninja」を作成します。このロールは、デフォルトの「user」ロールから権限を継承します。
ninja ロールは、デフォルトの「power」とほぼ同じ権限を保有しますが、サーチをスケジュールすることはでき
ません。また、以下のように設定されています。
サーチフィルタにより、ninja のサーチは host=foo に限定されています。
ninja には、すべての公開インデックス (アンダースコアで始まらないインデックス) のサーチが許可されて
おり、またサーチにインデックスが指定されていない場合は、インデックス mail および main に対してサー
チを⾏います。
ninja は、最⼤ 8 つのサーチジョブおよび 8 つのリアルタイムサーチジョブを同時に実⾏することができま
す。(これらの数は別個の値です。)
ninja は、ジョブに合計 500MB までのディスクスペースを利⽤できます。
[role_ninja]
rtsearch = enabled
importRoles = user
srchFilter = host=foo
srchIndexesAllowed = *
srchIndexesDefault = mail;main
srchJobsQuota
= 8
12
rtSrchJobsQuota = 8
srchDiskQuota
= 500
管理コンソールと App へのアクセスの設定
local.meta ファイルを利⽤して、Splunk インスタンスの特定の部分へのアクセスを許可したり、制限したりする
ことができます。たとえば、以下のような作業を⾏うことができます。
カスタムロールを保有するユーザーが特定の App を利⽤するのをを制限する
カスタムロール内のユーザーに管理者レベルの機能へのアクセス権を与える
ユーザーへの admin ロールの割り当て
Admin ロールに所属する⼀部の管理機能は、その特定のラベル固有のものです。Splunk Web または
authorize.conf でロールを設定する場合、そのような能⼒が Admin ロールから⾃動的に継承されることはありま
せん。
たとえば、すべての管理機能を継承するけれども、サーチジョブへのアクセスが制限されているカスタムロールを
作成する場合を考えてみましょう。このためには、新しいロール「SpecialAdmin」を作成し、Admin のすべて
の権限を継承するようにそれを設定し (「権限を持つロールの定義について」を参照)、次にサーチ制限を設定しま
す (「ロール・ベースのユーザー・アクセスの設定について」を参照)。
「SpecialAdmin」には、あなたが Admin ロールに割り当てた各権限を保有します。ただし、以下の事項も含め
て、Admin と同じ管理⽤ページへのアクセス権は、⾃動的には与えられません。
システム関連の機能:システム設定およびクラスタ設定の表⽰/変更、ライセンスの表⽰/更新、Splunk の
再起動。
データ機能:データ⼊⼒の表⽰/追加、転送と受信の設定、インデックスの管理、レポートの⾼速化。
分散環境:分散サーチの設定、デプロイクライアントの表⽰、サーバーステータス。
ユーザーと認証:LDAP 設定、ユーザー (⾃⼰が保有しているものを除く)、ロールの管理。
特定の App へのアクセスの制限
local.meta
ファイルを使って、アクセスを制限することもできます。
たとえば、1 つのダッシュボードビューへのアクセスのみを許可するように、ユーザーを制限する場合を考えてみ
ましょう。このためには、そのビュー⽤の App を作成し、ユーザーのロールにその App を割り当てます。その
App の表⽰をロールに許可するには、meta.local を使⽤する必要があります。
local.meta ファイルを使ったアクセスの追加と削除
local.meta ファイルを編集して新しいロールを追加することで、アクセスを許可または制限することができま
す。
1. local.meta ファイルを探します。メインサーチページ (例:管理者コントロール) へのアクセス権を編集する場合
は、$SPLUNK_HOME/etc/system/metadata/ を参照します。特定の App へのアクセスを編集する場合
は、$SPLUNK_HOME/etc/apps/<app_name>/metadata/ を参照します。⽬的の場所のディレクトリにこれらのファイルがな
い場合は、デフォルト版の default.meta ファイルをコピーしてファイル名を変更できます。
注意: default.meta ファイルの値を直接編集しないようにしてください 。このファイルのデフォルト値は、将来
的にも必要となります。
2. local.meta ファイルの、⽬的のスタンザに新たなロール名を追加します。
デフォルトのスタン
ザ
[manager/accesscontrols]
access = read : [ * ],
write : [ admin, power ]
[views]
[manager/accesscontrols]
access = read : [ * ],
write : [ admin ]
意味
すべてのユーザーにこの App のコンテンツの参照、または Splunk 管理ページのアク
セス機能を許可します (現在のディレクトリによる)。他のメタデータの設定が優先さ
れる場合を除き、この App でのオブジェクトの共有は、admin および power ユー
ザーにのみ許可してください。
Splunk 管理ページへのアクセス制御を決定します。
3. 変更作業が完了したら、Splunk を再起動します。
例
例 1: 新しいロール「usermanager」は、ユーザーからの権限のみを継承し、サーチやインデックスは継承しま
せん。⽬的は、データにはアクセスできず、ユーザーアカウントの作成と管理⽬的でのみ使⽤されるロールを作成
することです。
このようなロールを作成するために、以下のスタンザを編集します。
[manager/accesscontrols]
13
access = read : [ admin ], write : [ admin ]
以下の項⽬を含めます。
[manager/accesscontrols]
access = read : [ admin, usermanager ], write : [ admin, usermanager ]
これで、「usermanager」に Splunk 管理での [アクセス制御] ページの内容の表⽰、編集権限が与えられまし
た。
例 2: ロール「userview」を有効にして、ページを表⽰できるけれども編集できないようにするには、ロールに
読み取り値 (read) のみを追加します。
[manager/accesscontrols]
access = read : [ admin, userview, usermanager ], write : [ admin, usermanager ]
各ロールに [管理] ページへの読み取りアクセスを許可するためにワイルドカードを使⽤することもできます。
[manager/accesscontrols]
access = read : [ * ], write : [ admin ]
例 3: 指定した営業データのみを読み込めるユーザーのサブセットを設定したいと考えています。この⽬的を達
成するために、ダッシュボード⽤の App を作成して、次に新しいロール「salesusers」を作成します。
次に App ディレクトリ内の
す。
local.meta
ファイルで (default.meta ファイルから作成)、以下のスタンザを編集しま
[viewstates]
access = read : [ * ], write : [ * ]
to read:
[viewstates]
access = read : [ salesusers ], write : [ admin ]
既存のユーザーやロールの検索
まず、Splunk Web で既存のユーザーまたはロールを探し、メインメニューで [システム] をクリックして、[ア
クセス制御] を選択して [アクセス制御] ページに移動します。そこから、[ユーザー] または [ロール] をクリッ
クして、ユーザーやロールをサーチできます。Splunk サーチはワイルドカードをサポートしています。
デフォルトでは、利⽤可能なすべてのフィールドに対して、⼊⼒した⽂字列がサーチされます。特定のフィールド
内のみをサーチする場合は、そのフィールドを指定します。
たとえば、メールアドレスのみをサーチする場合は、「email=<メールアドレスまたはその⼀部>」と⼊⼒しま
す。フルネームのフィールドのみをサーチする場合は、「realname=<名前またはその⼀部>」と⼊⼒します。特
定のロールを持つユーザーを検索する場合は、「roles=」を使⽤します。
すべてのユーザーアカウントの削除
インストールされている Splunk からすべてのユーザーデータ (ユーザーアカウント) を削除するには、./splunk
clean に userdata 引数を指定します。これにより、Splunk のデフォルトアカウント (admin、power、user) 以外
のすべてのユーザーアカウントが削除されます。
警告: ユーザーデータの削除を元に戻すことはできません。誤ってユーザーデータを削除してしまった場合は、
⼿動でアカウントを再追加する必要があります。
システム内のすべてのユーザーアカウントを削除するには:
./splunk clean userdata
システム内のすべてのユーザーアカウントを削除して、Splunk による確認のメッセージの表⽰をスキップ
するには:
./splunk clean userdata -f
Splunk ナレッジオブジェクトへのアクセスの保護
Splunk を使⽤するにつれて、イベントタイプ 、タグ 、ルックアップ 、フィールド抽出 、ワークフローアク
ション 、保存済みサーチ などの、さまざまな Splunk ナレッジオブジェクト が作成されていきます。Splunk
Web では、Splunk 環境内のナレッジオブジェクトへのアクセスを制限または拡張することができます。以下の
14
⽬的に利⽤できます。
すべての App のユーザーに対してオブジェクトを利⽤できるようにする。
特定の App のユーザーに対してオブジェクトを利⽤できるようにする。
ユーザーロールを使って、オブジェクトへのアクセスを制限する。
オブジェクトを無効化または削除する。
ユーザーに、⾃⼰が保有していないオブジェクトの共有や削除を許可する。
ナレッジオブジェクトのセキュリティの詳細は、『ナレッジ管理』マニュアルの「ナレッジオブジェクト権限の管
理」および「ナレッジオブジェクトの無効化または削除」を参照してください。
Splunk Enterprise のビルトイン認証を使ったユー
ザーの設定
Splunk Enterprise のネイティブ認証を使ったユーザー認証の設定
Splunk Enterprise のネイティブ認証 機能により、システムのユーザーを⼿軽に設定することができます。
Splunk Enterprise には、3 種類のユーザー設定⼿段が⽤意されていますが、ネイティブ認証が他の外部システム
よりも常に優先されます。ユーザーの認証⼿段の順位を以下に⽰します。
1. Splunk Enterprise ネイティブ認証。
2. LDAP またはスクリプト認証 (有効な場合)。詳細は、「LDAP によるユーザー認証の設定」および「外部シス
テムによるユーザー認証の設定」を参照してください。
注意: LDAP およびスクリプト認証を同時に⾏うことはできません。
新しいユーザーを作成し、ロールベースのアクセス制御システムがあるロール にそれらのユーザーを割り当てる
には、2 種類の⽅法があります。
Splunk Web を使ってユーザーを作成し、ロールを割り当てる。詳細は、「Splunk Web を使ったユーザー
の設定」を参照してください。
CLI を使ってユーザーを作成し、次に Splunk Web を使ってロールに割り当てる。詳細は、「CLI を使っ
たユーザーの設定」を参照してください。
ユーザーとロールの作成時の重要な命名ガイドライン
ネイティブ認証に保管するユーザーに、スペース、コロン、またはスラッシュを使⽤することはできません。名前
の⼤⽂字と⼩⽂字は区別されません。例えば、「Jacque」、「jacque」、「JacQue」はすべて同じものとして
Splunk Enterprise に認識されます。
ロール名には⼩⽂字しか使⽤できません。また、スペース、コロン、スラッシュを使⽤することはできません。
Splunk Web を使ったユーザーの設定
Splunk Web でユーザーとロールを設定するには:
1. [設定] > [ユーザーと認証] > [アクセス制御] に移動します。
3. [ユーザー] をクリックします。
4. [新規] をクリックするか、または編集する既存のユーザーを選択します。
5. ユーザーの情報を指定または変更します。以下のような情報を指定することができます。
フルネーム。
メールアドレス。
タイムゾーン。これにより、イベントやその他の情報を、各⾃のタイムゾーンで表⽰することができます。
デフォルト App。これは、ユーザーのロールからデフォルトで継承されるデフォルト App の設定に優先し
ます。
パスワード。
6. 既存のロールにユーザーを割り当てて、[保存] をクリックします。
ユーザーが Splunk で何にアクセスできるのかを定義した、ユーザー専⽤のロールを作成することもできます。作
成したら、そのロールにユーザーを割り当てます。ロールの詳細は、「ロールベースのユーザーアクセスについ
て」を参照してください。
ユーザー設定の詳細は、Splunk Enterprise の『管理ガイド』を参照してください。
CLI を使ったユーザーの設定
CLI では、add
user
コマンドを使⽤します。以下にいくつかの例を⽰します。
新たな管理ユーザーにパスワード「changeme2」を追加するには:
./splunk add user admin2 -password changeme2 -role admin -auth admin:changeme
既存のユーザーのパスワードを「fflanda」に変更するには:
15
./splunk edit user admin -password fflanda -role admin -auth admin:changeme
重要: パスワードに、シェルに解釈される特殊⽂字を使⽤する場合 (例:'$' または '!')、エスケープ処理を⾏う
か、または単⼀引⽤符で囲む必要があります。例:
./splunk edit user admin -password 'fflanda$' -role admin -auth admin:changeme
または
./splunk edit user admin -password fflanda\$ -role admin -auth admin:changeme
Splunk Web によるロールへのユーザーの追加
ユーザーを、デフォルトのロールまたは独⾃に作成したカスタムロールに追加することができます。詳細は、
「ロールベースのユーザーアクセスについて」を参照してください。
Splunk Web を使ってロールにユーザーを追加するには:
1. メインメニューから、[設定] > [アクセス制御] > [アクセス制御] をクリックします。
2. [ユーザー] をクリックします。
3. 既存のユーザーを編集するか、または新しいユーザーを作成します。
4. [ロール] リストから、割り当てるロールを選択します。authorize.conf 内に作成された任意のカスタムロールが
ここに表⽰されます。
LDAP によるユーザー認証の設定
LDAP によるユーザー認証の設定
Splunk は、3 種類の認証 システムをサポートしています。
Splunk にビルトインされている独⾃のシステム。「Splunk 認証システムを使ったユーザー認証の設定」を
参照してください。
ここで説明する LDAP。
外部認証システム (PAM や RADIUS など) を使⽤するためのスクリプトによる認証 API。「外部システム
を使ったユーザー認証の設定」を参照してください。
Splunk の LDAP 認証の設定について
Splunk では、LDAP ユーザー/グループのユーザーとロール設定が可能です。1 つまたは複数の LDAP サーバー
を設定して、サーバーから Splunk 内で作成したロールに、ユーザーとグループをマップすることができます。
複数の LDAP サーバーの設定については、「Splunk が複数の LDAP サーバーと連携する仕組み」を参照してく
ださい。
LDAP を設定する前に、「LDAP の前提条件と検討事項」を参照してください。
Splunk で LDAP を使⽤するための設定⽅法
Splunk で LDAP を利⽤するための主な設定ステップを以下に⽰します。
1. 1 つまたは複数の LDAP ストラテジーを設定します (⼀般的には、1 台の LDAP サーバー当たり 1 つのストラ
テジーを設定)。
2. LDAP グループを 1 つまたは複数の Splunk ロールにマップします。
3. 複数の LDAP サーバーがある場合は、各サーバーへの接続順序を指定します。
これらのステップを実施するには、Splunk Web を利⽤するか、または設定ファイルを編集します。詳細は、
「Splunk Web による LDAP の設定」または「設定ファイルによる LDAP の設定」を参照してください。
認証の優先度
Splunk のビルトインシステムは、他の外部システムよりも常に優先されます。Splunk によるユーザーの認証順
序を以下に⽰します。
1. Splunk ビルトイン認証
2. LDAP またはスクリプト認証 (これらの⼿段が有効になっている場合)。スクリプト認証の詳細は、「外部シス
テムによるユーザー認証の設定」を参照してください。
Answers
何か質問がありますか?「Splunk Answers」から、Splunk コミュニティに寄せられた、Splunk での LDAP 認
証の使⽤⽅法に関する質問と回答をご覧ください。
16
LDAP を使った Splunk ユーザーロールの管理
Splunk で LDAP 認証を使⽤するように設定するには、まず各 LDAP サーバーに対する Splunk ストラテジーを
作成し、次に Splunk のロールをサーバーのグループにマップします。ユーザーのログイン時には、Splunk が
サーバーに問い合わせて、当該ユーザーを検索します。ユーザーには、そのユーザーがメンバーとなっている
LDAP グループに対応するロールに基づいて、ユーザー権限が与えられます。
ユーザー権限を変更する場合、さまざまな⼿段を利⽤することができます。
ユーザーグループの権限を変更するために、LDAP グループを別の Splunk ロールにマップし直すことがで
きます。また、ロール⾃体を更新して、別の権限を指定することもできます。この作業は Splunk で⾏いま
す。
個別のユーザーの権限を変更するために、そのユーザーを別の Splunk ロールにマップされた LDAP グルー
プに移動することができます。この作業は、LDAP サーバー上で⾏います。
その他のユーザー管理作業を以下に⽰します。
ユーザーを Splunk ロールに追加するには:まず Splunk Web で、Splunk ロールを LDAP グループに
マップしたことを確認します。次に LDAP サーバー上で、ユーザーを LDAP グループに追加します。
ユーザーを Splunk ロールから削除するには: LDAP サーバー上で、対応する LDAP グループからユー
ザーを削除します。
ユーザーは、複数のロールのメンバーシップを保有することができます。その場合、それらの任意のロールが利⽤
できるすべての権限が与えられます。たとえば、ユーザーが docs と eng グループの両⽅のメンバーで、docs が
「user」に、eng が「admin」にマップされている場合、そのユーザーは「user」と「admin」ロールに割り当
てられているすべての権限を取得します。
注意: ユーザーが Splunk にログインする場合、Splunk は⾃動的に LDAP メンバーシップ情報をチェックしま
す。ユーザーの追加/削除時に、認証設定を再ロードする必要はありません。
LDAP の前提条件と検討事項
Splunk での LDAP の使⽤を設定する前に、ここの説明に従って準備作業を⾏ってください。
ユーザーとグループのベース DN の決定
Splunk で LDAP 設定をマップする前に、ユーザー/グループベース DN または識別名を確認してください。DN
は、認証情報が保管されているディレクトリの場所です。
ユーザーのグループメンバーシップ情報が個別のエントリに保持されている場合は、グループ情報が保管されてい
るディレクトリ内のサブツリーを識別する、個別の DN を⼊⼒します。ユーザーとグループは、この DN 下のす
べてのサブノード上で再帰的に検索されます。LDAP ツリーにグループエントリがない場合は、グループベース
DN にユーザーベース DN と同じ値を設定して、ユーザーを⾃⼰のグループとして処理することができます。こ
のためには、後述する設定作業が必要になります。
この情報が分からない場合は、LDAP 管理者に⽀援を依頼してください。
注意: Splunk を Active Directory と統合する際に最良の結果を得るために、グループベース DN はユーザー
ベース DN と別個の階層に配置するようにしてください。
その他の検討事項
Splunk で LDAP を使⽤する際には、以下の事項に注意してください。
Splunk Web および authentication.conf 内のエントリでは、⼤⽂字と⼩⽂字が区別されます。
Splunk のネイティブ認証を利⽤してローカルに作成されたユーザーは、同名の LDAP ユーザーよりも優先
されます。たとえば、LDAP サーバーにユーザー名属性 (たとえば、cn または uid) を持つユーザー
「admin」があり、同名のデフォルト Splunk ユーザーが存在している場合、その Splunk ユーザーが優先
されます。この場合、ローカルのパスワードのみが受け付けられます。また、ログイン時には、ローカル
ユーザーに与えられているロールが有効になります。
Splunk Web がロールへのマッピングとして表⽰できる LDAP グループ数は、LDAP サーバーがクエリに
対して返すことができるグループ数に制限されています。サーチ要求サイズ制限 とサーチ要求時間制限 設
定でこれを設定することができます。
不要なグループの表⽰を防⽌するには、groupBaseFilter を使⽤します。例: groupBaseFilter =
(|(cn=SplunkAdmins)(cn=SplunkPowerUsers)(cn=Help Desk))
ロールを最⼤値以上のグループにマップする必要がある場合は、authentication.conf を直接編集するこ
とができます。この例では、「roleMap_AD」が Splunk ストラテジー名を⽰しています。各属性/値
のペアが、Splunk ロールを 1 つまたは複数の LDAP グループにマップしています。
[roleMap_AD]
admin = SplunkAdmins1;SplunkAdmins2
power = SplunkPowerUsers
user = SplunkUsers
Splunk が複数の LDAP サーバーと連携する仕組み
Splunk は、ユーザーの認証時に複数の LDAP サーバーに対して検索することができます。LDAP サーバーを設
定するには、それぞれの LDAP サーバーに対して 1 つずつ「ストラテジー」を設定します。
17
ストラテジーを作成したら、Splunk が LDAP ユーザーを検索する際にそれらのストラテジーに対してクエリを
⾏う順番を指定することができます。検索順序を指定しない場合は、ストラテジーが作成された順番に基づいてデ
フォルトの「接続順序」が割り当てられます。
LDAP ストラテジーの設定⼿順については、「Splunk Web による LDAP の設定」または「設定ファイルによる
LDAP の設定」を参照してください。
検索中の接続順序の仕組み
認証時には、指定した接続順序で、サーバーに対して作成したストラテジーに基づいて検索が⾏われます。サー
バー上にユーザーが⾒つかると、検索を終了して、ユーザーの資格情報を取得します。検索順序に従って残りの
サーバー上に資格情報があっても、それらは無視されます。
例えば、A、B、C の順番で三つのストラテジ―を設定・有効化する場合、Splunk は同じ A、B、C という順番で
サーバーをサーチします。ユーザーが Aで⾒つかると、検索を停⽌します。B や C にユーザーが存在しているか
どうかは考慮されません。A にあるユーザーの資格情報のみが使⽤されます。A にユーザーが⾒つからなかった
場合は、残りのサーバーに対して検索が⾏われます。まず B が、次に C が検索されます。
後ほどストラテジー A を無効にした場合は、残りのストラテジーが B、C の順序で検索されます。
接続順序はいつでも変更することができます。変更するには、Splunk Web を使⽤するか、
「authentication.conf」仕様ファイルの説明に従って、authSettings 属性内のストラテジーの順序を変更します。
本ファイルを LDAP に合わせて編集する⽅法の詳細については、「authentication.conf の編集」を参照してくだ
さい。
重要: Splunk のビルトイン認証を利⽤してローカルに作成されたユーザーは、同名の LDAP ユーザーよりも優
先されます。詳細は、「ユーザー認証について」を参照してください。
Splunk Web による LDAP の設定
このセクションでは、Splunk Web を使った LDAP の設定⽅法について説明していきます。authentication.conf
を直接編集して LDAP を設定する場合は、「設定ファイルによる LDAP の設定」を参照してください。
Splunk Web を使った LDAP の設定作業は、主に 3 つのステップから成り⽴っています。
1. LDAP ストラテジーを作成します。
2. LDAP グループを Splunk ロールにマップします。
3. 接続順序を指定します (複数の LDAP サーバーがある場合)。
LDAP ストラテジーの作成
LDAP ストラテジーを作成するには:
1. [設定] > [ユーザーと認証] > [アクセス制御] に移動します。
3. [認証⽅法] をクリックします。
4. [LDAP] を選択します。
5. [LDAP を使⽤してグループをマップする] をクリックします。[LDAP ストラテジー] ページに移動しま
す。
6. [新規] をクリックします。[新規追加] ページに移動します。
7. 設定の [LDAP ストラテジー名] を⼊⼒します。
8. LDAP サーバーのホスト 名を⼊⼒します。⼊⼒するホスト名は、Splunk サーバーが解決できなければなりませ
ん。注意:現在の所、Windows で Splunk は IPv6 アドレス形式をサポートしていません。
9. LDAP サーバーに接続するために Splunk が使⽤する [ポート] を⼊⼒します。
デフォルトで LDAP サーバーは、TCP ポート 389 で待機しています。
LDAPS (SSL を使⽤した LDAP) の場合は、デフォルトでポート 636 が使⽤されます。
10. SSL を有効にするには、[SSL 有効] を選択します。
セキュリティのために、この設定を使⽤することをお勧めします。
また、LDAP サーバーでも SSL を有効にする必要があります。
11. [バインド DN] を⼊⼒します。
LDAP サーバーにバインドするために⽤いられる識別名です。
⼀般的には管理者ですが、必ずしもそうである必要はありません。このユーザーには、取得するすべての
LDAP ユーザー/グループエントリに対する読み取りアクセスが必要です。
匿名バインドで⼗分な場合は、空欄にしてください。
12. バインドするユーザーの [バインド DN パスワード] を⼊⼒、再⼊⼒します。
13. [ユーザーベース DN] を⼊⼒します。複数のユーザーベース DN を指定する場合は、セミコロンで区切って
ください。
18
Splunk はこの属性を使ってユーザー情報を検索します。
認証を機能させるために、この属性を設定する必要があります。
14. ユーザーをフィルタリングするオブジェクトクラスの、[ユーザーベースフィルタ] を⼊⼒します。
適切なユーザーのみを返す場合に使⽤することをお勧めします。例:(department=IT)。
デフォルト値は空です。この場合、ユーザーエントリのフィルタリングは⾏われません。
15. ユーザー名を含む [ユーザー名属性] を⼊⼒します。
ユーザー名に空⽩⽂字を⼊れることはできません。
Active Directory の場合、⼀般的にこれは sAMAccountName になりますが、cn のような他の属性を認証するこ
ともできます。
他の⼤部分の設定で、値 uid を利⽤できます。
16. ユーザーの [実名属性] (共通名) を⼊⼒します。
⼀般的な値は、displayName または
cn
(共通名) になります。
17. [メール属性] を⼊⼒します。
18. [グループマッピング属性] を⼊⼒します。
これは、グループエントリがそのメンバーを定義するために使⽤するユーザー属性です。
デフォルトは、Active Directory の dn になります。この属性は、ユーザー DN に加えて他の属性を使って
グループをマップしている場合にのみ設定してください。
たとえば、ユーザーをグループにマップするために⼀般的に⽤いられる属性は dn になります。
19. [グループベース DN] を⼊⼒します。複数のグループベース DN を指定する場合は、セミコロンで区切って
ください。
これは、LDAP 内のユーザーグループの場所になります。
LDAP 環境にグループエントリがない場合は、各ユーザーを独⾃のグループとして取り扱うことができま
す。
groupBaseDN に userBaseDN と同じ値を設定してください。この場合、ユーザーと同じ場所でグ
ループを検索することになります。
次に、groupMemberAttribute と groupMappingAttribute に、userNameAttribute と同じ属性を設
定します。この場合、エントリがグループとして処理されるときに、ユーザー名の値がその唯⼀のメ
ンバーとして使⽤されます。
また、groupNameAttribute にも userNameAttribute と同じ値を設定しなければならないことがあり
ます。
注意: Active Directory と統合する際に最良の結果を得るために、グループベース DN はユーザーベース DN と
別個の階層に配置するようにしてください。
20. 静的グループをフィルタリングするオブジェクトクラスの、[静的グループサーチフィルタ] を⼊⼒します。
適切なグループのみを返すために使⽤することをお勧めします。例:
(|(objectclass=groupofNames)(objectclass=groupofUniqueNames))
デフォルト値は空です。この場合、静的グループのフィルタリングは⾏われません。
21. [グループ名属性] を⼊⼒します。
これは、値がグループ名を保管しているグループエントリ属性になります。
⼀般的には cn になります。
22. [静的メンバー名属性] を⼊⼒します。
これは、値がグループのメンバーであるグループ属性です。
⼀般的には、member、uniqueMember、または memberUid になります。
22. ネスト化グループを展開する場合は、[ネスト化グループ] を選択します。
これは、Splunk が memberof 属性を使って、ネスト化されたグループをデプロイするかどうかを⽰しま
す。メンバーを解決するために memberof 属性を使⽤しているネスト化グループがある場合にのみ、選択し
てください。OpenLDAP の場合は、「memberof」オーバーレイを明⽰的に有効にする必要があります。
23. 動的グループ (ある場合) を取得するために、[動的グループサーチフィルタ] を⼊⼒します。
動的グループが Splunk に返されるように、この値は動的グループ定義のオブジェクトクラスと⼀致してい
なければなりません。例: (objectclass=groupOfURLs)
デフォルト値は空です。この場合、認証時に Splunk は動的グループエントリを検索しません。
24. [動的メンバー名属性] を⼊⼒します。
これは、メンバーの定義に LDAP 検索 URL 形式 (ldap:///o=Acme,
⽤するグループ属性です。
⼀般的には memberURL になります。
c=US??sub?(objectclass=person)
など) を使
25. [詳細設定] を選択した場合は、その他の各種オプションを設定することもできます。
匿名バインドでのみ紹介を有効にする
この設定はデフォルトで有効になっています。紹介が不要な場合は、これをオフにしてください。
19
Splunk は匿名バインドの紹介のみを追跡できます。また、LDAP サーバーでも匿名サーチを有効にす
る必要があります。
⻑い LDAP 検索タイムアウトが発⽣し (Active Directory などで)、splunkd.log に
ScopedLDAPConnection の「Operations error」が記録される場合は、紹介に関連する問題である
可能性があります。
サーチ要求サイズ制限
パフォーマンス関連の問題を回避するために、サーチ要求のサイズ制限を設定することができます。
Splunk が LDAP サーバーにサーチ要求を⾏うと、サーバーから最⼤で指定された数のエントリが返
されます。数百万⼈ものユーザーが存在する⼤規模デプロイ環境で、この値を⼤きくすると、LDAP
ストラテジー設定のサーチフィルタ設定によっては応答時間が⻑くなることがあります。この限度に
達すると、splunkd.log に size limit exceeded メッセージが記録されます。
[サーチ要求時間制限] と [サーチ要求サイズ制限] の値は、splunkweb タイムアウトプロパティ値
(「ユーザーセッションタイムアウトの設定」を参照) と連携して指定する必要があります。Splunk コ
ンソールに表⽰されないグループがある場合は、これらの制限のいずれかが原因で除外されている可
能性があります。必要に応じてこれらのプロパティの値を調整してください。
要求サイズ制限に 1000 以上の値を設定する場合は、要求サイズ制限に設定したユーザー数に対応で
きるように limits.conf 内の max_users_to_precache を変更する必要があります。
サーチ要求時間制限
パフォーマンス関連の問題を回避するために、サーチ要求の時間制限を設定することができます。
Splunk が要求を⾏うと、LDAP サーバーは指定秒数で検索を完了します。数百万⼈ものユーザーが存
在する⼤規模デプロイ環境で、この制限に⼤きな値を設定すると、Splunk Web でタイムアウトが発
⽣する可能性があります。この限度に達すると、splunkd.log に time limit exceeded メッセージが記録
されます。
[サーチ要求時間制限] と [サーチ要求サイズ制限] の値は、splunkweb タイムアウトプロパティ値
(「ユーザーセッションタイムアウトの設定」を参照) と連携して指定する必要があります。Splunk コ
ンソールに表⽰されないグループがある場合は、これらの制限のいずれかが原因で除外されている可
能性があります。必要に応じてこれらのプロパティの値を調整してください。
ネットワークソケットタイムアウト
このプロパティは、複数のストラテジー設定がある環境で、ネットワークの輻輳が原因でいずれかの
LDAP サーバーに到達不可能、またはサーバーの応答時間が⻑すぎる場合の、認証チェーン内のルー
プを回避するために⽤いられます。指定された秒数の待機後、次に利⽤できるストラテジー (ある場
合) から認証プロセスが続⾏されます。
LDAP ストラテジーを最初に作成する時に、Splunk は LDAP サーバー/ポートと他のパラメータを検
証します。その時に、LDAP サーバーが停⽌している、またはいずれかのパラメータを検証できない
場合、LDAP ストラテジーは作成されません。
26. [保存 ] をクリックします。
新しい LDAP グループの Splunk ロールへのマップ
LDAP サーバー経由で認証を⾏うように Splunk を設定したら、LDAP グループを Splunk ロールにマップしま
す。グループを使⽤しない場合は、ユーザーを個別にマップすることができます。
注意: ユーザーまたはグループのどちらかをマップすることができます。両⽅をマップすることはできません。
グループを使⽤する場合、Splunk にアクセスさせるすべてのユーザーが、適切なグループのメンバーでなければ
なりません。グループは、それがメンバーとなっている最⾼レベルのロールから権限を継承します。
すべてのユーザーは、Splunk 管理の [ユーザー] ページに表⽰されます。Splunk Web でロールをグループに割
り当てるには:
1. メインメニューで、[システム] > [ユーザーと認証] > [アクセス制御] を選択します。
2. [アクセス制御] ページで、[認証⽅法] をクリックします。
3. [LDAP] ラジオボタンを選択して、[LDAP を使⽤してグループをマップする] をクリックします。[LDAP
ストラテジー] ページに移動します。
4. 特定のストラテジーの [アクション] 列の [グループのマップ] をクリックします。[LDAP グループ] ペー
ジに移動します。ページの右上にあるサーチフィールドを使って、グループのリストを調整することができます
(例:特定のユーザーを含むグループを表⽰)。
5. グループ名をクリックします。マッピング⽤ページに移動します。このページには、利⽤可能なロールのリス
ト、およびグループの LDAP ユーザーのリストが表⽰されています。
6. ロールをグループにマップするには、[利⽤可能なロール] リスト内の、ロールの左側にある⽮印をクリックしま
す。この操作により、グループが [選択されたロール] リストに移動します。グループに複数のロールをマップす
ることができます。
7. [保存 ] をクリックします。[LDAP グループ] ページに戻ります。
8. Splunk ロールを割り当てる各グループに対して、このプロセスを繰り返します。
サーバーの接続順序の指定
複数の LDAP ストラテジーを有効にしている場合、「Splunk が複数の LDAP サーバーと連携する仕組み」で説
明しているように、Splunk がユーザーを検索するためにサーバーに接続する順序を指定することができます。
デフォルトでは、サーバーを有効にした順序に検索が⾏われます。接続 (検索) 順序を変更するには、各ストラテ
ジーのプロパティを個別に編集する必要があります。
1. メインメニューで、[システム] > [ユーザーと認証] > [アクセス制御] を選択します。
2. [認証⽅法] をクリックします。
20
3. [LDAP] ボタンを選択します。
4. [LDAP を使⽤してグループをマップする] をクリックします。[LDAP ストラテジー] ページに移動しま
す。
5. 接続順序を指定するストラテジーをクリックします。この操作により、ストラテジーのプロパティページに移動
します。
6. ページの上部にある [接続順序] フィールドを編集します。このフィールドは、複数のストラテジーを有効にし
た場合にのみ表⽰されます。
注意: 最初にストラテジーを作成する時点では、[接続順序] フィールドは表⽰されません。後ほどプロパティを
編集する時にのみ表⽰されます。また、ストラテジーが無効になっている場合、フィールドは灰⾊表⽰になりま
す。
7. [保存 ] をクリックします。
8. 有効順序を変更するその他の有効なストラテジーに対しても、同じプロセスを繰り返します。
Splunk Web を使った LDAP グループの Splunk ロールへのマップ
LDAP サーバー経由で認証を⾏うように Splunk を設定した場合、LDAP グループを Splunk ロールにマップす
ることができます。グループを使⽤しない場合は、LDAP ユーザーを個別にマップすることもできます。
Splunk Web での LDAP グループの設定については、このマニュアルの「Splunk Web による LDAP の設定」
を参照してください。
注意: ユーザーまたはグループのどちらかをマップすることができます。両⽅をマップすることはできません。
グループを使⽤する場合、Splunk にアクセスさせるすべてのユーザーが、適切なグループのメンバーでなければ
なりません。グループは、それがメンバーとなっている最⾼レベルのロールから権限を継承します。
すべてのユーザーは、Splunk 管理の [ユーザー] ページに表⽰されます。Splunk Web でロールをグループに割
り当てるには:
1. Splunk Web で [設定] をクリックします。
2. [ユーザーと認証] セクションで、[アクセス制御] をクリックします。
3. [認証⽅法] をクリックします。
4. [LDAP] ボタンを選択します。
5. [LDAP を使⽤してグループをマップする] をクリックします。[LDAP ストラテジー] ページに移動しま
す。
6. 特定のストラテジーの [アクション] 列の [グループのマップ] をクリックします。[LDAP グループ] ペー
ジに移動します。ページの右上にあるサーチフィールドを使って、グループのリストを調整することができます
(例:特定のユーザーを含むグループを表⽰)。
7. グループ名をクリックします。マッピング⽤ページに移動します。このページには、利⽤可能なロールのリス
ト、およびグループの LDAP ユーザーのリストが表⽰されています。
8. ロールをグループにマップするには、[利⽤可能なロール] リスト内の、ロールの左側にある⽮印をクリックしま
す。この操作により、グループが [選択されたロール] リストに移動します。グループに複数のロールをマップす
ることができます。
9. [保存 ] をクリックします。[LDAP グループ] ページに戻ります。
10. Splunk ロールを割り当てる各グループに対して、このプロセスを繰り返します。
設定ファイルによる LDAP の設定
Splunk Web を使って LDAP を設定する代わりに、authentication.conf ファイルを直接編集することもできま
す。
この例では、authentication.conf の設定⼿順を紹介していきます。Splunk Web を使って LDAP を設定する場合
は、「Splunk Web による LDAP の設定」を参照してください。
注意: LDAP 認証の設定後、デフォルトの Splunk 認証に変更する場合、もっとも簡単な⽅法は既存の
authentication.conf ファイルを認識できないようにして (例:名前を authentication.conf.disabled に変更する)、
Splunk を再起動することです。
authentication.conf ファイルの最後には、その他の例が記載されています。
の authentication.conf を編集します。設定ファイルの⼀般情報については、『管理
マニュアル』の「設定ファイルについて」を参照してください。
$SPLUNK_HOME/etc/system/local/
認証タイプとストラテジー名の設定
デフォルトで Splunk は、⾃⼰の認証タイプを使⽤しています。[authentication] スタンザの認証タイプを LDAP
に変更してください。
21
[authentication]
authType = LDAP
authSettings = ldaphost1,ldaphost2
以下の事項に注意してください。
を設定することで、LDAP を有効にします。
属性は、1 つまたは 複数の LDAP ストラテジーを⽰します。後述するように、各ストラテジー
が独⾃のスタンザを保有します。
authType = LDAP
authSettings
LDAP ストラテジースタンザの設定
各 LDAP ストラテジーに、独⾃のスタンザが必要です。ストラテジーのスタンザの属性/値のペアに、LDAP 値を
マップしてください。
注意: 現在の所、Windows で Splunk は IPv6 アドレス形式をサポートしていません。
「ldaphost1」ストラテジーのスタンザの例を以下に⽰します (authSettings 属性の前半に指定)。
[ldaphost1]
host = ldaphost1.domain.com
port = 389
SSLEnabled = 0
bindDN = cn=bind_user
bindDNpassword = bind_user_password
groupBaseDN = ou=Groups,dc=splunk,dc=com
groupBaseFilter = (objectclass=*)
groupMappingAttribute = dn
groupMemberAttribute = uniqueMember
groupNameAttribute = cn
realNameAttribute = displayName
userBaseDN = ou=People,dc=splunk,dc=com
userBaseFilter = (objectclass=*)
userNameAttribute = uid
注意: Active Directory と統合する際に最良の結果を得るために、グループベース DN はユーザーベース DN と
別個の階層に配置するようにしてください。
複数の LDAP ストラテジーの設定
「Splunk が複数の LDAP サーバーと連携する仕組み」で説明しているように、Splunk は複数の LDAP サー
バーにまたがって検索することができます。そのように設定するには、カンマ区切り形式のストラテジーリストに
authSettings 属性を、Splunk がクエリする順番に設定します。次に、各ストラテジーに対して個別のスタンザを
指定します。
グループのロールへのマップ
Splunk ロールをストラテジーの LDAP グループにマップするには、そのストラテジーの roleMap スタンザを設定
する必要があります。各ストラテジーに、独⾃の roleMap スタンザが必要になります。この例では、
「ldaphost1」ストラテジー内のグループに対してロールをマップします。
[roleMap_ldaphost1]
admin = SplunkAdmins
itusers = ITAdmins
ユーザーのロールへの直接割り当て
ユーザーを直接 Splunk ロールに割り当てる必要がある場合は、groupBaseDN に userBaseDN の値を設定します。ま
た、groupMappingAttribute、groupMemberAttribute、および groupNameAttribute の属性に、userNameAttribute と同じ属
性を設定します。例:
[supportLDAP]
SSLEnabled = 0
bindDN = cn=Directory Manager
bindDNpassword = #########
groupBaseDN = ou=People,dc=splunksupport,dc=com
groupBaseFilter = (objectclass=*)
groupMappingAttribute = uid
groupMemberAttribute = uid
groupNameAttribute = uid
host = supportldap.splunksupport.com
port = 389
realNameAttribute = cn
22
userBaseDN = ou=People,dc=splunksupport,dc=com
userBaseFilter = (objectclass=*)
userNameAttribute = uid
[roleMap_supportLDAP]
admin = rlee;bsmith
設定ファイルでの LDAP グループ/ユーザーの Splunk ロールへの
マップ
LDAP 認証とユーザーを設定したら、Splunk Web で LDAP グループとユーザーをロールにマップできます。
Splunk で LDAP を設定するには、このマニュアルの「設定ファイルによる LDAP の設定」を参照してくださ
い。
グループのロールへのマップ
Splunk ロールをストラテジーの LDAP グループにマップするには、そのストラテジーの roleMap スタンザを設定
する必要があります。各ストラテジーに、独⾃の roleMap スタンザが必要になります。この例では、
「ldaphost1」ストラテジー内のグループに対してロールをマップします。
[roleMap_ldaphost1]
admin = SplunkAdmins
itusers = ITAdmins
ユーザーのロールへの直接割り当て
ユーザーを直接 Splunk ロールに割り当てる必要がある場合は、groupBaseDN に userBaseDN の値を設定します。ま
た、groupMappingAttribute、groupMemberAttribute、および groupNameAttribute の属性に、userNameAttribute と同じ属
性を設定します。例:
[supportLDAP]
SSLEnabled = 0
bindDN = cn=Directory Manager
bindDNpassword = #########
groupBaseDN = ou=People,dc=splunksupport,dc=com
groupBaseFilter = (objectclass=*)
groupMappingAttribute = uid
groupMemberAttribute = uid
groupNameAttribute = uid
host = supportldap.splunksupport.com
port = 389
realNameAttribute = cn
userBaseDN = ou=People,dc=splunksupport,dc=com
userBaseFilter = (objectclass=*)
userNameAttribute = uid
[roleMap_supportLDAP]
admin = rlee;bsmith
LDAP 設定のテスト
Splunk が LDAP サーバーに接続できない場合は、ここで説明するトラブルシューティング⼿順をお試しくださ
い。
1. $SPLUNK_HOME/var/log/splunk/splunkd.log の認証エラーを確認します。
2. userBaseFilter および groupBaseFilter に対して追加したカスタム値を削除します。
3.
ldapsearch
を使って、指定した変数が適切なエントリを返すことを確認します。
ldapsearch -x -h <ldap_host> -p <ldap_port> -D "bind_dn" -w "bind_passwd" -b "user_basedn"
"userNameAttribute=*"
ldapsearch -x -h <ldap_host> -p <ldap_port> -D "bind_dn" -w "bind_passwd" -b "group_basedn"
"groupNameAttribute=*"
これらのコマンドが⼀致するエントリを返す場合、バックエンド LDAP システムは正しく設定されています。
Splunk LDAP ストラテジー設定のトラブルシューティングに進んでください。
Splunk のビルトイン認証から LDAP への変換
ビルトイン認証から LDAP に移⾏した場合、Splunk で作成したアカウントは⾃動的には無効にならず、LDAP
23
アカウントよりも優先されることに注意する必要があります。
Splunk のビルトイン認証システムから LDAP に変換した場合、LDAP 資格情報を使⽤するために Splunk のビ
ルトインシステムからユーザーを削除しなければならないこともあります。この作業は、両⽅のシステムでユー
ザー名が同じ場合にのみ必要になります。
ローカル Splunk アカウントの保護
Splunk で LDAP 認証を使⽤するように設定した場合、Splunk のビルトイン認証を使っているすべてのローカル
アカウントが引き続き存在しており、アクティブになっていることに注意する必要があります。これには、
「Admin」アカウントも含まれています。このことによるセキュリティ上の意味を考慮する必要があります。
LDAP 認証の有効化時に、すべてのローカルアカウントを削除するには:
ファイルを passwd.bak に移動します。
空の $SPLUNK_HOME/etc/passwd ファイルを作成します。
Splunk を再起動します。
$SPLUNK_HOME/etc/passwd
Splunk が LDAP 認証を使⽤している場合にも、ローカル Splunk アカウントを作成できることに注意してくだ
さい。また、バックアップや障害対策⽬的で残しているローカル Splunk アカウントには、強⼒なパスワードを使
⽤するようにしてください。
LDAP を使⽤する場合、LDAP が以下の事項を採⽤していることを確認してください。
⻑さと複雑性が強⼒なパスワード要件。
試⾏失敗回数が⼩さなパスワードロックアウト要件。
保存済みサーチ
LDAP ユーザー名が、Splunk ビルトインシステムで使⽤していたユーザー名と同じ場合、その後ビルトインシス
テムのユーザーを削除しても、保存済みサーチは変換せずにそのまま利⽤できます。
Splunk のビルトイン認証システムの使⽤時に作成した保存済みサーチを、別名の LDAP ユーザーに移転したい
場合は、メタデータを編集してください。
1. $SPLUNK_HOME/etc/apps/<app_name>/metadata/local.meta を編集して、各 savedsearch permission スタンザ下の [owner
= <username>] フィールドを、対応する LDAP ユーザー名のフィールドと交換してから、変更内容を保存します。
2. 変更内容を反映するため Splunk を再起動します。
LDAP ユーザー削除のベストプラクティス
LDAP ディレクトリからユーザーを削除する場合、Splunk がネイティブの認証ディレクトリからそれを⾃動的に
削除することはありません。通常このことは問題にはなりませんが、ユーザーが何らかのグローバル権限を持って
いた場合、LDAP でエラーが発⽣することがあります。
Splunk における LDAP ユーザーの作業に関する詳細は、このマニュアルの「LDAP によるユーザー認証の設
定」を参照してください)。
Splunk のディレクトリからユーザー名を安全に削除するために、以下の⼿順に従ってください。
1. まず、$HOME/splunk/etc/users/$userid フォルダをバックアップします。
2. $HOME/splunk/etc/apps/ 下のファイルのユーザー ID ⽂字列を検索して、ユーザーがグローバル権限を持つサーチ
やオブジェクトを所有しているかどうかを確認します。
3. ユーザーが所有しているサーチやオブジェクトの所有者を変更します。所有者を、管理者ユーザーや保守アカウ
ント、または他の適切なアカウントに変更してください。
4. サーチヘッドの
splunkd.log
をチェックして、他の LDAP 認証エラーが発⽣していないことを確認します。
5. 任意のオブジェクト所有権をリダイレクトしたら、$HOME/splunk/etc/users/$userid フォルダを安全に削除するこ
とができます。
外部システムによるユーザー認証の設定
外部システムによるユーザー認証の設定
Splunk では、3 種類の認証システムがサポートされています。
Splunk にビルトインされている独⾃のシステム。「Splunk 認証システムを使ったユーザー認証の設定」を
参照してください。
LDAPに関する説明は「LDAP を使ったユーザー認証の設定」を参照してください。
ここで説明する、PAM や RADIUS などの外部認証システムを使⽤するための、スクリプト認証 API。
重要: Splunk のビルトインシステムは、他の外部システムよりも常に優先されます。Splunk によるユーザーの
認証順序を以下に⽰します。
1. Splunk ビルトイン認証 2. LDAP またはスクリプト認証 (有効な場合)。LDAP の詳細は、「LDAP によるユー
24
ザー認証の設定」を参照してください。
スクリプト認証の仕組み
スクリプト認証では、ユーザーが⽣成した Python スクリプトが、Splunk サーバーと PAM や RADIUS などの
外部認証システム間の仲介役を果たします。
API は、Splunk と認証システム間のやり取りを処理するいくつかの関数から成り⽴っています。それらの関数を
実装するハンドラを持つスクリプトを作成する必要があります。
Splunk で認証システムを使⽤するには、認証システムが動作していることを確認の上で、以下の作業を⾏いま
す。
1. Python 認証スクリプトを作成します。詳細は、「認証スクリプトの作成」を参照してください。
2. authentication.conf を編集して、スクリプト認証と関連する設定を指定します。詳細は、
「authentication.conf の編集」を参照してください。
例
Splunk には、RADIUS ⽤や PAM ⽤を含めて、さまざまなサンプル認証スクリプトと関連する設定ファイルが⽤
意されています。また、dumbScripted.py と呼ばれる単純なスクリプトも⽤意されています。このスクリプトは、ス
クリプトと Splunk 間のやり取りに注⽬しています。
サンプルのスクリプトと設定ファイルを参考に、独⾃のスクリプトを作成することができます。ご⾃分の環境に合
わせて変更してください。
これらのサンプルは、$SPLUNK_HOME/share/splunk/authScriptSamples/ にあります。このディレクトリには、サンプル
に関する情報、および Splunk と外部認証システム間の接続に関する情報を記載した README ファイルも存在
しています。
重要: Splunk は、これらのスクリプトに関するサポートを提供していません。また、お客様の認証/セキュリ
ティニーズに適合していることは、保証いたしません。これらのサンプルはあくまでも参考例として提供されてお
り、お客様のニーズに合わせて変更/機能拡張する必要があります。
認証スクリプトの作成
Splunk で認証システムを使⽤するには、認証システムが動作していることを確認の上で、以下の作業を⾏いま
す。
1. Python 認証スクリプトを作成します。詳細は、「Python スクリプトの作成」を参照してください。
2. 新たなスクリプトをテストします。詳細は、「スクリプトのテスト」を参照してください。
3. authentication.conf を編集して、スクリプト認証と関連する設定を指定します。詳細は、
「authentication.conf の編集」を参照してください。
Python スクリプトの作成
以下の認証関数を実装した Python スクリプトを作成する必要があります。
userLogin
getUserInfo
getUsers
Splunk は必要に応じてこれらの関数を呼び出して、ユーザーログインの認証やユーザーのロール情報の取得を⾏
います。
必要に応じて、スクリプトにこの関数のハンドラを含めることもできます。
getSearchFilter
以下の表に、認証関数、引数、およびリターン値の概要を⽰します。
関数
説明
引数⽂字列
リターン値⽂字列
-username=<username>
userLogin
ユーザー資格情報を使って
ログインします。
fail
-password=<password>
(stdout 経由で安全に渡される)
(値は stdin 経由で
1 ⾏当たり 1 つ渡
される)
--status=success|fail
-userInfo=<userId>;<username>;<realname>;<roles>
25
以下の事項に注意してください。
は、セミコロン区切りリストで
指定する必要があります。
<userId> は廃⽌されました。単に関連す
るセミコロンのみが返されます。
<username> が必要です。
<realname> は省略できますが、そのセミ
コロンは必要です。
<roles> が必要です。複数のロールを返
すには、コロンを使って各ロールを区切
ります。
例: admin:power
この例では、「docsplunk」という名前
のユーザーのロールが返されます。
userInfo
getUserInfo
名前とロールを含めたユー
ザー情報を返します。
-username=<username>
--status=success -userInfo=;docsplunk;;admin:power
--status=success|fail
-userInfo=<userId>;<username>;<realname>;<roles>
-userInfo=<userId>;<username>;<realname>;<roles>
-userInfo=<userId>;<username>;<realname>;<roles>
...
getUsers
すべての Splunk ユーザー
の情報を返します。
以下の事項に注意してください。
なし
各ユーザーの情報を返す構⽂についての
情報は、getUserInfo を参照してくださ
い。
各ユーザーの情報はスペースで区切りま
す。
<roles> が必要です。複数のロールを返
すには、コロンを使って各ロールを区切
ります。
例: admin:power
--status=success|fail --search_filter=<filter>
--search_filter=<filter> ...
getSearchFilter
オプション。このユーザー
に特に適⽤されているフィ
ルタ、およびユーザーの
ロールに適⽤されている
フィルタを返します。各
フィルタは OR で結合され
ます。
-username=<username>
注意: ユーザーベースのサーチフィルタはオ
プションで、使⽤はお勧めできません。ロー
ルにサーチフィルタを割り当ててから、ユー
ザーをそのロールに割り当てることをお勧め
します。
詳細は、「サーチ時の getSearchFilter 関数
を使ったフィルタリング」を参照してくださ
い。
これらの関数の実装⽅法については、サンプルスクリプトを参照してください。
スクリプトのテスト
Splunk とスクリプト間の通信は stdin および stdout 経由で⾏われるため、Splunk から呼び出さずにコマンド
シェルから対話的にスクリプトをテストすることができます。1 ⾏当たり 1 つの引数を送信して、各関数呼び出
しは EOF (Ctrl-D) で終了するようにしてください。
以下のパターンで、各関数を個別にテストします。
> python [script] [function name]
[pass arguments here, one per line]
[send eof, with Ctrl-D]
[output appears here, check that it's correct]
>
架空のスクリプト「example.py」、および 2 ⼈のユーザー「alice」と「bob」を使った、スクリプトの簡単なテ
ストを⾏うデバッグセッションの例を以下に⽰します。ここで「alice」は「Admin」および「Super」ロールの
メンバーで、「bob」は「user」ロールのメンバーです。
> python example.py userLogin
--username=alice
26
--password=correctpassword
<send an EOF>
--status=success
> python example.py userLogin
--username=bob
--password=wrongpassword
<send an EOF>
--status=fail
> python example.py getUsers
<no arguments for this function, send an EOF>
--status=success --userInfo=bob;bob;bob;user --userInfo=alice;alice;alice;admin:super
> python example.py getUserInfo
--username=bob
<send an EOF>
--status=success --userInfo=bob;bob;bob;user
> python example.py getUserInfo
--username=userdoesnotexist
<send an EOF>
--status=fail
>
重要: これは単なるスクリプトのテスト例です。実際のスクリプトの徹底的なテストを想定している訳ではあり
ません。
authentication.conf の編集
Splunk で認証システムを使⽤するには、認証システムが動作していることを確認の上で、以下の作業を⾏いま
す。
1. 1. Python 認証スクリプトを作成、テストします。詳細は、「認証スクリプトの作成」を参照してください。
2. authentication.conf を編集して、認証スクリプトを有効にします。このトピックの「スクリプトを有効にす
る」を参照してください。
3. authentication.conf を編集して、キャッシュの保持期間を設定します。このトピックの「キャッシュ期間の設
定」を参照してください。
スクリプトを有効にする
認証を実装する Python スクリプトを作成したら、$SPLUNK_HOME/etc/system/local/ 内の authentication.conf を更新
してスクリプトを有効にします。また、$SPLUNK_HOME/share/splunk/authScriptSamples/ のサンプル
authentication.conf をコピーして編集することも可能です。
[authentication]スタンザのヘッダー下にある認証タイプに Scripted
を設定します。
[authentication]
authType = Scripted
authSettings = script
[script]
スタンザのヘッダー下に、スクリプト変数を設定します。例:
[script]
scriptPath = $SPLUNK_HOME/bin/python $SPLUNK_HOME/bin/<scriptname.py>
キャッシュ期間の設定
スクリプト認証使⽤時の認証パフォーマンスを⼤幅に⾼速化するには、Splunk の認証キャッシュ機能を活⽤して
ください。そのためには、オプションの [cacheTiming] スタンザを追加します。各スクリプト関数 (getSearchFilter
を除く) には、設定可能な cacheTiming 属性があります。この属性は当該関数のキャッシュをオンにして、またそ
のキャッシュ期間を⽰します。たとえば、getUserInfo 関数のキャッシュタイミングを指定するため
に、getUserInfoTTL 属性を使⽤します。関数のキャッシュは、対応する属性が指定されている場合にのみ⾏われま
す。
設定は、Splunk が外部認証システムと通信するためにスクリプトを呼び出す頻度を指定します。時間
は秒 (s)、分 (m)、時間 (h)、⽇数 (d) などで指定できます。⼀般的にはキャッシュの頻度を秒または分で指定し
ます。単位を指定しない場合は、デフォルトの秒で値が判断されます。つまり、「5」は「5s」とみなされます。
cacheTiming
この例は、⼀般的なキャッシュの値を表しています。
[cacheTiming]
userLoginTTL
= 10s
getUserInfoTTL
= 1m
27
getUsersTTL
= 2m
は、ユーザーのログイン/パスワード妥当性をキャッシュに格納する期間を決定するため、この値を低
めに設定することができます。
userLoginTTL
すべてのキャッシュをすぐに更新するには、CLI コマンド
reload auth
を使⽤します。
./splunk reload auth
注意: このコマンドは、現在のユーザーをシステムからブートオフすることはありません。
キャッシュは Splunk Web から更新することもできます。
1. [システム] メニューの [ユーザーと認証] で、[アクセス制御] を選択します。
2. [認証⽅法] をクリックします。
3. [認証設定の再読込] をクリックして、キャッシュを更新します。
指定された各関数 (getUsers を除く) は、各ユーザーに対して個別のキャッシュを保有します。そのため、10 ⼈の
ユーザーがログオンしており、getUserInfoTTL 属性を指定している場合、getUserInfo 関数は 10 個のユーザーベー
スのキャッシュを保持します。getUsers 関数にはすべてのユーザーが含まれるため、単⼀のグローバルキャッシュ
を保持します。
PAM 認証の使⽤
サンプルディレクトリ $SPLUNK_HOME/share/splunk/authScriptSamples/ にある README の記載⼿順に従って、
Splunk の PAM 認証を設定することができます。
それでも認証できない場合は、/etc/pam.d/pamauth を編集して以下の⾏を追加してください。
auth sufficient pam_unix.so
サーチ時の getSearchFilter 関数を使ったフィルタリング
この関数はオプションで、サーチ時のユーザーベースのフィルタリングを実装するために利⽤できま
す。getSearchFilter を有効にすると、サーチの実⾏時に毎回この関数が呼び出されます。ユーザーベースのサーチ
フィルタは、そのユーザーのロールに指定されているフィルタを補⾜するものです。ロールに設定されているフィ
ルタと⼀緒に、返されたフィルタが各サーチに適⽤されます。この関数では、フィルタのキャッシュは⾏われませ
ん。
注意: ユーザーベースのサーチフィルタはオプションで、使⽤はお勧めできません。ロールにサーチフィルタを
割り当ててから、ユーザーをそのロールに割り当てることをお勧めします。
getSearchFilter
関数を有効にするには、authentication.conf に
scriptSearchFilters
を設定します。
[script]
scriptPath = $SPLUNK_HOME/bin/python $SPLUNK_HOME/bin/<scriptname.py>
scriptSearchFilters = 1
注意: 以前のバージョンでは、Splunk のビルトインシステムで認証されていたユーザーのサーチフィルタを実装
するために、getSearchFilter を使⽤することもできました。現在は使⽤することができません。4.2 以降では、ス
クリプト認証で認証されたユーザーに対してのみ、getSearchFilter が呼び出されます。
また、getSearchFilter の呼び出しが失敗した場合、ユーザーのサーチはキャンセルされて、エラーメッセージが返
されます。こうすることで、不正なサーチからの結果をユーザーが⾒ることはありません。
SAML によるシングルサインオン設定
SAML によるシングルサインオンについて
シングルサインオンの設定を有効にするためには、IDP (Splunk Enterprise は現在 PingFederate の Ping
Identity 製品をサポートしています) により提供される情報を使⽤し、Splunk Web から SAML を使⽤するか、
authentication.conf を直接編集して Splunk Enterprise を設定します。
Splunk 6.3 では SAML 認証を使⽤してシングルサインオンの設定を⾏います。SAML で SSO を設定するには、
次の⼿順にしたがってください。
IDプロバイダ:現在、IDプロバイダは Ping Identity のみがサポートされています。
オンプレミスサーチヘッドを使⽤した設定:現在、SAML による SSO では、外部からの設定はサポートさ
れていません。
change_authentication Splunk 権限による admin ロール:この権限レベルにより、SAML を有効化し、
Splunk サーチヘッドでの認証設定を編集できます。
28
設定⽅法:
1.IDP を設定するか、IDP 設定へのアクセス権限があることを確認します。Splunk に認証⽅法を指定するには、
IDP からの情報が必要です。権限に関する属性を与えるには、IdP を設定しなければなりません。
role
realName
mail
2.IdP より返されるグループを Splunk ロールにマップします。複数のグループを1種類の Splunk ロールにマッ
プできます。
3.ログイン URL をユーザーに提供することで、ロールを与えられた IdP ユーザーは SSO でログインできるよう
になります。
詳細は、以下の項⽬を参照してください。
設定ファイルにおける SAML SSO の設定
Splunk Web における SAML SSO の設定
Splunk Web における SAML SSO の設定
Splunk サーバーを設定して SAML 認証システムを使⽤すると、その SAML サーバーの各グループを Splunk の
ロールにマップすることで、ログインする権限を与えられます。
1.[設定 ] メニューで、[アクセス制御 ] > [認証⽅法 ] を選択します。
2.認証タイプとして [SAML ] を選択します。
3.[SAML を使⽤ ] をクリックします。
4.「SAML グループ」のページで、[SAML 設定 ] をクリックします。
29
6.ページの [⼀般設定 ] セクションで、次の情報を⼊⼒します。
メタデータファイルを閲覧、選択するか、メタデータをテキストウィンドウに直接コピー/貼り付けします。
シングルサインオン URL を指定します。これは、Splunk が認証リクエストを送信する IdP 上の保護され
たエンドポイントです。ユーザーはこの URL を SSO ログインに使⽤します。SAML の有効化後に、通常
の Splunk ログイン画⾯を取得するには、完全なログイン URL (/account/login) に loginType=Splunk を付加
する必要があります。
シングルログアウト URL を指定してください。これが IdP プロトコルのエンドポイントになります。こ
の URL を指定しない場合、ユーザーはログアウトできません。
証明書ファイル を IdP に指定してください。
エンティティ ID を指定してください。これは、IdP の SP 接続エントリで設定されたエンティティ ID で
す。
署名済み認証リクエスト および署名済み SAML レスポンス を希望するかどうかチェック (希望すること
を推奨) してください。
属性クエリセクションでは次の情報を⼊⼒します。スケジュール済みサーチを後で作成するには、この情報を指定
する必要があります。
属性クエリ URL を指定します。これは、SOAP を介したクエリが送信される IdP 上のエンドポイントで
す。
属性クエリおよびレスポンスに署名をつけたいか(つけることを推奨)どうかをチェック し 、[はい]にチェッ
クする場合は必要資格情報を指定してください。
オプションとして、ページの⾼度な設定セクションで、次の情報を⼊⼒します。
ホスト名またはロードバランサー IP
ロードバランシング⽤リダイレクトポート
ログアウト後にユーザーをリダイレクトするかどうか (およびリダイレクト先)
グループのロールへのマップ
Splunk サーバーを設定して SAML 認証システムを使⽤すると、その SAML サーバーの各グループを Splunk の
ロールにマップすることで、ログインする権限を与えられます。
1.[設定] メニューで、[アクセス制御] > [認証⽅法] を選択します。
2.認証タイプとして [SAML ] を選択します。
3.[SAML を使⽤ ] をクリックします。
30
4.「SAML グループ」のページで、[新規グループ ] をクリックするか、変更したいグループへの [編集 ] リンクを
クリックします。
5.グループに名前をつけます。
6.このグループに指定したいロールを、左列から右列に動かして、決定します。
7.[保存 ] をクリックします。
設定ファイルにおける SAML SSO の設定
このページは現在作業中で、まもなく更新される予定です。
このトピックでは、設定ファイルを使⽤して SAMLv2 の SSO を設定する⽅法を説明します。
Splunk Enterprise の authentication.conf と
また、IDプロバイダを設定します。
設定
web.conf
を設定します。
authentication.conf
次の場所に以下のスタンザを設定してください。
authentication.conf
[authentication]
authSettings = saml_settings
authType = SAML
[rolemap_SAML]
admin = Super Admin;
power = Power Admin;
user = <list roles with no spaces> Admin;Employee;
[saml_settings]
entityId = <entityid>
idpAttributeQueryUrl = <path to the Attribute query> https://yourpatj/idp/attrsvc.ssaml2
idpCertPath = <path to the idp cert in Splunk> /home/user/splunk/saml-install/etc/auth/ping_idp.crt
idpSSOUrl = <path to the sso url> https://your path/idp/SSO.saml2
idpSLOUrl = <Lougout url. If not specified, this will be treated as a typical sso and the logout button will be
disabled> https://your path/idp/SLO.saml2 #
redirectPort=443
attributeQueryTTL = 3600
signAuthnRequest = true
signedAssertion = true
31
attributeQueryRequestSigned = true
attributeQuerySignedResponse = true
attributeQuerySoapPassword = <your password>
attributeQuerySoapUsername = <your username>
次の⽅法で属性クエリリクエストフィールドに対処します。これは、スタンザに含まれるものです。このように設
定を⾏うのは、既存の SSL 設定は強⼒過ぎて Ping Identity と連携できず、属性クエリが機能しないためです。
次のように対処して SSL 暗号を弱めることで Ping Identity を調整することができます。
#cipherSuite = TLSv1+MEDIUM:@STRENGTH
cipherSuite = ALL:!aNULL:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM
defaultRoleIfMissing = user
skipAttributeQueryRequestForUsers=admin,username,anotherusername
sslKeysfile = <path_to_saml_signing_cert_and_keys>
sslKeysfilePassword = <password_for_saml_keys>
enforceResponseVerification = false
設定
web.conf
次の場所に以下のスタンザを設定してください。
web.conf
# Make sure that appserver is not disabled in web.conf, i.e. it should have a valid config like the following:
[settings]
appServerPorts = 8123
IDプロバイダの設定
まず、IdP を設定して、Splunk メタデータをインポートしてください。Splunk Enterprise メタデータを IdP に
インポートするには、AuthnRequest 署名および AttributeQuery リクエスト署名設定に対し、 Splunk Enterprise と
IdP への互換性を持たせてください。
1.IdP 証明書を Splunk Enterprise インスタンスのファイルにエクスポートします。
2.web.conf と
authentication.conf
にSAML 設定スタンザのこの証明書を指定します。
3.Splunk Enterprise サーバー資格 (server.pem) を署名認証⽤ IdP にインポートします。
Splunk メタデータは SplunkWeb の /saml/spmetadata エンドポイントにヒットすればエクスポートができる点に
留意してください。また、splunkd で <SAML-sp-metadata</code> エンドポイントにアクセスすることが可能で
す。
SAML SSO のトラブルシューティング
ここでは、⼀般的な問題と解決⽅法を紹介します。
問題
次のメッセージが表⽰された場合。
ERROR AuthenticationManagerSAML - Requesting user info from ID returned an error Error in Attribute query request,
AttributeQueryTransaction err=Cannot resolve hostname, AttributeQueryTransaction descr=Error resolving: Name or
service not known, AttributeQueryTransaction statusCode=502
問題への対応策
が SAML スタンザで正しく指定されていることを確認してください。Ping Identity の設定⽅法
によっては、次の場合もあります。
cipherSuite
cipherSuite = TLSv1+MEDIUM:@STRENGTH
cipherSuite = ALL:!aNULL:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM
SOAP パスワード要件がすべて Ping Indentity の最新版に対応していることを確認してください。
SAML の SSL 設定が
authentication.conf
に正しく設定されていることを確認してください。
問題
次のメッセージが表⽰されます。
ERROR UserManagerPro - user="samluser1" had no roles
32
問題への対応策
で、各ロール名の最後に「;」がついた正しいロールのマップ設定が⾏われていることを確認し
てください。
rolemap_SAML
問題
次のメッセージが表⽰されます。
ERROR AuthenticationManagerSAML - Attribute query request failed. Status
code=urn:oasis:names:tc:SAML:2.0:status:UnknownPrincipal, Status msg=No attributes found for requested subject
問題への対応策
role、mail、realName
といった属性が AuthnRequest および属性クエリリクエストの⼀部として返されるよう
マップされていることを確認してください。
問題
ユーザーは、アサーション認証後はログインできません。有効な Splunk ロールがローカルマッピングまたはア
サーションに⾒つかりません。
問題への対応策
スタンザで、IdP から返されるロールと 適切な Splunk ロールとの正しいマッピングが⾏われ
ていることを確認してください。
rolemap_SAML
authentication.conf
に定義された各ロールの間または前後にスペースが無いことを確認してください。例:
user = User;Employee
問題
認証を SAML として設定し、設定は正しく⾏えたように思えますが、ログイン画⾯の代わりに Splunk の認証
ページが表⽰されます。
問題への対応策
web.conf
で
appServerPorts
が有効なポートに設定され、『0』になっていないことを確認してください。
リバースプロキシによるシングルサインオンの設定
リバースプロキシによるシングルサインオンについて
Splunk のシングル サインオン (SSO) を利⽤すれば、リバースプロキシを使って Splunk 認証 を処理することが
できます。いったんユーザーがプロキシにログインすると、その後は Splunk Web (およびプロキシに設定されて
いる他のアプリケーション) にシームレスにアクセスすることができます。
Splunk Enterprise SSO でリバースプロキシを使えば、Splunk Web のみを経由した Splunk Enterprise へのロ
グインがサポートされます。リバースプロキシは認証情報の保存に cookie を使⽤するため、Splunk の CLI 認証
に SSO を使⽤することはできません。https://localhost:8089 (または割り当てられている管理ポート) の起動に
は、別途の認証が必要です。
リバースプロキシによる SSO を利⽤するには、以下のものが必要になります。
プロキシサーバー (Splunk Enterprise は IIS または Apache をサポート)。
LDAP サーバーまたは他の外部認証システム。
正しく機能する Splunk Enterprise 設定。
これらの項⽬の設定⽅法と SSO のセットアップの詳細は、「シングル サインオンの設定」を参照してください。
仕組み
Splunk Enterprise の管理者とユーザーは Splunk Web でデプロイされているプロキシ経由で Splunk Web を起
動します。プロキシは到着した要求を、認証システムに対して認証します。認証が成功すると、プロキシは要求
ヘッダーに認証された ID 属性を設定し、その情報を Splunk Enterprise に送信します。
Splunk Enterprise はプロキシからの HTTP 要求を受け付けて、ヘッダーにユーザーが含まれている場合、ログ
インページをバイパスしてユーザーを⾃動認証します。
33
正常にシングル サインオンを⾏うためには、プロキシから Splunk Web への要求にはすべて、この認証された
ヘッダーが含まれていなければなりません。要求にヘッダーが含まれていない場合、設定内容に応じてユーザーに
ログインページまたはエラーメッセージが表⽰されます。Splunk は ID がブラウザセッションを終了するまでの
間、この認証されたヘッダーの使⽤を継続します。
Splunk によるプロキシ要求の処理⽅法
プロキシサーバーが Splunk Web に要求を⾏う場合、Splunk Web は web.conf 内の
プロキシの IP が信頼する IP のリストに記載されているかどうかを検証します。
trustedIP
の値を参照して、
IP が信頼する IP でない場合、要求は拒否されてシングルサインオンの試みは失敗します。信頼する IP アドレス
だった場合は、Splunk Web が要求ヘッダー内の ID をクエリして、splunkd に認証要求を送信します。
splunkd は Splunk Web からの要求を受信すると、クライアント (⼀般的には Splunk Web) から受信した IP ア
ドレスが server.conf ファイルの trustedIP プロパティの値と⼀致するかどうかを検証します。
IP アドレスが trustedIP にない場合、要求は拒否されてシングルサインオンの試みは失敗します。web.conf の
SSOmode 設定に応じて、ログインページに戻るか、またはエラーページが表⽰されます。この属性および他の設定
の詳細は、「Splunk シングルサインオンの設定」を参照してください。
信頼する IP である場合、splunkd は要求ヘッダーに含まれている情報を使⽤して、認証⼿続きを実⾏します。
Splunk によるユーザーの認証⽅法
Splunk はまず、与えられた ID とロールが Splunk ネイティブユーザー設定内のユーザーと⼀致するかどうかを
確認します。⼀致する情報がない場合、LDAP に⼀致する項⽬があるかどうかを検索します。(Splunk による
ユーザーの認証⽅法は、このマニュアルの「LDAP によるユーザー認証の設定」を参照してください)
⼀致する項⽬が⾒つからず、ヘッダー内に含まれているユーザーを認証できない場合は、ブラウザにエラーメッ
セージが表⽰されます。
⼀致する項⽬が⾒つからない場合、Splunk はユーザーを認証して、既存のセッションが存在しているかどうかを
確認します。セッションがすでに存在している場合、Splunk はそのセッション ID を使⽤して、ユーザーに
Splunk Web へのアクセスを許可するために必要な cookie を作成します。セッションが存在しない場合は、新し
いセッションと Splunk Web 認証に必要な cookie が⽣成されます。
34
cookie を作成すると、Splunk Web は標準の処理作業を再開します。それ以降のプロキシ URL 経由の Splunk
へのアクセスには、要求のヘッダーに信頼する ID が含まれており、ブラウザのセッションが終了されるまでの
間、再認証の必要はありません。
リバースプロキシによるシングルサインオンの設定
Splunk Enterprise でリバースプロキシベースの SSO を設定する前に、以下のものを⽤意していることを確認し
てください。
外部システムを認証するためのリバースプロキシとして設定されたプロキシサーバー (Splunk Enterprise
は IIS または Apache をサポート)。
認証のためにプロキシのグループやユーザーが適切にプロビジョニングされた、LDAP サーバーまたは他の
外部認証システム。
プロキシと同じ外部認証システム (⼀般的には LDAP) を使⽤するように設定された、または外部認証システ
ムに含まれているユーザー/グループ ID と⼀致するネイティブ Splunk ユーザーを持つ、正常に機能する
Splunk Enterprise 設定。
リバースプロキシによる SSO を設定するには、以下の⼿順にしたがってください。
1. 認証するプロキシサーバーのプロパティを編集します。
2. Splunk Enterprise
server.conf
3. Splunk Enterprise
web.conf
ファイルを編集します。
ファイルを編集します。
注意: セキュリティを最適化するために、TLS/SSL 対応のデプロイに、HTTP ヘッダーベースのソリューション
を実装する必要があります。
設定
server.conf
スタンザの trustedIP を編集して、splunkd に安全な認証要求を⾏うための IP アドレスを追加し
ます。⼀般的にこれは Splunk Web、つまり localhost になります。 splunkd インスタンス当たり 1 つの IP ア
ドレスのみを⼊⼒することができます。
general settings
trustedIP=127.0.0.1
trustedIP
リストに IP アドレスが指定されていない場合、デフォルトでは Splunk SSO が無効になります。
web.conf の設定
SSO を有効にするには、web.conf (SPLUNK_HOME/etc/system/local) 内の
る必要があります。
[settings]
スタンザで、以下の項⽬を設定す
SSOMode = strict
trustedIP = 127.0.0.1,10.3.1.61,10.1.8.81
remoteUser = X-Remote-User
tools.proxy.on = True
属性
デフォル
ト
値
SSOMode
属性は、Splunk Web の SSO が strict モードで動作するか、または
モードで動作するかを決定します。
permissive
SSOMode
no
Strict モードでは、trustedIP プロパティ内に記載されている IP アドレスと⼀致する
ID のみに認証が制限されます。接続を試みている IP が記載されているどの IP アド
レスとも⼀致しない場合、ユーザーにエラーメッセージが表⽰されます。SSO には
Strict モードを使⽤することをお勧めします。
Permissive モードも、trustedIP リストに記載されている IP に要求の認証を制限し
ます。Permissive モードでは、接続を試みている IP がどの IP アドレスとも⼀致し
ない場合、ユーザーにログインページを表⽰して再認証を要求します。
trustedIP
N/A
これに、認証プロキシの IP アドレスを設定します。単⼀のアドレスまたは複数のア
ドレスのカンマ区切りリストを指定します。IP 範囲やネットマスク表記はサポート
されていません。
属性は、HTTP 要求ヘッダー経由でプロキシサーバーに渡される、認証さ
れた ID 属性を決定します。この値のデフォルトは REMOTE_USER ですが、プロキシが
認証後に LDAP に属性プロパティを設定する限り、この要求ヘッダー経由で任意の
LDAP 属性を渡すことができます。remoteUser 属性を設定する場合、ID 属性を
Splunk に渡すために、プロキシ設定内に RequestHeader プロパティを設定する必要
があります。この⼿順については、「Splunk シングルサインオンについて」を参照
してください。
remoteUser
remoteUser
REMOTE_USER
デフォルトで使⽤される Splunk ヘッダーは REMOTE_USER ですが、ご利⽤のプロキシ
が別のヘッダーを使⽤している場合は、ここでヘッダー名を変更することができま
す。
35
Splunk SSO を使⽤するには、tools.proxy.on に次の値を設定します:
tools.proxy.on
false
true
「false」を設定すると、ログオンしているコンピューターの IP アドレスを使⽤し
ますが、Splunk Enterprise の SSO でユーザーの代わりにログオンを要求するのは
プロキシです。IP アドレスが trustedIP プロパティに記載されていない場合、要求
は拒否されるため、この値に True を設定すると、Splunk Web がプロキシの IP ア
ドレスを確認することを表しています。
Splunk Web をプロキシの背後に設置しており、Splunk Web をプロキシのルートに配置していない場合
は、$SPLUNK_HOME/etc/system/local/web.conf 内の root_endpoint も設定する必要があります。
たとえば Splunk Web を「yourhost.com:9000/splunk」で提供している場合は、root_endpoint に
する必要があります。
/splunk
を設定
例:
root_endpoint=/lzone
ProxyPass /lzone http://splunkweb.splunk.com:8000/lzone
ProxyPassReverse /lzone http://splunkweb.splunk.com:8000/lzone
上記の例で、Splunk Web は
でアクセスされます。
次に
httpd.conf
http://splunk.example.com:8000/
の代わりに
http://splunk.example.com:8000/lzone
経由
でマッピングを設定し、プロキシが参照できるようにします。
ProxyPass /lzone http://splunkweb.splunk.com:8000/lzone
ProxyPassReverse /lzone http://splunkweb.splunk.com:8000/lzone
セッション管理
セッションの簡単なログアウト⼿段はありません。プロキシのヘッダー内に正しいヘッダー情報が含まれている限
り Splunk Enterprise はセッションを保持するため、そのことを考慮して適切なプロキシのセッション・タイム
アウト値を設定する必要があります。
タイムアウトになる前にセッションを終了する必要がある場合は、REST エンドポイントとセッション ID を使っ
てセッションを破棄してください。
curl -s -uadmin:changeme
-k -X DELETE https://localhost:8089/services/authentication/httpauth-
tokens/990cb3e61414376554a39e390471fff0
リバースプロキシ SSO のトラブルシューティング
Splunk Web には、デプロイ環境のデバッグに役⽴つ、環境とランタイムデータを分析するためのインターフェ
イスが⽤意されています。このページには、プロキシ経由でまたは直接 URL を⼊⼒してアクセスできます。プロ
キシサーバー経由でこのページにアクセスしない場合、要求ヘッダーは利⽤できません。
この URL は以下のようになります。
http://YourSplunkServer:8000/debug/sso
トラブルシューティングページを使ってデプロイ環境を分析する場合は、以下の事項を考慮してください。
[Splunk trusted IP] (Splunk が信頼する IP) として提供されている IP をホスト IP と⽐較してくださ
い。これらの値が同じでなければなりません (ご利⽤のプロキシの IP でなければなりません)。トラブル
シューティングページで両者の値が異なる場合は、server.conf の trustedIP の値を変更する必要がありま
す。
[ Incoming request IP received by splunkweb ] (splunkweb が受信した IP リクエスト)の値を確
認して、ご利⽤のクライアントの IP アドレスが表⽰されていることを確認します。クライアントの IP と⼀
致しない場合は、以下の作業を⾏う必要があります。
web.conf を編集してこれを修正する。
tools.proxy.on に true が設定されていることを確認する。
プロキシがヘッダーを提供していることを確認します。[Other HTTP Headers] (その他の HTTP ヘッ
ダー)下の [Authorization] (認証)フィールドをチェックしてください。値が存在しない場合は、プロ
キシの http.conf ファイルをチェックして、リモートヘッダー属性値が正しく設定されているかどうかを確
認してください。Splunk は、リモートヘッダー値の X_REMOTE_USER を受け付けるように設定されています。
⼤部分のプロキシでは、この値がデフォルト値になっています。プロキシのリモートヘッダーが異なってお
り、その値を保持しておきたい場合は、web.conf のリモートヘッダー値を編集して、Splunk が受け付ける
ヘッダーを変更してください。詳細は、「SSO の設定」を参照してください。
Splunk Web が splunkd に送信する cookie を作成しているかどうかを確認します。[Other HTTP
headers] (その他の HTTP ヘッダー)の [Cookie] (クッキー)フィールドをチェックして、cookie が
設定されていることを確認してください。cookie が設定されていない場合は、web.conf ファイルをチェック
して、ファイルが正しく設定されているかどうかを確認してください。詳細は、「SSO の設定」を参照して
ください。
36
SSL を使った Splunk Enterprise の保護について
SSL を使った Splunk の保護について
このセクションでは、SSL を使って保護する Splunk 設定のタイプについて説明していきます。
Splunk には、⼀連の証明書が⽤意されており、デフォルトではそれを使⽤するように設定されています。これら
の証明書により⼀般的な不正アクセス試⾏を防⽌することはできますが、Splunk に同梱されているルート証明書
はすべて同じルート証明書で、同じルート証明書を持つユーザーは認証できてしまうため、そのままでは脆弱性が
存在しています。
デフォルトの証明書は、起動時に⽣成/設定され、$SPLUNK_HOME/etc/auth/ に保管されます。
デフォルトの証明書は⽣成後 3 年で失効するように設定されており、失効後はこのマニュアルに記載されている
説明に従って、新しく証明書を作成、設定する必要があることに注意してください。
Splunk Web のデフォルト証明書の詳細は、「Splunk Web で暗号化 (https) を有効にする」または
「web.conf で (https) を有効にする」を参照してください。
デフォルトの証明書で転送するための SSL に関する情報については、「デフォルトの証明書を使⽤する
Splunk 転送の設定」を参照してください。
主に 3 種類の設定シナリオに、暗号化や認証を適⽤することができます。
ブラウザと Splunk Web 間の通信
Splunk のフォワーダー からインデクサー への通信
管理ポート経由の Splunk インスタンス間の通信
もっとも⼀般的なシナリオと、デフォルトの SSL 設定を以下の表に⽰します。
やり取りの
種類
クライアント機
能
サーバー機能
暗号化
証明書認証
共通名の
チェック
やり取りされ
るデータの種
類
ブラウザと
Splunk
Web
ブラウザ
Splunk Web
デフォル
トでは無
効
クライアント
クライアント
⽤語のサーチ
(ブラウザ) が記 (ブラウザ) が記
結果
述
述
Splunk 間
通信
Splunk Web
splunkd
デフォル
トで有効
デフォルトでは デフォルトでは ⽤語のサーチ
無効
無効
結果
フォワー
ダーとして
splunkd
インデ
クサーとして
デフォル
トでは無
効
デフォルトでは デフォルトでは インデックス
無効
無効
対象データ
転送
splunkd
Splunk 間
通信
splunkd
Splunk 間
通信
splunkd
デプロイ splunkd デプロ
デフォル
クライアントとし イサーバーとし トで有効
て
て
デフォルトでは デフォルトでは
設定データ
無効
無効
サーチ
ヘッドとして
デフォルトでは デフォルトでは
サーチデータ
無効
無効
サーチ
ピアとして
splunkd
デフォル
トで有効
ブラウザと Splunk Web 間の通信
ブラウザから Splunk Web へのデータは、主にサーチ要求と返されたデータで構成されています。
Splunk Web を使って、または設定ファイル を編集して、データの暗号化 (HTTPS) を⼿軽に有効化できます。
デフォルトの証明書による暗号化は、⼀般的な傍受に対処することができますが、完全に保護される訳ではないこ
とに注意してください。
よりセキュリティを強化するためには、デフォルトの証明書を信頼されている CA が署名した証明書に置換して
ください。この場合、証明書に⾃⼰署名するのではなく、CA 証明書を使⽤することを強くお勧めします。
Splunk Web にアクセスする各ブラウザの証明書ストアに CA を追加できない限り、ユーザーのブラウザは⾃⼰
署名の証明書を信頼できないものとみなします。詳細は、「Splunk Web の保護について」を参照してくださ
い。
Splunk フォワーダーからインデクサー
フォワーダーからインデクサーに送信されるデータは、インデクサーがサーチやレポートに使⽤するデータです。
組織、伝送されるデータの形式、および Splunk 設定に応じて、データは読み取り可能または保護されている場合
も、そうではない場合もあります。
機密 raw データを保護すれば、不正利⽤や中間者攻撃の防⽌に役⽴ちます。
SSL 暗号化を有効にすると、デフォルトの証明書が使⽤され、暗号化/圧縮機能が提供されます。ただし、デフォ
ルトの証明書を使った通信では、インストールされている各 Splunk に証明書パスワードが提供されるため、保護
された認証⼿段を提供していません。デフォルトの証明書は初期スタートアップ後 3 年で失効するように設定さ
れています。失効すると、フォワーダーとインデクサー間の通信は失敗します。
セキュリティを強化するには、署名された証明書を使った証明書認証が必要です。既知の相互に信頼している認証
局が署名した証明書は、⾃⼰署名した証明書よりもさらに安全であると外部の第三者には認識されます。Splunk
フォワーダーおよびインデクサーでの証明書の使⽤に関する詳細は、「フォワーダーからのデータの保護」を参照
してください。
37
Splunk 間
Splunk 間通信は、異なる Splunk インスタンス間で管理ポート経由で⾏われます。⼀般的には分散環境で⾏われ
ますが、常に⾏われる訳ではありません。たとえば、デプロイサーバーからクライアントに送信される設定データ
がこれにあたります。
デフォルトで SSL 暗号化は、Splunk 内通信に対して有効になっています。たいていの場合はこれで⼗分で、
Splunk 内通信に対して推奨できるセキュリティタイプです。ただし、Splunk 間通信を SSL 認証で保護する必要
がある場合は、このマニュアルの「Splunk 間通信の保護について」に記載されているガイドラインを参照してく
ださい。
共通名のチェック
セキュリティを強化するために、証明書を作成する際には共通名を指定して、証明書の認証時にその共通名を
チェックするように Splunk を設定してください。署名された任意の証明書に対して、共通名のチェックを設定で
きます。
暗号スイートの指定
Splunk 間および Splunk フォワーダーとインデクサー間の通信に使⽤する暗号スイートを選択、指定することが
できます。暗号スイートを追加するには、サーバー SSL 設定スタンザの最後に⾏を追加します。
詳細は、「暗号スイートの決定」を参照してください。
証明書の取得
SSL 証明書の専⾨知識がある場合、普段通りに証明書を作成して、Splunk インスタンスがそれを使⽤するように
設定することができます。
証明書を⼊⼿するために何らかの⼿助けが必要な⽅のために、OpenSSL コマンドを使ったとても簡単な例を⽤意
しました。(OpenSSL は Splunk に同梱されています)
証明書の⾃⼰署名⽅法
サードパーティの証明書の⼊⼿⽅法
Splunk Web ⽤証明書の⾃⼰署名⽅法
Splunk Web ⽤サードパーティの証明書の⼊⼿⽅法
証明書を保有している場合の作業
以下のトピックは、証明書⼊⼿後の、証明書を使⽤するための Splunk の設定⽅法について説明しています。
独⾃の証明書を使った Splunk Web の保護
独⾃の証明書を使⽤するための、Splunk 転送の設定
Splunk 間通信の保護について
Windows および Linux での SSL ツールの使⽤について
このマニュアルには、デフォルトの⾃⼰署名証明書、または認証局が署名した証明書を使⽤するための、Splunk
の設定⽅法が記載されています。証明書を持たない⽅のために、Splunk に同梱されている OpenSSL とコマンド
ラインを使った証明書の⽣成の、簡単な例も記載されています。
OpenSSL コマンドラインの使⽤例
このマニュアルには、コマンドラインで Splunk の OpenSSL を使って証明書を作成するための、いくつかの基
本的な例が記載されています。これらの作業を実施するためには、ルート管理者権限が必要です。リモートマシン
または仮想マシンで作業を⾏う場合は、全作業を完了するために追加⼿順が必要になることもあります。
Windows プラットフォームで作業している場合、管理者権限でコマンドラインを開く必要があります。ス
タートメニューで、.exe アプリケーションを右クリックして [管理者として実⾏ ] を選択してください。
*nix プラットフォームで作業を⾏う場合、ルート管理者としてログインするために sudo を使⽤する必要が
あります。
Windows と *nix の差異については、『管理』マニュアルを参照してください。
SSL ツールについて
Splunk には、最新バージョンの OpenSSL が $SPLUNK_HOME/splunk/lib に⽤意されています。6.0 の Splunk は、
FIPS 140-2 を有効にした OpenSSL をサポートしています。
証明書の作成と設定に利⽤できる、他のさまざまな SSL ツールを購⼊/ダウンロードして利⽤することができま
す。証明書の設定に OpenSSL を使⽤する場合、互換性の問題を回避するために、Splunk に同梱されているバー
ジョンを使⽤することを強くお勧めします。Splunk に同梱されているバージョンを確実に使⽤するために、
Windows の場合は環境に $SPLUNK_HOME/splunk/lib または $SPLUNK_HOME\splunk\bin のバージョンを設定してくださ
い。
*nix の場合のライブラリパスの例を以下に⽰します。
export LD_LIBRARY_PATH=$SPLUNK_HOME/splunk/lib
38
Windows の場合のライブラリパスの例を以下に⽰します。
set PATH = %PATH%;%SPLUNK_HOME%\bin
FIPS について
FIPS は法規制に適合するために、いくつかの政府認定版アルゴリズムを使⽤しています。それ⾃体はセキュリ
ティ拡張を考慮していないため、システムが遅くなる可能性があります。環境で規制に適合するために FIPS が必
要な場合にのみ、有効にすることをお勧めします。
FIPS を有効にすることを検討している場合は、以下の事項に注意してください。
Splunk は、Linux、Windows、および Solaris 上での OpenSSL と FIPS 140-2 (64 ビット x86) のみをサ
ポートしています。
デフォルトで FIPS は無効になっていますが、カーネルが FIPS モードで動作している Linuxマシン上で
Splunk を実⾏すると、⾃動的に FIPS が有効になります。
FIPS モジュールは、Splunk が App の実⾏に使⽤する Python インスタンス内の⼀部の暗号アルゴリズム
の使⽤を無効にします (md5 と rc4 など)。実⾏する Splunk App が FIPS モードで正常に動作し、それら
のアルゴリズムと依存関係がないことを確認してください。
FIPS を有効にするには:
最初に Splunk を開始する前に、$SPLUNK_HOME/etc/splunk-launch.conf を編集して次の⾏を追加します:
SPLUNK_FIPS=1
注意: ⾮ FIPS インストールの FIPS へのアップグレードはサポートされていません。FIPS を使⽤するかどうか
は、初期インストール時に決定する必要があります。
許可/制限する SSL バージョンの設定
Splunk Enterprise 6.2 には、古いバージョンのプロトコルを制限するためのキーワード sslVersions が⽤意され
ています。 アップグレードを容易にするために SSLv3 は最初から⽤意されていますが、アップグレードが完了し
たらすぐに無効化する必要があります。デフォルトで Splunk Enterprise は SSLv3 以降のバージョンでの通信を
許可しています。
Splunk Enterprise を FIPS モードで設定する場合、他の設定に関係なく SSLv2 と SSLv3 は常に無効になりま
す。
警告: v3 の「POODLE」脆弱性に対処するために、環境にアップグレードを適⽤する際には SSLv3 を削除する
ように設定を更新することを強くお勧めします。
1. web.conf で、Splunk Enterprise にサポートさせるバージョン (カンマで区切る) を記載または制限するよう
に、sslVersions 属性を更新します。デフォルトでこの属性は *,-sslv2 に設定されます。この場合、SSLv2 より新
しい任意のバージョンが対象となります (⾮推奨)。6.2 で許可されている SSL のバージョンを以下に⽰します。
sslv2 (⾮推奨)
sslv3 (⾮推奨)
tls1.0
tls1.1
tls1.2
例:
sslVersions = tls1.0, tls1.1, tls1.2
構⽂オプション
サポートされているすべてのバージョンを選択するには、「*」を使⽤します:
sslVersions = *
tls1.0 以降のすべてのバージョンを含めるには、「tls」を使⽤します:
sslVersions = tls
特定のバージョンを制限するには、その前に「-」を付けます:
sslVersions = *, -sslv3
注意: Splunk Enterprise を FIPS モードで設定する場合、この設定に関係なく SSLv2 と SSLv3 は常に無効に
なります。
2. inputs.conf で、Splunk Enterprise にサポートさせるバージョン (カンマで区切る) を記載または制限するよう
に、sslVersions 属性を更新します。
sslVersions = sslv2, tls1.0, tls1.1, tls1.2
サポートするすべてのバージョンを選択するために、「*」を使⽤できます:
sslVersions = *
39
tls1.0 以降のすべてのバージョンを含めるには、「tls」を使⽤します:
sslVersions = tls
特定のバージョンを制限するには、バージョンの前に「-」を付けます:
sslVersions = *, -sslv3
3. インデクサーと互換性があるようにフォワーダーを設定します。SSL のバージョンの変更または制限 (および
SSLV3 の制限) により、フォワーダーとの互換性上の問題が発⽣する可能性があります (特に古いバージョンの
Splunk Enterprise が動作している場合)。6.2 が動作しているフォワーダーの場合は、インデクサーの他に各
フォワーダーの inputs.conf および web.conf の設定も更新することで、互換性上の問題を軽減することができま
す。
インデクサーおよび SSL の設定と適合するように、フォワーダーを 6.2 に更新してください (下位互換性のため
に、6.0 は tls1.0 までをサポートできます)。
4. サーバーを設定し、クライアントとの接続を承認します (例えば、web.conf の承認は、
アントと同じものに編集して⾏います)。
sslVersions
属性をクライ
SSL 証明書の取得
証明書の⾃⼰署名⽅法
ここでは、フォワーダーからインデクサーへの通信および Splunk 間通信を保護するための、OpenSSL を使って
証明書に⾃⼰署名をする⽅法の 1 つを説明しています。
すでに必要な証明書の⽣成⽅法が分かっている場合は、このトピックをスキップしてこのマニュアルに記載されて
いる設定ステップに移動しても構いません。
Splunk ⽤の署名された証明書の準備⽅法
独⾃の証明書を使⽤するための、Splunk 転送の設定
Splunk 間通信の保護について
⾃⼰署名証明書は、組織内または既知のエンティティ間で⾏われるデータ通信に利⽤するのに適しています。何ら
かの理由で未知のエンティティと通信する必要がある場合は、認証局が署名した証明書を使ってデータを保護する
ことをお勧めします。
作業を開始する前に
この説明で、$SPLUNK_HOME は Splunk のインストールディレクトリを表しています。Windows の場合、デフォル
トで Splunk は C:\Program Files\splunk にインストールされます。⼤部分の UNIXプラットフォームでは、デフォ
ルトのインストールディレクトリは /opt/splunk になります。Mac OSの場合は、/Applications/splunk になりま
す。Windows および *nix での作業の詳細は、『管理マニュアル』を参照してください。
環境が *nix の場合は $SPLUNK_HOME/splunk/lib に、Windows の場合は $SPLUNK_HOME\splunk\bin 内のバージョンを設
定して、Splunk に同梱されているバージョンの OpenSSL を使⽤するようにしてください。そのために、以下の
作業を⾏うことができます。
証明書を作成する前に、$SPLUNK_HOME/bin/setSplunkEnv を実⾏します。
または
$SPLUNK_HOME/bin/
に移動して、./openssl を使って証明書⽣成コマンドを実⾏します。
証明書⽤の新規ディレクトリの作成
証明書の作成時には、作業⽤の新しいディレクトリを作成してください。この例で
は、$SPLUNK_HOME/etc/auth/mycerts を使⽤しています。
# mkdir $SPLUNK_HOME/etc/auth/mycerts
# cd $SPLUNK_HOME/etc/auth/mycerts
Splunk は、$SPLUNK_HOME/etc/auth に保管されている既存の証明書を上書きすることがないように、新しいフォル
ダを作成することを強くお勧めします。新しいディレクトリを使って作業することで、Splunk に同梱されている
$SPLUNK_HOME/etc/auth 内の証明書を保護し、必要に応じて他の Splunk コンポーネントで使⽤することができま
す。
ルート証明書の作成
まず、ルート認証局としての役割を果たすルート証明書を作成します。このルート認証局を使って、⽣成したサー
バー証明書に署名して、それを Splunk インスタンスに配布することができます。
ルート証明書⽤の秘密鍵の⽣成
1. 証明書に署名するための鍵を作成します。
40
*nix の場合:
# openssl genrsa -des3 -out myCAPrivateKey.key 1024
Windows の場合、openssl.cnf ファイルの場所を追加する必要があります。
>openssl genrsa -des3 -out myCAPrivateKey.key 1024
この例では、DES3 暗号および 1024 ビットのキー⻑を使⽤していることに注意してください。機密データの場
合は、可能な限り 2048 ビット以上のキー⻑を使⽤することをお勧めします。
2. 鍵のパスワードの作成を要求するメッセージが表⽰されたら、パスワードを作成します。
このステップが完了すると、ディレクトリに秘密鍵
myCAPrivateKey.key
が表⽰されます。
証明書の⽣成と署名
1. 新しい証明書署名要求 (CSR) を⽣成します。
*nix の場合:
# openssl req -new -key myCAPrivateKey.key -out myCACertificate.csr
Windows の場合:
>openssl req -new -key myCAPrivateKey.key -out myCACertificate.csr -config $SPLUNK_HOME\openssl.cnf
2. プロンプトが表⽰されたら、$SPLUNK_HOME/etc/auth/mycerts/myCAPrivateKey.key 内の秘密鍵に対して作成したパス
ワードを⼊⼒します。
3. 要求された証明書情報を指定します (Splunk 環境で共通名チェックを使⽤する場合は共通名も含めて)。
ディレクトリに、新しい CSR
4. CSR
myCACertificate.csr
myCACertificate.csr
が表⽰されます。
を使って、公開証明書を⽣成します。
*nix の場合:
# openssl x509 -req -in myCACertificate.csr -sha1 -signkey myCAPrivateKey.key -CAcreateserial -out
myCACertificate.pem -days 1095
Windows の場合:
>openssl x509 -req -in myCACertificate.csr -sha1 -signkey myCAPrivateKey.key -CAcreateserial -out
myCACertificate.pem -days 1095
5. プロンプトが表⽰されたら、秘密鍵
ディレクトリに、新しいファイル
公開 CA 証明書です。
myCAPrivateKey.key
myCACertificate.pem
のパスワードを⼊⼒します。
が表⽰されます。これは、Splunk インスタンスに配布する
サーバー証明書の作成
認証局としての役割を果たすルート証明書を作成したら、サーバー証明書を作成して署名する必要があります。
重要: この例は、新しい秘密鍵とサーバー証明書を作成する⽅法を表しています。このサーバー証明書はすべて
のフォワーダー、インデクサー、および管理ポートで通信する Splunk インスタンスに配布することができます。
各インスタンスで個別の共通名を使⽤する場合は、ここで説明している⼿順を繰り返して、Splunk インスタンス
に対する別個の証明書 (それぞれが別の共通名を持つ) を作成してください。
たとえば、複数のフォワーダーを設定する場合、以下の例を使⽤してインデクサー⽤の証明書
myServerCertificate.pem を作成して、次に同じルート CA を使⽤して myForwarderCertificate.pem を作成し、その証
明書をフォワーダーにインストールすることができます。インデクサーは、同じルート認証局により署名され、適
切に⽣成、設定されたフォワーダーからの証明書のみを受け付けます。
フォワーダーとインデクサーの設定の詳細については、「独⾃の証明書を使⽤するための Splunk 転送の設定」を
参照してください。
サーバー証明書⽤の鍵の⽣成
1. サーバー証明書⽤の新しい RSA 秘密鍵を⽣成します。この例でも、DES3 暗号と 1024 ビットのキー⻑を使⽤
します。
*nix の場合:
# openssl genrsa -des3 -out myServerPrivateKey.key 1024
Windows の場合:
# openssl genrsa -des3 -out myServerPrivateKey.key 1024
41
2. 鍵の新たなパスワードの作成を要求するメッセージが表⽰されたら、パスワードを作成します。
新しい鍵 myServerPrivateKey.key が作成されます。この鍵は、サーバー証明書の⼀部としてインストールした任意
の Splunk インスタンスの送信データの暗号化に使⽤されます。
新しいサーバー証明書の⽣成と署名
1. 新しいサーバー秘密鍵
myServerPrivateKey.key
を使って、サーバー証明書の CSR を⽣成します。
*nix の場合:
# openssl req -new -key myServerPrivateKey.key -out myServerCertificate.csr
Windows の場合:
openssl req -new -key myServerPrivateKey.key -out myServerCertificate.csr -config $SPLUNK_HOME\openssl.cnf
2. プロンプトが表⽰されたら、秘密鍵
myServerPrivateKey.key
にパスワードを指定します。
3. 要求された証明書の情報を指定します。共通名のチェックにより認証するように Splunk を設定する場合は、共
通名も指定します。
ディレクトリに、新しい CSR
myServerCertificate.csr
4. CSR
および CA 証明書と秘密鍵を使ってサーバー証明書を⽣成します。
myServerCertificate.csr
が表⽰されます。
*nix の場合:
# openssl x509 -req -in myServerCertificate.csr -sha1 -CA myCACertificate.pem -CAkey myCAPrivateKey.key CAcreateserial -out myServerCertificate.pem -days 1095
Windows の場合:
# openssl x509 -req -in myServerCertificate.csr -sha1 -CA myCACertificate.pem -CAkey myCAPrivateKey.key CAcreateserial -out myServerCertificate.pem -days 1095
5. プロンプトが表⽰されたら、認証局秘密鍵 myCAPrivateKey.key のパスワードを⼊⼒します。この署名には、作成
したサーバー鍵ではなく、ご⾃分の秘密鍵を使⽤してください。
ディレクトリに、新しい公開サーバー証明書
myServerCertificate.pem
が表⽰されます。
次のステップ
この時点で作成したディレクトリ内には、以下のファイルが存在しているはずです。これらのファイルを利⽤し
て、管理ポート経由で通信を⾏うインデクサー、フォワーダー、および Splunk インスタンスの設定を⾏うことが
できます。
myServerCertificate.pem
myServerPrivateKey.key
myCACertificate.pem
必要な証明書を⼊⼿したら、サーバー証明書を準備して (中間証明書の追加も含む)、次に Splunk がそれらを使⽤
するように設定する必要があります。
Splunk への証明書の設定⽅法については、「Splunk ⽤の署名された証明書の準備⽅法」を参照してくださ
い。
転送⽤の証明書認証の設定については、「独⾃の証明書を使⽤するための Splunk 転送の設定」を参照して
ください。
Splunk 間通信のための証明書認証の設定⽅法の詳細は、「Splunk 間通信の保護について」を参照してくだ
さい。
サードパーティが署名した証明書の⼊⼿⽅法
ここでは、Splunk に同梱されている OpenSSL を使った、サードパーティ証明書の⼊⼿⽅法の 1 つを説明してい
ます。この証明書は、フォワーダーからインデクサーへの通信や Splunk 間通信を保護する⽬的で使⽤することが
できます。
証明書を⼊⼿するために、保護されたブラウザと Splunk Web 間の通信を使⽤できます。詳細は、「Splunk
Web ⽤のサードパーティが署名した証明書の⼊⼿」を参照してください。
すでに必要な証明書の⽣成⽅法が分かっているまたは証明書を所有している場合は、このトピックをスキップして
このマニュアルの後半に記載されている設定ステップに移動しても構いません。
独⾃の証明書を使⽤するための、Splunk 転送の設定
Splunk 間通信の保護について
注意: 設定に複数の共通名を使⽤する場合、ここに記載されている⼿順を繰り返して、同じルート CA を使って
独⾃の共通名を持つ各サーバー証明書を作成し、その後それらを使⽤するように Splunk インスタンスを設定する
ことができます。フォワーダーとインデクサーの設定の詳細については、「独⾃の証明書を使⽤するための
42
Splunk 転送の設定」を参照してください。
作業を開始する前に
この説明で、$SPLUNK_HOME は Splunk のインストールディレクトリを表しています。Windows の場合、デフォル
トで Splunk は C:\Program Files\splunk にインストールされます。⼤部分の UNIXプラットフォームでは、デフォ
ルトのインストールディレクトリは /opt/splunk になります。Mac OSの場合は、/Applications/splunk になりま
す。Windows および *nix での作業の詳細は、『管理マニュアル』を参照してください。
環境が *nix の場合は $SPLUNK_HOME/splunk/lib に、Windows の場合は $SPLUNK_HOME/splunk/bin 内のバージョンを設
定して、Splunk に同梱されているバージョンの OpenSSL を使⽤するようにしてください。
証明書⽤の新規ディレクトリの作成
証明書の作成時には、作業⽤の新しいディレクトリを作成してください。この例で
は、$SPLUNK_HOME/etc/auth/mycerts を使⽤しています。
# mkdir $SPLUNK_HOME/etc/auth/mycerts
# cd $SPLUNK_HOME/etc/auth/mycerts
にある既存の証明書を上書きすることがないように、新しい証明書と鍵を保管するための新
しいフォルダを作成することを強くお勧めします。新しいディレクトリを使って作業することで、Splunk に同梱
されている証明書を保護し、必要に応じて他の Splunk コンポーネントで使⽤することができます。
$SPLUNK_HOME/etc/auth
サーバー証明書の要求
認証局に送信するには、証明書署名要求 (CSR) を作成して、それに署名します。
重要: この例は、新しい秘密鍵を作成し、サーバー証明書を要求する⽅法を表しています。このサーバー証明書
はすべてのフォワーダー、インデクサー、および管理ポートで通信する Splunk インスタンスに配布することがで
きます。各インスタンスで個別の共通名を使⽤する場合は、ここで説明している⼿順を繰り返して、Splunk イン
スタンスに対する別個の証明書 (それぞれが別の共通名を持つ) を作成してください。
たとえば、複数のフォワーダーを設定する場合、以下の例を使⽤してインデクサー⽤の証明書
myServerCertificate.pem を作成して、次に同じルート CA を使⽤して myForwarderCertificate.pem を作成し、その証
明書をフォワーダーにインストールすることができます。インデクサーは、同じルート認証局により署名され、適
切に⽣成、設定されたフォワーダーからの証明書のみを受け付けます。
フォワーダーとインデクサーの設定の詳細については、「独⾃の証明書を使⽤するための Splunk 転送の設定」を
参照してください。
サーバー証明書⽤の秘密鍵の⽣成
1. 新しい秘密鍵を作成します。以下の例では DES3 暗号と 1024 ビットのキー⻑を使⽤しています。可能な場合
は 2048 ビット以上のキー⻑を使⽤することをお勧めします。
*nix の場合:
# openssl genrsa -des3 -out myServerPrivateKey.key 1024
Windows の場合:
>openssl genrsa -des3 -out myServerPrivateKey.key 1024 -config $SPLUNK_HOME\openssl.cnf
2. 鍵のパスワードの作成を要求するメッセージが表⽰されたら、パスワードを作成します。
作業が完了したら、ディレクトリ内に新しい秘密鍵
書署名要求 (CSR) に署名します。
myServerPrivateKey.key
が作成されます。この鍵を使って証明
新しい証明書署名要求 (CSR) の⽣成
1. 新しい秘密鍵
myServerPrivateKey.key
を使って、サーバー証明書の CSR を⽣成します。
*nix の場合:
# openssl req -new -key myServerPrivateKey.key -out myServerCertificate.csr
Windows の場合:
>openssl req -new -key myServerPrivateKey.key -out myServerCertificate.csr -config $SPLUNK_HOME\openssl.cnf
2. プロンプトが表⽰されたら、秘密鍵
myServerPrivateKey.key
に対して作成したパスワードを⼊⼒します。
3. 要求された証明書に関する情報を指定します。共通名チェックを使⽤する場合は、証明書の詳細の⼊⼒時に共通
名も指定してください。
作業が完了すると、ディレクトリ内に新しい CSR
myServerCertificate.csr
サーバー証明書と公開鍵のダウンロードと検証
43
が表⽰されます。
1. CSR を認証局 (CA) に送って、新しいサーバー証明書を要求します。使⽤する認証局によって、要求⼿続きは
異なります。
2. 準備が完了したら、認証局から新しいサーバー証明書をダウンロードします。このマニュアルの例では、この証
明書を myServerCertificate.pem と呼ぶことにします。
3. また、認証局の公開 CA 証明書もダウンロードします。このマニュアルの例では、この証明書を
myCACertificate.pem と呼ぶことにします。
認証局が PEM 形式の証明書を提供していない場合は、そのファイルタイプに応じた OpenSSL コマンドを使って
証明書を変換する必要があります。変換⽅法の詳細は、OpenSSL のドキュメントを参照してください。
4. 内容を確認して、必要なものがすべて揃っていることを確認してください。
「Issuer」エントリは CA の情報を参照していなければなりません。
「Subject」エントリには、先ほどの CSR 作成時に⼊⼒した情報 (国名、組織名、共通名など) が表⽰され
ていなければなりません。
次のステップ
この時点で作成したディレクトリ内には、以下のファイルが存在しているはずです。これらのファイルを利⽤し
て、管理ポート経由で通信を⾏うインデクサー、フォワーダー、および Splunk インスタンスの設定を⾏うことが
できます。
myServerCertificate.pem
myServerPrivateKey.key
myCACertificate.pem
必要な証明書を⼊⼿したら、サーバー証明書を準備して (中間証明書の追加も含む)、次に Splunk がその証明書を
使⽤するように設定する必要があります。
Splunk への証明書の設定⽅法については、「Splunk ⽤の署名された証明書の準備⽅法」を参照してくださ
い。
転送⽤の証明書認証の設定については、「独⾃の証明書を使⽤するための Splunk 転送の設定」を参照して
ください。
Splunk 間通信のための証明書認証の設定⽅法の詳細は、「Splunk 間通信の保護について」を参照してくだ
さい。
Splunk ⽤の署名された証明書の準備⽅法
証明書を⼊⼿したら、サーバー証明書と鍵を単⼀のファイルにまとめて、Splunk が使⽤できる状態にする必要が
あります。
まだ証明書を持っておらず、⼊⼿する必要がある⽅のために、以下のトピックでは OpenSSL を使⽤する基本的
な例を説明しています。
証明書の⾃⼰署名⽅法
サードパーティが署名した証明書の⼊⼿⽅法
注意: Splunk で SSL を設定する場合、証明書と公開鍵が x509 フォーマット、秘密鍵が RSA フォーマットに
なっていることを確認してください。
単⼀の PEM ファイルの作成
署名サーバー証明書、サーバーの秘密鍵、および CA 公開鍵を単⼀の PEM ファイルに統合します。
ここの例では、「証明書の⾃⼰署名⽅法」および「サードパーティが署名した証明書の⼊⼿⽅法」で使⽤したファ
イル名を使⽤します。
以下は、*nix ⽤です。
# cat myServerCertificate.pem myServerPrivateKey.key myCACertificate.pem > myNewServerCertificate.pem
以下は、Windows ⽤です。
>type myServerCertificate.pem myServerPrivateKey.key myCACertificate.pem > myNewServerCertificate.pem
作成するファイル
myNewServerCertificate
には、以下の順序で情報が含まれていなければなりません。
サーバー証明書 (myServerCertificate.pem)
秘密鍵 (myServerPrivateKey.key)
認証局公開鍵 (myCACertificate.pem)
適切に連結された証明書の例を以下に⽰します。
-----BEGIN CERTIFICATE----MIICUTCCAboCCQCscBkn/xey1TANBgkqhkiG9w0BAQUFADBtMQswCQYDVQQGEwJV
...
<Server Certificate>
...
44
8/PZr3EuXYk1c+N5hgIQys5a/HIn
-----END CERTIFICATE---------BEGIN RSA PRIVATE KEY----Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,CFCECC7976725DE5
S+DPcQ0l2Z1bk71N3cBqr/nwEXPNDQ4uqtecCd3iGMV3B/WSOWAQxcWzhe9JnIsl
...
<Server Private Key - Passphrase protected>
...
-----END RSA PRIVATE KEY---------BEGIN CERTIFICATE----MIICUTCCAboCCQCscBkn/xey1TANBgkqhkiG9w0BAQUFADBtMQswCQYDVQQGEwJV
...
<Certificate Authority Public Key>
...
8/PZr3EuXYk1c+N5hgIQys5a/HIn
-----END CERTIFICATE-----
証明書チェーンの設定⽅法
複数の証明書を使⽤する場合は、サーバーの証明書ファイルの最後に中間証明書を追加してください。必要な数の
証明書を追加することができます。ルートまで、階層の降順に追加してください。
証明書は以下の順番で連結する必要があります。
[ server certificate]
[ intermediate certificate]
[ root certificate (if required) ]
証明書チェーンの例を以下に⽰します。
-----BEGIN CERTIFICATE----... (certificate for your server)...
-----END CERTIFICATE---------BEGIN CERTIFICATE----... (the intermediate certificate)...
-----END CERTIFICATE---------BEGIN CERTIFICATE----... (the root certificate for the CA)...
-----END CERTIFICATE-----
次のステップ
必要な証明書が揃ったら、Splunk がそれらを使⽤するように設定を⾏います。
転送⽤の証明書認証の設定については、「独⾃の証明書を使⽤するための Splunk 転送の設定」を参照して
ください。
Splunk 間通信のための証明書認証の設定⽅法の詳細は、「Splunk 間通信の保護について」を参照してくだ
さい。
Splunk Web ⽤の⾃⼰署名証明書
ここでは、Splunk に同梱されている OpenSSL を使った、コマンドラインからの基本的な⾃⼰署名証明書の作成
例を説明していきます。
⾃⼰署名証明書の作成⽅法は、社内規則、ご利⽤のプラットフォーム、および使⽤するツールによってさまざまで
す。すでにこれらの証明書と鍵を⽣成している場合、または証明書の⽣成経験がある場合は、ここをスキップして
このマニュアルの「独⾃の証明書を使った Splunk Web の保護」に進んでも構いません。
⾃⼰署名証明書はご⾃分の組織により署名されているため、それにブラウザ証明書ストアは含まれていません。そ
のため、Web ブラウザは⾃⼰署名証明書を「信頼できない」ものとみなします。そのため、ユーザーには警告
メッセージが表⽰され、場合によってはユーザーのアクセスが禁⽌されることもあります。
⾃⼰署名証明書は、使⽤するすべてのブラウザに独⾃の CA を追加できる、社内または既知のエンティティ間で
の、ブラウザから Splunk Web への通信に使⽤するのに適しています。その他の状況では、CA の署名証明書を
使⽤することをお勧めします。詳細は、「Splunk Web ⽤のサードパーティが署名した証明書の⼊⼿」を参照し
てください。
作業を開始する前に
この説明で、$SPLUNK_HOME は Splunk のインストールディレクトリを表しています。Windows の場合、デフォル
トで Splunk は C:\Program Files\splunk にインストールされます。⼤部分の UNIXプラットフォームでは、デフォ
ルトのインストールディレクトリは /opt/splunk になります。Mac OSの場合は、/Applications/splunk になりま
45
す。Windows および *nix での作業の詳細は、『管理マニュアル』を参照してください。
環境が *nix の場合は $SPLUNK_HOME/splunk/lib に、Windows の場合は $SPLUNK_HOME/splunk/bin 内のバージョンを設
定して、Splunk に同梱されているバージョンの OpenSSL を使⽤するようにしてください。
認証局とする新しいルート証明書の⽣成
1. 証明書と鍵⽤の新しいディレクトリを作成します。この例では、$SPLUNK_HOME/etc/auth/mycerts を使⽤します。
既存の証明書を上書きしないように、新しい証明書は $SPLUNK_HOME/etc/auth/splunkweb とは違うディレクトリに保
管することをお勧めします。そうすることによって、必要に応じて他の Splunk コンポーネント
で、$SPLUNK_HOME/etc/auth/splunkweb 内の Splunk に同梱されている証明書を使⽤できます。
注意: 「証明書の⾃⼰署名⽅法」の説明に従って⾃⼰署名証明書を作成した場合は、ルート証明書をディレクト
リにコピーして、次のステップ「Splunk Web ⽤の新しい秘密鍵の作成」をスキップすることができます。
2. 新しい RSA 秘密鍵を作成します。この例では、1024 ビットのキー⻑を使⽤しています。
# openssl genrsa -des3 -out myCAPrivateKey.key 1024
Windows の場合、openssl.cnf ファイルの場所を追加しなければならない場合もあります。
>openssl genrsa -des3 -out myCAPrivateKey.key 1024
-config $SPLUNK_HOME\openssl.cnf
この例では 1024 ビットのキー⻑を使⽤していますが、ご利⽤のブラウザがサポートしている場合はそれ以上の
キー⻑を使⽤することもできます。機密データの場合は、可能な限り 2048 ビット以上のキー⻑を使⽤すること
をお勧めします。
3. プロンプトが表⽰されたら、パスワードを作成します。
ディレクトリに秘密鍵
myCAPrivateKey.key
4. ルート証明書の秘密鍵
が表⽰されます。これがルート証明書の秘密鍵になります。
myCAPrivateKey.key
を使って、証明書署名要求を⽣成します。
*nix の場合:
# openssl req -new -key myCAPrivateKey.key -out myCACertificate.csr
Windows の場合:
>openssl req -new -key myCAPrivateKey.key -out myCACertificate.csr
5. 秘密鍵
myCAPrivateKey.key
-config $SPLUNK_HOME\openssl.cnf
にパスワードを指定します。
ディレクトリに、新しい CSR
myCACertificate.csr
が表⽰されます。
6. CSR を使って新しいルート証明書を⽣成して、それにご⾃分の秘密鍵で署名します。
*nix の場合:
# openssl x509 -req -in myCACertificate.csr -signkey myCAPrivateKey.key -out myCACertificate.pem -days 3650
Windows の場合:
>openssl x509 -req -in myCACertificate.csr -signkey myCAPrivateKey.key -out myCACertificate.pem -days 3650
-config
$SPLUNK_HOME\openssl.cnf
7. プロンプトが表⽰されたら、秘密鍵
ディレクトリに、新しい証明書
myCAPrivateKey.key
myCACertificate.pem
にパスワードを指定します。
が表⽰されます。これが公開証明書になります。
Splunk Web ⽤の新しい秘密鍵の作成
1. 新しい秘密鍵を作成します。
*nix の場合:
# openssl genrsa -des3 -out mySplunkWebPrivateKey.key 1024
Windows の場合:
>openssl genrsa -des3 -out mySplunkWebPrivateKey.key 1024 -config $SPLUNK_HOME\openssl.cnf
2. プロンプトが表⽰されたら、パスワードを作成します。
ディレクトリに、新しい鍵
mySplunkWebPrivateKey.key
が表⽰されます。
3. 鍵からパスワードを削除します。(現在 Splunk Web はパスワードで保護された秘密鍵をサポートしていませ
ん。)
46
*nix の場合:
# openssl rsa -in mySplunkWebPrivateKey.key -out mySplunkWebPrivateKey.key
Windows の場合:
>openssl rsa -in mySplunkWebPrivateKey.key -out mySplunkWebPrivateKey.key -config $SPLUNK_HOME\openssl.cnf
パスワードが削除されたことを確認するには、以下のコマンドを実⾏します。
*nix の場合:
# openssl rsa -in mySplunkWebPrivateKey.key -text
Windows の場合:
>openssl rsa -in mySplunkWebPrivateKey.key -text -config $SPLUNK_HOME\openssl.cnf
パスワードを⼊⼒せずに、証明書の内容を参照できるはずです。
サーバー証明書の作成と署名
1. 秘密鍵
mySplunkWebPrivateKey.key
を使って、新しい証明書署名要求を作成します。
*nix の場合:
# openssl req -new -key mySplunkWebPrivateKey.key -out mySplunkWebCert.csr
Windows の場合:
>openssl req -new -key mySplunkWebPrivateKey.key -out mySplunkWebCert.csr -config $SPLUNK_HOME\openssl.cnf
ディレクトリに CSR
mySplunkWebCert.csr
2. ルート証明書秘密鍵
myCAPrivateKey.key
が表⽰されます。
で CSR に⾃⼰署名します。
*nix の場合:
# openssl x509 -req -in mySplunkWebCert.csr -CA myCACertificate.pem -CAkey myCAPrivateKey.key -CAcreateserial -out
mySplunkWebCert.pem -days 1095
Windows の場合:
>openssl x509 -req -in mySplunkWebCert.csr -CA myCACertificate.pem -CAkey myCAPrivateKey.key -CAcreateserial -out
mySplunkWebCert.pem -days 1095 -config $SPLUNK_HOME\openssl.cnf
3. プロンプトが表⽰されたら、ルート証明書秘密鍵
ディレクトリに証明書
mySplunkWebCert.pem
myCAPrivateKey.key
のパスワードを⼊⼒します。
が追加されます。これがサーバー証明書になります。
単⼀の PEM ファイルの作成
サーバー証明書と公開証明書を以下の順序で単⼀の PEM ファイルにまとめます。
証明書チェーンの設定
複数の証明書を使⽤する場合は、サーバーの証明書ファイルの最後に、中間証明書を以下の順番で追加してくださ
い。
[ server certificate]
[ intermediate certificate]
[ root certificate (if required) ]
証明書チェーンの例を以下に⽰します。
-----BEGIN CERTIFICATE----... (certificate for your server)...
-----END CERTIFICATE---------BEGIN CERTIFICATE----... (the intermediate certificate)...
-----END CERTIFICATE---------BEGIN CERTIFICATE----... (the root certificate for the CA)...
-----END CERTIFICATE-----
47
次のステップ
証明書が⽤意できたら配布して、splunkd と Splunk Web がそれを使⽤するように設定する必要があります。詳
細は、このマニュアルの「独⾃の証明書を使った Splunk Web の保護」を参照してください。
Splunk Web ⽤のサードパーティが署名した証明書の⼊⼿
ここでは、Splunk Web の SSL 認証/暗号化を設定するために必要な、サードパーティが署名した証明書の、基
本的な作成例について説明していきます。
ここで説明する⼿順は、Splunk 固有の作業ではありません。これらの証明書の作成⽅法は、社内規則、ご利⽤の
ネットワーク構造、および使⽤するツールによってさまざまです。すでにこれらの証明書と鍵を⽣成している場
合、またはサードパーティ証明書の作成経験がある場合は、ここをスキップしてこのマニュアルの「独⾃の証明書
を使った Splunk Web の保護」に進んでも構いません。
作業を開始する前に
この説明で、$SPLUNK_HOME は Splunk のインストールディレクトリを表しています。Windows の場合、デフォル
トで Splunk は C:\Program Files\splunk にインストールされます。⼤部分の UNIXプラットフォームでは、デフォ
ルトのインストールディレクトリは /opt/splunk になります。Mac OSの場合は、/Applications/splunk になりま
す。Windows および *nix での作業の詳細は、『管理マニュアル』を参照してください。
環境が *nix の場合は $SPLUNK_HOME/lib に、Windows の場合は $SPLUNK_HOME/bin 内のバージョンを設定して、
Splunk に同梱されているバージョンの OpenSSL を使⽤するようにしてください。
Splunk Web ⽤の新しい秘密鍵の作成
1. 独⾃の証明書と鍵⽤の新しいディレクトリを作成します。この例では、$SPLUNK_HOME/etc/auth/mycerts を使⽤しま
す。
既存の証明書を上書きしないように、新しい証明書は $SPLUNK_HOME/etc/auth/splunkweb とは違うディレクトリに保
管することをお勧めします。そうすることによって、必要に応じて他の Splunk コンポーネントで、Splunk に同
梱されている証明書を使⽤できます。
2. 新しい秘密鍵を作成します。この例では 1024 ビットのキー⻑を使⽤していますが、ご利⽤のブラウザがサ
ポートしている場合はそれ以上のキー⻑を使⽤することもできます。機密データの場合は、可能な限り 2048
ビット以上のキー⻑を使⽤することをお勧めします。
# openssl genrsa -des3 -out mySplunkWebPrivateKey.key 1024
Windows の場合、openssl.cnf ファイルの場所を追加しなければならないことがあることに注意してください。
>openssl genrsa -des3 -out mySplunkWebPrivateKey.key 1024 -config $SPLUNK_HOME\openssl.cnf
3. プロンプトが表⽰されたら、パスワードを作成します。
ディレクトリに新しい秘密鍵
できます。
mySplunkWebPrivateKey.key
が追加されます。この鍵を使って CSR に署名することが
4. 秘密鍵からパスワードを削除します (Splunk Web は秘密鍵のパスワードをサポートしていません)。
*nix の場合:
# openssl rsa -in mySplunkWebPrivateKey.key -out mySplunkWebPrivateKey.key
Windows の場合:
>openssl rsa -in mySplunkWebPrivateKey.key -text -config $SPLUNK_HOME\openssl.cnf
パスワードが正常に削除されたことを確認するには、以下のコマンドを使⽤します。
*nix の場合:
# openssl rsa -in mySplunkWebPrivateKey.key -text
Windows の場合:
>openssl rsa -in mySplunkWebPrivateKey.key -text -config $SPLUNK_HOME\openssl.cnf
オリジナルの鍵のパスフレーズの⼊⼒を要求するプロンプトが表⽰されます。(鍵からのパスフレーズの削除を検
証するため)
パスワードが正常に削除されていれば、パスワードを⼊⼒せずに証明書の内容を参照できます。
認証局 (CA) 要求の作成とサーバー証明書の⼊⼿
1. 秘密鍵
mySplunkWebPrivateKey.key
を使って、新しい証明書署名要求を作成します。
*nix の場合:
48
# openssl req -new -key mySplunkWebPrivateKey.key -out mySplunkWebCert.csr
Windows の場合:
>openssl req -new -key mySplunkWebPrivateKey.key -out mySplunkWebCert.csr -config $SPLUNK_HOME\openssl.cnf
Windows プラットフォームの注意事項: 次のようなエラーが表⽰された場合
Unable to load config info from c:\\build-amd64-5.0.2-20130120-1800\\splunk/ssl/openssl.cnf
コマンドプロンプトに以下のコマンドを⼊⼒してから、もう⼀度
openssl
コマンドを実⾏してください。
set OPENSSL_CONF=c:/Program Files/Splunk/openssl.cnf
2. この CSR mySplunkWebCert.csr を使って、認証局 (CA) に新しい署名証明書を要求します。署名証明書の要求⼿
順は、利⽤する認証局が証明書署名要求をどのように取り扱っているかによって異なります。詳細は CA にお問
い合わせください。
3. 認証局から返されたサーバー証明書をダウンロードします。ここでは、これを「mySplunkWebCert.pem」と呼ぶこ
とにします。
4. 認証局の公開 CA 証明書をダウンロードします。ここでは、これを「myCAcert.pem」と呼ぶことにします。
5. サーバー証明書と公開 CA 証明書の両⽅が PEM フォーマットであることを確認します。証明書が PEM フォー
マットでない場合は、そのファイルタイプに応じた openssl コマンドを使ってファイルを変換してください。DER
フォーマットを変換するコマンドの例を以下に⽰します。
x509 -in input.crt -inform DER -out output.crt -outform PEM/x509 -in input.crt -inform DER -out output.crt outform PEM
6. 両⽅の証明書に必要な情報が含まれており、またパスワードで保護されていないことを確認します。
# openssl x509 -in myCACert.pem -text
# openssl x509 -in mySplunkWebCert.pem -text
>openssl x509 -in myCACert.pem -text -config $SPLUNK_HOME\openssl.cnf
>openssl x509 -in mySplunkWebCert.pem -text -config $SPLUNK_HOME\openssl.cnf
の発⾏者 (Issuer) 情報は、myCACert.pem の発⾏先 (Subject) 情報でなければなりません (中間
証明書を使⽤している場合を除く)。
mySplunkWebCert.pem
証明書と鍵の単⼀ファイルへの統合
サーバー証明書と公開証明書を以下の順序で単⼀の PEM ファイルにまとめます。
証明書チェーンの設定
複数の証明書を使⽤する場合は、サーバーの証明書ファイルの最後に、中間証明書を以下の順番で追加してくださ
い。
[ server certificate]
[ intermediate certificate]
[ root certificate (if required) ]
証明書チェーンの例を以下に⽰します。
-----BEGIN CERTIFICATE----... (certificate for your server)...
-----END CERTIFICATE---------BEGIN CERTIFICATE----... (the intermediate certificate)...
-----END CERTIFICATE---------BEGIN CERTIFICATE----... (the root certificate for the CA)...
-----END CERTIFICATE-----
中間証明書に署名したルート CA およびすべての中間証明書が、ブラウザ証明書ストア内になければならないこ
とに注意してください。
次のステップ
証明書を認証に使⽤するには、Splunk の web.conf ファイルを設定します。詳細は、「独⾃の証明書を使った
Splunk Web の保護」を参照してください。
暗号スイートの決定
Splunk 間、Splunk Web、および Splunk フォワーダーとインデクサー間の通信に使⽤する暗号スイートを選
49
択、指定することができます。暗号スイートを追加するには、サーバー SSL 設定スタンザの最後に⾏を追加しま
す。
フォワーダーからインデクサーへの証明書認証設定時の、inputs.conf の更新⽅法の例を以下に⽰します。
[splunktcp-ssl:9998]
[SSL]
password = password
requireClientCert = false
rootCA = $SPLUNK_HOME/etc/auth/cacert.pem
serverCert = $SPLUNK_HOME/etc/auth/server.pem
cipherSuite = AES256-SHA256:DHE-RSA-AES256-SHA256
利⽤できる暗号を確認するには:
$SPLUNK_HOME/bin/splunk cmd openssl ciphers -v
$SPLUNK_HOME/bin/splunk cmd openssl ciphers -v "TLSv1.2"
$SPLUNK_HOME/bin/splunk cmd openssl ciphers -v "HIGH"
利⽤できる暗号スイートは、OpenSSL のバージョンに基づいています。実⾏している OpenSSL のバージョンを
確認するには:
$SPLUNK_HOME/bin/splunk cmd openssl version
SSL による ブラウザから Splunk Web への通信の保
護
Splunk Web の保護について
Splunk Web に送信される情報の⼤半は、サーチ要求とその結果です。
ブラウザから Splunk Web への通信を常に保護する必要はないことに注意してください。たとえば、ユーザーが
常に Splunk Web と同じファイアウォールの背後にあるローカルのブラウザからのみ Splunk Web にアクセスす
る場合は、セキュリティがさほど重要ではないことがあります。このような場合は、Splunk のデフォルト証明書
を使った単純な暗号化でも⼗分かもしれません。
Splunk Web のデフォルト証明書の詳細は、「Splunk Web で暗号化 (https) を有効にする」または
「web.conf で (https) を有効にする」を参照してください。
デフォルトの証明書で転送するための SSL に関する情報については、「デフォルトの証明書を使⽤する
Splunk 転送の設定」を参照してください。
基本的な暗号化を有効にするには、「Splunk Web で暗号化 (https) を有効にする」を参照してください。
⼀⽅、ファイアウォール外のさまざまな場所からブラウザで Splunk Web にアクセスするような分散環境の場合
は、署名証明書を使って強⼒なセキュリティを採⽤する必要があります。署名証明書を使⽤するための Splunk
Web の設定⽅法については、「トラッキング時の証明書を使った Splunk Web の保護」を参照してください。
署名証明書を使⽤してブラウザから Splunk Web への通信セキュリティを強化するには、さまざまな⽅法が存在
しています。
認証付きの保護された暗号化の場合、デフォルトの証明書を署名証明書に置換することができます。
Splunk が提供するデフォルトの証明書を、要求した信頼できる認証局からの証明書に置換します。これが
もっとも安全な⽅法で、セキュリティが重要な場合はこの⽅法を利⽤することをお勧めします。
認証局証明書の⼊⼿⽅法については、「Splunk Web ⽤のサードパーティが署名した証明書の⼊⼿」を参照
してください。
保護された認証に⾃⼰署名証明書を使⽤することもできますが、そのような証明書は既知の信頼されている
認証局ではなく⾃⾝が署名しているため、ブラウザが証明書ストアであなたを認証局として認識せず、結果
的に証明書が信頼されないことに注意してください。⾃⼰署名証明書を有効にするには、Splunk Web にア
クセスする各ブラウザの証明書ストアに証明書を追加する必要があります。
⾃⼰署名証明書の作成⽅法については、「Splunk Web ⽤の⾃⼰署名証明書」を参照してください。
署名証明書を使⽤する場合、共通名チェックをオンにして SSL 設定をさらに強化することができま
す。
共通名チェックでは、各通信インスタンスの証明書内の共通名が⼀致する必要があり、新たなセキュリティ
層が追加されます。共通名チェックは証明書の作成時に有効にできます。また、認証時に共通名をチェック
するように、Splunk を設定する必要があります。
Splunk で証明書を使⽤するための設定および共通名の詳細は、「独⾃の証明書を使った Splunk Web の保護」
を参照してください。
Splunk Web で暗号化 (https) を有効にする
ここでは、Splunk Web を使って、ブラウザから Splunk Web への https 通信を有効にする⽅法について説明し
ていきます。Splunk は HTTPS または HTTP を待機できますが、両⽅を待機することはできません。
Splunk Web で利⽤できる単純暗号化は、同梱されているデフォルトの証明書を使⽤しています。インストール
50
される各 Splunk にはすべて同じデフォルトの証明書が同梱されているため、この⽅法はセキュリティがあまり強
くはありません。セキュリティを重視する場合は、デフォルトの証明書を変更して、適切な認証⼿段を設定するこ
とでセキュリティを強化することをお勧めします。デフォルト証明書の変更⽅法については、「独⾃の証明書を
使った Splunk Web の保護」を参照してください。
Splunk Web を使って HTTPS を有効にするには:
1. Splunk Web で、[システム] > [システム設定] を選択します。
2. [Splunk Web で SSL (HTTPS) を有効にしますか?] で、[はい] ボタンを選択します。
暗号化を有効にすると、Splunk はデフォルトの証明書を指すように設定されています。以下のデフォルト設定
は、$SPLUNK_HOME/etc/auth/web.conf に存在しています。
[settings]
enableSplunkWebSSL = true
privKeyPath = etc/auth/splunkweb/privkey.pem
caCertPath = etc/auth/splunkweb/cert.pem
3. Splunk Web を再起動します。
これで、Splunk Web にアクセスする際には、URL の先頭に「https://」を追加する必要があります。
web.conf で暗号化 (https) を有効にする
設定ファイルを使って HTTPS を有効にすることができます。ローカルディレクトリに存在していない場
合は、デフォルト版のファイルを $SPLUNK_HOME/etc/system/default から、ローカルディレクトリ
$SPLUNK_HOME/etc/system/local/、または $SPLUNK_HOME/etc/apps/ 内の独⾃のカスタム App ディレクトリにコピーしま
す。設定ファイルの⼀般情報については、「設定ファイルについて」を参照してください。
web.conf
ここで有効にする暗号化は、さほど安全ではありません。セキュリティを重視する場合は、デフォルトの証明書を
変更して、適切な認証⼿段を設定することでセキュリティを強化することをお勧めします。デフォルト証明書の変
更⽅法については、「独⾃の証明書を使った Splunk Web の保護」を参照してください。
web.conf
で HTTPS を有効にするには:
1. enableSplunkWebSSL 属性に
true
を設定します。
[settings]
httpport = <https port number>
enableSplunkWebSSL = true
注意: デフォルトでは暗号化を有効にすると、Splunk はデフォルトの証明書を指すように設定されています。こ
の設定は、$SPLUNK_HOME/etc/auth/web.conf にあります。
[settings]
enableSplunkWebSSL = true
privKeyPath = etc/auth/splunkweb/privkey.pem
caCertPath = etc/auth/splunkweb/cert.pem
2. 「Splunk の開始」の説明に従って、Splunk Web を再起動します。
これで、Splunk Web にアクセスする際には、URL の先頭に「https://」を追加する必要があります。
独⾃の証明書を使った Splunk Web の保護
この例は、すでに⾃⼰署名証明書を⽣成しているか、またはサードパーティの証明書を購⼊していることを前提に
しています。まだ⼊⼿しておらず、何をすればよいか分からない場合は、以下のような簡単な例を参照してくださ
い。
Splunk Web ⽤の⾃⼰署名証明書
Splunk Web ⽤のサードパーティが署名した証明書の⼊⼿
注意: 現在 Splunk Web はパスワードで保護された秘密鍵をサポートしていません。Splunk Web の証明書の設
定を⾏う前に、鍵からパスワードを削除してください。
開始前に:新しいディレクトリへの証明書のコピー
サーバー証明書を $SPLUNK_HOME/etc/auth/splunkweb、または
ピーしてください。
以下の例では、Web 証明書
mySplunkWebCertificate.pem
$SPLUNK_HOME/etc/auth
および秘密鍵
mySplunkWebPrivateKey.key
*nix:
# cp $SPLUNK_HOME/etc/auth/mycerts/mySplunkWebCertificate.pem
$SPLUNK_HOME/etc/auth/mycerts/mySplunkWebPrivateKey.key
$SPLUNK_HOME/etc/auth/splunkweb
51
内の独⾃の証明書リポジトリにコ
を使⽤しています。
Windows:
copy $SPLUNK_HOME\etc\auth\mycerts\mySplunkWebCertificate.pem $SPLUNK_HOME\etc\auth\splunkweb\
copy $SPLUNK_HOME\etc\auth\mycerts\mySplunkWebPrivateKey.key $SPLUNK_HOME\etc\auth\splunkweb\
注意: $SPLUNK_HOME/etc/auth/splunkweb/ にある既存の証明書を上書きしたり、削除したりはしないでください。こ
の場所にある証明書は起動時に⾃動的に⽣成されるため、何らかの変更を⾏っても起動時に上書きされてしまいま
す。代わりに次のステップで、新しい証明書の場所を指すように、関連する設定ファイルを編集します。
鍵と証明書ファイルを使⽤するための Splunk Web の設定
注意: Splunk Web は秘密鍵のパスワードをサポートしていません。Splunk Web の保護に鍵を使⽤する前に、
鍵からパスワードを削除する必要があります。
1. $SPLUNK_HOME/etc/system/local/web.conf (デプロイサーバーを使⽤している場合は、他の適切な場所)
で、[settings] スタンザに以下の変更を⾏います。
編集した設定スタンザの例を以下に⽰します。
[settings]
enableSplunkWebSSL = true
privKeyPath = etc/auth/splunkweb/mySplunkWebPrivateKey.key
caCertPath = etc/auth/splunkweb/mySplunkWebCertificate.pem
2. Splunk Web を再起動します。
# $SPLUNK_HOME/bin/splunk restart splunkweb
caCertPath
属性に関する重要な注意事項
属性を使って新しいデフォルト証明書を指定する場合、指定する証明書ファイルが以下の条件を満たし
ていることを確認してください。
caCertPath
最低 1 つのサーバー SSL 証明書と 1 つの認証局 (CA) 証明書が含まれている。
複数の証明書が適切な順番で格納されている。
サーバーの SSL 証明書。
必要な場合は、中間証明書。
必要な場合は、ルート証明書。
最良の結果を得るために、証明書ファイルへの絶対パスを使⽤している。相対パスも使⽤できますが、それ
らのパスは $SPLUNK_HOME と相対的なもので、この設定を変更することはできません。
CA 証明書しかない場合、SSL が安全な接続を確⽴できないため、caCertPath 属性に CA 証明書のみを含むファイ
ルを指定することはできません。CA 証明書しかない証明書ファイルを指定すると、HTTPS を使った Splunk
Web は機能しません。
caCertPath
属性の設定⽅法の詳細は、『管理マニュアル』の web.conf に関する説明を参照してください。
設定の検証
正しく設定を⾏えば、ブラウザを使って証明書を表⽰できるようになります。また、web_service.log
($SPLUNK_HOME/var/log/splunk 内) に接続が成功したことを知らせるメッセージが記録されます。
正常に接続できない場合は、「Splunk Web 認証のトラブルシューティング」を参照してください。
Splunk Web 認証のトラブルシューティング
証明書設定を検証できない場合は、$SPLUNK_HOME/var/log/splunk 内の
したエラーを確認してください。
web_service.log
を参照して、再起動時に発⽣
SSL 設定の警告を探してください。たとえば、caCertPath に誤ったサーバー証明書へのパスを指定した場合、
Splunk Web を開始できず、以下のエラーメッセージが表⽰されます。
2010-12-21 16:25:02,804 ERROR [4d11455df3182e6710] root:442 - [Errno 2] No such file or directory:
'/opt/splunk/share/splunk/mycerts/mySplunkWebCertificate.pem'
注意: privKeyPath にある秘密鍵がパスワードで保護されている場合、エラーは発⽣しませんが、ブラウザに
Splunk Web は表⽰されません。
パスワードの削除については、「Splunk Web ⽤の⾃⼰署名証明書」または「Splunk Web ⽤のサードパーティ
が署名した証明書の⼊⼿」を参照してください。
SSL による Splunk フォワーダーからインデクサー
への通信の保護
52
フォワーダーからのデータの保護について
フォワーダー は、インデクサー に raw データを送信します。このデータには、不正な参照や破壊などの⾏為に対
して脆弱性があります。データが閉鎖ネットワークや共存ネットワーク外に転送される場合、またはデータの機密
性が⾼い場合は、SSL 証明書を使ってデータを保護する必要があります。
デフォルトの証明書を使って⼀般的な不正参照者を防⽌することはできますが、Splunk に同梱されているルート
証明書はすべて同じルート証明書で、同じルート証明書を持つユーザーは認証できてしまうため、そのままでは脆
弱性が存在しています。デフォルトの証明書は、起動時に⽣成/設定され、$SPLUNK_HOME/etc/auth/ に保管されま
す。
重要: デフォルトの証明書を使⽤する場合、⽣成後 3 年で失効するように設定されており、失効後はこのマニュ
アルに記載されている説明に従って、新しく証明書を作成、設定する必要があることに注意してください。
デフォルトの証明書での SSL の設定については、「デフォルトの証明書を使⽤する Splunk 転送の設定」を参照
してください。
トラフィックやインデクサーへの送信データを簡単にのぞき⾒ることができないように、新たに⾃⼰署名証明書を
⽤意するか、またはサードパーティ認証局から証明書を購⼊して、それを使⽤することをお勧めします。フォワー
ダーやインデクサーが証明書を使⽤するための設定⽅法については、「独⾃の証明書を使⽤するための Splunk 転
送の設定」を参照してください。
⾃⼰署名証明書または CA の署名証明書を使って、フォワーダーからインデクサーへ転送されるデータのセキュ
リティを強化するには、さまざまな⽅法が存在しています。
デフォルトの証明書を、独⾃のルート CA により署名された証明書に変更することができます。
Splunk に同梱されているデフォルトの証明書を、⾃分で⽣成、署名した証明書に置換します。証明書の⽣
成と⾃⼰署名については、「証明書の⾃⼰署名⽅法」を参照してください。
デフォルトの証明書を、信頼できる認証局により署名された証明書に変更することができます。
「サードパーティが署名した証明書の⼊⼿⽅法」を参照してください。
共通名チェックを設定することで、さらにセキュリティを強化することができます。
共通名チェックにより、新たなセキュリティレイヤーが追加され、各インデクサーの証明書に指定されてい
る共通名が、フォワーダーの設定ファイルに指定されている共通名と⼀致していなければ通信が許可されま
せん。また、個別の共通名を持つ複数の証明書を設定して、それらをインデクサーに配布することもできま
す。共通名チェック機能は、証明書の設定時に有効にします。詳細は、「独⾃の証明書を使った Splunk 転
送の設定」を参照してください。
デフォルトの証明書を使⽤する Splunk 転送の設定
Splunk に同梱されているデフォルトの証明書は、すべて同じルート証明書です。つまり、Splunk をダウンロー
ドした任意のユーザーは、同じルート証明書により署名されたサーバー証明書を持っているため、他の同じ証明書
を使⽤しているシステムの認証を受けることが可能です。悪意のある第三者がトラフィックを⼿軽に参照したり、
あなたのインデクサーに不正にデータを送信することがないように、デフォルトの証明書を署名証明書に変更する
ことをお勧めします。
重要: デフォルトの証明書は⽣成後 3 年で失効するように設定されており、失効後はこのマニュアルに記載され
ている説明に従って、新しく証明書を作成、設定する必要があることに注意してください。
フォワーダーが、独⾃のルート CA またはサードパーティ CA が署名した証明書を使⽤するように設定する⽅法
については、「独⾃の証明書を使⽤するための Splunk 転送の設定」を参照してください。
このトピックでは、以下の事項について説明していきます。
Splunk に同梱されているデフォルトの証明書を使⽤するためのインデクサーの設定。
Splunk に同梱されているデフォルトの証明書を使⽤するためのフォワーダーの設定。
注意: 複数のフォワーダーを設定する場合は、各フォワーダーがデフォルトの証明書を個別に使⽤するように設
定してください。
デフォルトのサーバー証明書を使⽤するためのインデクサーの設定
1.$SPLUNK_HOME/etc/system/local/inputs.conf (または転送の設定を配布するために使⽤している任意の App の適切
なディレクトリ内のファイル) に、以下のスタンザを設定します。
この例では、フォワーダーからのデータの受信にポート 9997 を使⽤しています。
[SSL]
rootCA = $SPLUNK_HOME/etc/auth/cacert.pem
serverCert = $SPLUNK_HOME/etc/auth/server.pem
password = password
[splunktcp-ssl:9997]
disabled=0
ここで、rootCA は CA の公開鍵へのパス、serverCert はデフォルトのサーバー証明書へのパスになります。
デフォルトの証明書は、$SPLUNK_HOME/etc/auth/server.pem にあります。
注意: デフォルトの証明書を使⽤する場合、デフォルトサーバー証明書の妥当性をチェックする必要がないた
53
め、requireClientCert
= true
を設定する必要はありません。
2.splunkd を再起動します。
$SPLUNK_HOME/bin/splunk restart splunkd
フォワーダーの設定
フォワーダーがインデクサーと同じデフォルトの証明書を使⽤し、設定されている待機ポートにデータを送信する
ように設定します。
この例では、インデクサーの IP アドレスに 10.1.12.112 を使⽤しています。
1.$SPLUNK_HOME/etc/system/local/outputs.conf (または転送の設定を配布するために使⽤している任意の App の適切
なディレクトリ内のファイル) に、以下のスタンザを定義します。
[tcpout]
defaultGroup = splunkssl
[tcpout:splunkssl]
server = 10.1.12.112:9997
sslVerifyServerCert = false
sslRootCAPath = $SPLUNK_HOME/etc/auth/cacert.pem
sslCertPath = $SPLUNK_HOME/etc/auth/server.pem
sslPassword = password
ここで、rootCA は CA の公開鍵へのパス、serverCert はデフォルトのサーバー証明書へのパスになります。
を設定する必要はありません。デフォルトのサーバー証明書の妥当性を確認するよう
に、フォワーダーに指⽰する必要はありません。
sslVerifyServerCert = true
2.splunkd を再起動します。
# $SPLUNK_HOME/bin/splunk restart splunkd
次のステップ
次に、設定が正常に機能していることを確認するために、接続をチェックする必要があります。詳細は、「設定の
検証」を参照してください。
独⾃の証明書を使⽤するための、Splunk 転送の設定
ここでは、独⾃の SSL 証明を使ってフォワーダーからインデクサーにデータを送信するように、Splunk を設定
する⽅法について説明していきます。フォワーダーからのデータ保護に証明書を使⽤することで、ネットワーク上
のデータ伝送時にデータが安全に暗号化されることが保証されます。ここでは、以下の作業⼿順について説明して
います。
新しい署名証明書を使⽤するためのインデクサーの設定。
新しい署名証明書を使⽤するためのフォワーダーの設定。
作業を開始する前に、証明書を事前に⽤意しておく必要があります。証明書は x509 フォーマットの PEM ファイ
ル、鍵は RSA フォーマットであることを確認してください。何かお⼿伝いが必要な⽅のために、独⾃の証明書を
作成、準備するための簡単な例がいくつか⽤意されています。詳細は、「独⾃の証明書を使った Splunk 転送の設
定」および「Splunk 間通信の保護について」を参照してください。
また、異なる共通名を持つ複数の証明書 (同じ認証局が署名) を作成し、それをインデクサーに配布してセキュリ
ティを強化することも可能です。
証明書を使⽤するためのインデクサーの設定
1.サーバー証明書と CA 公開証明書を、対象インデクサー上のアクセス可能なフォルダにコピーします。
この例では、証明書
スに保管します。
myNewServerCertificate.pem
および
myCACertificate.pem
を使⽤して、これらの証明書を以下のパ
$SPLUNK_HOME/etc/auth/mycerts/
警告: App ディレクトリ内の inputs.conf または outputs.conf に設定した場合、パスワードが暗号化されず、平
⽂のままファイルに保管されます。そのため、App ディレクトリ内に SSL 設定を⾏う場合に使⽤する別の証明書
(同じルート CA が署名) を作成することができます。
2.インデクサーの inputs.conf を編集して、新しいサーバー証明書を使⽤するように設定しま
す。$SPLUNK_HOME/etc/system/local/inputs.conf (または転送の設定を配布するために使⽤している任意の App の適
切なディレクトリ内のファイル) に、[SSL] スタンザを設定します。
この例では、フォワーダーからのデータ受信にポート 9997 (デフォルト) を使⽤しています。
[SSL]
rootCA = $SPLUNK_HOME/etc/auth/mycerts/myCACertificate.pem
serverCert = $SPLUNK_HOME/etc/auth/mycerts/myNewServerCertificate.pem
54
password = <server certificate private key password>
cipherSuite = <your chosen cipher suite (optional)>
[splunktcp-ssl:9997]
compressed = true
内のファイルを編集すると、Splunk の再起動時にパスワードが暗号化さ
れて平⽂サーバー証明書パスワードに上書きされます。
$SPLUNK_HOME/etc/system/local/inputs.conf
3.splunkd を再起動します。
# $SPLUNK_HOME/bin/splunk restart splunkd
証明書を使⽤するためのフォワーダーの設定
1.サーバー証明書 (既存のサーバー証明書、またはこのフォワーダー⽤に特別に作成した新たな証明書をコピーで
きます。この例では、myNewServerCertificate.pem を使⽤します) および 認証局公開証明書 myCACertificate.pem を、
設定する予定のフォワーダー上のアクセス可能なフォルダにコピーします。この例で
は、$SPLUNK_HOME/etc/auth/mycerts/ に保管します。
警告: App ディレクトリ内の inputs.conf または outputs.conf に設定した場合、パスワードが暗号化されず、平
⽂のままファイルに保管されます。そのため、App ディレクトリ内に SSL 設定を⾏う場合に使⽤する別の証明書
(同じルート CA が署名) を作成することができます。
2.$SPLUNK_HOME/etc/system/local/outputs.conf (または転送の設定を配布するために使⽤している任意の App の適切
なディレクトリ内のファイル) に、[SSL] スタンザを定義します。
[tcpout]
defaultGroup = splunkssl
[tcpout:splunkssl]
server = 10.1.12.112:9997
compressed = true
sslRootCAPath = $SPLUNK_HOME/etc/auth/mycerts/myCACertificate.pem
sslCertPath = $SPLUNK_HOME/etc/auth/mycerts/myNewServerCertificate.pem
sslPassword = default
sslVerifyServerCert = true
ファイルを $SPLUNK_HOME/etc/system/local/outputs.conf に保存する際に、splunkd の再起動時に指定したサーバー
証明書のパスワードが Splunk により暗号化されて平⽂パスワードに上書きされます。
3.splunkd を再起動します。
# $SPLUNK_HOME/bin/splunk restart splunkd
その他の設定オプション
データを複数のインデクサーに転送するには
フォワーダーが複数のインデクサーを認証するように設定するには、ターゲットグループを定義しているスタンザ
の server パラメータに、「ホスト:ポート」アドレスをカンマ区切りリストで追加します。
以下の例では、インデクサーとフォワーダーで同じ証明書を使⽤しています。
[tcpout]
defaultGroup = splunkssl
[tcpout:splunkssl]
server = 10.1.12.112:9997,10.1.12.111:9999
compressed = true
sslRootCAPath = $SPLUNK_HOME/etc/auth/mycerts/myCACertificate.pem
sslCertPath = $SPLUNK_HOME/etc/certs/auth/mycerts/myNewServerCertificate.pem
sslPassword = <your server private key password>
sslVerifyServerCert = true
以下の例では、次の証明書を使⽤しています:
myForwarderCertificate.pem
[tcpout]
defaultGroup = splunkssl
[tcpout:splunkssl]
server = 10.1.12.112:9997,10.1.12.111:9999
compressed = true
sslRootCAPath = $SPLUNK_HOME/etc/auth/mycerts/myCACertificate.pem
sslCertPath = $SPLUNK_HOME/etc/auth/mycerts/myForwarderCertificate.pem
sslPassword = <your server certificate private key password>
sslVerifyServerCert = true
55
異なる共通名を持つ証明書を使って複数のインデクサーにデータを転送するには
各インデクサーに対して個別のサーバー証明書を作成し、フォワーダーの outputs.conf にそれぞれのインデク
サーに対応する [SSLConfig] スタンザを定義することができます。
インデクサー当たり 1 つのサーバー証明書を作成して、各インデクサーの証明書にフォワーダーがチェックする
⼀意の共通名 (CN) を設定した場合、outputs.conf にインデクサー当たり 1 つの [tcpout-server://HOST:PORT] スタ
ンザを設定する必要があります。これにより、どのインデクサーに対してどの共通名をチェックするのかを指定で
きます。
以下の例では、フォワーダーがインデクサー 10.1.12.112 が「CN="phobos"」のサーバー証明書を、インデク
サー 10.1.12.113 が「CN="deimos"」のサーバー証明書を持つことをチェックします。いずれかの条件が⼀致し
ない場合、フォワーダーは当該インデクサーへのデータの送信を拒否します。
[tcpout]
defaultGroup = splunkssl
[tcpout:splunkssl]
server = 10.1.12.112:9997
compressed = true
[tcpout-server://10.1.12.112:9997]
sslRootCAPath = $SPLUNK_HOME/etc/certs/myCACertificate.pem
sslCertPath = $SPLUNK_HOME/etc/certs/myNewServerCertificate.pem
sslPassword = <your server private key password>
sslVerifyServerCert = true
sslCommonNameToCheck = phobos
[tcpout-server://10.1.12.113:9997]
sslRootCAPath = $SPLUNK_HOME/etc/certs/myCACertificate.pem
sslCertPath = $SPLUNK_HOME/etc/certs/myNewServerCertificate.pem
sslPassword = <your server private key password>
sslVerifyServerCert = true
sslCommonNameToCheck = deimos
こうすることにより、同じ CA により署名された証明書を提⽰し、その証明書が予期されている名前 (CN) により
発⾏されていることを確認できたインデクサーにのみ、フォワーダーはデータを転送します。Splunk は、設定
ファイル内の名前 (sslCommonNameToCheck) とインデクサーの証明書に署名されている共通名の照合を⾏いま
す。
次のステップ
次に、設定が正常に機能していることを確認するために、接続をチェックする必要があります。詳細は、「設定の
検証」を参照してください。
設定の検証
設定をデプロイする前に、splunkd.log を使って設定の検証とトラブルシューティングを⾏うことができます。
Splunkd.log は、インデクサーとフォワーダーの $SPLUNK_HOME/var/log/splunkd.log に存在しています。
インデクサーの場合は、スタートアップシーケンス内の以下のようなメッセージをチェックして、接続が正常に⾏
われているかどうかを確認します。
02-06-2011 19:19:01.552 INFO TcpInputProc - using queueSize 1000
02-06-2011 19:19:01.552 INFO TcpInputProc - SSL cipherSuite=ALL:!aNULL:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM
02-06-2011 19:19:01.552 INFO TcpInputProc - supporting SSL v2/v3
02-06-2011 19:19:01.555 INFO TcpInputProc - port 9997 is reserved for splunk 2 splunk (SSL)
02-06-2011 19:19:01.555 INFO TcpInputProc - Port 9997 is compressed
02-06-2011 19:19:01.556 INFO TcpInputProc - Registering metrics callback for: tcpin_connections
フォワーダーの場合は、スタートアップシーケンス内の以下のようなメッセージをチェックして、接続が正常に⾏
われているかどうかを確認します。
02-06-2011 19:06:10.844 INFO TcpOutputProc - Retrieving configuration from properties
02-06-2011 19:06:10.848 INFO TcpOutputProc - found Whitelist forwardedindex.0.whitelist , RE :
forwardedindex.0.whitelist
02-06-2011 19:06:10.848 INFO TcpOutputProc - found Whitelist forwardedindex.1.blacklist , RE :
forwardedindex.1.blacklist
02-06-2011 19:06:10.848 INFO TcpOutputProc - found Whitelist forwardedindex.2.whitelist , RE :
forwardedindex.2.whitelist
02-06-2011 19:06:10.850 INFO TcpOutputProc - Will retry at max backoff sleep forever
02-06-2011 19:06:10.850 INFO TcpOutputProc - Using SSL for server 10.1.12.112:9997,
sslCertPath=/opt/splunk/etc/aut/server.pem
56
02-06-2011 19:06:10.854 INFO TcpOutputProc - ALL Connections will use SSL with sslCipher=
02-06-2011 19:06:10.859 INFO TcpOutputProc - initializing single connection with retry strategy for 10.1.12.112:9997
設定上の問題のトラブルシューティングについては、このマニュアルの「フォワーダー/インデクサー設定のトラ
ブルシューティング」を参照してください。
フォワーダー/インデクサー認証のトラブルシューティング
1.$SPLUNK_HOME/var/log/splunk/splunkd.log (インデクサーとフォワーダーの両⽅) に、エラーが記録されていないか
どうかを確認します。インデクサー上で、TCP ⼊⼒プロセッサ TcpInputProc からのメッセージをチェックしま
す。フォワーダー上で、TCP 出⼒プロセッサ TcpOutputProc からのメッセージをチェックします。
2.インデクサー/フォワーダー上の
す。
フォワーダー上で
$SPLUNK_HOME/etc/log.cfg
category.TcpOutputProc=DEBUG
にある、適切なプロセッサのログレベルを増やしま
を、インデクサー上で
category.TcpInputProc=DEBUG
を設定します。
3.変更内容を反映するために Splunk を再起動してから、関連コンポーネントのスタートアップシーケンスを調査
します。この⽅法で、⼤部分の設定上の問題を発⾒することができます。
4.btool を使って SSL 設定をチェックします。
インデクサーの場合:
$SPLUNK_HOME/bin/splunk cmd btool inputs list --debug
フォワーダーの場合:
$SPLUNK_HOME/bin/splunk cmd btool outputs list --debug
⼀般的な問題
inputs.conf の serverCert に設定されている、サーバー証明書ファイルセットへのパスが誤っている、また
はファイルを読み取れない。この場合、以下のようなエラーが⽣成されます。
12-16-2010 16:07:30.965 ERROR SSLCommon - Can't read certificate file
/opt/splunk/etc/auth/server.pem errno=33558530 error:02001002:system library:fopen:No such file or
directory
サーバー証明書ファイルに含まれている、RSA 秘密鍵のパスワードが誤っている。
12-07-2010 07:56:45.663 ERROR SSLCommon - Can't read key file /opt/splunk/etc/auth/server.pem
*nix の場合、ファイルに含まれている RSA 鍵のパスワードを、以下のコマンドを使って⼿動でテストすることが
できます。
# openssl rsa -in /opt/splunk/etc/auth/server.pem -text
Windows の場合は、以下のコマンドを使って RSA 鍵のパスワードをテストすることができます。
>openssl.exe rsa -in "c:\Program Files\Splunk\etc\auth\server.pem" -text
SSL を使った Splunk 間通信の保護
Splunk 間通信の保護について
この章で、「Splunk 間通信」とは、管理ポート経由で⾏われる通信の暗号化と認証のことを表しています。これ
には、以下のような事項が含まれています。
分散サーチ :サーチヘッドとピア間の通信。
デプロイサーバー :デプロイサーバーとクライアント間の通信。
クラスタ設定 :指定されたインデクサー間でのデータ/設定情報のレプリケーション。
Splunk Web :Splunk Web と splunkd 間の通信の保護。
注意: この章では、管理ポート経由の通信への SSL の使⽤⽅法のみを説明しています。ブラウザと Splunk Web
間の通信への SSL の使⽤については、「Splunk Web の保護について」を参照してください。フォワーダーとレ
シーバー間の通信への SSL の使⽤については、「フォワーダーからのデータの保護について」を参照してくださ
い。
SSL を使った Splunk 間通信の保護⽅法
ここでは、Splunk 間通信への SSL セキュリティの導⼊⽅法について説明していきます。
Splunk が提供しているデフォルトの証明書を使って、SSL を使⽤することができます。
この設定は⼿軽に利⽤でき、暗号化と圧縮を提供しています。⼤部分の環境において、推奨する⽅法がこれ
です。また、デフォルトで有効になっています。SSL が無効になっている場合、または何らかの理由でご利
⽤のシステムに証明書がない場合は、このマニュアルに記載されている⼿順で暗号化を有効にして、Splunk
57
に証明書を使⽤するように指⽰することができます。「デフォルトの証明書を使った Splunk 間通信につい
て」を参照してください。
保護されている認証の場合、Splunk が提供するデフォルトの証明書を、独⾃の CA で署名した証明書また
は信頼されている認証局から購⼊した証明書に変更することができます。⼤部分の Splunk 環境でこれはお
勧めできない⽅法で、通常は必要ありません。これは⾼度な設定で、複雑な SSL 設定の知識がある管理者の
みが作業を⾏ってください。詳細は、以下のトピックを参照してください。
Splunk Web と splunkd 間の通信の保護
分散サーチヘッドとピアの保護
デプロイサーバーとクライアントの保護
クラスタの保護について
Splunk Web と splunkd 間の通信の保護
Splunk Web から splunkd への通信は、サーチ要求、結果データ、および REST API 呼び出しから成り⽴ってい
ます。
デフォルトの証明書を使った SSL 暗号化は最初から有効になっています。たいていの環境ではこれで⼗分です
が、Splunk Web と splunkd インスタンスがファイアウォール外のインスタンスと機密データを通信しているよ
うな場合は、署名証明書を使⽤することもできます。また、server.conf の設定でクライアントの証明書が必要な
場合は、splunkd に証明書を提⽰するように Splunk Web を設定する必要があります。
証明書を使⽤するように Splunk Web から splunkd への通信を設定するには:
1. 1 つまたは複数の証明書を設定します。
2. server.conf を編集して、splunkd に 証明書を指⽰します。sslConfig スタンザの編集例を以下に⽰します。
[sslConfig]
enableSplunkdSSL = true
sslKeysfile = server.pem
sslKeysfilePassword = password
caCertFile = cacert.pem
caPath = $SPLUNK_HOME/etc/auth
cipherSuite = <your chosen cipher suite (optional)>
3. server.conf で、splunkd に接続するすべての HTTPS クライアントに Splunk 認証局が署名した証明書が必要な
ことを⽰すために、requireClientCert=true 内に server.conf を設定します。
警告: requireClientCert を有効にすると、splunkd は通信を要求するすべてのクライアントに証明書の提⽰を要
求するため、CLI からは接続できません。
4. web.conf を編集して、splunkd が検証する証明書を指定します。
編集した設定スタンザの例を以下に⽰します。
[settings]
enableSplunkWebSSL = true
privKeyPath = etc/auth/splunkweb/mySplunkWebPrivateKey.key
caCertPath = etc/auth/splunkweb/mySplunkWebCertificate.pem
cipherSuite = <your chosen cipher suite (optional)>
秘密鍵へのパスワードに対応する属性はないことに注意してください。Splunk Web は秘密鍵のパスワードをサ
ポートしていないため、鍵からパスワードを削除する必要があります。詳細は、「Splunk Web ⽤のサードパー
ティが署名した証明書の⼊⼿」を参照してください。
分散サーチヘッドとピアの保護
分散サーチ 環境は、サーチ情報、ナレッジオブジェクト、App、および設定情報を、管理ポート経由で共有して
います。
サーチヘッドとピア間の通信には、公開鍵暗号を使⽤しています。Splunk は起動時に、秘密鍵と公開鍵を⽣成し
ます。サーチヘッドに分散サーチを設定した場合、公開鍵がピアに配布されて、それらの鍵が通信の保護に⽤いら
れます。このデフォルト設定は、パフォーマンスを向上するビルトインの暗号/データ圧縮機能を提供していま
す。
これらの⽣成された鍵を独⾃の鍵と交換することができます。ただし、そうすることはお勧めできません。また、
⼀般的には不要です。分散サーチ⽤の公開鍵暗号を設定するには、鍵を作成してそれをサーチヘッドとピアに配布
します。サーチピアへの鍵ファイルの配布については、『分散サーチ』マニュアルの「鍵ファイルの配布」を参照
してください。
デプロイサーバーとクライアントの保護
デプロイサーバーとクライアント間の通信には、管理ポート経由の設定情報が関与しています。これらのコンポー
ネントがサーチデータを転送することはありません。
管理ポート経由で通信されるデータに対しては、最低でも、最初から有効になっているデフォルトの証明書を使っ
58
たSSL 暗号化を使⽤することを強くお勧めします。Splunk のデフォルト SSL 設定は、パフォーマンスを向上す
るビルトインの暗号/データ圧縮機能を提供しています。詳細は、「デフォルト値を使った Splunk 間通信につい
て」を参照してください。
デプロイサーバーおよびクライアントの証明書認証を設定すると、構成の残りの部分に影響を与えることを理解し
ておく必要があります。
Splunk Web も証明書を使⽤するように設定しないと、Splunk Web は認証に失敗してしまいます。
CLI はデプロイサーバーと通信できなくなります。
ただし、とても機密性が⾼いサーバー設定データなどが、ファイアウォール外のさまざまな場所に送信される環境
など、⼀部の分散環境ではこのような設定が必要になります。
以上のことを念頭に、Splunk 間通信に対する SSL の設定に関する、いくつかのガイドラインをここに記載しま
す。
サーチヘッドとピア間の SSL 証明書を設定する場合、以下の⼿順を遵守する必要があります。
1. 同じルート CA を使って、1 つまたは複数の証明書を作成します。
2. デプロイサーバーとクライアントに証明書を配布します。
3. server.conf を編集して、証明書の場所を指定します。
[sslConfig]
enableSplunkdSSL = true
sslKeysfile = server.pem
sslKeysfilePassword = password
caCertFile = cacert.pem
caPath = $SPLUNK_HOME/etc/auth
cipherSuite = <your chosen cipher suite (optional)>
4. server.conf を編集して、証明書に対して認証を⾏うように設定します。
requireClientCert = [true|false]
重要: requireClientCert には、デフォルトでは「false」が設定されています。これを true に変更して、Splunk
にクライアントの証明書のチェックを強制すると、Splunk Web と CLI も証明書がチェックされます。CLI 接続
ではクライアントとして証明書を提⽰できないため、CLI 接続は利⽤できなくなります。
5. Splunk Web がサーバーに接続できるように、web.conf を編集して、同じルート CA が署名した証明書を指定し
ます。
編集した設定スタンザの例を以下に⽰します。
[settings]
enableSplunkWebSSL = true
privKeyPath = etc/auth/splunkweb/mySplunkWebPrivateKey.key
caCertPath = etc/auth/splunkweb/mySplunkWebCertificate.pem
cipherSuite = <your chosen cipher suite (optional)>
注意: Splunk Web は秘密鍵のパスワードをサポートしていないため、秘密鍵からパスワードを削除する必要が
あります。詳細は、「Splunk Web ⽤のサードパーティが署名した証明書の⼊⼿」を参照してください。
クラスタの保護について
Splunk には、クラスタリングノードが相互に認証できるように、「共有シークレット」機能が⽤意されていま
す。クラスタを設定する際に、共有シークレットを決定します。各ノードには同じシークレットを割り当てます。
最適なパフォーマンスを得るために、Splunk 間データ通信にはデフォルトの SSL 暗号を使⽤して (デフォルトで
有効です)、Splunk に⽤意されている共有シークレット機能を活⽤することをお勧めします。
Splunk Web を使った共有シークレットの設定に関する詳細は、「マスターノードを有効にする」を参照してく
ださい。
CLI での共有シークレット使⽤の詳細は、『インデクサーとクラスタの管理』の「server.conf によるクラスタの
設定」を参照してください。
デフォルト値を使った Splunk 間通信について
最初に Splunk サーバーを有効にした時に、サーバーはそのインスタンスの証明書を⽣成します。デフォルトで証
明書は $SPLUNK_HOME/etc/auth/ ディレクトリに保管されます。
署名証明書を使⽤する場合は、専⽤の新しいディレクトリを作成して、新しい証明書を使⽤するように、
server.conf にパスを指定します。再びデフォルトの証明書を使⽤するようにシステムを設定するには、単純に⾃
動⽣成される証明書を使⽤するように、server.conf ファイルをデフォルト設定に変更します。
Splunk が⽣成した証明書を使⽤する、デフォルトの
server.conf
59
設定を以下に⽰します。
[sslConfig]
enableSplunkdSSL = true
sslKeysfile = server.pem
sslKeysfilePassword = password
caCertFile = cacert.pem
caPath = $SPLUNK_HOME/etc/auth
Splunk Enterprise アクティビティの監査
Splunk を使ったシステムアクティビティの監査
システムを安全に保護するために、システムで何が⾏われているのかを知ることが必要不可⽋です。
システムを最⼤限活⽤し安全に保つため、次のベストプラクティスに沿うことをお勧めします。
Splunk のアクセスログや監査ログを定期的にレビューしてください。
Splunk サーバーの監査ログやセキュリティログを定期的にレビューしてください。
すべての Splunk ユーザーとロールを定期的にレビューしてください。
Splunk アクティビティの監査
監査イベントには何がある?
タイムスタンプ:
イベントの⽇時。
ユーザー情報:
イベントを⽣成したユーザー。
イベントにユーザー情報が含まれていない場合、Splunk は現在ログインしているユーザーを設定しま
す。
その他の情報:
利⽤可能なイベント情報 -- ファイル、成功/拒否など。
監査イベントを⽣成するアクティビティ
監査イベントはモニターから⽣成されます。
Splunk の次の設定ディレクトリ内のすべてのファイル: $SPLUNK_HOME/etc/*
ファイルシステム変更モニターを使って、ファイルの追加/変更/削除がモニターされます。
システムの開始/停⽌。
ユーザーのログイン/ログアウト。
新規ユーザーの追加/削除。
ユーザー情報の変更 (パスワード、ロールなど)。
システム内の任意の権限の実⾏。
権限は authorize.conf に記載されています。
監査イベントストレージ
Splunk は、監査イベントをローカルの監査インデックス (index=_audit) に保管します。監査イベントは、次のロ
グファイルに記録されます: $SPLUNK_HOME/var/log/splunk/audit.log。
Splunk を分散環境のフォワーダーとして設定した場合、監査イベントは他のイベントと同様に転送されます。署
名は、フォワーダー上、または受信 Splunk インスタンス上で⾏われます。
監査イベントのサーチ
監査イベントは、Splunk Web または Splunk の CLI でサーチします。サーチでパイプ⽂字を使⽤しながら
audit コマンドを指定していきます。audit コマンドは、監査イベント署名が設定されている場合に特に役⽴ちま
す。ただし、監査イベント署名が設定されていない (または整合性検証をスキップする) 環境ですべての監査イベ
ントをサーチしたい場合は、監査インデックス全体をサーチすることができます。
すべての監査イベントをサーチするには、_audit インデックスを指定します。
index=_audit
すべての監査イベントを返します。
サーチを audit コマンドにパイプします。
index=_audit | audit
監査インデックス全体を返し、⾒つかった監査イベントを
audit
コマンド経由で処理します。
audit コマンドにパイプする前に、サーチで返される項⽬数を絞り込んでください。ただし、時間範囲または単⼀
のホストでのみ絞り込むことができます。これは、各ホストが固有の ID 番号シーケンスを保有しているためで
す。連番は監査イベントのギャップを検出するために存在しているので、複数のホストにサーチを絞り込むと偽の
ギャップが検出される可能性があります。
60
イベントのステータスが含まれているフィールドは、「妥当性」と呼ばれています。以下の値が設定されます。
VALIDATED - このイベントの前にギャップが存在しておらず、イベント署名が⼀致している
TAMPERED - イベントの署名が⼀致しない
NO SIGNATURE - 署名が⾒つからない
ギャップステータスが含まれているフィールドは、「ギャップ」 (gap) と呼ばれています。以下の値が設定され
ます。
TRUE - ギャップが⾒つかった
FALSE - ギャップは⾒つからなかった
N/A - ID が⾒つからない
データ統合性の管理
Splunk Enterprise のデータ統合性制御機能を使えば、インデックスされているデータの統合性を検証することが
できます。
インデックスのデータ統合性制御を⾏う場合、Splunk Enterprise はデータの⼀つ⼀つにハッシュ値を計算し、保
存します。これにより、後でまた戻ってきてデータの統合性を検証可能です。
仕組み
データの統合性管理を⾏う場合、Splunk Enterprise は新しくインデックスされた未加⼯のデータの⼀つ⼀つに
ハッシュ値を計算し、l1Hashes ファイルに書き込みます。バケツがホットからウォームに移⾏する場合、Splunk
Enterprise は l1Hashes のコンテンツのハッシュ値を計算し、l2Hash に保存します。ハッシュファイルはどちらも
バケツ⽤の rawdata ディレクトリに保存されます。
新しくデータにインデックスされたデータ統合性制御ハッシュ、フォワーダーからのデータは SSL で安全に暗号
化されていることに留意してください。詳細は、「SSL による Splunk の保護について」を参照してください。
データを検証するためのハッシュ値の確認
Splunk Enterprise データを確認するために、次の CLI コマンドを実⾏してインデックスまたはバケツの統合性
を検証します。
./splunk check-integrity -bucketPath [ bucket path ] [ verbose ]
./splunk check-integrity -index [ index name ] [ verbose ]
データ統合性制御の設定
データ統合性の制御を設定するために、indexes.conf を編集して enableDataIntegrityControl 属性を各インデックス
に有効化します。すべてのインデックスのデフォルト値は false (オフ) です。
enableDataIntegrityControl=true
クラスタ環境のデータ統合性
クラスタ環境では、クラスタマスターとピアすべてが Splunk Enterprise 6.3 を実⾏でき、正確なインデックスレ
プリケーションを有効にする必要があります。データ統合性設定のバンドルをクラスタマスターからピアにプッ
シュします。
クラスタ環境の管理設定に関する詳細は、『分散デプロイ』マニュアルを参照してください。
データスライスのサイズ変更 (オプション)
デフォルトでは、データスライスは 128kb に設定されています。これは、データスライスが 128KB毎に作成・
ハッシュされることを意味しています。オプションとして indexes.conf を編集し、各スライスのサイズを指定する
ことができます。
rawChunkSizeBytes = 131072
データハッシュの保存と保護
最適なセキュリティのため、データがホストされるシステムの外 (別のサーバー等) にハッシュを任意で保存する
ことが可能です。名前の重複を避けるため、保護ハッシュは別々のディレクトリに保存します。
ハッシュの再⽣成
バケツのハッシュをなくしてしまった場合、次の CLI コマンドを使⽤して、バケツまたはインデックスでハッ
シュファイルを再⽣成します。このコマンドはジャーナルに埋め込まれたハッシュを抽出します。
./splunk generate-hash-files -bucketPath [ bucket path ]
[ verbose ]
61
./splunk generate-hash-files -bucketPath [ bucket path ]
[ verbose ]
./splunk generate-hash-files -index [ index name ] [ verbose ]
Splunk Enterprise のパスワードとアクセスのセ
キュリティ
複数のサーバーへの保護パスワードのデプロイ
初期起動時に Splunk は $SPLUNK_HOME/etc/auth/splunk.secret ファイルを作成します。このファイルには、設定ファ
イル内の⼀部の認証情報を暗号化するために使⽤される鍵が含まれています。
web.conf:各インスタンスの
SSL パスワード。
LDAP パスワード (ある場合)。
inputs.conf: SSL パスワード (splunktcp-ssl を使⽤している場合)。
outputs.conf:: SSL パスワード (splunktcp-ssl を使⽤している場合)。
authentication.conf:
Splunk 開始時に、これらの設定の⼀つに平⽂パスワードが検出された場合、同等のローカルフォルダ内の設定
が、暗号化パスワードで作成、または上書きされます。
Splunk を複数のサーバーにデプロイする場合は、以下の⼿順に従ってこれらのパスワードを暗号化して、それら
がデプロイ環境全体で⼀貫していることを確認してください。この⼿順は初期デプロイ時に実⾏する必要がありま
す。また、新しいパスワードをデプロイする場合にも実⾏する必要があります。
1. Splunk インスタンスを設定し、必要に応じてパスワードを変更します。(新しい設定の場合は、まだ他のインス
タンスを開始しないでください)
2. ファイル内のパスワードを暗号化するために、設定したインスタンスを再起動します。再起動で暗号化しない限
り、パスワード情報は平⽂のまま保管されます。
3. 設定したインスタンスから、他のすべてのインスタンスに、暗号化された
す。
splunk.secret
ファイルをコピーしま
4. ファイルをコピーしたすべてのインスタンスを起動します。デプロイ完了後に、変更したファイルを配布した場
合は、既存のインスタンスを再起動します。
注意: この⼿順はサーチヘッドクラスタには関連していません。サーチヘッドクラスタで、クラスタの初期デプ
ロイ中、キャプテンは他のクラスタメンバーすべてに splunk.secret ファイルを複製するため、⼿動で複製を⾏う
必要はありません。通常の運⽤の中で、クラスタは個⼈⽤ App によって保存された資格情報を⾃動的に複製しま
す。
サービスアカウントの保護
Splunk を権限がある root や管理者などのユーザーではなく、権限がないユーザーとして操作して、最低権限割
り当ての原則を調査してください。
UNIX または Linux の場合、PKG または RPM パッケージで作成される「splunk」ユーザーを使⽤する
か、または $SPLUNK_HOME に対する権限と所有権のみを保持する独⾃のユーザーを作成、使⽤してくださ
い。
Windows の場合は、ローカルシステムコンテキストが適しています。ただし、WMI などの Windows の通
信チャネルを使って通信する必要がある場合には、制限されたアクセスアカウントを使⽤してください。
Splunk Enterprise のアクセス制御リストの使⽤
Splunk Enterprise 設定を保護するために、Splunk アクセス制御リスト (ACL) を使って、ネットワークの各部
にアクセスできる IP アドレスを制限してください。
アクセス制御リストを設定するには、server.conf および
ドレスを指定します。
inputs.conf
を編集して、各種通信で許可/拒否する IP ア
ACL の設定⽅法
複数のアドレスを指定する場合は、カンマまたはスペースで区切ります。アドレスは以下の形式で指定できます。
単⼀の IPv4 または IPv6 アドレス。例:10.1.2.3, fe80::4a3。
CIDR ブロックアドレス。例:10/8, fe80:1234/32。
DNS 名、通常は * をワイルドカードとして使⽤して次の例のように指定できます:
*.splunk.com。
任意のアドレスに⼀致する、単⼀の * (これがデフォルト値です)。
myhost.example.com,
⽬的のアドレスを追加するには、以下のいずれかの形式でそのアドレスを追加します。アドレスを除外する場合
は、アドレスの先頭に「!」を指定します。
ルールは順番に適⽤され、最初に⼀致したルールが使⽤されます。たとえば、「!10.1/16, *」と指定すると、
10.1.*.* ネットワーク以外のすべてのネットワークからの接続が許可されます。
62
ACL の設定場所
[Accept from]
の値を編集して、以下の接続の IP アドレスを保護することができます。
特定の IP を持つ他のノードからの複製データのみを受け付けるように設定するには、server.conf の
httpServer スタンザを編集します。
この属性を設定する場合、クラスタ内の他のすべてのピアの IP アドレスを指定していることを確認する必
要があります。クラスタの詳細は、「クラスタとインデックスレプリケーションについて」を参照してくだ
さい。server.conf の編集⽅法の詳細は、「server.conf」を参照してください。
TCP 接続を特定の IP アドレスのみに制限する場合は、inputs.conf の tcp スタンザを編集します。情報が競
合する場合、server.conf 内の出⼒値が上書きされるため、設定には注意が必要です。
SSL を使った TCP 接続を特定の IP アドレスに制限する場合は、inputs.conf の
す。
tcp-ssl
スタンザを編集しま
インデクサーが特定の IP アドレスを持つフォワーダーからのみデータを受け付けるように制限するに
は、inputs.conf の splunktcp スタンザを編集します。これにより、誰かがフォワーダーになりすましてデー
タを破壊する危険性を防⽌できます。
フォワーダーからインデクサーへの通信を SSL で保護している場合は、inputs.conf の splunktcp-ssl スタン
ザを編集して、インデクサーが特定の IP アドレスを持つフォワーダーからのみデータを受け付けるように
制限します。
UDP 接続を特定の IP アドレスのみに制限する場合は、inputs.conf の
inputs.conf
の編集⽅法の詳細は、「inputs.conf」を参照してください。
63
UDP
スタンザを編集します。
Fly UP