はじめに
Google Cloud コンソールや Cloud Identity コンソールでは、二要素認証の強制が可能です。
本記事では、Cloud Identity を利用した二要素認証における「猶予期間」の概要から注意すべき点について、私自身の経験を交えながら対処方法を紹介します。
二要素認証の猶予期間と注意点
Cloud Identityでは、新しくユーザーを作成した際に、ログイン時の二要素認証を強制するまでの猶予期間を設定することが可能です。
注意点
- 猶予期間を設定しない場合
ユーザーはアカウント作成通知を受け取っても、二要素認証の設定ができず、ログイン不能となるリスクがあります。 - 猶予期間を設定する場合
二要素認証を強制している状態でも、その期間内であればユーザー自身が認証設定を行うことが可能です。 - 猶予期間は 「1日~最大6カ月」 まで設定可能です。
猶予期間を過ぎた場合の運用対処
私の実体験として、以下のような事例がありました。
- ユーザーは作成通知メールを確認し、初回ログインを行ったが 二要素認証の設定を後回しにしてしまった
- そのまま猶予期間を超過
- ユーザーがログインを試みても、二要素認証を行っていないため ログインに失敗
- ユーザー側だけでは対処できず、運用担当での対応が必要になる
対処方法の比較
以下のような2つの手法を検討しました。
手法 | 結果 | 問題点 |
---|---|---|
二要素認証の猶予期間を延ばす | ログイン時に二要素の設定画面が表示され、ユーザー側で二要素認証の設定が可能となる | 個別ユーザーの設定ができないため、一時的にでも全ユーザーに対して猶予期間が延び、セキュリティリスクが発生する |
ユーザー個別にバックアップコードを発行する | ログイン時に「別の方法を試す」という選択肢が増え、バックアップコードを入力することで二要素認証の設定が可能となる | 10個のバックアップコードが発行されるため、ユーザーへ個別に伝える運用負荷が発生する |
私の場合は「ユーザー個別にバックアップコードを発行する」方法を採用しました。
理由は、二要素認証が設定できないユーザーに限定した対応が可能となり、セキュリティリスクを最小化できるためです。
詳細な手順は以下を参照してください。
Google 公式ヘルプ:バックアップコードの生成
まとめ
Cloud Identity における二要素認証の強制は、セキュリティ強化の上で非常に有効な手段です。
しかし一方で、猶予期間の設計やユーザー対応次第では、ログイン不能のトラブルが発生する可能性があります。
対処方法を選択する際は、以下を総合的に考慮することが重要です。
- セキュリティ要件
- 運用負荷
- ユーザー対応のしやすさ
今後、Google Cloud でも 二要素認証の必須化 が進められており、同様の問題が多数発生する可能性があります。
運用を検討する際の参考になれば幸いです。