PKI Enhancements in Windows 7 and Windows Server 2008 R2

[アーティクル]
08/25/2016

セキュリティ

Windows 7 と Windows Server 2008 R2 での PKI の機能強化

John Morello

この記事は、プレリリース版のコードに基づいています。ここに記載されているすべての情報は、変更される場合があります。

概要:

サーバーの統合
既存のシナリオの強化
Software Plus Services
強力な認証

「Windows での PKI の機能強化」という記事を書いたのが、つい昨日のことのように思われます。TechNet Magazine の 2007 年 8 月号に掲載されたこの記事では、Windows Vista と Windows Server 2008 で導入されるいくつかの新機軸について説明しました。これらの新機軸には、登録に使用する UI の機能強化や、オンライン証明書状態プロトコル (OCSP) 機能などがありました。これらの機能強化は価値が高く、ユーザーからの評価も上々でしたが、IT プロフェッショナルの観点から見ると、追加的な変更の度合いが強いと言えます。ただし、Windows 7 で提供される PKI の機能強化によって、展開と運用に関するユーザーエクスペリエンスが大幅に強化され、新しい強力なシナリオの実現と運用コストの削減が可能になります。

Windows 7 と Windows Server 2008 R2 での PKI の機能強化は、次の 4 つの主要な領域を中心に行われます (図 1 参照)。

サーバーの統合。この領域では、組織が自社のビジネス要件を満たすために必要な証明機関 (CA) の数を減らすことができるようにします。

既存のシナリオの強化。この領域では、より包括的な SCEP (Simple Certificate Enrollment Protocol) のサポートやベストプラクティスアナライザ (BPA) などを提供します。

Software Plus Services。この領域では、ネットワーク境界や証明書プロバイダに関係なく、自動的にユーザーとデバイスの証明書を登録できるようにします。

強力な認証。この領域では、スマートカード操作の機能強化や Windows 生体認証フレームワークの導入などを行います。

図 1 4 つの主要な領域から成る PKI の機能強化

この記事では、IT プロフェッショナルの観点から、これらの領域で導入されるいくつかの重要な変更について説明します。

サーバーの統合

ここ何年か、IT 分野で主流となっているテーマの 1 つは、サーバーの統合です。簡単に言うと、サーバーコンピューティング環境に含まれるリソースの総数を削減しながら、ビジネス目標を達成し、さらには拡大することがテーマです。現在の世界経済では、多くの IT グループにとって、コストの削減が最優先課題になっていて、サーバーの統合がその戦略全体を構成する要素の 1 つであることは間違いありません。ほとんどの組織が CA を数限りなく大量に所有しているわけではありませんが、証明書の作成に関するスループットだけを見ると、多くの組織が必要以上の数の CA を所有しています。つまり、多くの組織は、所有している CA をほとんど活用していません。

CA が活用されない理由は、主に 2 つあります。1 つは、組織によっては、規制上またはセキュリティポリシー上の理由から個別に CA を必要とする場合があるからです。たとえば、一部の顧客は、外部の関係者に証明書を発行するときに、内部のユーザーとコンピュータに証明書を発行するときとはまったく異なる CA を使用します。このような場合、Hyper-V 上で CA を仮想化すると、別のサーバーハードウェアを使用する必要がなくなります (ただし、CA 自体は VM として管理する必要があります)。

もう 1 つの一般的な理由は、これまで自動登録がフォレスト内のシナリオでのみサポートされていたからです。具体的に言うと、CA は、エンティティがその CA と同じフォレストに参加している場合のみ、エンティティの証明書を自動的に登録できました。また、フォレストレベルで双方向の信頼が確立されている場合でも、自動登録を使用するフォレストごとに、異なる CA を配置する必要がありました。

Windows Server 2008 R2 で導入される重要な新機能の 1 つは、信頼関係が確立された複数のフォレストにまたがって自動登録を実行できる機能です。この機能によって、企業内で必要な CA の数が大幅に減少する可能性があります。たとえば、ある一般的な企業ネットワークで、既にある程度の統合作業が完了していて、現在運用、開発、テスト、およびエッジ環境に使用する 4 つのフォレストが構成されているとします。R2 よりも前のバージョンでは、各フォレスト上で自動登録機能を提供する場合、すべてのフォレスト間で信頼関係が確立されていても、証明書を発行する CA を 4 つ以上配置する必要がありました。このシナリオで R2 を使用すると、必要な CA の数を 1 つに減らすことができます。これは、いずれかのフォレスト内にある 1 つの CA から、他のすべてのフォレスト内にあるエンティティに証明書を発行することによって実現されます。

