フェデレーション サーバーのための証明要件

Active Directory フェデレーション サービス (AD FS) 2.0 のすべての設計では、通信をセキュリティで保護し、インターネット クライアントとActive Directory 2. 0 フェデレーション サービスの間のユーザー認証に対応するために、さまざまな証明書を使用する必要があります。各Active Directory 2. 0 フェデレーション サービスは、AD FS 2.0 の通信に参加するためにサービス通信証明書とトークン署名証明書を必要とします。次の表に、Active Directory 2. 0 フェデレーション サービスに関連付けられる証明書の種類をまとめます。

サービス通信証明書は、IIS 用の Microsoft 管理コンソール (MMC) スナップインを使用して、要求およびインストールできます。SSL 証明書の使用に関する一般的な情報については、「IIS 7.0: IIS 7.0 で SSL (Secure Sockets Layer) を構成するhttps://go.microsoft.com/fwlink/?LinkID=108544 」(https://go.microsoft.com/fwlink/?LinkID=108544) および「IIS 7.0: IIS 7.0 でサーバー証明書を構成するhttps://go.microsoft.com/fwlink/?LinkID=108545」(https://go.microsoft.com/fwlink/?LinkID=108545) を参照してください。

AD FS 2.0 では、デジタル署名で使用される セキュア ハッシュ アルゴリズム (SHA) レベルを SHA-1 または SHA-256 (より安全) のいずれかに変更できます。AD FS 2.0 は、MD5 (Makecert.exe コマンドライン ツールで使用される既定のハッシュ アルゴリズム) など、その他のハッシュ方式を用いた証明書の使用はサポートしません。セキュリティ ベスト プラクティスとしては、すべての署名に対して SHA-256 (既定で設定) を使用することをお勧めします。SHA-1 は、Microsoft 以外の製品または AD FS 1. x など、SHA-256 を使用する通信をサポートしない製品と連携する必要がある場合にのみ使用することをお勧めします。

証明機関 (CA) に関する方針を決定する

AD FS 2.0 では、証明書が CA によって発行される必要はありません。ただし、サービス通信証明書は、AD FS 2.0 クライアントによって信頼される必要があります。これらの種類の証明書として自己署名証明書を使用することはお勧めしません。

自己署名の SSL 証明書を運用環境で使用すると、アカウント パートナー組織に属する悪意のあるユーザーにより、リソース パートナー組織のActive Directory 2. 0 フェデレーション サービスが制御されてしまう可能性があります。このセキュリティ リスクが存在する理由は、自己署名証明書がルート証明書であることです。これらの証明書は、別のActive Directory 2. 0 フェデレーション サービス (リソース Active Directory 2. 0 フェデレーション サービスなど) の信頼されたルート ストアに追加する必要があります。そのため、このサーバーが危険にさらされる可能性があります。

CA からトークン署名証明書およびサービス通信証明書を受け取ったら、証明書を両方ともローカル コンピューターの個人証明書ストアにインポートします。どちらの証明書も、MMC の証明書スナップインを使用して個人ストアにインポートできます。

証明書スナップインを使用する代わりに、サービス通信証明書を既定の Web サイトに割り当てる際、IIS マネージャー スナップインを使用してサービス通信証明書をインポートすることもできます。詳細については、「サーバー認証証明書を既定の Web サイトにインポートする [Deploy2]」(英語) を参照してください。

Active Directory 2. 0 フェデレーション サービスとなるコンピューターに AD FS 2.0 ソフトウェアをインストールする前に、証明書が両方ともローカル コンピューターの個人証明書ストアに含まれており、サービス通信証明書が既定の Web サイトに割り当てられていることを確認してください。Active Directory 2. 0 フェデレーション サービスをセットアップするために必要なタスクの順序については、「チェックリスト: フェデレーション サーバーのセットアップ」(英語) を参照してください。

セ キュリティと予算の要件に基づいて、各証明書を公的 CA と企業 CA のどちらから取得するかを慎重に検討してください。次の図は、指定された証明書の種類に対して推奨される CA 発行者を示します。この推奨事項は、セキュリティとコストに関するベスト プラクティスの方法を反映したものです。

トークン署名証明書

フェ デレーション サーバーでは、攻撃者がフェデレーション リソースに許可なくアクセスして、セキュリティ トークンを改ざんまたは偽造することを防ぐために、トークン署名証明書が必要です。トークン署名証明書で使用される秘密/公開キーの組は、すべてのフェデ レーション パートナーシップの最も重要な検証メカニズムです。これらのキーは、セキュリティ トークンが有効なパートナーのフェデレーション サーバーによって発行され、転送中に変更されていないことを検証します。

パートナー間でトークン署名証明書が使用される方法}
す べてのトークン署名証明書には、セキュリティ トークンに (秘密キーを使用して) デジタル署名するために使用される、暗号化用の秘密キーと公開キーが含まれます。パートナーのフェデレーション サーバーがこれらの証明書を受け取ると、これらのキーにより、暗号化されたセキュリティ トークンの信頼性が (公開キーを使用して) 検証されます。

各 セキュリティ トークンは、アカウント パートナーによってデジタル署名されるため、リソース パートナーは、セキュリティ トークンが実際にそのアカウント パートナーによって発行され、かつ変更されていないことを確認できます。デジタル署名は、パートナーのトークン署名証明書の公開キー部分によって検証され ます。署名が検証されると、リソース Active Directory 2. 0 フェデレーション サービスは、その組織で使用する独自のセキュリティ トークンを生成し、独自のトークン署名証明書を使用してセキュリティ トークンに署名します。

フェデレーション パートナー環境で、トークン署名証明書が CA によって発行されている場合は、以下を確認してください。

1. 証明書の証明書失効リスト (CRL) に、Active Directory 2. 0 フェデレーション サービスを信頼する証明書利用者と Web サーバーがアクセスできること。

2. ルート CA 証明書は、Active Directory 2. 0 フェデレーション サービスを信頼する証明書利用者と Web サーバーによって信頼されていること。

リソース パートナーの Web サーバーは、トークン署名証明書の公開キーを使用して、セキュリティ トークンがリソース Active Directory 2. 0 フェデレーション サービスによって署名されていることを確認します。その後、Web サーバーは、クライアントへの適切なアクセスを許可します。

トークン署名証明書が AD FS 2.0 で機能するには、以下の要件を満たしている必要があります。

• トークン署名証明書によってセキュリティ トークンへの署名が正しく行われるためには、トークン署名証明書に秘密キーが含まれている必要があります。

• AD FS 2.0 サービス アカウントは、ローカル コンピューターの個人ストアにあるトークン署名証明書の秘密キーへのアクセス権を持つ必要があります。

  これは、セットアップ時に処理されます。また、後からトークン署名証明書を変更した場合には、AD FS 2.0 管理スナップインを使用して、このアクセスを許可することもできます。

公開キー基盤 (PKI) のベスト プラクティスとして、秘密キーを複数の目的の間で共有しないことをお勧めします。したがって、Active Directory 2. 0 フェデレーション サービスにインストールしたサービス通信証明書を、トークン署名証明書として使用しないでください。

トークン署名証明書の展開に関する考慮事項

新しい AD FS 2.0 のインストール時に最初のActive Directory 2. 0 フェデレーション サービスを展開する場合は、トークン署名証明書を取得して、そのActive Directory 2. 0 フェデレーション サービスのローカル コンピューターの個人証明書ストアにインストールする必要があります。トークン署名証明書は、エンタープライズ CA または公的 CA に要求するか、自己署名証明書を作成することで取得できます。

AD FS 2.0 ファームを展開する場合、トークン署名証明書のインストール方法は、サーバー ファームの作成方法によって異なります。展開用にトークン署名証明書を取得する際には、次の 2 つのサーバー ファームのオプションを検討できます。

• 1 つのトークン署名証明書の秘密キーをファーム内のすべてのActive Directory 2. 0 フェデレーション サービス間で共有する場合。

  Active Directory 2. 0 フェデレーション サービス ファーム環境では、すべてのActive Directory 2. 0 フェデレーション サービスで同じトークン署名証明書を共有 (または再利用) することをお勧めします。CA から発行されたトークン署名証明書がエクスポート可能とマークされている場合は、1 つの証明書をActive Directory 2. 0 フェデレーション サービスにインストールし、その秘密キーをエクスポートできます。

  次の図に示すように、1 つのトークン署名証明書の秘密キーを、ファーム内のすべてのActive Directory 2. 0 フェデレーション サービスで共有できます。公的 CA からトークン署名証明書を取得する場合、このオプションを使用すると、この後に示す "一意のトークン署名証明書" オプションと比べてコストを削減できます。
  

