5.3. セキュリティードメインの計画


セキュリティードメイン は PKI サービスのレジストリーです。CA などの PKI サービスは、これらのドメインに独自の情報を登録するため、PKI サービスのユーザーはレジストリーを確認して他のサービスを検索できます。Certificate System のセキュリティードメインサービスは、Certificate System サブシステムの PKI サービスの登録と、共有信頼ポリシーのセットの両方を管理します。
レジストリーは、ドメイン内でサブシステムによって提供されるすべての PKI サービスの完全なビューを提供します。各 Certificate System サブシステムは、ホストまたはセキュリティードメインのメンバーのいずれかである必要があります。
CA サブシステムは、セキュリティードメインをホストできる唯一のサブシステムです。セキュリティードメインは、特権ユーザーおよびグループ情報の CA 内部データベースを共有して、セキュリティードメインを更新し、新しい PKI サービスを登録し、証明書を発行できるユーザーを決定します。
セキュリティードメインは CA の設定中に作成され、セキュリティードメインの CA の LDAP ディレクトリーにエントリーが自動的に作成されます。各エントリーには、ドメインに関する重要な情報がすべて含まれます。セキュリティードメインを登録する CA を含む、ドメイン内のすべてのサブシステムは、セキュリティードメインコンテナーエントリーの下に記録されます。
CA の URL はセキュリティードメインを一意に識別する。セキュリティードメインには、Example Corp Intranet PKI などの分かりやすい名前も付与されます。他のすべてのサブシステム (KRA、TPS、TKS、OCSP、およびその他の CA) は、サブシステムの設定時にセキュリティードメイン URL を指定して、セキュリティードメインのメンバーになる必要があります。
セキュリティードメイン内の各サブシステムは、異なるサーバーやブラウザーから取得できる同じ信頼ポリシーと信頼されたルートを共有します。セキュリティードメインで利用可能な情報は、新しいサブシステムの設定中に使用されます。これにより、設定プロセスが合理化および自動化されます。たとえば、TPS が CA に接続する必要がある場合、TPS はセキュリティードメインを参照して、使用可能な CA のリストを取得できます。
各 CA には独自の LDAP エントリーがあります。セキュリティードメインは、CA エントリーの下にある組織グループです。
ou=Security Domain,dc=server.example.com-pki-ca
次に、セキュリティードメイン組織グループの下に各サブシステムタイプのリストがあり、グループタイプを識別するための特別なオブジェクトクラス (pkiSecurityGroup) があります。
cn=KRAList,ou=Security Domain,o=pki-tomcat-CA
objectClass: top
objectClass: pkiSecurityGroup
cn: KRAList
各サブシステムインスタンスは、エントリータイプを識別するための特別な pkiSubsystem オブジェクトクラスを使用してそのグループのメンバーとして保存されます。
dn: cn=kra.example.com:8443,cn=KRAList,ou=Security Domain,o=pki-tomcat-CA
objectClass: top
objectClass: pkiSubsystem
cn: kra.example.com:8443
host: server.example.com
UnSecurePort: 8080
SecurePort: 8443
SecureAdminPort: 8443
SecureAgentPort: 8443
SecureEEClientAuthPort: 8443
DomainManager: false
Clone: false
SubsystemName: KRA kra.example.com 8443
サブシステムが操作を実行するために別のサブシステムに接続する必要がある場合は、(CA の管理ポートを介して接続するサーブレットを呼び出すことにより) サブシステムがセキュリティードメインをホストする CA に接続します。次に、セキュリティードメイン CA は、LDAP データベースからサブシステムに関する情報を取得し、その情報を要求元のサブシステムに返します。
サブシステムはサブシステム証明書を使用してセキュリティードメインに対して認証します。
セキュリティードメインを計画するときに以下を考慮してください。
  • セキュリティードメインをホストする CA は外部認証局によって署名できます。
  • 複数のセキュリティードメインを組織内に設定することができます。ただし、各サブシステムは 1 つのセキュリティードメインにのみ属できます。
  • ドメイン内のサブシステムをクローンできます。サブシステムインスタンスは、システム負荷を分散し、フェイルオーバーポイントを提供します。
  • セキュリティードメインは、CA と KRA との間の設定を合理化します。KRA は、管理者が証明書を手動で CA にコピーする必要がなく、KRA コネクター情報をプッシュして証明書を CA に自動的に転送できます。
  • Certificate System セキュリティードメインを使用すると、オフラインの CA を設定できます。このシナリオでは、オフラインルートには独自のセキュリティードメインがあります。オンラインの下位 CA はすべて、異なるセキュリティードメインに属します。
  • セキュリティードメインは、CA と OCSP の間の設定を簡素化します。OCSP は、CA が OCSP 公開を設定するために、その情報を CA にプッシュし、CA から CA 証明書チェーンを取得して、内部データベースに格納することもできます。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.