複数のフォレストから成る、より設計が複雑な環境では、必要な CA の数がさらに大きく減少するので、R2 へのアップグレードに関する投資をすぐに回収できます。

また、フォレストを越えた登録機能によって、吸収合併時に PKI を簡単に拡張できるようになります。その理由は、フォレストの信頼を確立した直後に、新しく獲得した資産の証明書の準備を開始できるからです。さらに、フォレストを越えた登録機能はサーバー側のみの変更なので、クライアントコンピュータに変更を加えることなく登録を開始できます。この登録機能は、Windows XP などの古いクライアントオペレーティングシステムにも対応しています。

では、フォレストを越えた登録機能は、どのようなしくみで動作するのでしょうか。エンドユーザーにとって、この登録処理は完全にシームレスに実行されます。他の自動登録シナリオと同様、ユーザーはほとんどまたはまったく対話を行うことなく証明書を取得します。エンドユーザーは、おそらく CA がどのフォレストに配置されているかも知らないまま、特別な操作を行う必要なく証明書を取得できます。

IT プロフェッショナルにとって、フォレストを越えた登録機能の基本的な構成要素は、従来のフォレスト内自動登録とほとんど変わりません。重要な違いは、CA が外部フォレストから受信した要求を処理し、その要求に関するメタデータを、信頼関係のある Active Directory から取得できるようになったことです。

信頼関係のあるフォレストから要求を受信して適切に処理するこの機能は、R2 で提供される重要な新機能で、上記のようなシナリオの実現を可能にします。R2 CA を用意し、フォレスト間で双方向の信頼を確立するだけでなく、CA を配置するフォレストと、そのフォレストに対して登録を行う他のすべてのフォレストとの間で証明書テンプレートをレプリケートする必要があります。このレプリケーションを自動化する Windows PowerShell スクリプトが、マイクロソフトから提供されています。テンプレートに変更を加えるたびに、レプリケーションを実行することをお勧めします。通常は、スケジュールされたタスクとして、このスクリプトを実行するとよいでしょう。

他にもいくつか、サーバーの統合に役立つ小規模な機能が提供されます。1 つは、CA で非固定要求がサポートされることです。非固定要求は証明書の要求で、通常は有効期間が短く、CA のデータベースには書き込まれません。たとえば、ネットワークアクセス保護の正常性登録機関について考えてみましょう。このシステムは、数時間のみ有効な証明書を 1 日に何千回も発行する場合があります。証明書の要求をすべて CA データベース内で保持してもほとんど価値はなく、必要な記憶域が大幅に増加します。R2 では、これらの要求をデータベースに書き込まないように構成できます。この構成は、CA またはテンプレートレベルで行うことができます (図 2 参照)。

図 2 証明書をデータベースに格納しないことを選択する

サーバーの統合作業を単純化するために提供されるもう 1 つの機能は、Server Core のサポートです。R2 では、Server Core に CA の役割をインストールできます。ただし、他の Active Directory 証明書サービス (AD CS) の役割サービスは、Server Core 上では使用できません。Server Core にインストールした CA は、certutil などのコマンドラインユーティリティを使用するか、リモートシステムから標準的な MMC を使用して管理できます。ハードウェアセキュリティモジュール (HSM) を使用する場合、HSM の製造元に、このような統合コンポーネントを Server Core 上で実行できるかどうかを確認した方がよいでしょう。

既存のシナリオの強化

Windows 7 と R2 では、既存の機能への追加的な強化が数多く行われます。まず、各 SKU での証明書テンプレートのサポートに変更が加えられます。以前の AD CS のリリースでは、自動登録機能を提供する高度な証明書テンプレート (バージョン 2 および 3) を使用するために、Enterprise Edition の CA を用意する必要がありました。Windows Server 2008 R2 では、Standard Edition の CA でもすべてのバージョンのテンプレートがサポートされます。また、R2 では、Simple Certificate Enrollment Protocol のサポートにもいくつかの変更が加えられます。R2 の SCEP コンポーネントでは、デバイスの更新要求とパスワードの再利用がサポートされます。

