パスワードを忘れた、認証キーを紛失したという問い合わせは、どの組織でも日常的に発生します。多くの場合は急ぎの案件として扱われ、業務を止めないことが優先されます。その結果、本人確認が事実上省略されるという運用が定着してしまうことがあります。この記事では、復旧の窓口が抜け道になる構造と、業務を止めずに本人確認を成立させるための決め方を整理します。
認証を強くしても復旧の窓口が弱ければ意味が薄れる
パスワードの要件を見直し、多要素認証を導入しても、それらは正面から入ろうとする相手に対する対策です。攻撃側は最も手間のかからない経路を選ぶため、復旧の窓口が最も緩い場所であれば、そこが実質的な最弱点になります。認証の強度と復旧手続きの強度は、セットで考える必要があります。ポリシー側の設計についてはパスワードポリシーの決め方、認証方式そのものについてはWindows OSログインの2要素認証で扱っています。
なぜ本人確認が省略されてしまうのか
担当者が手を抜いているというより、省略される方向に運用が傾く理由がいくつも重なっています。依頼者が急いでいて待たせにくい、相手が忙しい役職者で確認を求めにくい、担当者が相手を知っているつもりで判断してしまう、そもそも手順が定まっておらずその場の判断になる、といった状況です。とくに手順が文書化されていない組織では、対応の厳しさが担当者ごと、状況ごとにばらつきます。
なりすましにはいくつかの類型がある
防御側として知っておきたいのは、細かい手口ではなく類型です。急いでいると訴えて手続きを飛ばさせる、社内の関係者を装って権限がある前提で話を進める、外部の人物が社員として問い合わせる、といった形があります。共通しているのは、技術的な突破ではなく人の判断に働きかけるという点です。だからこそ、担当者の判断力に頼るのではなく、手順として確認方法を固定しておくことが対策になります。
本人確認をどう成立させるか
- 事前に登録した連絡手段へ折り返す — 問い合わせてきた経路で答えず、台帳に登録済みの番号や社内アドレスへこちらから連絡します
- 上長または別ルートで確認する — 依頼者本人以外の一人が確認に関わる形にします
- 受付経路を限定する — 対面、または既知の社内システム経由に限り、それ以外の経路では受け付けないと決めます
- 初回ログインで必ず変更させる — 発行した仮のパスワードは一度しか使えない状態にし、本人に設定させます
誰にどの権限が付いているかが分からなければ、そもそも影響範囲を判断できません。前提となる管理の考え方はアカウント管理システムとは？の解説記事で整理しています。
業務を止めないための工夫
手続きを厳しくすると業務が止まる、という懸念から運用が緩むケースが多いため、順番を逆にします。まず急ぎのケースを想定した手順を先に作っておくことです。至急の場合はこの経路で確認する、と決めておけば、その場で判断する必要がなくなります。あわせて、役職や状況によって手順を緩めないことを明示しておきます。例外を認める余地が残っていると、そこが狙われる場所になります。
一方で、一般的なケースは自動化して問い合わせ自体を減らすことも有効です。利用者自身で再設定できる仕組みを用意すれば、窓口の負荷が下がり、人の判断が必要な案件に時間を割けます。認証デバイスを紛失したときの復旧手続きは要件が異なるため、多要素認証の導入と運用もあわせて確認してください。
記録を残すことと管理者アカウントの別扱い
いつ、誰の依頼で、誰が承認し、誰がリセットしたかを記録に残します。記録が残ると分かっていること自体が抑止として働き、後から経緯を追跡することもできます。何をどこまで残すかという設計はアクセスログの監査で扱っています。
また、管理者アカウントは影響範囲が大きいため、復旧の要件を一般利用者より厳しくします。承認者を限定する、単独では手続きを完了できないようにするといった扱いです。権限そのものの整理については特権アカウントの管理も参考になります。
まずは自社の状況を確認する
復旧の窓口の運用は、手順が文書化されているかどうかで実態が大きく変わります。applippliの無料診断では、約3分の質問に回答するだけで、自社のID・アカウント管理の対応状況を確認できます。まずは現状を把握するところから始めてみてください。