前回の記事では、[条件付きアクセス]でCBAを必須とする認証強度を作成・設定し、パスワードなど他手段によるログインをさせないようにしました。しかし、この方法では証明書を使った単要素認証であることには変わりはないので（デバイスへのアクセス時のパスコードや、Face ID / Touch IDといった生体認証との組み合わせを前提）、今回の記事ではEntra IDでのID・パスワード＋クライアント証明書の多要素認証の設定を行います。

Entra IDの管理者設定

Entra IDの設定内容は、前回の記事の「Azure AD CBAの設定」内の手順⑤までは同じです。
「Microsoft Entra ID (Azure Active Directory)」＞「セキュリティ」＞「認証方法」＞「証明書ベースの認証」まで進めた後の変更点を解説します。

①   [有効化およびターゲット]にて、今回は特定のグループのみを対象にすることにしました。
これにより、証明書をインポートしたことを確認した後に、ユーザーをそのグループに参加させるといったことができるかと思います。

②   [構成]では、新たに[CRL検証を必須にする (推奨)]、[発行者ヒント]設定が追加されました。
弊社の「マネージドPKI Lite byGMO」ではCRL公開を行っているので、[CRL検証を必須にする (推奨)]にチェックをします。
[発行者ヒント]は、Entra IDに設定したCA証明書をTLSセッションハンドシェイク時にクライアントに送信させる機能なので、Onにします。
※クライアントブラウザにおいて、無関係のクライアント証明書が表示・選択されなくなります。

③   同画面[認証バインド] > [保護レベル]を「単一要素認証」にします。
「多要素認証」を選択すると、証明書による認証が成功するだけで「多要素認証をした」とみなされてしまうようなので、ID・パスワードとクライアント証明書による認証を必須とする今回の目的には不適です。

同画面[ユーザー名バインド]は、こちらの記事で記載のように高アフィニティバインドを設定します。
低アフィニティバインド（証明書のサブジェクト代替名フィールドにユーザープリンシパル名やメールアドレスを入れて、それとEntra IDのユーザー属性をバインドする方法）よりも、証明書とEntra IDのユーザアカウントの結合が強くなり、結果として不正な証明書を利用してのなりすましの可能性を低減することが可能です。
※デメリットとしては、ユーザーIDのCertificateUserIds属性の設定が初回登録時・証明書更新時ともに煩雑になることが挙げられます。

これら設定をしたうえで保存します。

④   「セキュリティ」＞「条件付きアクセス」＞「ポリシー」に進み、「+新しいポリシー」をクリックします。

[割り当て] > [ユーザー]には、先ほどの証明書認証用グループに割り当てます。

⑤   [ターゲットリソース]は、今回、Entra IDで利用頻度が最も高いと思われるOffice 365を選択しました。このようにEntra IDで認証連携をするアプリケーションを選択します。

⑥今回、[ネットワーク]は未構成にしましたが、特定の発信元IPアドレス（例：オフィスネットワーク）からのアクセスは本ポリシーを適用しない、といったことも可能でした。

⑦   今回、[条件]も未構成にしましたが、デバイスプラットフォームによりこのポリシーの適用可否も決められるようです。

⑧   以上、追加したら[ポリシーの有効化]をOnにしておきます。

⑨   [アクセス制御] > [許可]で、「多要素認証を要求する」にチェックをします。

⑩   [セッション]の「サインインの頻度」を設定すると再認証までの時間を設定することが可能です。
※検証時は設定しません。

条件付きアクセスポリシーは以上となり、Entra IDの管理者設定が完了しました。

認証時の挙動イメージ

まずはOffice 365ログイン画面より、Entra IDサインインページにリダイレクトします。

①    IDは、先ほど指定した証明書認証用のグループに参加するユーザーIDを入力します。

②    パスワードの入力を求められます。

③    次に、証明書を求められます。

④    このフローを経て、Office 365のトップ画面が表示されます。

なお、証明書がない場合は、以下の画面表示となりログインできません。

※画像内の「トラブルシューティングの詳細」は、[詳細]を展開した後の画面になります。

また、パスワード入力の画面で「証明書またはスマートカードを使用する」をクリックし正当なクライアント証明書を提示した場合（つまりパスワード無しでログイン試行する場合）、以下のようになりログインできません。

このときに、「パスワードを使う」を選択し正しいパスワードを入力すれば、多要素認証の条件を満たしたとしてログインできます。

条件付きアクセスをサポートしないプランの場合

条件付きアクセスをサポートしないプラン（Microsoft 365系のプランなど）の場合は、証明書ベースの認証を有効にした状態で「ユーザーごとのMFA」を使うことで同様のことができました。

ただし、「条件付きアクセス」でおこなえるような細かな適用条件は設定できず、そのユーザーがEntra IDにログインする際は必ずMFAが適用されるようです。

※Entra IDをMicrosoft 365のログインにしか使わないなどの場合は、あまり問題にはならないものと思われます。

まとめ

本記事でご紹介しました設定により、Microsoft Entra IDへID・パスワード＋クライアント証明書での多要素認証が可能になります。

Microsoft Entra IDは、TeamsやOneDriveなどのOffice365サービスへのアクセスポイントとして普段の業務で使用されているため、セキュリティ対策は極めて重要です。しかし、アクセスするユーザー目線での利便性も犠牲にしてはなりません。今回のクライアント証明書による認証方法は、多要素認証においてID・パスワードとの組み合わせで用いられる他の認証方法と比較しても、パスワード入力の手間を解消しつつ、フィッシング耐性もある認証方法となりますので、Microsoft Entra IDのセキュリティを大幅に強化することができます。

GMOグローバルサインでは、Microsoft Entra CBAでご利用いただけるクライアント証明書の発行・管理サービス「マネージドPKI Lite by GMO」を提供しております。ご紹介しましたMicrosoft Entra IDへの証明書認証にご興味を持たれましたら、ぜひお気軽にお問い合わせください。