R2 の AD CS で提供される新機能は、ベストプラクティスアナライザです (図 3 参照)。BPA の目的は、管理者が設定した構成を、マイクロソフトの機能チームによって作成され、管理されているベストプラクティスデータベースと照らし合わせて、簡単に確認できるようにすることです。カスタマサポートサービスからのデータによると、AD CS に関する問い合わせ内容のほとんどは、構成の誤りに関連しているので、BPA を使用して、CA が正しく構成されているかどうかを簡単に確認できることによって、カスタマエクスペリエンスが向上します。BPA は、機関情報アクセス (AIA) や OCSP ポインタが存在するかどうか、証明書の有効期限が近づいているかどうか、信頼チェーンに関する問題が発生しているかどうかなどを確認します。

図 3 新しいベストプラクティスアナライザの実行

Windows の現在のリリースでは、エンドユーザーがクライアント認証用の証明書を選択することが困難な場合があります。認証に使用できる証明書が複数存在する場合、Windows では、ユーザーが特定の用途に適した証明書を選択するのに役立つ機能が提供されないので、ヘルプデスクへの問い合わせ件数が増加し、その結果、カスタマサポートコストがかかります。Windows 7 では、証明書の選択に使用するインターフェイスが大幅に強化され、これまでよりも簡単に、特定のシナリオに適した証明書を選択できるようになります。また、一覧に表示される項目の順序も変更され、対象のシナリオに最も適していると思われる証明書が既定で選択されるので、より賢明な判断を下すことができます。さらに、選択に使用する UI で、スマートカード上の証明書とファイルシステム上の証明書が区別されます。スマートカードの証明書は使用される可能性が高いので、一覧の最上部に表示されます。この区別は、図 4 のスクリーンショットで確認できます。以前のオペレーティングシステム上でも、Internet Explorer 8 によって、この強化されたフィルタ機能が提供されます (ただし、UI の変更は適用されません)。

図 4 より適切な証明書の提示

Software Plus Services

Windows 7 の設計プロセスで、チームは多くの一流 PKI ユーザーとの会議を開き、新しいリリースでどの領域に注目すべきかについて意見を出し合いました。非常に多くのユーザーが、組織の境界にまたがって (たとえば、ビジネスパートナー関係を結ぶ 2 つの企業間で) 証明書を管理することはきわめて難しいという考えを示しました。また、多くのユーザーが、PKI を効率的に管理するには専門的なスキルが必要であることから、管理を外部委託することが望ましいと考えていることがわかりました。Windows 7 と Windows Server 2008 R2 は、これらの要件を両方とも満たす新しいテクノロジを提供します。このテクノロジによって、組織の境界にまたがって簡単に証明書を準備できるようになると共に、ホストされた PKI ソリューション用の新しいビジネスモデルが確立されます。そのテクノロジとは、HTTP 登録機能です。

図 5 新しい登録モデル

HTTP 登録機能は、以前のリリースで自動登録に使用されていた従来の RPC/DCOM ベースのモデルに代わるテクノロジです (RPC ベースの手法は、R2 でも使用できます)。ただし、HTTP 登録機能は単なる登録プロトコルではなく、柔軟な認証オプションを使用して、証明書がどこに格納されているかや、提供先のコンピュータが管理されているかどうかに関係なく、証明書をエンドエンティティに提供できる、まったく新しい手法です。この新しいモデルによって、組織の境界にまたがった自動登録でこれまで発生していた問題の多くが解決され、サードパーティは、クライアントに追加のソフトウェアをインストールする必要なく自動登録サービスを簡単に提供するためのフレームワークを使用できるようになります。

HTTP 登録機能には、2 つの新しい HTTP ベースのプロトコルが実装されます。1 つ目のプロトコルは Certificate Enrollment Policy Protocol と呼ばれ、ユーザーが HTTPS セッション経由で証明書テンプレートを使用することを可能にします。有効なエンドエンティティには、信頼関係を確立していない別のフォレスト内のコンピュータや、ドメインに参加していないコンピュータ上のエンティティも含まれます。認証には、Kerberos、ユーザー名とパスワード、または証明書が使用されます。Certificate Enrollment Policy Protocol を使用すると、ユーザーがテンプレートをポーリングし、新しいまたは更新されたテンプレートに基づいて、いつ証明書を要求すればよいかを確認できるようになります。

