条件付きアクセスを利用した証明書認証

皆さんこんにちは。国井です。

今日はAzure ADの条件付きアクセスの話です。
条件付きアクセスの存在を知り、ある程度条件付きアクセスのことについてわかってくると
お客さんから必ず聞かれることがあります。

条件付きアクセスで証明書認証できないの?

Microsoft Cloud App Security (MCAS) を使えば可能です。
(条件付きアクセスを利用した証明書認証って、表現として正しくない気がしますが、
細かいことは言いっこなしでお願いします)

条件付きアクセスにはアクセスを許可/拒否するアクセス制御設定とは別に、
[セッション]と呼ばれるアクセス制御設定があり、これを利用するとExchange  OnlineやSharePoint Online、MCASのアクセス制御機能と連携したアクセス制御が実現できます。これにより、特定のクラウドサービスにアクセスしてくるユーザーが証明書を持っているか?をMCASで判定させておいて、その結果に基づいて条件付きアクセス(とMCAS)を利用してアクセス制御することができます。

では設定方法を見てみましょう。

条件付きアクセスの設定

MCASで証明書を持っているかをもとにした判定を行う場合、アクセスポリシーと呼ばれるポリシーを作るのですが、アクセスポリシーは条件付きアクセスを事前に設定していることが条件になります。条件付きアクセスでは、次のようなポリシーを作りました。

■ユーザーとグループ:すべてのユーザー
■クラウドアプリ:SharePoint Online
■セッション:アプリの条件付きアクセス制御を使う – カスタムポリシーを使用する

image

設定できたら、ポリシーを有効化しておきましょう。
これでSharePoint Onlineをターゲットにしたポリシーができました。

MCASで認証局を登録

続いてMCASの設定です。ポータルサイトから[設定]画面にアクセスし、[デバイスの識別]にアクセスします。
すると、[クライアント証明書ベースの識別] 欄から認証局の情報が登録できます。
認証局の情報は認証局のルート証明書を登録することで設定できます。
ちなみに、下の画面ではcontoso.comドメインのCAのルート証明書を登録しました。

image

認証局であれば、パブリックCA、プライベートCAどっちでもOKなのがありがたい。
そういえば、ゼロトラストのオライリー本にもプライベートCA使えって書いてありましたね。

アクセスポリシーの作成

続いてMCASからアクセスポリシーを作成します。
MCASのアクセスポリシーとは名前のとおり、クラウドサービスに対するアクセスを制御するためのポリシーで具体的にアクセスを制御する条件を設定します。ここでは、「デバイスが有効なクライアント証明書を持っていなかったら」という条件を設定し、アクションとして「テスト」としておきました。
(ブロックを選べばブロックされますが、まずはテストで確認しましょうね)

image

アクセスしてみる

ここまでで設定は完了。
実際に証明書を持っていないユーザーがSharePoint Onlineにアクセスすると、アクセス自体はできましたが、MCASで以下のようなアラートが出力されました。

image

ちなみにアクセスポリシーのアクションをテストからブロックに変えてアクセスしてみると、ご覧のようにブロックされます。

image

一方、MCASに登録した認証局から発行した証明書を持っているユーザーがSharePoint Onlineにアクセスすると、ご覧のように「あなたが使う証明書、これで良い?」という確認画面が出てきて、OKをクリックすると、

image

問題なくSharePoint Onlineにアクセスできました。
ちなみに、ここで使う証明書は特定の認証局から発行された証明書であればOKなので、
ユーザー証明書(デバイスではなく)でもOKです。

image

証明書認証ができるならIntuneいらなくね?

条件付きアクセスにはIntuneにデバイスが登録されていることを基準にアクセス制御する方法があるので、証明書認証でアクセス制御できるなら代替できるのではないか?という疑問もあるでしょう。
しかし、それは2つの理由で「それは違う!」と言えます。

ひとつはIntuneの持つ機能です。
Intuneを使った条件付きアクセスはデバイスが登録されているかだけでなく
コンプライアンスポリシーを使って

特定OSバージョンのみ許可
BitLockerを有効化しているときだけ許可

のような追加条件が入れられるので、その点で単純に証明書認証をするのとは違うと思います。もっと言えばIntuneを使う理由って条件付きアクセスだけじゃないですよね?

もうひとつはコストです。
条件付きアクセスはAzure AD Premium P1(650円)のライセンスが必要ですが、
MCASを使うことになればMCASのコスト(380円)もかかってきます。
それに対してAzure AD Premium P1 + Intuneの組み合わせであればEMS E3(960円)で両方使えるので、EMS使ったほうが安くなってるんですよね。
(※どうやって購入するかによって値段は変わってくるので、必ずしもこれが正しいとは言えないという言い訳だけ先にしておきます)

ただ、MCASもまた証明書認証のためだけに使うものじゃないので、結局は何をやりたいか?で買うものって決まるんですよね。

証明書認証の是非を考える

この話を突き詰めると、そもそも証明書認証ってどうなの?という話になります。
人によっていろいろな意見があるでしょうし、私の一方的な立場を表明して炎上するのも嫌なので(笑)マイルドな表現にとどめておきますが、少なくともマイクロソフトさんの中では証明書ありきのセキュリティ対策をビジョンとして掲げていないように思います。
実際、Intune登録デバイスのみアクセスを許可する、Windows Hello for Businessで認証する、FIDO2デバイスで認証する、などの最近の流れを見ればわかるように、証明書をむき出しで使うようなやり方はしていないわけです。
(※この話をしていて、あるお客さんの会社でWPA EnterpriseのWi-Fiが導入されていて、証明書を入れなきゃいけないんだけど、面倒くさいからPFXファイルを直接インストールするってやり方をしている話を思い出しました)
どこの会社のクラウドサービスを選ぶかはそれぞれの会社次第ですけど、マイクロソフトのクラウドサービスを選択するのであれば証明書認証は永続的な認証方法として選択するべきじゃないと思います。
勝手な想像でしかないけど、証明書を認証基盤の中心に据えていると、いつかハシゴを外されるような気がして怖い.. その意味でも証明書認証は他の認証(というかアクセス制御)を導入するまでのつなぎと考えておくのが吉かと思います。

  • このエントリーをはてなブックマークに追加
  • Evernoteに保存Evernoteに保存

コメントをどうぞ

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください