Windows Serverを利用してActive Directory Domain Serviceなど、社内の認証・認可、ユーザー・デバイス管理をまとめて実現されていたお客様も、昨今のインフラをクラウド化する流れやゼロトラスト・アーキテクチャを目的とした境界型防御からの脱却など、様々な目的で「ADをやめて、Microsoft Entra ID (旧 Azure AD)に移行する」ケースが増加しているのではないでしょうか。この記事では、ネットワークポリシーサーバー(NPS)をどうやってクラウドに移行できるのかについてまとめてみました。
Windowsサーバーが果たしてきた役割
オンプレミスのWindows Serverでは、いくつか用意された役割をインストールすることで様々な機能・役割を1つまたは複数のサーバーにより実現してきました。そのなかでも代表例に挙げるとすれば、Active Directory Domain Service (AD DS)があります。これは、ユーザーやコンピュータの管理、ログオンなどをまとめて実現することができ、ファイルサーバーのアクセス権限管理からコンピュータのグループポリシー管理まで、多くの組織内で利用されてきました。
また他にも、デバイスの構成設定の自動配布・一括管理を行うためのMicrosoft Configuration Manager、グループウェアの基盤となったメール・カレンダーを支えたExchange Server、プライベート認証局のためのActive Directory Certificate Service (AD CS)、WS-FederationやSAMLのローカルIdPとなるActive Directory Federation Service (AD FS)、そしてネットワーク認証のためのNetwork Policy Server (NPS)など、様々な機能を一手に引き受けてきました。
クラウドへの移行のなかで取り残されたPKIとRADIUS
Windowsサーバーは多くの役割を果たしてきましたが、現在では多くの組織がその基盤たるActive Directory Domain Service (AD DS)とActive Directory Federation Service (AD FS)で実現していたユーザー管理、シングルサインオンをMicrosoft Entra IDへ移行しクラウドで管理することが主流となりました。
他にもMicrosoft Configuration Managerといったデバイスの構成管理ツールは、Microsoft IntuneなどのMDMに置き換えが進み、Exchange ServerはMicrosoft 365に含まれるExchange Onlineへメールサーバーごと移行し、既に何年もこの新しい構成で運用している組織も少なくありません。
しかし、Active Directory Certificate Service (AD CS)が提供してきたPKI、そしてNetwork Policy Server (NPS) が提供してきたRADIUSは、先行して取り組みが進んだAD廃止が順調に進んだあと、残る課題として移行先の検討に悩まれている組織が多い状況です。なぜならば、Microsoft Entra IDには、PKI基板となるマネージドPKIサービスは用意されておらず、またRADIUSについては現在でもNPSを継続利用し、Entra IDとの連携はAzure MFA（OTP認証）のみで、これには専用のエージェントと複雑な構成設定が必要なため、従来のようにADで管理するデバイスにサイレントでクライアント証明書を配布し、EAP-TLSでネットワークの認証を行うことは、簡単にクラウドには持っていけなかったのです。
PKIとRADIUSはクラウドに移行できる
ここでまず最初に申し上げることは、取り残されてしまったAD CSとNPSが担ってきた組織のPKI基盤とRADIUSサーバーはクラウドへ移行できるということです。MicrosoftはAD CSに代わる仕組みとして、2024年にMicrosoft Cloud PKIと呼ばれる限定的な機能を持つマネージドPKIサービスを、Microsoft Intuneのアドオンとして一般に提供開始しました。このサービスでは、Intuneで管理されたデバイスに対しては動的なクライアント証明書の発行が可能となりました。これにより、限定的な範囲ではありますが802.1Ｘ認証に利用するためのクライアント証明書の配布はMicrosoft Entra ID + Microsoft Intune + Microsoft Cloud PKIの組み合わせにより実現可能となりました。
次にRADIUSですが、こちらは残念なことにMicrosoftは2024年になってもクラウド型のソリューションがMicrosoftから提供されることはありませんでした。そのため、いくつか世の中にあるクラウドRADIUSへの関心が高まっており、そのなかでも古くからクラウドRADIUSを提供しきてたSecureW2はいちはやく、Microsoft Cloud PKIをはじめとする様々なPKI基盤で発行されたクライアント証明書を利用した802.1X認証に対応し、多くの組織においてNPSやアプライアンス型RADIUSからの移行先として選定されています。
最も先進的なクラウドRADIUS
SecureW2は、マネージドPKIとクラウドRADIUS、そして証明書のオンボーディングというPKIの運用に不可欠な3つの機能を一体として提供するSaaSです。日本では、ペンティオが2021年から取り扱いを開始して数百デバイスから数万デバイスまで、幅広い規模・業種でのご利用が既にスタートしています。
クラウドRADIUSというと、単にRADIUS認証を行うRADIUSサーバーのエンドポイントがクラウドでホスティングされているだけ... と思われがちですが、実際には多くの新しい技術とインフラの運用ノウハウにより実現している高度な認証認可サービスです。例えば、SecureW2のクラウドRADIUSではいちはやく業界に先駆けてRadSecをサポートし、積極的にRADIUS認証の安全性・プライバシー課題に対応し、Cisco Meraki・HPE Aruba・Juniper Mist・Fortinet ForiGateなど主要なネットワーク機器において暗号化されたRADIUS通信を実現しています。
参考: Cisco Meraki MRとSecureW2でRadSecを利用した802.1X 無線認証を行う
そのほかにも、クラウドに場所を移すだけでなく、クラウドが主流となり、またゼロトラスト・アーキテクチャを採用する組織の増加に対応した各種機能を提供しています。例えば、RADIUS認証要求がきた際にMicrosoft Entra ID、Okta、OneLoginなどIDaaSのユーザー有効性や所属グループなどに応じた動的なネットワークアクセス管理（VLANの変更）や接続可否のコントロールを行うことや、これらIDaaSで退職処理などにより無効化/削除されたユーザーの証明書を即時失効し、接続中のネットワークデバイスもアクセス遮断を要求するなど、IDaaSを源泉とした認証認可をクラウドのみで実現します。
参考: Microsoft Entra IDとクラウドRADIUSで無線LAN認証を実現する
またSecureW2は世界中に多数のRADIUSエンドポイントを保有・運用しているため、世界中どこでも統一した認証基盤、ネットワークポリシーを実現しつつも、どの地域から利用しても高いレスポンス性と可用性を享受できます。グローバル企業においては、物理資産やSD-WANなどが不要なクラウドRADIUSの有用性はネットワーク設計の自由度、運用性、コスト面にも広がります。
NPSからの移行はRADIUSとPKIをまとめて行う
ここまで説明してきたとおり、SecureW2のクラウドRADIUSを利用することで既存のPKI基盤やMicrosoft Cloud PKIのような新しいPKI基盤で管理・発行された証明書を用いて、NPSを廃止・クラウドへRADIUSに移行できることがわかりました。では、PKI基盤についてはどうすればよいでしょうか？
SecureW2のクラウドRADIUSはAD CS、Microsoft Cloud PKIの証明書を利用することはできますが、ペンティオでは認証局基盤についても同時にSecureW2のマネージドPKIに移行することを推奨しています。
ADCSの利用継続は非現実的
PKI基盤を従来どおりAD CSで管理し続けることには多くの課題が残ります。AD CSの運用は言わずもがな、オンプレミスまたはAzure VMなどのハードウェアまたは仮想インフラの資産が継続して必要となり、また高度な運用知識とWindows Serverの保守、アップデート対応等が今後も必要になるため「ADからの脱却」「オンプレミスの廃止」を目的とする組織においては適切な策ではありません。せっかくMicrosoft Entra IDに移行したのに認証局だけオンプレミスというのは本末転倒でもあります。
Microsoft Cloud PKIは一見良いが多くの制約事項がある
Microsoft Cloud PKIも一見してとても使い勝手のよいソリューションに見えますが、これは非常に限定的なシチュエーションを満たす組織、利用用途の場合に限られます。Microsoft Cloud PKIでは、Microsoft Intuneが管理するデバイスでしかクライアント証明書の発行を受けることが出来ません。もちろん多くの組織内のWindowsデバイスはIntuneによる管理を受けている、または今後受けることが出来ると思いますが、実は多くの組織ではここが最も課題となります。
Microsoft Cloud PKIでは組織のマネージドPKIには不十分
デバイス管理構成への制約
例えば、ホールディングスなどの複数の子会社を束ねるグループ企業や、子会社や工場、支社を含めてグローバルに展開する企業においては、本社やホールディングス企業がIT統制を効かせるためには、各社・各地域でいままで分散してきた運用基盤を一新するなど、相当な労力をかける構成変更が必須となります。なぜならMicrosoft Cloud PKIとMicrosoft Intuneで利用できるSCEP構成は同一テナント内に限られているため、グループ企業で統一したMicrosoft Entra IDのディレクトリ運用となっていない限りは事実上利用できるのは国内法人、なかでも本社や親会社のみなど限られた範囲となってしまうためです。また、各Entra IDのテナント単位で同じ構成をとるにも、その場合は認証局構成はすべて別管理となり、ポリシーの統一や統合的な管理、ガバナンスの適用には課題が残ります。また、現地のIT管理者にPKIの管理を委任する必要性や、トラブルシュート対応などの運用面でも不安が多く募ります。
また、現在はWindows PC以外の業務用端末も多く普及しており、macOSやiOSの管理はMicrosoft Intuneではない別のMDM、例えばJamf ProやKandjiのようなApple専用のサービスのほか、iPhoneなどはキャリアから提供される例えばBCDM、Optimal Biz、CLOMOのような国産のサービスと、実際には管理方法が分散していることも一般的です。さらにAndroid端末やChrome OSとなると、Googleが提供するChrome EnterpriseやGoogle Workspaceによる管理なども必要となり、現実にはCloud PKIでは組織が必要とする十分なPKI基盤にはならないことが多々あります。MDMの移行は非常にハードルが高く、現実的でないことも重要なポイントです。
参考: Microsoft Intuneで無線LAN認証用のSCEP証明書を自動配布する
SecureW2のマネージドPKIは、複数のMDMといくつでも連携を行うことができ、Windows PCはIntuneとの連携、macOSとiOSはJamf Proとの連携、AndroidとChrome OSはGoogleとの連携といった構成はもちろんのこと、これらを同時にいくつでも構成することが可能です。また、BYODデバイスに対してはJoinNow MultiOSと呼ばれる専用のセルフオンボードツールを利用した簡単な証明書取得のほか、管理画面での証明書の手動作成にも対応します。例外的なデバイスというものはどの組織にもつきものです。
証明書ライフサイクル管理への制約
Microsoft Cloud PKIは、SCEPによるクライアント証明書の発行・配布をサポートしていますが、これらはIntuneのSCEPプロファイルに依存しています。このためIntuneを通じてMicrosoft Cloud PKIが発行したクライアント証明書は、仮に従業員が退職してMicrosoft Entra IDでユーザーが無効となった場合でも、その情報を受けって自動的に失効されることはありません。なぜならデバイス起点の管理となっていて、IDドリブンではないためです。
SecureW2であれば、Microsoft Entra IDでユーザーが無効化されたり削除されるなど、IDの状態に変化があればリアルタイムにそれを検知し、当該ユーザー向けに発行されたクライアント証明書はすべて自動的に失効されます。また、証明書が失効された場合に、Cisco Meraki・HPE Aruba・Ubiquiti UniFiの3製品ではリアルタイムにデバイスの接続を遮断する機能もサポートします。これにより、クリティカルなネットワークのアクセスコントロールにも最適です。
また最近では、CrowdStrikeなどのセキュリティプラットフォームから共有されるデバイスのリスクレベルなどの情報をもとに一定の脅威がある場合には自動的に当該デバイス上のクライアント証明書を失効し、正当なデバイスであっても問題がある場合にはネットワーク、IDaaS、アプリケーションへの接続を拒否することもリアルタイムにコントロールすることが出来ます。
認証局構成への制約
無線LANと有線LANの接続、VPNのデバイス認証、IDaaSのデバイストラストなど、クライアント証明書の用途は様々です。サービスによっては、中間認証局を識別して認証認可に利用するものもあり、そのような場合には複数の認証局を構成できるかどうかも重要なポイントとなります。Microsoft Cloud PKIでは、最大で6つのCAしか作成することが出来ません。これはルート認証局だけでなく中間認証局も含むため、今後の拡張性に不安が残ります。SecureW2では無制限にHSMを利用した安全な認証局の追加が可能ですので、安心して今後のPKIの利用拡大に備えることができます。
また、一部の証明書を扱うサービスやアプリケーションでは、組織の認証局にCSRへ署名を行いトラストアンカーを必要とするものもございます。例えば、Cisco Meraki System ManagerのようなMerakiエコシステムの中で信頼されたデバイスかどうかを判定するためのクライアント証明書の発行・管理には、Merakiが用意したCSRに署名を行い、発行局となる中間認証局をPKI基盤の外部に用意する必要があります。Microsoft Cloud PKIはBYOCAはできますが、CSRへの署名やHSM以外に秘密鍵を生成してエクスポートするような自由度はないため、このようなシステムを組織のCAに取り込むことが出来ません。
証明書設計の自由度
Microsoft Cloud PKIではIntuneとEntra IDで管理されている情報しか証明書に埋め込むことが出来ませんが、SecureW2は証明書にIDaaSであるOkta、OneLoginなどの外部IdPが管理する情報を埋め込むことや、任意の値を書き込むことができ、証明書テンプレートを自由に定義することで詳細な認証要件に応えることが可能です。
以上の理由から、Microsoft Cloud PKIはAD CSに代わる素晴らしいMicrosoftエコシステムにおける製品ではありますが、Microsoft Intuneと専用ライセンスの両方が利用に必要であること、制約事項が多いことから、組織のPKIとして実際に活用できる幅を考えるとSecureW2をおすすめしたいと思います。
NPSとADCSはSecureW2のマネージドPKIとクラウドRADIUSに移行
ここまで、ネットワークポリシーサーバー(NPS)のRADIUSサーバーによる認証と、ADCSによる認証局・証明書の管理をSecureW2のマネージドPKI・クラウドRADIUSに移行ができること、そしてそのメリットと比較対象となるMicrosoft Cloud PKIとの違いに触れてきました。ペンティオでは、NPSからSecureW2への移行について、クラウド移行後の認証局・証明書・認証フローのデザインはもちろん、移行にあたってNPSやADCS側で必要な作業を評価し、実際にお客様が行うべき移行シナリオの検証を行っています。移行方法を含めていくつかの取り組み方がありますので、2025年春にはNPSからSecureW2に移行してみる検証レポートをお届けする予定です。
ぜひ、NPSやADCSがオンプレミスからの脱却の最後の課題になっているというお客様は、SecureW2をご検討ください。
SecureW2を知る
ペンティオでは、SecureW2の各機能を実際にいろいろな連携ソリューションと一緒に利用してみた検証レポートを数多く掲載しています。ぜひ下記検証レポート記事の一覧もご覧ください。
https://www.pentio.com/securew2/support/document/
Entra ID関連の記事は下記FAQからもリンクがございます。