はじめてのOkta Workforce Identity Cloud (WIC) [第5回] 「セルフサービスのアカウント復旧」ってどうやるの？
目次
本ブログ記事では、Okta Workforce Identity Cloud (以降、Okta WIC) での「Self-service account recovery (セルフサービスのアカウント復旧)」機能について解説します。
Oktaでは、「パスワードレス認証」＝「パスワードを使わない認証」を推奨していますが、まだまだパスワードは利用されているようです。
理由は「パスワードは誰もが慣れているから」「導入しやすいから」という側面が大きいように思います。
しかし、パスワード文字数が少なかったり、abc123のようなありきたりなパスワードだと推測されやすいので、攻撃者にログインされてしまうリスクが高まります。
そこで、文字数を長く、様々な文字種 (大文字と小文字の混在、記号を1つ以上入れる、等) が必要な、類推されにくいであろうパスワード設定ルールを適用することになると思います。
(「どのようなパスワードルールが適切なのか、基準を知りたい。」という場合には、NIST800-63B 「5.1.1.2 Memorized Secret Verifiers」がご参考になるかと思います。)
ところが、そうするとユーザーは「パスワードを忘れてしまった」、「何度も入力を間違えてロックアウトされてしまった」ということが頻発し、ヘルプデスクでそれらに対応する人々は疲弊してしまいます。
かといって、そのためにパスワード設定ルールを簡単なものにするわけにもいきません。ではどうすればよいか？
「パスワード忘れもロックアウトも、ユーザー自身で復旧してもらう方式があればよい」ですよね。
本ブログ記事では、その方法について解説していきます。
スクリーンショットが多いので記事が長くなりましたが、お付き合いくださいますと幸いです。
以降の解説は、以下のブログ記事の内容を実施済み (理解済み) の前提で進めていきます。
・初めてのOkta Workforce Identity Cloud (WIC) トライアル環境の構築
・初めてのOkta Workforce Identity Cloud (WIC) [第1回] ユーザーと認証器の関係を紐解く
・初めてのOkta Workforce Identity Cloud (WIC) [第2回] 多要素認証を紐解く
メールだけでパスワード復旧する
まずはシンプルな、メールだけを使ってユーザー自身でパスワードを復旧する方法から説明します。
(おそらく、デフォルトで有効になっているはずですが、設定と確認方法をお伝えします。)
パスワード復旧に限らずのことですが、ユーザーがOkta WIC上で何かを行いたくてOkta WICにアクセスする場合は、兎にも角にも最初にOkta Dashboardアプリにアクセスすることになります。
そのため、パスワード復旧においても、少なからずOkta Dashboardアプリの認証ポリシー設定の影響を受けます。
よって、本ブログ記事では、Okta Dashboardアプリはシンプルに「パスワード」だけで認証できるように設定しています。(以降の説明がややこしくならないように。)
メールだけでパスワード復旧する設定
では、設定を確認していきましょう。
「セキュリティ」→「Authenticator」→「セットアップ」タブで、「パスワード」の「編集」をクリックします。
表示された「パスワード」設定画面の一番下に「デフォルトルール」がありますので、その右端のペンシルマークをクリックします。
デフォルトルールの設定画面が表示されます。
上記画面の「[THEN] ユーザーはセルフサービスで実行できます」の設定で、以下2つが有効になっていますが、今回は、2つ目の「パスワードリセット」の方に焦点を当てます。
・「パスワード変更 (アカウント設定から)」＝「ログインしてから自身でパスワード変更する」
・「パスワードリセット」＝「パスワードを忘れてしまったので自分自身で復旧する」
「[AND] ユーザーは次を使用してリカバリーを開始可能:」の設定では、「メール」が選択されています。
「[AND] 追加の検証:」の設定では、「任意」が選択されていますが、英語UIでは「Not Required」なので、「要求しない」が正しいです。(Okta社内で修正依頼中です。)
※ 上記2つの[AND]の設定がやや曲者ですので、後ほど実例を用いて解説します。
ここまでで説明した設定になっていれば、「キャンセル」でOKです。
設定が異なっていれば、この状態に設定変更して、「ルールを更新」をクリックします。
メールによるパスワード復旧の動作確認
本ブログ記事では、テスト用に新規ユーザー: 「[email protected]」を追加しました。
「[email protected]」は有効化済みであり、Okta Dashboard へパスワードでログインできることも確認済み、という前提です。
では、メールを使ったパスワード復旧の動作を確認してみましょう。
Okta Admin Consoleとは異なるブラウザ (またはシークレットウィンドウ) で、Okta WICのURLへアクセスします。
表示された以下の画面で「[email protected]」を入力して、「次へ」をクリックします。
「パスワードをお忘れですか？」をクリックします。
「メールを送信する」ボタンをクリックします。
メールアプリに移動し、[email protected]宛に届いたメールを開き、「Reset Password」をクリックするか、Okta WIC画面に戻って、6桁のコードを認証画面に入力します。
以下のように、新しいパスワードの入力が求められる画面が表示されます。
パスワード要件に従って、新しいパスワードを2箇所に入力し、「パスワードのリセット」をクリックします。
結果、パスワードのリセットが成功し、Okta Dashboradにログインできます。
2つのオーセンティケーターを使って、パスワード復旧する
「メールだけでパスワードを復旧するのは、セキュリティ面で不安がある」という場合に、追加で別のオーセンティケーターを加えることができます。
ここでは、時刻同期ワンタイムパスワード (TOTP) 機能を持つ「Google Authenticator」を追加して、『「メール」と「Google Authenticator」の2つで認証が成功したら、パスワード復旧を許可する』という設定にしたいと思います。
「セキュリティ」→「Authenticator」→「セットアップ」タブで、「Authenticatorの追加」をクリックします。
「Google Authenticator」の「追加」をクリックします。
表示された画面の「用途」の下に「認証と復旧」とありますので、「認証」と「パスワード復旧」の2つの用途で利用されることがわかります。「追加」をクリックします。
現時点では、「メール＝パスワード復旧のみ」「Google Authenticator＝認証とパスワード復旧」となっていることを意識しておいてください。
ちょっと難ありな設定
ここではまず、「ちょっと難ありな設定」を行ってみます。
「難ありな設定」を知っておくことで、設定が持つ意味を掴めると思いますので。
もう一度、「セキュリティ」→「Authenticator」→「セットアップ」タブで、「パスワード」の「編集」をクリックします。
表示された「パスワード」設定画面の一番下の「デフォルトルール」の右端のエンピツマークをクリックします。
表示された以下の画面で、以下2つを設定変更します。
「[AND] ユーザーは次を使用してリカバリーを開始可能:」の設定では、「メール」と「Google Authenticator」を選択します。
「[AND] 追加の検証:」の設定では、「MFA/SSOに使用される任意の登録済みAuthenticator」を選択します。
この設定が意味するところは「パスワード復旧は、2つ目の認証がOKになったら許可しますよ」ということです。
「ルールを更新」をクリックします。
(※ 現在のオーセンティケーター設定とこの設定の組合せが、既に「難あり」な状態になっています。)
ユーザーが「メール」と「Google Authenticator」の2つの認証が成功したらパスワード復旧を許可したいので、「Google Authenticator」も登録しておいてもらう必要があります。
「セキュリティ」→「Authenticator」→「登録」タブで、「アクション」の「編集」をクリックします。
表示された画面で、「Google Authenticator」を「必須」に変更して「ポリシーを更新」をクリックします。
まずは、「Google Authenticator」を登録して、正常にOkta Dashboardにログインできることを確認しておきましょう。
お持ちのスマートフォンに「Google Authenticator」をインストールしてください。
Okta Admin Consoleとは異なるブラウザ (またはシークレットウィンドウ) で「[email protected]」でログインを行います。
パスワードを入力後に、「[email protected]」を登録するための画面が表示されますので「セットアップ」をクリックします。
「Google Authenticator」を設定するためのQRコードが表示されます。
スマートフォンの「Google Authenticator」を開き、「＋」→「QRコードをスキャン」をクリックして、上記のQRコードをスキャンすると、6桁のパスコードが表示されます。
Okta WICの認証画面に戻って、「次へ」をクリックします。
スマートフォンの「Google Authenticator」に表示された6桁のパスコードを入力し、「確認」をクリックします。
続いて「オプションの設定」として「Okta Verify」の登録画面が表示されると思いますが、本ブログ記事では使わないので、設定しないで「続行」をクリックします。
結果、Okta Dashboardへログインできると思います。
ちょっと難ありな設定の動作確認
それでは、本題の「ちょっと難ありな」パスワード復旧を行ってみたいと思います。
Okta Dashboradアプリの右上のユーザー名をクリックして表示されたメニューから「サインアウト」を選択します。
再度、ユーザー名に「[email protected]」を入力して進んだ後、以下のパスワード入力画面で「パスワードをお忘れですか？」をクリックします。
まずは、問題が発生しないパターンから。
「メール」の横にある「選択」をクリックします。
既述の方法と同様に、表示された画面で「メールを送信する」ボタンをクリックします。
メールアプリに移動し、[email protected]宛に届いたメールを開き、「Reset Password」をクリックするか、Okta WIC画面に戻って、6桁のコードを認証画面に入力します。
「メール」での認証が完了すると、次に「Google Authenticator」での認証が行われます。
スマートフォンの「Google Authenticator」の6桁のコードを入力して「確認」をクリックします。
この後、既述の内容と同じく、新しいパスワードを入力する画面が表示されます。
画面に表示されているパスワードルールに従ってパスワードを変更したら、完了です。
問題なくパスワード変更ができました。
では次に、問題が発生するパターンを見てみましょう。
Okta Dashboardの右上のユーザー名をクリックして表示されたメニューから「サインアウト」を選択して、もう一度パスワードリセットの手順を実施します。
以下の画面まで進んだら、今度は「Google Authenticator」の「選択」をクリックします。
スマートフォンの「Google Authenticator」の6桁のコードを入力して「確認」をクリックすると、以下のようなメッセージが出て、新しいパスワードを設定する画面に進むことができません。
この原因は、下記の設定にあります。
先に「Google Authenticator」を選択したので、「Google Authenticator」は「復旧」＝「パスワードの復旧」として使用されました。
ユーザー: [email protected] が使えるオーセンティケーターとして現時点で残っているのは「メール」だけですが、「メール」は「パスワードの復旧」として使えるように設定されているものの、「認証」に使えるようには設定されていません。
1つ目のオーセンティケーターで「パスワードの復旧」、2つ目のオーセンティケーターで「追加の検証(＝認証)」を行っている、というわけです。
なので、現時点の設定状態ですと、先に「Google Authenticator」を選択すると、「メール」には「追加の検証(＝認証)」が許可されていないので、結果、パスワード復旧ができない、ということになるのです。
うまくいく設定 (パターン1)
上記の問題を回避する1つ目の設定方法です。
上記の「ちょっと難あり」な設定は、「ユーザーが、先にGoogle Authenticatorを選択してしまうこと」にありました。
よって、「ユーザーは、先にメールだけが選択できるようにすればよい (＝先にGoogle Authenticatorが選択できなければよい)」ということになります。
以下に、その設定方法を示します。
もう一度、「セキュリティ」→「Authenticator」→「セットアップ」タブで、「パスワード」の「編集」をクリックします。
表示された「パスワード」設定画面の一番下の「デフォルトルール」の右端のエンピツマークをクリックします。
表示された以下の画面の「[AND] ユーザーは次を使用してリカバリーを開始可能:」の設定で、「メール」にはチェックを入れたまま、「Google Authenticator」のチェックを外します。
この「[AND] ユーザーは次を使用してリカバリーを開始可能:」の「開始可能」という言葉がポイントです。
この設定はあくまで「ユーザーがパスワードを復旧 (リカバリー) するために、最初にどのオーセンティケーターを使わせるようにしますか？」と聞いているだけで、「ユーザーにどのオーセンティケーターで復旧させるか、該当するものを全て選んでください。」とは言っていないのです。
よって、「メール」だけを有効にすることで、ユーザーが「パスワードをお忘れですか？」をクリックした後には、以下のように「メール」だけが出てくるようになります。
このメールでの認証が完了した後、「Google Authenticator」の認証が行われ、その後で新しいパスワードを入力する画面へと進んでいき、パスワード復旧が成功します。
うまくいく設定 (パターン2)
2つ目は、「メールも、復旧と認証の両方を有効にする」という方法です。
「セキュリティ」→「Authenticator」→「セットアップ」タブで、「メール」の「編集」をクリックします。
用途で「認証と復旧」を選択して「保存」をクリックします。
再び、以下の設定を一つ前の状態 ＝「メール」にも「Google Authenticatior」にもチェックが入った状態に戻します。
では確認してみましょう。
「パスワードをお忘れですか？」をクリックした後に、「メール」と「Google Authenticator」の2つの選択肢が出てきます。
既述の「ちょっと難ありな設定」で課題となった「先にGoogle Authenticatorを選択」を行います。
スマートフォンの「Google Authenticator」に表示された6桁のコードを入力して「確認」をクリックします。
すると今度は、以下のように、「Google Authenticator」での認証の後に、「メール」での認証が行われるようになります。
「メール」の認証が完了すると、新しいパスワードを設定する画面が表示され、パスワード復旧 (リセット) ができます。
うまくいく設定の (パターン1)と (パターン2) のどっちがよい？
メールをアプリのサインオンで使う予定がなければ ( ≒ 使いたくなければ)、「うまくいく設定 (パターン1)」がお勧めです。
「うまくいく設定 (パターン2)」の設定は、メールをログインの認証要素として利用することを許可することになります。
認証ポリシーの設定で、許可する/許可しないオーセンティケーターの指定はできますので、注意深く設定すれば問題ありませんが、パターン1にしておけば、そもそもメールはオーセンティケーターの候補として出てこなくなりますので、設定ミスを防ぐことができます。
パスワードを何度も間違えてロックアウトされた場合の復旧
デフォルトでは、ユーザーがパスワードを10回間違えるとロックアウトされるように設定されています。
ここでは、その解除もユーザー自身に行ってもらうための設定方法をお伝えします。
「セキュリティ」→「Authenticator」→「セットアップ」タブで、「パスワード」の「編集」をクリックします。
表示された画面の「デフォルトポリシー」の下の方の「ロックアウト」の右横に「次の経過後にユーザーはロックアウトされます： 10 試行失敗回数」との記載があります。
右上の「編集」をクリックすることで、回数を変更することもできますが、本ブログ記事ではこのまま利用します。
この画面の一番下の「ルールの追加」ボタンをクリックします。
(デフォルトルールでは「アカウントロック解除」を有効にできないので、新しくルールを作ります。)
任意のルール名を入力します。
「[THEN]ユーザーはセルフサービスで実行できます」の「アカウントロック解除」にチェックが入っていることを確認します。
「復旧Authenticator」以降の設定は、以下のように設定しました。
(「うまくいく設定 (パターン2)」の設定のまま、その流れで設定しています。)
「ルールの作成」をクリックします。
新しく作成したルールが、優先度としてデフォルトルールより上に来ていることを確認します。
それでは、動作を確認しましょう。
Okta Admin Consoleとは異なるブラウザ (またはシークレットウィンドウ) で、Okta WICのURLへアクセスします。
表示された以下の画面で「[email protected]」を入力して、「次へ」をクリックします。
表示されたパスワードを入力する画面で、わざと間違ったパスワードを入力し、「確認」を10回クリックします。
結果、アカウントがロックされるので、以下の画面に遷移します。
ユーザー名「[email protected]」を入力し、メールかGoogle Authenticatorのどちらかを選択してください。
以降は、パスワード復旧の際の動作と同様です。
その他、より詳細はオンラインマニュアルの「セルフサービスのアカウント復旧」をご参照ください。
まとめ
本ブログ記事では、Okta WICでの「Self-service account recovery (セルフサービスのアカウント復旧)」機能についてご紹介しました。
弊社としては、セキュリティ強化の観点から「パスワードレス認証」に移行していただくのを推奨していますが、PC環境の制約などにより、当面はパスワード認証が使われるケースは多いのかな、とも思います。
という状況であれば、できるだけ強固なパスワードルールを強制しつつ、この「セルフサービスのアカウント復旧」機能で、管理者 (ヘルプデスク) の負担を軽減できると思いますので、ぜひご活用頂けたらと思います。
とはいえ、パスワードレス認証はユーザーの生産性をさらに高めるだけでなく、フィッシング耐性を備えるなど、セキュリティ面でも優れていますので、パスワードレス認証への移行がベストです。中期的なご計画として、是非ともご検討頂きたく思います。
また、Okta WICでは、認証の強化だけでなく、管理者が行うユーザーの登録/変更/削除に関わる業務の自動化や、人事管理システムや既設ディレクトリなどとの柔軟な連携も可能です。
Oktaでは、これらの機能を体感頂くことができる「Okta Essentials」トレーニングをご用意しております。(日本語でのトレーニングもご用意しております。)
このトレーニングは全体像を体系的にご理解頂ける内容となっておりますので、是非ともご活用ください。
Follow 岸本 卓也
