証明書とキー

[アーティクル]
11/09/2015

更新日: 2015 年 6 月 19 日

適用先:Azure

Microsoft Azure Active Directory Access Control (Access Control サービスまたは ACS とも呼ばれます) には、トークンの署名と暗号化を行う 2 つの異なる方法が用意されています。秘密キーを使用した X.509 証明書と 256 ビット対称キーです。各証明書またはキーを、名前空間における特定の証明書利用者アプリケーションまたはすべての証明書利用者アプリケーションのトークンに署名するように構成し、証明書とキーをプライマリまたはセカンダリとして指定できます。トークン署名、暗号化、暗号化解除の証明書とキーを追加して構成するには、ACS 管理サービスまたは ACS 管理ポータルを使用します。

トークンへの署名

ACS は、X.509 証明書 (秘密キーを使用) または 256 ビット対称キーで発行するすべてのセキュリティトークンに署名します。署名資格情報の種類 (証明書またはキー) の選択は、ACS で発行されたトークンに対して選択するトークン形式によって異なります。詳細については、「証明書利用者アプリケーションのトークン署名」を参照してください。作成する署名資格情報の種類を選択する場合は、次のことを考慮してください。

SAML トークンは X.509 証明書で署名されます。 SAML は、Windows Identity Foundation (WIF) で構築されたアプリケーションによって使用される既定のトークン形式です。 SAML トークンは、WS-Federation や WS-Trust などの、複数のプロトコルで発行できます。
SWT トークンは 256 ビット対称キーで署名されます。 SWT トークンは、OAuth WRAP や WS-Federation などの、複数のプロトコルで発行できます。
JWT トークンは X.509 証明書または 256 ビット対称キーで署名できます。 JWT トークンは、WS-Federation、WS-Trust、および OAuth 2.0 などの、複数のプロトコルで発行できます。

名前空間または専用の証明書およびキー

署名証明書または対称キーを構成して、Access Control名前空間全体、または名前空間内の特定の証明書利用者アプリケーションにのみ使用できます。違いは次のとおりです。

Access Control名前空間 —Access Control名前空間全体に署名証明書またはキーが構成されている場合、ACS は証明書またはキーを使用して、アプリケーション固有の証明書またはキーを持たないこの名前空間内のすべての証明書利用者アプリケーションのトークンに署名します。名前空間スコープの証明書は、ACS WS-Federation メタデータへの署名にも使用されます。
専用:特定の証明書利用者アプリケーションに使用する署名証明書またはキーを構成する場合、ACS は署名証明書またはキーを使用して、指定された証明書利用者アプリケーションに配信されるトークンに署名します。

専用対称キーを作成または入力すると、ACS は専用キーを使用してアプリケーションのトークンに署名します。専用キーの有効期限が切れ、置き換えられない場合、ACS はAccess Control名前空間の対称キーを使用してアプリケーションのトークンに署名します。

注意

セキュリティのベストプラクティスとして、対称キーを使用する場合は、各証明書利用者アプリケーションの専用キーを作成します。 X.509 証明書は、Access Control名前空間内の複数のアプリケーションで安全に共有できます。
Microsoft が管理する証明書利用者アプリケーションを管理対象の名前空間に追加する (Service Bus 証明書利用者アプリケーションを Service Bus 名前空間に追加するなど) 場合は、アプリケーション固有 (専用) の証明書やキーを使用しないでください。代わりに、管理対象の名前空間のすべてのアプリケーションに対して構成された証明書とキーを使用する ACS オプションを選択します。他のすべての証明書利用者アプリケーションには、アプリケーション固有の証明書とキーを使用します。詳細については、「マネージド名前空間」を参照してください。
ACCESS CONTROL名前空間の X.509 証明書を使用して JWT トークンに署名する証明書利用者アプリケーションを構成すると、ACS 管理ポータルの証明書利用者アプリケーションのページに、Access Control名前空間証明書とAccess Control名前空間キーへのリンクが表示されます。ただし、ACS は名前空間証明書のみを使用して証明書利用者アプリケーションのトークンに署名します。

署名証明書は通常、名前空間におけるすべての証明書利用者アプリケーションのトークンに署名するために使用されます。名前空間署名証明書の公開キーコンポーネントは ACS WS-Federation メタデータに発行されるため、証明書利用者アプリケーションはそれらの構成を自動化できます。特定の証明書利用者アプリケーションにのみ割り当てられる証明書の公開キーは、ACS WS-Federation メタデータには存在せず、証明書利用者アプリケーションの署名証明書を個別に制御する必要がある場合にのみ使用されます。

プライマリ証明書とキー

ACS では、複数の証明書とキーを保持できますが、指定された証明書とキーのみを使用してトークンに署名します。署名用に指定された証明書およびキーは、プライマリ証明書およびキーと呼ばれます。

証明書またはキーをプライマリとして指定するには、証明書またはキーのページで [プライマリにする] 項目を選択します。別の証明書をプライマリとして指定するには、他の証明書またはキーのページで [プライマリにする] 項目を選択します。その場合、ACS は既存のプライマリ証明書またはキーを非プライマリに自動的に降格します。

1 つ以上の証明書またはキーがプライマリである場合、そのプライマリ証明書またはキーが無効か期限切れになっても、非プライマリ証明書とキーは、管理者によってプライマリステータスに昇格されるまで署名では使用されません。ただし、どの証明書 (またはキー) もプライマリでない場合、ACS は最も早い有効な開始日を持つ非プライマリ証明書を使用します。

プライマリ証明書と非プライマリ証明書の両方の公開キーコンポーネントは、プログラムによる証明書のロールオーバーを有効にするために ACS WS-Federation メタデータに発行されます。ただし、ACS では、プライマリ証明書とキーのみを使用してトークンに署名します。

