はじめに こんにちは、 ネクストモード株式会社 のSaaSおじさん久住です 当エントリは『ネクストモード フルリモート業務を実現するSaaS活用＆カルチャー Advent Calendar...
当エントリは『ネクストモード フルリモート業務を実現するSaaS活用＆カルチャー Advent Calendar 2024』11日目のエントリです。
こんにちは、ネクストモードのゆきなわです。
ネクストモード株式会社では、設立時より基本的に全員フルリモートで働いています。
就業場所に関しての制限は特に設けてはおらず、ワーケーションや自宅以外からの業務も推奨しています。
働き方は『自由に楽しく効率よく』。社員一人ひとりが自分にマッチした働き方を見つけることができます。
今回のアドベントカレンダー企画では、そんなネクストモードの働き方＝フルリモート業務を実現するためにSaaSをどのように活用しているか、
また働き方のベースとなっている『ネクストモードのカルチャー』をどのように絡めて日々業務を遂行しているかについて
メンバー個々のユースケースや実践例、想いなどを様々な切り口でご紹介します。
はじめに
本記事では、日々の Okta 運用時に発生する、パスワードベースの不正なサインイン試行への対処方法を紹介します。攻撃者がブルートフォースやリスト攻撃を用いてパスワード認証を繰り返し試行すると、ユーザーアカウントが意図せずロックアウトされ、利用者の業務に支障をきたす可能性があります。
この問題への対処方法として、本記事では Okta におけるユーザーアカウントのロックアウトの仕組みと、Okta が提供する多要素認証 (MFA) やその他のセキュリティ対策機能を活用し、Okta をより安全かつ利便性の高い認証基盤として利用するためのアプローチをまとめました。
不正なサインイン試行とアカウントロックアウト
Okta では、パスワードベースの不正なサインイン試行に対する基本的な対策として、規定回数以上のサインイン失敗後に認証試行をブロックする、ユーザーアカウントのロックアウト機能を提供しています。本機能はデフォルトで有効になっていますが、パスワードポリシーを編集することにより、回数の設定やロックアウト後の挙動など、より詳細な設定が可能です（下図）。
パスワードポリシーには、Okta Admin Console のセキュリティ > Authenticator > セットアップから、パスワードのアクション > 編集を選択することでアクセス可能です。
ユーザーアカウントのロックアウトは、不正なサインイン試行への対策として有効な第一歩と言えます。その一方で、ロックアウトはあくまでも事後的な対処となるため、パスワードベースの攻撃そのものを防ぐことはできません。また、攻撃により意図せずロックアウトが発生すると、利用者の業務に支障をきたす恐れがあります。
そのため、追加対策として、パスワードを認証方法として維持しつつ、その優先度を下げた認証フローを構築し、さらに不審な認証試行をプロアクティブにブロックすることで、攻撃者による悪意のあるサインイン試行を防ぐことが重要となります。
不正なサインイン試行への対処方法
本記事では以下、不正なサインイン試行への対策のため Okta の基本的な機能で実現可能な5つのアプローチを紹介します:
- パスワード以外の認証方法を利用する
- 多要素認証を構成しパスワードを他の認証方法の後に要求する
- デバイストラストポリシーを構成する
- Okta ThreatInsight を利用する
- CAPTCHA 統合を利用する
このうち、1, 2 はサインイン時に認証方法としてのパスワードのプライオリティを下げる方法（1 はそもそもパスワードを利用しない方法）、3, 4, 5 はサインイン試行自体をブロックする方法となり、それぞれを組み合わせて使うことも可能です。
1. パスワード以外の認証方法を利用する
本記事ではパスワードを認証方法として利用することを前提としていますが、まず、パスワードレス認証について触れておきます。パスワードを使用せず、代わりにワンタイムパスワード (OTP) などの所有要素や Okta Verify、FIDO2 などの生体認証に基づく認証方法を用いることで、パスワードベースのサインイン試行を根本的に防ぐことが可能です。
Okta ではパスワードレスや多要素認証を実現するために多様な認証方法をサポートしていますが、詳細については以下の公式ドキュメントをご参照ください。
実際は運用上の要件から完全なパスワードレス化が難しいケースも多いですが、有効な選択肢の一つとして検討に含めておくことをおすすめします。
2. 多要素認証を構成しパスワードを他の認証方法の後に要求する
パスワードに加えて、所有要素や生体認証を組み合わせた多要素認証を構成します。この際、デフォルトではサインイン時にパスワード入力が最初に求められますが、パスワード以外の認証を先に実施し、その後でパスワードを要求するように設定を変更することができます。
この認証順序の変更により、攻撃者は最初の認証方法を突破できずにパスワード認証のステップまで到達できなくなるため、連続した不正なパスワード試行とアカウントのロックアウトを未然に防ぐことが可能です。
以下では、Okta でこれを実現するための2つの方法を紹介します。
2-1. 「パスワードベースの攻撃から保護」の有効化による方法
Okta のセキュリティ機能「パスワードベースの攻撃から保護」で「MFA時にパスワードの前に所有要素を求める」を有効化することで、パスワードなどの知識要素の入力前に、所有要素による本人確認を要求することができます（下図）。
本機能は Okta Admin Console のセキュリティ > 一般のパスワードベース攻撃から保護からアクセスできます。
2-2. 認証方法チェーンによる方法
前述の方法は Okta org 全体の認証ポリシーに影響しますが、認証方法チェーン (authentication method chain) を利用することで、個別の認証ポリシーのルールで認証方式の順序を明示的に制御することが可能です。これにより、認証フローをより柔軟にカスタマイズすることができます。
下図は、最初に FIDO2（生体認証）による認証を求め、成功後にパスワードを要求する認証フローを構成するためのルールの例となります。
認証方法チェーンの設定方法詳細については弊社の下記ブログ記事をご参照ください。
【Okta】Authentication method chainを使って認証方法を完全に制御する！｜Nextmode Blog
なお、2024年12月現在、認証方法チェーンは早期アクセス (Early Access; EA) の機能として提供となっている点、ご留意ください。本機能を利用する場合、設定 > 機能より「認証方法チェーン」を有効化してください。
3. デバイストラストポリシーを構成する
認証ポリシーにおいてデバイストラストポリシーを構成することで、信頼できる端末と信頼できない端末を判別し、端末の信頼性に基づいて認証方法の要求前にサインイン試行をブロックすることができます。
Okta の認証ポリシーのルールでは、デバイストラストを実現するために以下の2つの条件を使用します（下図）:
- Okta Verify のインストール・登録状態を確認する「デバイスの状態」
- クライアント証明書の配布状態を確認する「デバイス管理」
Okta Verify の詳細については以下の公式ドキュメントをご参照ください。
Okta Verify Authenticatorを構成する | Okta
基本的には、「デバイスの状態」を登録済みに設定するだけで、Okta Verify が未登録の端末からのアクセスを効果的にブロックできます。この簡易的な設定だけでも十分な効果が得られるケースが多いでしょう。
ただし、運用上の制約などにより Okta Verify を導入できない端末に対しては、上記のデバイストラストポリシーを構成できません。このような場合でも、「ユーザーのIP」条件で社内ネットワークのアドレスを指定するなど、Okta の他の条件設定で柔軟に対応できます。さらに、次に説明する Okta ThreatInsight と組み合わせることで、よりセキュアな運用も可能になります。
4. Okta ThreatInsight を利用する
Okta のセキュリティ機能 Okta ThreatInsight を有効化することで、Okta が顧客をまたいで収集・分析したデータに基づき、不審な IP アドレスからのサインイン試行を検知・記録・ブロックできます。
下図は、不審な IP アドレスからのサインイン試行をブロック・記録する設定例です。この設定では、事前に登録された社内 IP ゾーンからのアクセスは除外されます。
Okta ThreatInsight は Okta Admin Console からセキュリティ > 一般 から Okta ThreatInsight の設定よりアクセス可能です。また、記録されたログについては、レポート > System Log よりsecurity.threat.detected のイベントタイプとして確認できます。
Okta ThreatInsight の詳細については下記公式ドキュメントをご参照ください。
5. CAPTCHA 統合を利用する
Okta では CAPTCHA 統合によりサインインフローに CAPTCHA チャレンジを組み込むことができます。これにより、ボットなどによる自動化されたサインイン試行を防ぐ、という側面からの対策も可能です。CAPTCHA そのものの説明については、下記 Okta 公式サイトの情報をご参照ください。
CAPTCHAとは？CAPTCHAの種類と仕組み | Okta
Okta の CAPTCHA 統合では、以下の CAPTCHA サービスをサポートしています。
- reCAPTCHA v2 https://www.google.com/recaptcha/about/
- hCaptcha https://www.hcaptcha.com/
CAPTCHA 統合の有効化には、CAPTCHA タイプの選択、上記サービスから事前に取得したサイトキーと秘密鍵の入力が必要です。下図は本記事で対象としているサインインを対象とする場合の設定例ですが、サインアップ、パスワードリセットの操作についても対象とすることが可能です。
CAPTCHA 統合は Okta Admin Console からセキュリティ > 一般 のCAPTCHA 統合よりアクセス可能です。
CAPTCHA 統合の詳細については下記公式ドキュメントをご参照ください。
まとめ
本記事では、Okta におけるパスワードベースの不正なサインイン試行への対処方法を紹介しました。これらの機能を運用要件に合わせて組み合わせることで、より強固なセキュリティ対策を実現することが可能です。
今回は Okta の基本的な機能で実現できる方法に焦点を当てましたが、EDR と連携した認証制御など、より高度な認証制御の選択肢も用意されています。
本記事が皆さまの Okta 運用のお役立ていただければ幸いです。
明日12日目はおもちさんによるエントリとなります。お楽しみに！
