1.はじめに
本記事は、Intune クラウドPKIを利用して、Entra CBA(証明書ベースの認証)を試してみたという内容です。
以下図のように、Intune クラウドPKIを利用して、SCEP証明書を発行し、IntuneによってSCEP証明書を配布します。そして、テスト用のSaaSに対して、Entra CBA(証明書ベースの認証)を利用してアクセス制御を実施します。
少し長くなるので、クラウドPKIのところと、Entra CBAのところで、2つに分割しており、今回はクラウドPKI編です。
2.クラウドPKIとは
2-1.Intuneの試し方
クラウドPKIは、Intuneの知識がベースとして必要となります。
もし、初めてIntuneを触る場合は、以下URL先に、Microsoft社の太田さんが投稿された「Microsoft Intuneのタメシカタ」という無料Bookがありますので、ご一読いただくと良いです。
2-2.クラウドPKIとは
IntuneアドオンプランとなるIntune Suiteに含まれるクラウドマネージドの公開鍵基盤(PKI: Public Key Infrastructure)です。
オンプレミスの基盤を用意することなく、二階層の認証局(CA:Certificate Authorities)を構成することができ、SCEP(Simple Certificate Enrollment Protocol)を利用して、ネットワーク経由で証明書を発行することができます。
クラウドPKIの利点
以下図は、Microsoft Learnの引用となりますが、クラウドPKIを利用することで、緑の円内に囲まれた部分をクラウド型で利用することができます。
画像引用:https://learn.microsoft.com/ja-jp/mem/intune/protect/microsoft-cloud-pki-overview#architecture
対して、クラウドPKIを利用しない場合は、以下図のオレンジのサーバ「ルートCA、発行CA、ネットワーク デバイス登録サービス (NDES)、証明書コネクタ」のようなオンプレミス基盤を用意する必要があります。もちろん、可用性(冗長構成にするなど)も考える必要があります。
さらに、NDESに関しては、エンドポイントがインターネット経由でSCEPを利用したい場合は、アタックサーフェス(攻撃表面)となるため、セキュリティにも注意を払う必要があります。
このような大変さをクラウドPKIの利用で、軽減することができます。
PKCSと比べてみると
Intuneのプロファイルのテンプレートには、SCEP証明書のほかに、PKCS証明書があります。
違いとしては、SCEPは、証明書の各要求に固有の証明書がプロビジョニングされ、PKCSは、各デバイスに一意の証明書がプロビジョニングされるという違いがあります。
また、IntuneによるPKCS証明書の利用においては、Intuneからデバイスに証明書を直接配布することができます。
先ほどのSCEP証明書の場合で、クラウドPKIを利用しない場合は、NDESがアタックサーフェスになるということを記載しましたが、IntuneによるPKCS証明書の配布の場合は、Intuneからデバイスに証明書を配布する仕組みとなりますので、そのような心配がないというメリットがあります。
クラウドPKIを利用可能なデバイス
クラウドPKIを利用可能なデバイスは、Intuneに登録済みのWindows, macOS, iOS/iPadOS, Androidとなります。
クラウドPKIのSCEP URI
ちなみに、クラウドPKIのSCEP URI(証明書を要求する際に利用するアクセスポイント)は、https://{{CloudPKIFQDN}}/TrafficGateway/PassThroughRoutingService/CloudPki/CloudPkiService/Scep/*****
となっています。
IntuneによるSCEP証明書プロファイルをエンドポイントに適用したタイミングで、{{CloudPKIFQDN}}
のところを正しい文字列に置き換える仕様だったりします。
3.手順
ここからはクラウドPKIの作成手順になります。
クラウドPKIに、ルートCAと発行元CAを作ることで、二階層CAを構成し、Entra JoinedとIntune登録を実施したWindows 11 PCにSCEP証明書の配布をいたします。
3-1.テスト構成
- ライセンスとして、Intune P1ライセンスに加えて、Microsoft Intune Suite ライセンス(試用版)を利用
- デバイスとして、Windows 11を利用し、Entra JoinedとIntune登録済み
※本PCは、Hyper-V上に構築しているVirtual Machineとなります
3-2.ルートCAの作成
まずは、Intune管理センターにて、「テナント管理 > CA管理」を選択し、「作成」をクリックします。
CAの種類に、「ルートCA」を選択し、有効期間を10年にします。
拡張キーの使用法は、とりあえず選択可能な種類を全部選択しておきます。
ここで選択した種類の中から、さらに発行元CAでは選択することになります。
件名の属性情報を入力します。ここで入力した情報は、エンドポイントに発行記載する情報となります。
クラウドPKIの現在の仕様上、作成した後は編集不可となりますので、注意しましょう。
スコープタグはそのままの情報を利用し、確認しましたら、「作成」をクリックします。
これで、ルートCAは作成完了です。
証明機関の削除
2024年7月22日の週のアップデートで、CAの削除が実装されました。
詳細に関しては、下記参考URLをご確認下さい。
参考URL
https://learn.microsoft.com/ja-jp/mem/intune/protect/microsoft-cloud-pki-delete
3-3.発行元CAの作成
再度、 「CA管理」にて、「作成」をクリックします。
発行元CAの名前を入力します。
CAの種類には、「発行元CA」を入力し、ルートCAソースには、「Intune」を選びます。
するとルートCAを選択可能になるので、先ほど作成したルートCAを選びます。
有効期間は、6年を選択しました。
拡張キーの使用法は、とりあえず選択可能なものをすべて選択しておきます。
なお、IntuneによるSCEP証明書の配布時には、この中のClient authを利用する予定です。
そして、件名の属性情報を入力します。
共通名は、発行元CAだとわかるような情報を入力します。
暗号化のところは、選択不可で、ルートCAの情報がそのまま選択されています。
それでは、入力した情報を確認し、「作成」をクリックします。
なお、一度作成すると修正ができませんので、注意をする必要があります。
3-4.証明機関からルート証明書のダウンロードとSCEP URIの確認
出来上がった、証明機関のリストです。
各証明機関名を選択すると、詳細画面や各証明機関の証明書をダウンロードすることができます。
ルート証明機関をクリックした画面です。
こちらの「証明書のダウンロード」をクリックし、ルート証明書をダウンロードしておきます。
また、発行元CAの方は、Monitorという項目があり、こちらで発行した証明書や失効させた証明書の確認ができます。
実際に発行した証明書が表示されるまで、ディレイがありました。
Monitorではなく、「Properties」を選択します。
ここでは発行元CAの情報を確認することができます。下の方にある「SCEP URI」をメモしておきます。
この情報は、IntuneでSCEP証明書のプロファイルの設定をする際に利用します。
3-5.ルート証明書の配布
それでは、ルート証明書をエンドポイントに配布します。
Intune管理センターから、「デバイス > Windows > 構成」に移動します。
「作成 > + 新しいポリシー」から、「Windows 10 以降 > テンプレート」を選択します。
テンプレートから、「信頼済み証明書」を選択します。
先ほどダウンロードしておいたルート証明書をアップロードします。
保存先ストアは、「コンピューター証明書ストア ルート」を選びます。
配布対象のセキュリティグループを選びます。
ここでは、テスト用のユーザを入れたグループを作っています。
割り当てグループ
「信頼済み証明書」プロファイルで割り当てたセキュリティグループと、「SCEP証明書」プロファイルで割り当てるセキュリティグループは、同じにすることが推奨です。
Microsoft Learnによると、片方がユーザグループ、もう片方がデバイスグループだと、SCEP証明書配布に失敗する可能性があります。
「作成」をクリックして、完了です。
3-6.SCEP証明書の配布
Intune管理センターから、「デバイス > Windows > 構成」に移動します。
「作成 > + 新しいポリシー」から、「Windows 10 以降 > テンプレート」を選択します。
テンプレートから、「SCEP証明書」を選択します。
プロファイルの名前を入力します。
ここでは、証明書の種類に「ユーザー」を選択します。
ユーザーを選んだ場合は、Windows PCのユーザ証明書(certmgr.msc)の個人のところに証明書がインストールされます。
以下画像のように、入力しています。
選択可能なオプション
①証明書の種類
- ユーザー証明書:証明書のサブジェクトと SAN 内にユーザー属性とデバイス属性の両方を含める
- デバイス 証明書:証明書のサブジェクトと SAN のデバイス属性のみを含める
②キー記憶域プロバイダー (KSP)
証明書のキーを格納する場所を指定
③証明書のキー使用法
- デジタル署名: キーがデジタル署名で保護されている場合だけ、キーを交換
- キーの暗号化: キーが暗号化されている場合だけキーを交換
④ハッシュアルゴリズム
- SHA-1:任意の長さの元データを元に160ビットの値を生成するハッシュ関数
2005年にSHA-1に対する攻撃法が発見されSHA-2への移行が推奨 - SHA-2:SHA-224 , SHA-256 , SHA-384 , SHA-512 と種類があり、一般的には、 SHA-256 がよく使用される
参考
https://learn.microsoft.com/ja-jp/mem/intune/protect/certificates-profile-scep
拡張キー使用法ですが、Entra CBA用ですので、クライアント認証を選んでいます。
なお、ここで定義済みの値を選択すると、オブジェクト識別子と名前は自動で入力されます。
そして、SCEPサーバのURLには、先ほど発行元CAでメモをしておいたSCEP URLの情報を入力します。
CloudPKIFQDN
SCEPサーバのURL中に、{{CloudPKIFQDN}}という部分がありますが、このままで問題ありません。
Intuneがエンドポイントに、SCEPプロファイルを配信する際に、正しい値に変換してくれます。
信頼済み証明書のプロファイル作成時に、選んだグループと同じグループを割り当てて、完了です。
3-7.SCEP証明書の確認
Windows PCを確認してみます。
検索バーで、「certmgr.msc」を選択し、「個人 > 証明書」を選択します。
正常に、SCEP証明書が配布されている場合は、発行者名が発行元CAの証明書があります。
証明のパスを確認すると、ルートCA(Cloud-PKI-Root-CA)から発行元CA(Cloud-PKI-ICA)、SCEP証明書と信頼チェーンが確立されています。
また、サブジェクトのところには、IntuneのSCEP証明書プロファイルでユーザ名を指定したため、ユーザ名が入っていることが確認できます。
サブジェクト代替名のところには、IntuneのSCEP証明書プロファイルでUPNを指定したため、UPNが入っていることが確認できます。
4.おわりに
これで「クラウドPKIを利用して、Entra CBA(証明書ベースの認証)をやってみる」のクラウドPKI編は終了となります。
ADCSを二階層CAで作って、SCEP証明書の発行をしてみるよりも、構築も保守も、だいぶ楽そうですね。
次回は、以下URLとなります。このクラウドPKIを利用して、Entra CBAをやってみようと思います。