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 スタンザを編集します。