こんにちは、Azure Identity サポート チームの 竜 です。
本記事は、2022 年 12 月 15 日に米国の Azure Active Directory Identity Blog で公開された End user passwordless utopia を意訳したものになります。
Azure と Azure Active Directory (Azure AD) で利用できる技術はたくさんありますが、全体像を把握し、それらがどのようにエンドユーザーのユーザー体験に作用するという全体像については見逃しがちです。
Azure AD で利用できる技術には以下があります:
- Azure AD
- 多要素認証 (MFA: multi-factor authentication)
- パスワードレス認証
- 条件付きアクセスおよび認証強度
- デバイス登録
- プライマリ更新トークン (PRT: Primary Refresh Token)
- エンタープライズ アプリ / シングル サインオン (SSO)
- Intune
- Autopilot
- 一時アクセス パス
上記の中には、利便性を促進する機能もあればセキュリティを強化する機能もあります。これらの技術を使用することで、ユーザーの認証負担を軽減し、セキュリティを強化することができます。
弊社の目標は、パスワードや資格情報のプロンプトや従来の MFA プロンプト無しに、安全性を維持しながらデバイスを使用し、企業のアプリケーションやデータにアクセスする方法を示すことです。
まずは、弊社が取り組んでいる 2 つの問題からお話しします。
1. 認証疲労
私たちは、ユーザーとして、20 年以上にわたり、デバイスがユーザー名とパスワードの入力プロンプトを表示する度に、それらを入力するよう促されてきました。これは、まさに攻撃者がユーザーをフィッシングするのに利用している手法です。攻撃者は、偽のサインイン ページに誘導するリンクをユーザーに送り、そこでユーザーが認証情報を入力するよう促します。
2. MFA 疲労
Microsoft の 統計 によると、Azure AD で侵害されたアカウントの 99.9% は、MFA を強制していないアカウントでした。
MFA が構成されているエンド ユーザーであっても侵害するため、攻撃者はその手法を変更せざるを得なくなりました。ユーザーは、携帯電話に表示された MFA プロンプトに従って行動することが想定されます。攻撃者は、この行動を悪用してアカウントを侵害しようとします。ユーザーの認証情報が漏洩し、攻撃者が狙いすましたタイミングで多数の MFA プロンプトをユーザーに送信すると、ユーザーが誤って「承認」をクリックしてしまう可能性があります。これは、MFA フィッシングとして知られています。
Microsoft Authenticator の 番号の一致機能 により、この問題を軽減することができます。MFA プロンプトが表示されたら、ユーザーはコンピュータの画面に表示された番号を認証アプリのプロンプトに入力します。コンピューターの認証画面上にプロンプトが表示されていないのにも関わらず、Authenticator アプリ上でこのプロンプトが表示された場合、ユーザーは番号を入力できないため、ユーザーが誤って「承認」することとはできず、MFA フィッシングに遭う可能性は大幅に減少します。
解決方法
Azure AD に登録されたクラウド アプリや、アプリケーション プロキシを経由したオンプレミス アプリの利用に、パスワードレス認証を組み合わせて使用することで、これらの問題に対処できます。
企業が管理するデバイスからであれば、ユーザーはユーザー名やパスワードの入力やを求められたり、携帯電話で MFA のプロンプトや電話、SMS による認証を行うことなく、これらのアプリケーションにアクセスすることができます。
詳細の説明の前に、このシナリオを図で表したものが以下です。「ハイブリッド Azure AD 参加」および「Azure AD 参加」したデバイスのどちらでも同じ流れとなります。
注: 今回の説明では、ドメイン コントローラーへの認証フローは省略します。
クラウド アプリケーションにアクセスする際の SSO フローの概要:
| ステップ | 説明 |
|---|---|
| A | ユーザーが Windows Hello for Business を使用して、PIN、生体認証、または FIDO2 キーを使用し、デスクトップまたはノート PC にサインインします。 |
| B | コンピューターがユーザーを認証すると、次に Azure AD へのサインインを試みます。デバイスがハイブリッド Azure AD 参加しているか、Azure AD 参加しているかにより、この順序は異なります。Azure AD がユーザーを認証すると、MFA クレームを含むプライマリ更新トークンが発行されます。 |
| C | ユーザーが、Azure AD を IDP (ID プロバイダー) として使用しているアプリケーションにアクセスすると、Azure AD に誘導されます。この誘導処理では、ユーザーは特段の操作を必要とせず、動作も透過的なものになります。デバイスは既に Azure AD に登録されているため、サインイン時に使用する Microsoft Online の URL がレジストリに保存されています。これらの URL が、SSO の際に誘導される Azure AD の URL と一致するため、ブラウザーこれをもって SSO を開始し、PRT の使用を試みます。 |
| D | 次に、条件付きアクセスがサインインを評価します。このアプリケーションを MFA で保護するポリシーが適用されている場合、PRT にすでに MFA クレームが含まれているため、ユーザーは MFA を行う必要はありません。 |
| E | ここで、Azure AD は、アプリにアクセスする際に必要となるトークンをユーザーに発行します。このトークンは、アプリケーションの構成に応じて、SAML または OAuth のトークンとして発行されます。 |
| F | ユーザーは、これらのトークンをアプリケーションに提示し、アプリケーションにサインインします。 |
ステップ B の詳細: 初回サインイン中の PRT 発行
ステップ C の詳細: PRT を使用したブラウザー SSO
動作の詳細
デバイスの登録
ハイブリッド Azure AD 参加または Azure AD 参加 (デバイス登録) が、Windows Hello for Business または FIDO キーを使用するための前提条件です。デバイスを Azure AD に登録するのに、様々な方法で登録プロセスを開始するようにポリシーを適用することができます。
パスワードレス/MFA
Windows Hello for Business や FIDO2 キーは、パスワードの代わりに、デバイス上で強力な二要素認証を行います。この認証は、デバイスに紐づけられたユーザーの資格情報で構成されており、生体認証または PIN が使用されます。Windows Hello for Business の詳細については このリンク を、FIDO2 のログオンについては このリンク をご参照ください。
ログオンを完了するためには、キーのデータを含む実際のデバイスと、そのキーへのアクセスを解除するための PIN または生体認証の 2 つの要素が必要です。この処理には、私たちが持っているもの (コンピューター)、私たちが知っているもの (PIN) または私たち自身 (生体認証) という複数要素が必要となります。なぜパスワードより PIN の方が優れているかについては、詳しくは こちらの公開情報 をご覧ください。
エンタープライズ アプリ/SSO
デバイスが Azure AD に参加すると、いくつかの URL がレジストリに追加されます。これらの Azure AD の URL がサインインの際に使用されます。ブラウザーから Azure AD に登録されたアプリケーションにアクセスし、さらに そのブラウザーが Azure AD SSO をサポートしており (Edge、Office 用の拡張機能付きの Chrome, Firefox v91 以上)、かつ 誘導された Azure AD の URL がレジストリ内の URL と一致する場合、ブラウザ－はデバイスへのサインイン時に取得したプライマリ更新トークンを使用して、ユーザー操作を必要とせずに認証を試行します。これについては、PRT を使用したブラウザー SSO で詳しく説明しています。
この場合、ユーザーには、サインイン時にプロンプトは表示されません。
ユーザーが Azure AD に似た偽のウェブサイトに誘導され、ユーザー名とパスワードの入力プロンプトが表示されたとしても、この URL はレジストリに保存されている URL とは異なるため、SSO の処理は開始されません。偽のウェブページには SSO を受け入れるために必要なエンドポイントがないため、SSO の処理が開始されることはありません。本物の Azure AD のサインイン ページでは、パスワード プロンプトは表示されません。
条件付きアクセス
次に、条件付きアクセスが認可の要求を評価します。ユーザーやアプリに対して構成された条件付きアクセス ポリシーのアクセス制御に従って、MFA、ハイブリッド Azure AD 参加、および準拠しているデバイスなど、複数のアクセス権付与の要件 (コントロール) を設定することができます。MFA やハイブリッド Azure AD 参加など、 1 つまたは複数のコントロールを必要とすることもできます。Azure AD に登録されているデバイスは、ハイブリッド Azure AD 参加の条件を満たし、プライマリ更新トークンに存在する MFA クレームは MFA の条件を満たすことができます。
また、認証強度 という条件付きアクセスの新しいプレビュー機能を使って、会社のデータおよびアプリにアクセスする際に、Windows Hello for Business のようなパスワードレスの認証や FIDO2 のようなフィッシング耐性のある MFA を要求することも可能です。
これらの技術を用いることで、以下のようなことが実現可能となります:
- ユーザーがアカウントの正当な保持者であり、複数の認証要素を用いてコンピューターにログオンしたことを証明する。
- 管理されたデバイスにサインインする。
- 同じアプリに、普段から使われる場所からアクセスする。
- ユーザーのセキュリティ状態が変更されていないことを確認する (アカウントが無効になっていない、パスワードがリセットされていない状態)。
- 流出した資格情報にそのユーザーの情報が含まれていないことを確認する。
ここまでのことから、ユーザーに頻繁に再認証させる必要性はないというのがお分かりいただけると思います。
注: 上記の議論は、企業が管理するデバイスにのみ当てはまります。BYOD や、その他のサポートされているデバイスでは引き続き条件付きアクセス ポリシーがトリガーされるため、MFA やその他のコントロールを満たす必要があります。
まとめ
既に多くのお客様がこれらの技術を利用しています。恐らく、皆さまの組織でも、気付かないうちにこれらの構成によってもたらされるセキュリティ強化の恩恵を受けています。上記の情報を理解したうえで、ユーザーに対して、会社のデバイスから会社のアプリケーションやサービス、データにアクセスする際に、限られた状況を除き、パスワードが要求されることはほとんどないということができます。ユーザーがパスワードを使用しなければ、パスワードが漏えいする可能性は大幅に減少します。
サイバー セキュリティのトレーニングでは、エンド ユーザーに対し、ユーザーが資格情報を入力するたびに、使用しているサイトが本物であるか、URL に疑わしいものがないか、有効な証明書などでサイトが安全であるかを確認する責任を常に課しています。MFA のプロンプトが表示された場合にも、ユーザーが自ら開始した MFA であることを確認する責任を課しています。
ユーザーがこれらの複雑さから解放され、よりシンプルな確認で済むよう共に取り組んでいきましょう。もしユーザーが自身の資格情報を入力させるようなプロンプトを見かけたら、認証を行わず、社内の IT に報告するように依頼しましょう。もし MFA のプロンプトが突然表示されたとしたら、おそらくユーザーが開始した MFA ではないので、認証を行わず社内 IT に報告するように依頼しましょう。すべてのサインインの試行とすべての MFA を確認するよりも、このような方法の方が簡単なはずです。
これらの技術により、私たちのセキュリティが向上します。ユーザーがフィッシングの被害者になる可能性を減らすことができるのです。Intune、Autopilot、Temporary Access Pass または FIDO2 キーを組み合わせれば、ユーザーは会社から支給された新しいノートパソコンを箱から取り出し、デスクトップを開いて、パスワードを知ることなく会社のアプリケーションやデータにアクセスし始めることができるようになります。これでパスワードのない世界が実現できます。
Tarek Dawoud
Principal Program Manager, Product Management
Twitter: @cybertarek
※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。