SIEMにイベントが届くようになっても、それだけでは監視になりません。どれだけの期間残すのか、どの操作が起きたら人を呼ぶのか、その判断を誰がするのかを決めて、はじめて仕組みになります。ここは製品の設定ではなく設計の話なので、正解が1つに決まりません。このページでは、ログの3つの経路の違い、保管期間の決め方、SIEMに流す前に決めておくこと、アラートを3段階に分ける考え方、誤検知を減らす前提、そして仕組みが生きていることの確かめ方を説明します。接続そのものはSIEMごとの接続で扱います。
経路によって残るものが違う
1Passwordの記録を残す経路は3つあり、それぞれ性質が違います。
| 経路 | 保管期間 | 入るもの | 欠け方 |
|---|---|---|---|
画面の監査ログ | 365日 | 管理操作 | 開いた人がアクセスできる範囲だけ |
| CSVへの書き出し | 自社の保管次第 | 管理操作と識別子 | 書き出した時点までの分 |
| Events APIからSIEMへ | 自社の保管次第 | 管理操作、アイテムの使用状況、サインイン試行 | 取り込みが止まった時間の分 |
3つの中で最も範囲が広いのはSIEMへの経路です。画面には出ないアイテムの使用状況とサインインの成功が入るためです。一方で、取り込みが止まった時間のイベントは後から取り直せません。管理操作だけは画面に365日分が残っているので、そこから穴を埋められます。
CSVへの書き出しは、SIEMを持っていない組織の現実的な選択肢です。四半期に一度書き出して保管しておけば、365日を超える調査にも対応できます。手作業なので忘れます。担当者と期日を決めて、他の定例作業に紐づけてください。
保管期間を決める
まず、自社の規程に1Passwordのログが含まれるかを確認します。アクセス記録の保管期間を定めている規程があれば、それに従います。特に定めがない場合は、次の3つの期間から長い方を採ります。
- 監査や外部の審査で提出を求められる期間
- 事故が発覚するまでに想定される期間
- システムの更改や人事の異動の周期
2つ目が効いてきます。クレデンシャルの不正な持ち出しは、発覚までに時間がかかります。90日で捨てる設計にすると、発覚した時点で肝心の記録が消えています。監査対応だけを理由に決めると短くなりがちなので、調査に使う前提で考えてください。
【注意】 1Password側の365日は、自社の保管期間とは別の話です。SIEMに1年分を入れているつもりでも、SIEM側の設定で90日で消えていれば、それが実際の保管期間です。イベントの種類ごとにインデックスを分けておくと、監査イベントは長く、アイテムの使用状況は短く、という設計ができます。全部を同じ期間にすると、量の多い種類に引きずられて全体が短くなります。
SIEMに流す前に決めること
識別子を名前に戻せるようにする
保管庫の名前とアイテムの名前はSIEMに届きません。届くのは一意の識別子です。対応表を用意しておかないと、アラートが飛んでも何が起きたのか分かりません。保管庫とグループの識別子はコマンドラインから一覧で取得できます。管理コンソールで対象を開いたときのアドレス欄からも読み取れます。
対応表は作って終わりにせず、更新の担当を決めてください。保管庫が増えるのは日常的に起きます。表が古いと、新しく作られた保管庫での操作だけが識別子のまま残ります。
時刻の扱いをそろえる
イベントの日時がどの時間帯で表示されているかを、最初に確かめてください。管理コンソールの画面、書き出したCSV、SIEMに届いたデータで表記が違うことがあります。事故の報告書は日本時間で書くことになるので、どこで変換するかを決めておかないと、後から時系列を組み立てる段階で混乱します。
送る種類を絞りすぎない
トークンに含めるイベントの種類は後から変えられません。変えたいときは発行し直しになります。量を気にして最初から絞ると、後で必要になったときに手戻りが生じます。3種類とも送っておき、量の調整はSIEM側で行う方が扱いやすくなります。
アラートは3段階に分ける
全てを通知にすると、全てが無視されます。起きたときの緊急度で3つに分けてください。
すぐ人を呼ぶもの
アクセス権そのものが変わる操作です。グループへのメンバーの追加、グループへの保管庫のアクセス権の付与、サービスアカウントのトークンの発行、SSO設定の変更、サインインアドレスの変更が該当します。いずれも、実行されたこと自体が正当な変更管理の記録と対応しているはずの操作です。申請がないのに実行されたら、その時点で確認が要ります。
翌営業日に確認するもの
頻度が高く、単独では判断できないものです。保管庫の作成と削除、ファイアウォールのルールの更新、端末の認証、サインイン試行の上限の超過が該当します。まとめて一覧で見て、心当たりのないものだけを追います。
数えるだけのもの
アイテムの使用状況とサインインの成功です。1件ずつ見ても意味がありません。傾向として見る対象で、平常時との差が出たときに初めて調べます。定着の度合いは利用状況と定着のレポートの画面でも確認できます。
誤検知を減らす
しきい値を件数だけで決めると外します。1Passwordには、悪意がないのに失敗として記録される経路がいくつかあります。
複数の1Passwordアカウントを併用している人が、別のアカウントのパスワードを入力すると失敗になります。個人のアカウントと業務のアカウントを両方使っている人で日常的に起きます。ファイアウォールのルールを記録のみの動作に設定している場合、正規の利用者の接続も試行として積み上がります。ルールを追加した月は、攻撃がなくても件数が跳ねます。
従って、見るのは総件数ではなく次の2つです。同じメールアドレスに対する短時間の繰り返しと、業務に関係のない場所からの試行です。件数のしきい値を使うなら、ポリシーを変更した日付も一緒に記録し、増減の理由を後から追えるようにしてください。この2つの経路の詳細はサインイン試行と端末のレポートで扱います。
仕組みが生きていることを確かめる
監視の仕組みで最も多い失敗は、止まっていることに気付かないことです。原因のほとんどはトークンの期限切れです。
【運用のポイント】 1Passwordからのイベントが一定時間届かないことを検知するルールを、必ず1本作ってください。届いたイベントを監視するルールだけでは、届かなくなったことを検知できません。しきい値は、平常時に最も間隔が空く時間帯を基準にします。深夜と休日は操作そのものが少ないため、平日の日中と同じ基準にすると誤検知が続きます。
あわせて、四半期に一度は次の3つを確認してください。トークンの有効期限が近づいていないか、対応表が最新か、アラートのルールが実際に発火した実績があるかです。一度も発火していないルールは、条件が厳しすぎるか、監視すべき対象からずれています。
アラートが発火したときに誰が一次対応するかも、先に決めておきます。1Passwordのパーミッションの変更は、情報システム部門とセキュリティー部門のどちらが所管するかが曖昧になりやすい領域です。決まっていないと、通知は届いているのに誰も動かない、という状態になります。割り当ての設計は管理権限の一覧と割り当て方で扱います。