クレーム ルールと条件付きアクセスの比較

Last Update: feedback 共有

Note

本記事は Technet Blog の更新停止に伴い https://blogs.technet.microsoft.com/jpazureid/2018/01/30/claimrule-conditionalaccess/ の内容を移行したものです。

元の記事の最新の更新情報については、本内容をご参照ください。

こんにちは、Azure & Identity サポート チームの坂井です。

今回は AD FS を利用したクレーム ルールと Azure AD を利用した条件付きアクセスについて比較します。これまで AD FS のクレーム ルールでアクセス制御を実施しているが、条件付きアクセスの機能にも興味をお持ちの方も多いかと思います。今後の運用においてクレーム ルールと条件付きアクセスのどちらで運用を行うか検討するにあたり少しでも本記事がお役に立ちましたら幸いです。

はじめに

クレーム ルールと条件付きアクセスは、両者ともに指定した条件に応じて認証アクセスの制御を行うことができます。例えば、多要素認証を発生させるための条件設定は、クレーム ルールでも条件付きアクセスでも可能です。

それぞれを利用する際に必要な前提条件は次のとおりです。

  • クレーム ルール

    AD FS 環境が必須です。AD FS を利用した認証フローとなるため、認証についてはオンプレミス側で行います。

  • 条件付きアクセス

    Azure AD 環境が必須です。また、条件付きアクセスの利用には、利用するユーザー分 Azure AD Premium のライセンスが必要です。AD FS が導入されている環境においても、条件付きアクセスを利用することが可能です。

コスト比較

まずは、重要となるコスト面について比較してみましょう。

  • クレーム ルール

    AD FS 環境が必須となりますが、すでに AD FS を導入済みの環境の場合は、クレーム ルール設定のための追加コストは不要です。ただ、クレーム ルール自体は少し書き方が特殊なのとメンテナンスが必要で、メンテナンスに要する人的なコストは考慮する必要があります。サポートでクレーム ルールをいただいてみたら、連携先が新しい認証方式に対応していてクレーム ルールが使われていなかったというケースもあります。

  • 条件付きアクセス

    条件付きアクセスを利用するユーザー分の Azure AD Premium (P1 または P2) のライセンスが必要となります。例えば、Azure AD 内に 1000 人のユーザーを登録している環境で特定の 300 人に対して条件付きアクセスの制御を行いたい場合は、300 ライセンス必要となります。詳細な価格情報については、下記の情報を参照ください。

    Azure Active Directory の価格
    https://azure.microsoft.com/ja-jp/pricing/details/active-directory/

機能比較

続いて、検討材料のメインとなるであろう機能について比較してみましょう。

クレーム ルール 条件付きアクセス
ADAL への対応 △ ※1
非 ADAL への対応 △ ※1 ×
アプリケーション毎の制御 △ ※1 ○ ※2
ユーザーやグループによる制御
IP アドレス ベースでの制御
OS の種類による制御 △ ※3
多要素認証 ○ ※4 ○ ※5
Intune との連携 ×
デバイス ベースの制御 △ ※6 ○ ※7
GUI での設定
コマンドラインでの設定 ×

※ 1: user-agent などによりアプリケーションの特定が可能なものもありますが、OS やアプリケーションのバージョンによって変更される可能性があり、厳密な判別には十分な検証が必要です。また、ADAL を利用するアプリケーションは、 user-agent はブラウザーと区別が付かず、アプリケーション固有のクレームでの判別が困難です。

※ 2: 利用可能なアプリケーションについては下記の情報を参照ください。

https://docs.microsoft.com/ja-jp/azure/active-directory/active-directory-conditional-access-technical-reference

※ 3: 既定では、OS の情報は取得できないため、別途デバイス認証を追加設定する必要があります。

※ 4 ※ 5: AD FS の多要素認証としては、証明書認証を使用するのが一般的です。一方で、条件付きアクセス (Azure MFA) では、電話、テキストコード、モバイルアプリ (Authenticator) が使用可能です (証明書認証は不可)。それぞれ利用できる多要素認証の種類が異なるため、重要な検討材料になります。

※ 6 ※ 7: AD FS においては、証明書認証とデバイス認証の方法がありますが、証明書認証はモバイル端末への証明書の配布方法、デバイス認証は各種デバイスの対応状況に課題があります (例えば、Windows 10 は AD FS 3.0 のデバイス認証に対応していません)。

一方で、条件付きアクセスでは Windows 端末がドメイン参加していることを条件に制御することができます。また、Intune に登録済みのデバイスを準拠済みデバイスとして制御可能です。詳細については、リンク の記事もご参照ください。

おわりに

現時点においても、条件付きアクセスは細かな制御に対応してきており、かつ今後の機能拡張も期待できます。なお、条件付きアクセスに関するよくあるお問い合わせについてもご紹介しておりますので、参考になれば幸いです。

今回、機能についてはお問い合わせの多いものを抜粋してご紹介させていただきました。より、詳細な内容の確認やお客様のご要望に沿った制御方法についてのご質問については、ぜひ弊社サポートサービスをご利用ください。製品動作に関する正式な見解や回答については、お客様環境などを十分に把握したうえでサポート部門より提供させていただきますので、ぜひ弊社サポート サービスをご利用ください。

※本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります。