イベントレポートでトークンを発行したら、次はSIEM側の設定です。つなぎ方は製品ごとに違いますが、型は3つしかありません。どの型に当たるかが分かれば、細部は各製品の手順書をたどれます。このページでは、3つの型の違い、接続先のアドレスの選び方、Splunk、Elastic、Microsoft Sentinelの接続の流れ、接続できたことの確かめ方を説明します。トークンの発行そのものはEvents Reportingの設定で扱います。
接続方式は3通り
ベンダーが用意したアドオンを入れる
Splunkがこの型です。<a href="https://splunkbase.splunk.com/app/5632/" target="_blank">Splunkbase</a>からアドオンを入れ、その設定画面に1Password側で発行したトークンを貼り付けます。取り込みの間隔やインデックスの割り当てもアドオンが面倒を見ます。
1Passwordが用意したコネクターを使う
Microsoft SentinelとElasticはこの型です。SIEM側のカタログから1Password向けの部品を入れ、アドレスとトークンを設定すると動きます。分析ルールやダッシュボードも一緒に入るため導入は速い一方で、中身に手を入れるには各製品の知識が要ります。
Events APIに直接つなぐ
一覧にない製品や、社内で作った基盤に送る場合です。Events APIに定期的に問い合わせ、返ってきたイベントを自社側に書き込むクライアントを用意します。ElasticのBeatもこの型です。取り込みの間隔、失敗したときの再試行、重複の除去を自分で設計することになります。
接続先のアドレスを確かめる
どの型でも、最初に入力するのは接続先のアドレスです。アカウントを作ったサイトによって変わります。
| アカウントのサイト | Events APIのアドレス |
|---|---|
| 1Password.com（Business） | https://events.1password.com |
| 1Password.com（Enterprise） | https://events.ent.1password.com |
| 1Password.ca | https://events.1password.ca |
| 1Password.eu | https://events.1password.eu |
【注意】 同じ1Password.comでも、BusinessとEnterpriseでアドレスが違います。Enterpriseのアカウントに対してBusinessのアドレスを入れると、トークンが正しくても認証が通りません。トークンに含まれる宛先の情報と、問い合わせ先のアドレスが一致しないためです。トークンが無効だという趣旨のエラーが出たら、作り直す前にアドレスを確かめてください。作り直しても同じ結果になります。
リージョンの選び方と、日本の組織がどのサイトを使うことになるかはリージョンの選択とデータの保管場所で扱います。
Splunkに接続する
Splunkは利用している基盤によって手順が分かれます。Splunk EnterpriseとSplunk CloudのVictoria Experienceは自分でアドオンを入れられます。Splunk CloudのClassic Experienceは自分では入れられません。
インデックスを種類ごとに分ける
先にイベントの種類ごとのインデックスを作ります。mainにまとめる構成でも動きますが、種類ごとに分けておくと保管期間を別々に設定できます。監査イベントは長く、アイテムの使用状況は短く、という設計ができるようになります。分散構成でフォワーダーを使っている場合は、フォワーダー側にもアドオンを入れてください。
検索マクロを作る
アドオンの設定が終わったら、種類ごとに検索マクロを作ります。マクロの名前は決まった文字列を使い、定義には対応するインデックスを書きます。ここを間違えると、取り込みは動いているのに検索に出てこないという状態になります。取り込みの確認は、マクロではなくindex=を直接指定した検索で行ってください。検索は必ず検索ヘッドで行います。
Classic Experienceは事前の依頼が要る
Classic Experienceでは<a href="https://docs.splunk.com/Documentation/SplunkCloud/latest/Admin/IntroGDI#Work_with_Inputs_Data_Manager" target="_blank">Inputs Data Manager（IDM）</a>が必要です。持っていない場合は用意してもらうところから始まります。アドオンの導入も自分ではできず、Splunkのサポートに依頼します。依頼の本文には、検索ヘッドとIDMの両方に入れること、検索ヘッド側では設定の入力を無効にすること、独自のインデックスの設定をIDMに同期することを書いておいてください。
【注意】 Classic Experienceでは、依頼を出してから作業が終わるまでの待ち時間が発生します。導入の計画を立てるときは、1Password側の設定が10分で終わることと、Splunk側に数営業日かかることを分けて見積もってください。自分がどちらのExperienceを使っているか分からない場合は、<a href="https://docs.splunk.com/Documentation/SplunkCloud/latest/Admin/Experience" target="_blank">Splunkの確認手順</a>を見てください。バージョンが8.1以前であればClassic Experienceです。
Elasticに接続する
Elasticには入り口が2つあります。用途が違うので、先にどちらを使うかを決めてください。
ダッシュボードで見る
あらかじめ組まれたダッシュボードで見たい場合は、Kibanaの統合の一覧から1Password向けの統合を追加します。Elastic Agentが動いていることと、Kibanaが7.16以降であることが前提です。追加したら、Events APIのアドレスとトークンを入れ、取り込むイベントの種類を有効にします。ここで有効にする種類は、トークンに含めた種類と一致させてください。含まれていない種類を有効にしても何も届きません。
コマンドラインから動かす
手元のコマンドから流したい場合は、1Passwordが出している<a href="https://github.com/1Password/events-api-elastic/releases" target="_blank">Beat</a>を使います。設定ファイルにイベントの種類ごとのトークンを書き、出力先をElasticsearchかLogstashに指定して起動します。設定ファイルの名前は、起動時に-cで渡す名前と実際のファイル名を必ず一致させてください。拡張子が.ymlと.yamlのどちらでも動きますが、食い違うと起動しません。
取り込みの間隔を決める
間隔と1回当たりの件数は、詳細な設定から変えられます。既定は10秒ごとに最大1000件です。速くするほど検知は早くなりますが、上限に当たります。
【注意】 Events APIには1分当たり600回、1時間当たり30000回という問い合わせの上限があります。既定の10秒間隔は1時間当たり360回なので余裕がありますが、イベントの種類ごとに別々の取り込みが走る点に注意してください。3種類を有効にして間隔を1秒に縮めると、それだけで上限に達します。他のツールからも同じアカウントに問い合わせている場合は、合計で数えることになります。
Microsoft Sentinelに接続する
Azureの<a href="https://learn.microsoft.com/azure/sentinel/" target="_blank">Microsoft Sentinel</a>の画面から、コンテンツのカタログで1Passwordを検索してソリューションを導入します。導入が終わったらデータコネクターの一覧から1Passwordのサーバーレス版を選び、接続先のアドレスとトークンを入れて接続します。
接続してからデータが流れ始めるまでには時間がかかります。コネクターが接続済みになるまでが5分ほど、イベントが見え始めるまでが10分から15分ほどで、最初の処理が終わるまでに30分かかることもあります。すぐに出ないからといって設定をやり直すと、原因の切り分けが難しくなります。
ソリューションには分析ルールが18本と、組織全体と個人ごとの活動を見るワークブックが付いてきます。分析ルールの一部は、どのグループや保管庫を重要とみなすかを指定しないと機能しません。指定は<a href="https://learn.microsoft.com/azure/sentinel/watchlists" target="_blank">ウォッチリスト</a>で行います。ルールの既定の問い合わせ文がウォッチリストを参照する形になっているので、決められた名前でウォッチリストを作り、そこに対象の識別子を入れます。識別子をルールの中に直接書く方法もありますが、対象が増えるたびに全てのルールを直すことになります。
【注意】 新しいイベントがないときは、時刻だけが記録された行が書き込まれます。この行しか出ていない状態は、壊れているのではなく、送るべきイベントがなかったという意味です。導入直後にこの行だけを見て失敗と判断しないでください。判断がつかないときは、1Password側で何か操作をしてから数分待って、その操作が届くかを見ます。
接続できたことをどう確かめるか
どの製品でも確かめかたは同じです。1Password側で記録に残る操作を1つ行い、それがSIEMに現れるかを見ます。テスト用のグループを作って削除する、といった影響のない操作で十分です。
見るのは3点です。イベントが届いているか、3種類とも届いているか、日時が正しく解釈されているかです。1種類だけ届かない場合は、トークンにその種類が含まれていないか、SIEM側で有効にしていないかのどちらかです。
疎通が確認できたら、その手順を記録に残してください。半年後にイベントが止まったとき、同じ手順をなぞれば1Password側とSIEM側のどちらの問題かがすぐに分かります。
【運用のポイント】 接続の不具合が起きたときの問い合わせ先は、製品によって変わります。SIEM側の製品に起因するものは各ベンダーのサポートに、1Password側の設定やトークンに起因するものは1Passwordに問い合わせることになります。切り分けの目安は、トークンを発行し直しても直らず、他の製品でも同じ症状が出るかどうかです。同じトークンで別の取り込みが動くなら、原因はSIEM側にあります。