認証を厳しくする作業には、自分たちが締め出される側になるという固有のリスクがあります。しかも締め出された状態では、設定を直すための管理画面にも入れません。先に逃げ道を作ってから鍵を締める——順序はこれだけですが、逆にすると復旧に外部の窓口を頼ることになります。
締め出しが起きる3つの経路
- ポリシーの設定ミス — 対象の指定を誤り、管理者自身を含む全員に厳しい条件が適用される。作成した本人がサインアウトした瞬間に気づく、という形で表面化します
- 認証に使う端末の紛失・故障・機種変更 — 認証アプリを入れたスマートフォンが1台しかなく、それが手元にない。管理者が1人しかいない会社では、これだけで詰みます
- 認証サービス側の障害 — 自社に落ち度がなくても、追加の確認が通らない時間帯は発生し得ます。復旧を待てる業務ばかりとは限りません
3つに共通するのは、事前準備がなければ社内の誰にも解決できないという点です。普段は誰も使わないアカウントを1つ余分に持っておくことが、この3つ全部に効きます。
緊急用アカウントの要件
| 要件 | 理由 |
|---|---|
| 個人に紐づけない | 担当者の退職・異動でアカウントごと失われるのを防ぐ |
| 社内システムに依存させない | 連携元が止まっているときに使えないのでは意味がない |
| 条件付きアクセスの対象から除外する | ポリシーの設定ミスで一緒に締め出されないようにする |
| 長く、他で使っていないパスワードにする | 追加の確認を外す以上、パスワードだけが防壁になる |
| 2つ用意する | 片方が使えない事態も想定する。保管場所も分ける |
| 日常業務では使わない | 使用の記録が出たこと自体を異常として検知できるようにする |
手順
- クラウド側で管理者アカウントを2つ作成します。氏名ではなく用途が分かる名前にし、誰の持ち物でもない扱いにします
- 十分に長く、他のどこでも使っていないパスワードを設定します。推測できる規則性を持たせないでください
- パスワードを2つに分けて別々の場所に封書で保管します。片方だけ見た人には使えない状態にしておくと、保管そのものが単独のリスクになりません
- 条件付きアクセスの各ポリシーで、このアカウントを除外に指定します。ポリシーを新しく作るたびに除外を入れる必要があります。ここが抜けると、用意した意味がなくなります
- このアカウントのサインインを監視対象にします。使われたら管理者に通知が飛ぶようにしておきます
- 手順書を紙でも残します。締め出されている状況では、社内の共有フォルダに置いた手順書が読めない可能性があります
除外することの危険と、その打ち消し方
追加の確認を免除された管理者アカウントを作る、というのはそれ自体が弱点を1つ作る行為です。ここを認識せずに作るのが一番危険なので、打ち消す仕掛けを同時に入れます。
- 使用されたら必ず気づく状態にする — 普段使わないアカウントなので、サインインの記録が出ること自体が異常です。この特性は監視の対象として非常に扱いやすく、緊急用アカウントを作る利点のひとつでもあります
- 使ったら必ずパスワードを変える — 開封したら再発行、というルールにしておけば、封書が開いているかどうかで状態が分かります
- 棚卸しの対象に含める — 管理者権限を持つアカウントの一覧を確認する際に、想定どおり2つだけであることを確かめます。確認の手順は管理者権限を持つアカウントを一覧で確認する手順で扱っています
年に一度、実際に使えるか確かめる
用意しただけで一度も試していない緊急用アカウントは、動かないことが多いです。パスワードの有効期限で失効している、後から作ったポリシーの除外に入れ忘れている、保管場所が分からなくなっている——いざというときに気づくのでは遅すぎます。
年に一度、封書を開けて実際にサインインし、通ることを確認して、終わったらパスワードを再発行して封をし直します。この確認を誰の担当にするかまで決めて初めて、対策として完成します。認証の入口を段階的に固めていく全体像はWindowsのOSログインに2要素認証を導入する解説で整理しています。
まずは自社の状況を確認する
applippliの無料診断では、約3分の質問に回答するだけで、クラウドとPC本体の双方を含めた認証の状況を5段階で判定し、結果をPDFレポートでお届けします。個人情報の入力は不要で、会員登録もありません。
