管理コンソールの画面を開かずに1Passwordの活動を追い続けるには、イベントをSIEMへ送ります。その入り口が統合のイベントレポートです。設定そのものは10分ほどで終わりますが、先に決めておかないと後で作り直しになるものが3つあります。どのイベントを送るか、トークンをいくつ発行するか、トークンをどこに保管するかです。このページでは、送れるイベントの種類と送られないデータ、統合の追加とトークンの発行、トークンの設計と差し替えの手順、データの保護の仕組みを説明します。SIEMごとの接続手順はSIEMごとの接続で、保管期間とアラートの決め方はログの保管とアラートの設計で扱います。
送れるイベントは3種類
イベントレポートで送れるのは次の3種類です。トークンを発行するときに、どれを含めるかを選びます。
| 種類 | 内容 |
|---|---|
| 監査イベント | アカウント、保管庫、グループ、人に対する管理操作 |
| アイテムの使用状況 | 共有保管庫のアイテムが変更、閲覧、使用されたこと |
| サインイン試行 | サインインの成功と失敗 |
管理コンソールの監査ログに出るのは1つ目だけです。アイテムが実際に使われたことと、サインインが成功したことは、画面の監査ログには現れません。この2つを追いたい場合はイベントレポートが唯一の経路になります。
逆に、送られないものもあります。
【注意】 保管庫の名前とアイテムの名前は送られません。これらはクライアント側で暗号化されており、Events APIからは取り出せない仕組みだからです。SIEMに届くのは一意の識別子です。「経理保管庫でアイテムが使われた」という形のアラートを組むには、識別子と名前を対応させる表を自社で用意し、SIEM側で突き合わせる必要があります。これを用意しないまま運用を始めると、アラートは飛ぶのに何が起きたか分からない状態になります。
対応表はop vault listとop group listで取得できます。管理コンソールで対象を開いたときのアドレス欄からも読み取れます。保管庫やグループを追加したら表も更新する、という運用を最初から手順に入れておいてください。
統合を追加してトークンを発行する
所有者と管理者が設定できます。サイドバーの統合を開き、イベントレポートから送り先のSIEMを選びます。一覧にない場合はその他を選びます。ここで選んだ名前は表示上の区別に使うもので、選び間違えてもデータの中身は変わりません。
手順は4つです。
- 統合の名前を入力して追加します
- ベアラートークンの名前と有効期限を決めます
- そのトークンで送るイベントの種類を選び、発行します
- 表示されたトークンを1Passwordに保存し、保存先の保管庫を選びます
トークンの文字列が全て表示されるのはこの画面だけです。保存せずに閉じると再表示できず、発行し直しになります。保存の操作は必ず画面を閉じる前に行ってください。
保存先には、管理者だけがアクセスできる保管庫を指定します。既定で従業員保管庫に入ってしまうと、担当者が退職したときに一緒に見えなくなります。SIEM運用を引き継げるよう、共有保管庫に置いてください。保管庫の設計は保管庫の権限モデルで扱います。
トークンの設計
サービスごとに1本にする
複数のSIEMやツールから同じトークンを使い回さないでください。1本を失効させると、そのトークンを使っている全ての取り込みが同時に止まります。サービスごとに分けておけば、影響を1つに閉じ込められます。
有効期限は運用の周期に合わせる
発行時に有効期限を選びます。短くすると差し替えの手間が増え、長くすると漏洩したときの影響が長引きます。判断の基準は、差し替えを忘れずにやりきれるかどうかです。四半期ごとの棚卸しが定着している組織なら、その周期に合わせると期限切れに気付けます。棚卸しの仕組みがない場合は、期限が来る前に取り込みが止まったことに気付く仕組みを先に作ってください。
送るイベントは後から変えられない
トークンが扱えるイベントの種類は、発行したときに固定されます。後から追加も削除もできません。変更したい場合は新しいトークンを発行し、SIEM側の設定を書き換えることになります。最初は3種類とも含めておき、SIEM側で絞る方が、後の手戻りが少なくなります。
トークンを差し替える
失効させると、そのトークンを使っているSIEMは即座にイベントを受け取らなくなります。順序を間違えると、気付くまでの間のイベントが欠けます。
- 新しいトークンを発行します
- SIEM側の設定を新しいトークンに書き換えます
- 新しいトークンでイベントが届いていることを確認します
- 古いトークンを失効させます
失効は統合の対象のイベントレポートを開き、該当するトークンの設定から行います。
【注意】 欠けたイベントは後から取り直せません。管理コンソールの
監査ログは365日分を保持しているので、監査イベントであれば画面から書き出して穴を埋められます。アイテムの使用状況とサインイン試行にはこの逃げ道がありません。この2つは止まった時間がそのまま記録の欠落になります。差し替えは必ず上の順序で行ってください。
送られるデータの保護
Events APIにイベントを渡すサーバーは、1Password.comの他の部分から分離されています。このサーバーが持つのはイベントのデータだけで、保管庫の中身には触れません。
取得のたびにベアラートークンによる認証が行われます。トークンは発行元の統合に対してだけ有効で、他の統合には使えません。いつでも失効させられます。
データは保管中も転送中も暗号化されます。前述の通り、保管庫名とアイテム名はクライアント側で暗号化されたままで、Events APIからは読めません。SIEMに預けるデータの範囲を社内で説明するときは、識別子と操作の記録は渡るが、クレデンシャルの中身と対象の名前は渡らない、という整理になります。
【運用のポイント】 設定した直後は届いていても、数カ月後に止まっていることに気付くというのがよくある失敗です。原因はトークンの期限切れがほとんどです。SIEM側で、1Passwordからのイベントが一定時間届かないことを検知するルールを1本作っておいてください。届いたイベントを監視するルールだけでは、届かなくなったことに気付けません。