Certificate Enrollment Service Protocol は、WS-Trust を拡張したプロトコルです。このプロトコルは、テンプレート情報を確認した後に、証明書を取得するために使用されます。Certificate Enrollment Service Protocol では、柔軟な認証方法がサポートされ、トランスポートには HTTPS が使用されます。

図 5 の例は、この新しい登録モデルのしくみを示しています。

手順 1. では、証明書の登録ポリシー Web サービス (R2 で新しく提供される役割サービス) を実行するサーバーに、Active Directory から証明書テンプレートが発行されます。これらのテンプレートを発行する管理者は、馴染みのある MMC やその他のツールを使用します。
手順 2. では、クライアントが HTTPS 経由で Web サービスにポーリングして、登録に使用できるテンプレートの一覧を確認します。クライアントは、グループポリシー、スクリプト、手動による構成などを使用して、Web サービスの URL を取得します。クライアントとして考えられるのは、ドメインに参加しているシステム、ビジネスパートナーのシステム、またはユーザーの自宅にあるシステムです。
手順 3. では、クライアントが、登録に使用するテンプレートを決定し、証明書の登録 Web サービスに、実際の登録の実行要求を送信します。
手順 4. では、証明書の登録 Web サービスを実行するサーバーが、CA に処理要求を送信します。
手順 5. では、CA が要求者に関する情報 (電子メールアドレスや DNS 名など) を Active Directory から検索します。CA は、発行する証明書にこの情報を含めます。
手順 6. では、CA が完成した証明書を証明書の登録 Web サービスに返します。
手順 7. では、証明書の登録 Web サービスが、HTTPS 経由でクライアントとのトランザクションを完了し、署名入りの証明書を送信します。

この新しいサービスの設計における重要な基本方針の 1 つは、柔軟性です。この設計がどのようにさまざまなシナリオに適合するかを説明しておくことは重要です。登録プロトコルが HTTPS なので、クライアントは、企業のファイアウォールの外側や、ISP 接続を利用する自宅など、どこからでも VPN を使用する必要なく簡単に証明書を登録できます。また、3 つの異なる認証方法がサポートされるので、クライアントは、組織の内部ドメインに参加するか、外部組織の信頼されていないドメインに参加するか、どのドメインにも参加しないかを選択できます。さらに、サーバー側コンポーネントは Web サービスとして実装されるので、CA から個別にインストールでき、セグメント化された環境をサポートします。

HTTP 登録機能では、ユーザーやデスクトップなどのエンドエンティティの証明書を登録する従来のシナリオだけでなく、信頼されたルート CA から証明書を準備するシナリオもサポートされます。ユーザーの S/MIME 証明書などのシナリオ、公開されている Web サーバー、および証明書の暗黙的な信頼が重要な役割を果たすその他のシステムはすべて、より自動化された登録処理からメリットを得られる可能性があります。たとえば、数多くの Web サーバーを所有する組織のほとんどは、Microsoft Office Excel ブックに格納されたサーバー名と有効期限の一覧を使用して、手動で証明書を管理します。HTTP 登録機能では、信頼されたルート CA によって提供されるサービスを使用して、このような Web サーバーに証明書を直接、自動的に提供できます。これにより、管理者は手動で Web サーバー上の証明書を管理する必要がなくなります。このようなソフトウェアとサービスの組み合わせによって、組織はネットワーク境界や組織の境界に基づいて設計を行う必要なく、要件に最も合った展開モデルを選択できるようになります。

関連情報

	Windows 生体認証フレームワーク (WBF) の紹介 microsoft.com/whdc/device/input/smartcard/WBFIntro.mspx
	連邦従業員および委託業者の個人識別情報の検証 (PIV) csrc.nist.gov/groups/SNS/piv/index.html
	Windows Server PKI ホーム microsoft.com/pki
	Windows PKI ブログ blogs.technet.com/pki

強力な認証

Windows 7 には、Windows 生体認証フレームワーク (WBF) を使用する生体認証デバイスのサポートが初めて組み込まれます。WBF は、まず消費者のシナリオを対象とした指紋ベースの認証に重点を置き、生体認証をより簡単に行えるようにすること、および生体認証をより密接にユーザーの操作に統合することを目指しています。統合されたドライバモデルによって、さまざまなデバイスの種類で、一貫したユーザーエクスペリエンスが提供され、それと同時に、Windows ログオン (ローカルとドメインの両方)、ユーザーアカウント制御 (UAC)、およびデバイス自動検出機能のサポートが提供されます。また、WBF は、生体認証を使用しない組織向けにフレームワークをグループポリシーによって無効にする方法を提供します。企業は、アプリケーションに生体認証を使用し、ドメインへのログオンには生体認証を使用しないようにすることもできます。また、強化されたデバイス管理機能を使用して、ドライバのインストールだけでなく、デバイスの使用も防止できるようになります。

