失敗したサインインと、古いバージョンのアプリを使っている端末を把握する2本のレポートです。どちらもポリシーの効き方を確かめるための画面で、単独で眺めても判断にはつながりません。記録される範囲にも制約があり、アプリのロックの解除に失敗しても、この画面には出てきません。このページでは2本の読み方、疑わしい試行をその場でブロックする手順、記録されない操作、ポリシーとの組み合わせ方を説明します。ポリシーそのものの設定はファイアウォールルールによる制限とアプリのバージョンの強制で扱います。
サインイン試行のレポートに出るもの
レポートのサインイン試行のカードから開きます。対象は過去60日分で、記録されるのは次の3つの場合です。
- ファイアウォールのルールによってブロックされた、または記録された試行
- アプリのバージョンが古くて失敗した試行
- アカウントパスワード、Secret Key、第2要素のいずれかが違って失敗した試行
画面の上半分が地図、下半分がタイムラインです。地図には場所ごとの件数がまとめて表示され、拡大すると内訳に分かれます。タイムラインの1件を選ぶと、右側に詳細が出ます。詳細に入るのは、日時、対象のメールアドレス、端末のOS、IPアドレスと場所です。各行には失敗の理由を示す分類が付くので、第2要素の失敗とクレデンシャルの誤りを見分けられます。
疑わしい試行をその場でブロックする
詳細に出ているIPアドレスまたは場所の横の操作から拒否を選ぶと、ファイアウォールのルールが1件追加されます。調査の時間を確保するための一時的な措置として使えます。
【注意】 追加されたルールはポリシーとして残り続けます。出張先の回線、在宅勤務の回線、モバイル回線の経路によっては、正規の利用者が同じ場所やIPアドレスから接続します。ブロックした後は必ず
ポリシーのファイアウォールに戻り、恒久的に残すかどうかを判断してください。判断しないまま積み上げると、原因の分からないサインイン不可が後から発生します。
記録されないもの、誤って記録されるもの
アプリの中でのロックの解除の失敗は、このレポートに出ません。解除は端末内で完結する処理で、サーバーへのサインインとは別の動作だからです。端末を拾った人が解除を何度も試しても、この画面には現れません。紛失した端末への対応は、レポートを見ることではなく、アカウントの一時停止と端末の登録の解除になります。
逆に、攻撃ではないのに失敗として記録されるものがあります。複数の1Passwordアカウントをアプリやブラウザー拡張機能で併用している人が、別のアカウントのパスワードを入力した場合です。個人のアカウントと業務のアカウントを両方使っている人でよく起こります。全てのアカウントで同じアカウントパスワードを使うと減らせます。
しきい値を決めるときは、この2つを織り込んでください。見るのは件数の絶対値ではなく、同じメールアドレスに対する短時間の繰り返しと、業務に関係のない国からの試行です。
デバイスレポートで古いアプリを洗い出す
レポートのデバイスレポートのカードから開きます。上段に稼働中の端末の数と、古いバージョンのアプリの数が出ます。その下がアプリごとの内訳で、新しいバージョンと古いバージョンの台数に分かれます。古いバージョンを使っている人については、アプリの種類、端末名、OS、最終のサインインが一覧になります。
【注意】 上段の数字は人数ではありません。1人が複数の端末とブラウザーで使うため、端末数は人数の数倍になります。ブラウザー拡張機能も1台として数えられます。端末数は人数を大きく上回ります。この数字をライセンス数の根拠や利用者数の報告に使わないでください。人数は
チームレポートか概要レポートから取ります。
古いアプリを締め出すときに起きること
ポリシーの共有と許可にある1Passwordアップデートで、古いバージョンのアプリからのサインインを禁止できます。有効にすると、必要なバージョンに満たないアプリを使っている人はサインインできなくなります。1Password.comからは引き続き利用できるため、完全に締め出されるわけではありませんが、業務は止まります。
デバイスレポートの一覧は、このポリシーを有効にしたときに止まる人の一覧でもあります。順序としては、一覧を出す、対象者に更新を依頼する、台数が減ったことを確認する、それからポリシーを有効にする、という流れになります。逆の順序で進めると、ヘルプデスクへの問い合わせが同じ日に集中します。必要なバージョンとポリシーの設定はアプリのバージョンの強制で扱います。
管理対象の端末では、利用者に依頼するよりMDMでの配布の方が確実です。更新が止まっている端末は、アプリが古いのではなく端末の管理そのものが外れている場合もあります。台数が減らないときは、MDMによる設定の配布まで戻って確認してください。
2つのレポートを運用に組み込む
どちらも画面を開かないと分かりません。頻度を決めて、短時間で終わる形にします。
週次で見る
サインイン試行を開き、同じアドレスへの繰り返しと、業務に関係のない国からの試行だけを確認します。慣れれば数分で終わります。件数を記録に残すなら、ファイアウォールのルールを変更した日付も一緒に残してください。
月次で見る
デバイスレポートで古いアプリの台数を記録します。ロールアウトの途中は減っていく数字として、定常運用に入ってからは増えていないかを見る数字として使います。
継続的な監視は別の仕組みに寄せる
画面を開かずにアラートを受け取りたい場合は、イベントレポートでSIEMへ流し、サインインの失敗をルールにします。設計はEvents Reportingの設定とログの保管とアラートの設計で扱います。レポートは棚卸し、SIEMは監視、という切り分けにすると重複しません。
【運用のポイント】 サインイン試行の件数は、ファイアウォールのルールを増やすほど増えます。ルールの動作に
レポートを選ぶと、ブロックせずに記録だけが残るためです。前月比で急増したときは、攻撃ではなくルールの追加が原因のこともあります。数字を報告する前に、ポリシーの変更履歴を確認してください。