署名キーの有効日と有効期限

256 ビット対称キーを追加する場合は、有効日と有効期限も指定する必要があります。有効日はこのキーが有効になる日付を示します。有効期限は、このキーが期限切れとなり、トークンへの署名で使用できなくなる日付を示します。

トークンの暗号化

ACS では、ACS が証明書利用者アプリケーションに発行する SAML 1.1 または SAML 2.0 トークンを暗号化するように選択できます。

重要

ACS では、SWT または JWT トークンの暗号化はサポートされていません。

トークンの暗号化は、WS-Trust プロトコルで proof-of-possession トークンを使用する Web サービスで必要です。 ACS を使用してこのような証明書利用者アプリケーションの認証を管理する場合は、この証明書利用者アプリケーションに対して ACS によって発行されたすべてのトークンを暗号化する必要があります。他のすべてのシナリオでは、トークンの暗号化は省略できます。

ACS は、公開キー (.cer ファイル) を含む X.509 証明書を使用して SAML トークンを暗号化します。証明書利用者アプリケーショントークンは、その X.509 証明書の秘密キーを使用して、トークンの暗号化を解除します。詳細については、「証明書利用者アプリケーションのトークン暗号化」を参照してください。

トークンの暗号化解除

ACS は、WS-Federation ID プロバイダーからの暗号化されたトークンを受け入れます。次に例を示します。 WS-Federation ID プロバイダーは、ACS からメタデータWS-Federationインポートするときに X.509 証明書の公開キーを受け取り、この公開キーを使用して ACS に転送されるセキュリティトークンを暗号化します。 ACS は、この X.509 証明書の秘密キーを使用してトークンの暗号化を解除します。詳細については、「方法: AD FS 2.0 を ID プロバイダーとして構成する」を参照してください。

プライマリトークン暗号化解除証明書

証明書利用者アプリケーションまたはAccess Control名前空間に対して、複数のトークン暗号化解除証明書を保持できます。証明書を プライマリとして指定すると、ACS はその証明書を使用してWS-Federation ID プロバイダーからトークンの暗号化を解除し、プライマリ証明書の使用が失敗した場合にのみ非プライマリ証明書を使用します。

暗号化解除証明書をプライマリとして指定するには、その証明書のページで [プライマリにする] 項目を選択します。別の証明書をプライマリとして指定するには、他の証明書のページで [プライマリにする] 項目を選択します。その場合、ACS は、既存のプライマリ暗号化解除証明書を非プライマリに自動的に降格します。

X.509 証明書ファイルに関する ACS の制限事項

ACS では、公開キー (.cer ファイル) のみを含む X.509 証明書は、サービス ID の作成、ID プロバイダーの署名の検証、または SAML トークンの暗号化時に使用できます。 ACS で使用するには、公開キー (.cer ファイル) のみを含む X.509 証明書ファイルを DER エンコードする必要があります。 Base64 でエンコードされた証明書ファイルは現在サポートされていません。 base64 でエンコードされた証明書を ACS にアップロードすると、ACS がその証明書を必要とする受信トークンを受信すると、検証エラーが発生します。

ACS では、X.509 証明書は自己署名であるか、署名され、公開証明機関に直接チェーンされている必要があります。 ACS は、プライベート証明機関によって発行された証明書では機能しません。

注意

ACS にインポートされた X.509 証明書の有効期限が切れてはなりません。

X.509 証明書の取得

トークン署名、トークン暗号化、または暗号化解除で使用する X.509 証明書を取得する方法はいくつかあります。使用する方法は、要件と組織で使用可能なツールによって異なります。

商用証明機関 - 商用証明機関から X.509 証明書を購入することができます。

Self-Signed証明書の生成- ACS で使用する独自の自己署名証明書を生成できます。 Windows ベースのオペレーティングシステムを実行している場合は、Microsoft Windows ソフトウェア開発キット (https://go.microsoft.com/fwlink/?LinkID=214104) に含まれているツールである MakeCert.exe を使用して、自己署名証明書を生成できます。

たとえば、以下のコマンドでは個人証明書ストアに自己署名証明書が生成されます。

MakeCert.exe -r -pe -n "CN=<service_namespace_name>.accesscontrol.windows.net" -sky exchange -ss my -len 2048 –e <1 year from today>

ここで<、service_namespace_name>はAccess Control名前空間の名前です。

その後、個人用ストアから .pfx ファイルとして秘密キーをエクスポートし、ACS 管理ポータルを使用して ACS にアップロードできます。

自己署名証明書のエクスポート

次の手順では、Windows 8、Windows Server 2012、または実行されているコンピューターから自己署名証明書をエクスポートする方法について説明します。

自己署名証明書をエクスポートするには

MMC.exeを開始し、MMC コンソールに 証明書 スナップインを追加します。
[証明書 - 現在のユーザー]、[個人]、[証明書] の順にダブルクリックします。
証明書を右クリックし、[すべてのタスク] をクリックしてから [エクスポート] をクリックします。
証明書のエクスポートウィザードの [ようこそ] ページで、[次へ] をクリックします。
[秘密キーのエクスポート] ページで、[はい、秘密キーをエクスポートします] をクリックしてから [次へ] をクリックします。
[エクスポートファイルの形式] ページで、[Personal Information Exchange - PKCS #12 (.PFX)] をクリックします。
[パスワード] フィールドに、パスワードと確認用のパスワードを入力してから [次へ] をクリックします。
[ファイル名] フィールドに、パスとファイル名拡張子が .pfx のファイル名を入力してから [次へ] をクリックします。
[完了] をクリックします。