Windows 7 では、生体認証の機能強化が導入されるだけでなく、スマートカードのシナリオにおけるユーザーと管理者の操作性も強化されます。スマートカードは、ドライバのインストールを Windows Update ベースで行うプラグアンドプレイデバイスとして扱われるようになります。プラグアンドプレイの検出処理とインストール処理は、ログオン前に行われます。つまり、スマートカードを使用してログオンする必要のあるユーザーは、カードが以前に検出されたことがない場合でもログオンできます。また、管理者特権を使用する必要なくインストールを実行できるので、最小特権環境にも適しています。

スマートカードクラスミニドライバでは NIST SP 800-73-1 がサポートされるので、連邦政府機関は、追加のミドルウェアを使用する必要なく、個人識別情報の検証 (PIV) カードを使用できます。また、新しい INCITS GICS (Butterfly) 標準もサポートされ、このドライバを使用するカードでプラグアンドプレイエクスペリエンスが提供されます。

さらに、Windows 7 では、生体認証ベースのスマートカードのロック解除機能がサポートされ、セキュリティで保護されたキーの挿入を可能にする新しい API が提供されます。そして、Windows 7 では、楕円曲線暗号 (ECC) スマートカード証明書のサポートも追加されます。これにより、ECC 証明書を登録し、ログオン時にその ECC 証明書を使用できるようになります。

まとめ

Windows 7 と Windows Server 2008 R2 では、Windows 2000 で自動証明書要求機能が導入されて以来、最も重要な新しい PKI テクノロジの一部が提供されます。この新機能によって、これまでよりも簡単かつ効率的に PKI を管理し、より優れた操作性をエンドユーザーに提供できるようになります。

Windows 7 と Windows Server 2008 R2 では、より効率的に PKI を運用しながら、自動登録機能を大幅に強化できる強力な新機能が提供されます。フォレストを越えた登録機能によって、組織に必要な CA の数が大幅に減少し、合併、吸収、および子会社売却時に、より簡単に運用中の PKI を管理できるようになります。また、管理者は、ベストプラクティスアナライザを使用して、一般的な構成上の問題を、障害が発生する前に簡単に検出できます。さらに、Server Core のサポートや非固定要求などの機能によって、これまでよりも簡単に、組織の特定の要件に合わせて CA を運用できるようになります。そして、HTTP 登録機能によって、新たな方法で、組織とネットワークの境界にまたがって自動的に証明書を準備できるようになります。

エンドユーザーは、Windows 7 の PKI 機能によって、毎日の業務で、これまでよりも簡単に証明書を使用できるようになります。また、強化された証明書インターフェイスを使用して、より簡単に特定の目的に合った証明書を選択し、よりすばやく認証を完了できます。さらに、プラグアンドプレイベースのドライバのインストールや、カード標準のネイティブサポートといった、スマートカードに関する機能強化を利用して、より短時間でカードをユーザーのシステム上で動作させることができるようになります。そして、生体認証のネイティブサポートによって、エンドユーザーと管理者の両方に、より一貫性の高いシームレスな操作性が提供されます。

まだベータ版を試していない場合は、ぜひ試してみてください。フィードバックツールまたは blogs.technet.com/pki で公開されているブログから、感想をお寄せいただければ幸いです。

John Morello は、2000 年からマイクロソフトに勤務しています。5 年間 Microsoft Consulting Services に従事し、Fortune 500 の企業、および世界中の政府機関と軍事機関向けのセキュリティソリューションを設計していました。現在は、Windows Server グループでプリンシパルリードプログラムマネージャを務めています。John は TechNet Magazine に多くの記事を寄稿し、Microsoft Press から発行されたいくつかの書籍の執筆にも携わりました。また、TechEd や IT Forum などのカンファレンスでもよく講演を行っています。blogs.technet.com/WinCAT で、所属チームのブログが公開されています。

次の方法で共有

目次

その他のリソース