こんにちは、ヘルプデスクの織田です。
2022年2月ごろ、Azure AD 証明書ベース認証 (Azure AD CBA) がパブリックプレビューとしてリリースされたタイミングで以下の記事を投稿させていただきました。
前回の記事：Azure AD 証明書ベース認証を試してみた
そんな Azure AD CBA ですが、2022年10月に晴れて GA (一般提供) されました。
なお、前回の記事を投稿してから1年も経っておりませんが、Azure AD CBA は、様々な機能アップデートが行われております。
そこで、今回は、Azure AD CBA の今に迫り、Windows デバイス と iPhone デバイスでの認証動作を確認していきたいと思います。
なお、今回の検証はグループ会社であるサイバートラスト社が提供している証明書発行サービス「サイバートラスト デバイス ID (以降、デバイス ID)」を利用しております。
参考サイト：サイバートラスト デバイス ID
前回記事を投稿した2022年2月以降にリリースされた Azure AD CBA に関する主な機能アップデートとしては、以下の通りです。
左右にスクロールしてご覧ください。
| 項目 | リリース年月 | 新機能およびアップデート内容 |
|---|---|---|
| Windows スマートカードログオンのサポート | 2022年7月 | スマート カード上の X.509 証明書を使用して、Windows サインイン時に Azure AD に対して直接認証できるようになりました。 |
| モバイルデバイス (Android、iOS) のサポート | 2022年7月 | Android、および iOS を実行するデバイスにおいて、Azure AD CBA を利用した認証が実現可能となりました。 |
| 管理エクスペリエンスの向上 | 2022年7月 | これまでは、証明書機関の登録等は、PowerShell を利用して行う必要がありましたが、Azure ポータルを利用して、以下の設定が可能となりました。 ●証明機関 (ルート CA とすべての中間 CA) を Azure AD にアップロードする ●Azure AD にアップロードされたすべての信頼された証明機関を表示する ●CA が有効でない場合は削除する ●証明書の有効期限に基づいて証明書の有効性を簡単に確認 |
| ADFS から Azure AD CBA の段階的移行 | 2022年7月 | ADFS を利用していたフェデレーションユーザーが、Azure AD CBA を利用したクラウド認証に切り替えるオプションとして、[段階的ロールアウト] が利用可能となりました。 |
| モバイルデバイス (Android、iOS) におけるハードウェアセキュリティキーの認証サポート | 2022年11月 | ハードウェア セキュリティ キーの証明書を使用して、iOS および Android デバイスでの Azure AD CBA を利用した認証が実現可能となりました。 |
参考サイト：Azure AD 証明書ベースの認証 (CBA) の新しい機能強化を確認する - (2022年7月公開)
参考サイト：モバイルでの Azure AD 証明書ベースの認証 (CBA) - (2022年11月公開)
1年も経たないうちに様々な機能改善や新機能がリリースされていることがわかります。
特にスマートカードを利用したログオンやモバイルデバイスにおけるハードウェアセキュリティキー (YubiKey) との組み合わせによる認証は、セキュアな認証を実現するにあたり、今後重要な役割を果たす可能性を秘めていると考えております。
なお、これらの機能は現時点ではいくつか制限もあり、すぐに実装することは中々ハードルが高いと考えておりますので、今後の更なる機能アップデートを注視しながら、良いタイミングで改めて皆様に共有したいと思います。
今回は、サイバートラスト社がサービスとして提供する [デバイス ID] を活用しました。
ご利用開始までの流れについては以下のサイトを是非ご確認ください。
参考サイト：サイバートラスト デバイス ID ご利用開始までの流れ
デバイス ID は、端末識別情報 (MAC アドレス、IMEI、UDID、シリアル番号、Wi-Fi Mac) を遠隔で確認した上で、管理者が許可した端末にデバイス証明書をエクスポート出来ない状態で登録できるため、証明書管理がセキュアに行うことができます。
また、Windows 端末だけではなく、macOS、iOS、Android 等、様々な OS に対応しているのも特長になります。
Azure AD CBA でサポートされているサポートされている X.509 ユーザー証明書の認証フィールドは、以下の通りとなっております。
● SAN Principal Name > userPrincipalName
● SAN Principal Name > onPremisesUserPrincipalName
● SAN RFC822Name > userPrincipalName
● SAN RFC822Name > onPremisesUserPrincipalName
● SubjectKeyIdentifier > CertificateUserIds
● SHA1PublicKey > CertificateUserIds
[SubjectKeyIdentifier > CertificateUserIds] と [SHA1PublicKey > CertificateUserIds] は、前回の記事を投稿した以降に追加された設定項目だと思われます。
今回の検証では、デバイス ID の UPN 付きオプションで、[SAN RFC822Name > userPrincipalName] を利用することにします。
デバイス ID の証明書発行は、デバイス ID 契約者専用の管理ポータルで行い、ユーザーは端末に証明書をインストールします。
なお、この証明書発行に関わる申請作業を行えるのは、管理者向けに発行されるオペレーター証明書をインストールしたデバイスのみとなっております。
これにより、不用意にデバイス ID で証明書を発行するリスクをなくす仕様となっております。
また、デバイス ID ではルート証明書も提供されます。ルート証明書と CRL 配布ポイントは、次に説明する認証局の構成で使用することになります。
デバイス ID では今回紹介させていただいた方法以外に、Intune と連携してクライアント証明書を配付するオプション (SCEP証明書オプション) もございます。
SCEP 証明書オプションを利用することで、Intune 登録デバイスに対する証明書発行を自動化し、証明書発行の作業コストを大幅に削減できるので、非常にお勧めです！
次は、Azure AD CBA の構成について、説明していきたいと思います。
Azure AD CBA の構成を行っていきたいと思います。
前回の記事と重なる部分もございますが、認証局の構成が以前と比べて容易になっておりますので、この点に注目いただければと思います。
Azure AD CBA がパブリックプレビューとしてリリースされた当初は、PowerShell を利用して、認証局を構成する必要がありましたが、現在は不要となりました。
最新の構成手順に沿って、認証局を構成していきたいと思います。
＜設定手順＞
1. Azure AD 管理センター (https://aad.portal.azure.com/) にサインインします。
2. [Azure Active Directory] - [セキュリティ] を開きます。
3. [証明機関] - [アップロード] を開きます。
4. 利用するデバイス ID のルート CA 証明書を指定し、証明書の失効リストの URL を設定し、[追加] を選択します。
※ ルート CA 証明書はデバイス ID を発行、展開されたルート CA 証明書を利用し、証明書の失効リストの URL はデバイス ID で発行された証明書より確認して設定しました。
5. 証明書のアップロードが完了すると、Azure AD 管理センターの [証明機関] にアップロードしたルート CA が登録されます。
以上で認証局の設定は完了です。非常に簡単に設定できるようになっていました。
次は、Azure AD CBA の認証ポリシーを構成していきたいと思います。
次に、デバイスが Azure AD CBA を利用できるように、Azure AD CBA の有効化と認証ポリシーの構成方法をご紹介いたします。
こちらは、前回のブログ投稿から設定の方法自体は変わっていないため、おさらいとなります。
＜設定手順＞
1. Azure AD 管理センターの [Azure Active Directory] – [セキュリティ] を開きます。
2. [認証方法] - [ポリシー] より、[証明書ベースの認証] を開きます。
3. [有効化およびターゲット] のタブより、[有効にする] をオンにし、ターゲットとするグループを設定後、[保存] をクリックします。
4. [構成] タブで認証規則を構成して、[保存] をクリックします。
以上で設定完了です。今回は、規則として信頼されたルート証明機関を設定しました。
なお、認証規則の詳細は、以下のサイト (手順3, 4) を参考にしていただければと思います。
参考サイト：Azure AD 証明書ベースの認証を構成する方法
次はケース別の認証動作を確認していきたいと思います。
ケース別の認証動作を確認してみたいと思います。
なお、端末に証明書 (デバイス ID) がインストール済みであることが前提での検証結果となりますので、あらかじめご承知おきください。
もっともシンプルなパターンで、Windows デバイス にて、ブラウザから Microsoft 365 にアクセスした場合の動作を確認していきたいと思います。
なお、Azure AD CBA の認証規則は、単一要素認証で構成しております。
＜動作確認＞
はじめに、証明書がインストールされていることを確認します。
Microsoft 365 のポータルサイトにアクセスし、アカウント情報を入力して、[次へ] をクリックします。
[証明書またはスマートカードを使用する] をクリックします。
証明書選択画面が表示されますので、インストールしたデバイス ID の証明書を選択し、OK をクリックします。
[サインイン状態を維持しますか？] と表示されるので、[はい] をクリックします。
サインインできました。
「毎回、証明書選択するのは少し面倒だな」という気持ちになったので、 ここで、もう一工夫として、認証に利用する証明書 (デバイス ID) を強制する設定を追加します。
実施方法としては、以下のレジストリキー、または MDM ポリシーを構成することで実現できます。
●レジストリキー
左右にスクロールしてご覧ください。
| レジストリパス (デバイス制御の場合) | HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft \Edge\AutoSelectCertificateForUrls |
|---|---|
| レジストリキー名 | 1 |
| 値の種類 | REG_SZ |
| 値の数値 ※ ISSUER 以降は、Azure AD CBAで設定した CA の CN 情報等を指定します。 | {"pattern":"https://certauth.login.microsoftonline.com", "filter":{"ISSUER":{"CN":"～CA"}}} |
●MDM ポリシー (Intune - 構成プロファイル - 設定カタログ)
左右にスクロールしてご覧ください。
| パス (カテゴリー) | Microsoft edge – コンテンツ情報 |
|---|---|
| 項目 | Automatically select client certificates for these sites |
| Enable/Disable | Enable |
| 設定値 ※ ISSUER以降は、Azure AD CBAで設定した CAのCN情報等を指定します。 |
{"pattern":"https://certauth.login.microsoftonline.com", "filter":{"ISSUER":{"CN":"～CA"}}} |
Microsoft 365 のポータルサイトにサインインしてみると、証明書選択画面の回避できました。
なお、こちらの強制ポリシーは Microsoft Edge のポリシーであり、他のブラウザでは動作しないのでご注意ください。
また、証明書認証時の接続先 (URL) が変更になった場合など、仕様変更があった場合は動作しなくなる可能性があります。
参考サイト：Azure AD 証明書ベースの認証を構成する方法 (手順 5：構成をテストする)
次はモバイルデバイスの認証動作を確認するため、iPhone デバイスにおいて、Safari ブラウザから Microsoft 365 にアクセスした場合の動作を確認していきたいと思います。
なお、Azure AD CBA の認証規則は、単一要素認証で構成しております。
＜動作確認＞
はじめに、デバイス ID の証明書が iPhone にインストールされていることを確認します。
Safari ブラウザで、Microsoft 365 のポータルサイトにアクセスし、アカウント情報を入力して、[次へ] をタップします。
[証明書またはスマートカードを使用する] をタップします。
証明書選択画面が表示されるので、インストールしたデバイス ID の証明書を選択します。
サインインに成功しました。
モバイルデバイス (iOS、Android) の Azure AD CBA は現状では機能も限られており、活躍できるシーンが限られてくると感じています。
しかしながら、これからも続々と機能アップデートされていくと思われますので、期待して待ちましょう！
参考サイト：iOS での Azure Active Directory の証明書ベースの認証
これまでは、単一要素のシンプルな認証動作を確認していきましたが、より実践的な認証制御の検討として、
[認証強度 (プレビュー) ＋ 条件付きアクセスポリシー] を利用して、 Azure AD CBA 認証を強制する動作を確認していきたいと思います。
条件付きアクセスポリシーは広く知られている機能であり詳細な説明は不要かと思いますが、
認証強度 (プレビュー) は、2022年10月にテクニカルプレビューとしてリリースされた機能であり、知らない方も多いと思います。
認証強度 (プレビュー) は管理者が認証方法を組み合わせで指定する機能で、条件付きアクセスポリシーで利用することで、より機密性高いリソースへアクセスする際は、Azure AD CBA のようにフィッシング耐性の強い認証要求する等、様々な認証要件への対応を実現します。
上記の3つのビルトインポリシーに加えて、カスタムでポリシーを作成することも可能です。
参考サイト：Azure Active Directory の認証強度の概要 (プレビュー)
今回の検証では、特定の Windows 端末に対して、認証強度 (プレビュー) を利用した条件アクセスポリシーを構成し、
Azure Portal 接続時に Azure AD CBA、FIDO 2、Windows Hello for Business といったフィッシングに耐性がある認証を強制させた場合の動作を確認していきたいと思います。
条件付きアクセスポリシーに指定する認証強度 (プレビュー)は、ビルトインの [Phishing-resistant MFA (フィッシングに強い)] を利用します。
[Phishing-resistant MFA (フィッシングに強い)] で有効な Azure AD CBA の認証の保護レベルは [多要素認証] にする必要があります。
そして、条件付きアクセスポリシーを構成して、準備完了です。
＜動作確認＞
はじめに、デバイス ID の証明書がインストールされていることを確認します。
Azure Portalにアクセスし、アカウント情報を入力して、[次へ] をクリックします。
ここから、認証方法の違いによる動作の違いを確認していきたいと思います。
●Azure AD CBA 認証を行った場合 (条件付きアクセスポリシーの要件を満たしている認証)
[証明書またはスマートカードを使用する] をクリックします。
証明書選択画面が表示されるので (構成プロファイルでスキップ可能)、インストールしたデバイス ID の証明書を選択し、OK をクリックします。
[サインイン状態を維持しますか？] と表示されますので、[はい] をクリックします。
サインインできました。
サインインログでも、設定した条件付きアクセスポリシーが [成功] と判定されていることがわかります。
●パスワード 認証を行った場合 (条件付きアクセスポリシーの要件を満たしていない認証)
パスワードを入力して、[サインイン] をクリックします。
構成した条件アクセスポリシーの制御により、セキュリティ情報の要求画面が表示されますので、[次へ] をクリックします。
多要素認証 (MFA) が要求されますので、フィッシング耐性の強い認証に含まれない、SMS 認証を選択してみます。
認証コードを入力して、[検証] を選択します。
アカウントのセキュリティ保護の画面に証明書ベースの認証が必要であるとメッセージが表示され、アクセスがブロックされる動作になりました。
※ 現在の認証設定画面が表示される場合もあります。
サインインログでも、設定した条件付きアクセスポリシーが [失敗] と判定されていることがわかります。
今回の検証は以上です。
[認証強度 (プレビュー) ＋ 条件付きアクセスポリシー] の制御を活用することで、ADFS で実現していた証明書ベースの認証と同等、もしくはそれ以上の制御が実現できるようになったと感じました。
そして、現在広く普及している多要素認証 (MFA) が不正アクセスの排除において重要な役割を担っておりますが、
「Adversary-in-the-Middle(AiTM) (※)」のような攻撃も出てきており、これらに対応するには、よりフィッシング耐性をもつ証明書ベースの認証が必要不可欠になってくると思います。
そういった面でも、[認証強度 (プレビュー) ＋ 条件付きアクセスポリシー] の制御は、Azure AD CBA とともに高度化するセキュリティ攻撃対策として重要な仕組みになってくると思いますので、活用を検討してみてはいかがでしょうか。
※ Adversary-in-the-Middle (AiTM)
Microsoft のセキュリティ研究チームが、大規模なフィッシングキャンペーンである「Adversary-in-the-Middle (AiTM)」について発表しています。詳しくは以下のサイトをご参照ください。
今回は、GA (一般提供) された Azure AD CBA の動作を確認してきました。
できることも広がっており、脱 ADFS だけではなく、新たな認証方式の確立に重要なオプションとして含まれてくると感じました。
Azure AD は様々な認証オプションがあり、どう組み合わせればよりセキュアになるかをもっと考えていかなればいけないと検証を通じて感じましたので
私も Azure AD に負けないようにアップデートしていきたいと思います！
(認証まわりのセキュリティ強化を検討していきたいという方がいらっしゃれば、是非、弊社にご相談ください！)
私は今回の検証で、はじめて [デバイス ID] を利用しましたが、
様々な OS へ対応していること、Intune を利用した証明書の一括配付等、様々なオプションがある点が有り難いと感じました。
なお、フィッシング耐性をもつ証明書ベースの認証を活用するにあたり、証明書が不用意に発行されるリスクが懸念される方もいらっしゃるかと思いますが、
今回、検証した [デバイス ID ] では、証明書配付の段階から組織の管理者が厳格に管理すること可能であり、この点のセキュリティも確保できているといえます。
是非、[Azure AD CBA ＋ デバイスID ] という組み合わせの実装を検討してみるのはいかがでしょうか。
今回は以上となります。また、お会いしましょう！
関連ページ
「Enterprise Mobility + Security 導入支援サービス」はこちら |