• ファーム内のActive Directory 2. 0 フェデレーション サービスごとに一意のトークン署名証明書を使用する場合。

  ファーム内で一意の証明書を複数使用する場合、そのファーム内のサーバーは、各自で一意の秘密キーを使用してトークンに署名します。

  次の図に示すように、ファーム内のActive Directory 2. 0 フェデレーション サービスごとに、個別のトークン署名証明書を取得できます。公的 CA からトークン署名証明書を取得する場合、このオプションを使用するとコストが多くかかります。
  

エンタープライズ CA として Microsoft 証明書サービスを使用する場合の証明書のインストール方法については、「IIS 7.0: IIS 7.0 でドメイン サーバー証明書を作成する」(https://go.microsoft.com/fwlink/?LinkId=108548) を参照してください。

公的 CA からの証明書のインストールの詳細については、「IIS 7.0: インターネット サーバー証明書を要求する」(https://go.microsoft.com/fwlink/?LinkId=108549) を参照してください。

自己署名証明書のインストールの詳細については、「IIS 7.0: IIS 7.0 で自己署名入りサーバー証明書を作成する」(https://go.microsoft.com/fwlink/?LinkID=108271) を参照してください。

サービス通信証明書

Active Directory 2. 0 フェデレーション サービスでは、クライアント コンピューターがサーバーの ID を確立できるように、サービス通信証明書を使用する必要があります。Active Directory 2. 0 フェデレーション サービスは自身のソースを公開するサービス通信証明書をクライアント コンピューターに提示するためです。これによってクライアント コンピューターは、証明書によって識別された組織だけが送信されたデータを使用できることを確認できます。

サービス通信証明書の要件
トークン署名証明書が AD FS 2.0 で機能するには、以下の要件を満たしている必要があります。

• サービス通信証明書には、サーバー認証の拡張キー使用法 (EKU) が含まれている必要があります。

• 証明書失効リスト (CRL) には、サービス通信証明書からルート CA 証明書まで、チェーン内のすべての証明書がアクセスできる必要があります。また、ルート CA は、このActive Directory 2. 0 フェデレーション サービスを信頼するすべてのActive Directory 2. 0 フェデレーション サービス プロキシおよび Web サーバーによって信頼されている必要があります。

• サービス通信証明書で使用されるサブジェクト名は、フェデレーション サービスのプロパティのフェデレーション サービス名と一致する必要があります。

サービス通信証明書の展開に関する考慮事項

サービス通信証明書は、すべてのActive Directory 2. 0 フェデレーション サービスが 同じ証明書を使用するように構成してください。フェデレーション Web シングル サインオン (SSO) 設計を展開する場合は、公的 CA から発行されたサービス通信証明書を使用することをお勧めします。これらの証明書は、IIS マネージャー スナップインを使用して要求およびインストールできます。

テスト ラボ環境のActive Directory 2. 0 フェデレーション サービスでは、自己署名のサービス通信証明を問題なく使用できます。しかし、運用環境では、公的 CA からサービス通信証明書を取得することをお勧めします。実際の展開で、自己署名のサービス通信証明書を使用してはいけない理由は次のとおりです。

• 自己署名の SSL 証明書は、リソース パートナー組織の各Active Directory 2. 0 フェデレーション サービスの信頼されたルート ストアに追加する必要があります。これだけで攻撃者によるリソース Active Directory 2. 0 フェデレーション サービスへの侵入が可能になるわけではありませんが、自己署名証明書を信頼すると、コンピューターの攻撃対象領域が拡大され、証明書の署名者が信頼できない場合にセキュリティが脆弱になる可能性があります。

• ユー ザー エクスペリエンスが低下します。クライアントがフェデレーション リソースにアクセスしようとすると、"このセキュリティ証明書は、信頼する会社から発行されていません。" というセキュリティ警告プロンプトが表示されます。自己署名証明書は信頼されていないため、これは正常な動作です。

  必要に応じて、グループ ポリシーを使用し、AD FS 2.0 サイトにアクセスしようとする各クライアント コンピューターの信頼されたルート ストアに自己署名証明書を手動で移動することで、この状況を回避できます。

• CA は、秘密キーのアーカイブ、更新、失効など、自己署名証明書では提供されない証明書ベースの機能も備えています。

証明書失効リスト

使用する証明書に CRL が含まれている場合、その証明書を使用して構成されたサーバーは、その CRL を配布するサーバーにアクセスできる必要があります。