誰かにメールボックスを渡す従来の方法は、メールボックスを作成し、パスワードを決め、メールアドレスとパスワードを本人に送るというものです。安全ではないと誰もが知りながら、ほとんどの人が続けています。ほかの方法は手間がかかると考えられてきたからです。設定用の招待を使えば、その言い訳は不要になります。管理者はパスワードを決めず、メールやチャットで誰かに伝える必要もありません。
この記事では、招待の仕組み、パスワードを共有しないことが見た目以上に重要な理由、二要素認証と退職時のアクセス解除への影響を説明します。
問題が起きていなくてもパスワードを共有してはいけない理由
最も分かりやすい理由は、傍受される危険です。メールやチャットで送ったパスワードは、少なくとも2つのメールボックスに期限なく残り、検索でき、すべてのバックアップにも保存されます。将来どちらかのアカウントにアクセスした人は、そのパスワードを見つけられます。NISTのガイダンスも、このような方法で秘密情報を送らないよう長年勧告しています。
より気づきにくい問題は、そのパスワードが変更されないことです。初回ログイン時に利用者が自分のパスワードを設定するのが建前ですが、実際は送られたものを使い続けます。問題なく動き、変更も強制されないからです。数か月後も、管理者は他人のメールボックスへ入れる認証情報を知っています。これでは、そのメールボックス内の操作を本人のものだと断定できません。
何らかの争いが起きたとき、最後の点が特に重要になります。2人が同じパスワードを知っていれば、そのアカウントでの操作をどちらか一方に確実に帰属させることはできません。パスワードを共有しない仕組みは、安全性を高めるだけではありません。監査証跡を意味のあるものにするための前提です。
招待によってパスワード共有をなくす仕組み
管理者はパスワードを設定せずにメールボックスを作成します。システムが利用予定者へリンクをメールで送り、本人がリンクを開いて自分でパスワードを決めます。認証情報が他人の手を経由する場面はありません。
そのため、パスワードが本人以外に見える形で存在することはありません。送信済みフォルダーにも、チャット履歴にも残らず、管理者が知ってしまった情報を忘れようとする必要もありません。
招待は個別にも一括でも送れます。一括送信できるからこそ、単なる良い考えではなく実用的な方法になります。新しい顧客のために40個のメールボックスを用意するときは、40個のパスワードを生成、記録、送付する代わりに、1回の操作で40件の招待を送ります。詳しくは、メールボックスの一括作成で説明しています。
二要素認証で残りの弱点を補う
パスワードを共有しなければ一つの穴は閉じられますが、もう一つ残ります。利用者だけが知るパスワードでも、弱いものや、別のサービスで使い回したものかもしれません。
その弱点を補うのが二要素認証です。招待の途中ではなく、利用者がWebメールの設定から登録します。別に表示される案内であり、別に身につけるべき習慣でもあります。操作の流れによって強制されないため、普及するかどうかは管理者が利用者へ依頼するかに左右されます。
招待を送る時点で依頼し、1週間後にもう一度確認してください。管理画面のメールボックスセキュリティページでは、二要素認証が有効なメールボックスと、確認された日時が分かります。未対応者を推測するのではなく、一覧で追跡できます。
同時に、リカバリーコードの保管も必須にしてください。アカウント所有者は、管理画面からメールボックスの二要素認証を解除できません。利用者が端末とリカバリーコードの両方を失った場合は、サポートへの問い合わせが必要です。全体の手順は、2FAでロックアウトされた場合の解決方法で紹介しています。
管理者の仕事はどう変わるか
パスワードを共有しない運用にすると、管理者の仕事はほとんど減ります。ただし、一つだけ慣れが必要です。
認証情報を預かる役割がなくなり、それに関する依頼も一式なくなります。「パスワードを教えてください」という問い合わせは、利用者自身によるリセットに変わります。管理者だけを特別に信頼しなければならない状況もなくなります。同僚ではなく顧客のメールボックスを扱う場合は、大きな安心につながります。
慣れが必要なのは、確認のために他人のメールボックスへログインできなくなることです。初めは不便に感じても、それが常に正しい状態です。会社としてやり取りへのアクセスが必要なら、管理者が利用者のパスワードを知るのではなく、メンバー制の共有メールボックスを使います。両者は責任の所在が異なる別の仕組みです。混同を防ぐことこそ、パスワードを共有しない運用の目的です。
引き続き注意が必要なケース
設定して忘れるのではなく、少し考えて定期的に確認すべき状況が2つあります。記憶だけに頼らず、予定を決めて確認してください。
招待を完了しない利用者。初期設定が完了していないメールボックスは誰にも読まれませんが、すでにメールが届いている可能性があります。招待が期限切れになるのは正しい仕様です。しかし、対象者が本当に設定を終えたかを誰かが確認し、完了したと決めつけないようにしてください。
人ではなく物や業務に属するアドレス。物件や案件番号のためのメールボックスには、招待する個人がいません。最初からメンバー制の共有メールボックスにして、認証情報ではなく一覧でアクセスを管理してください。そうしなければ、別の経路から共有パスワードへ戻ることになります。
招待が期限切れになることで、意図しない共有を防ぐ
設定用リンクがいつまでも有効なら、手順が増えただけのパスワードと変わりません。そのため、招待には有効期間があり、期限を過ぎると使えなくなります。
実際の入社よりかなり前にメールボックスを用意すると、初日の朝にはリンクが期限切れになり、困惑した問い合わせが相次ぎます。利用者が使えるタイミングで招待を送りましょう。古いリンクを追いかけるのではなく再発行してください。数秒で完了します。
ほかのシステムでもパスワードを共有しない
メールボックスの認証情報を人から人へ渡さなくなると、ほかのシステムでも同じ問題に気づきます。そこでも同じ原則に従う価値があります。
ストレージ用の共通ログイン、複数端末で共有するアプリパスワード、3つのスクリプトで使い回す1個のAPIトークンには、同じ弱点があります。1人のアクセスを取り消すために、全員の動作を止めなければなりません。ストレージ用の認証情報を端末ごとに分ければ、同じ問題を解消できます。詳しくは、端末間でファイルを同期する方法で説明しています。
この原則はどこにでも当てはまります。複数の当事者が知っている認証情報は、そのうち1人だけから取り消すことができず、操作をどちらかに帰属させることもできません。パスワードを共有しない仕組みは、秘密を守ることだけが目的ではありません。ほかの全員を止めずに、1人へのアクセス許可だけを変更できるようにするためのものです。
