検索

2.3. Certificate System のアーキテクチャーの概要

download PDF
それぞれのサービスが異なるサービスを提供しますが、すべての RHCS サブシステム (CA、KRA、OCSP、TKS、TPS) が共通のアーキテクチャーを共有します。以下のアーキテクチャー図は、これらのすべてのサブシステムによって共有される共通のアーキテクチャーを示しています。

2.3.1. Java Application Server

Java アプリケーションサーバーは、サーバーアプリケーションを実行する Java フレームワークです。Certificate System は、Java アプリケーションサーバー内で実行されるように作られています。現在、サポートされている唯一の Java アプリケーションサーバーは Tomcat 8 です。他のアプリケーションサーバーのサポートは今後追加される可能性があります。詳細は、http://tomcat.apache.org/ を参照してください。
Certificate System の各インスタンスは Tomcat サーバーインスタンスです。Tomcat 設定は server.xml に保存されます。https://tomcat.apache.org/tomcat-8.0-doc/config/ では、Tomcat 設定の詳細情報が提供されています。
各 Certificate System サブシステム (CA や KRA など) は、Tomcat に Web アプリケーションとしてデプロイされます。Web アプリケーション設定は web.xml ファイルに保存され、Java Servlet 3.1 仕様で定義されます。詳細は https://www.jcp.org/en/jsr/detail?id=340 を参照してください。
Certificate System の設定自体は CS.cfg に保存されます。
これらのファイルの場所は、「インスタンスのレイアウト」 を参照してください。

2.3.2. Java Security Manager

Java サービスには、アプリケーションを実行するための安全でない操作と安全な操作を定義する Security Manager オプションがあります。サブシステムがインストールされると、Security Manager が自動的に有効になります。つまり、各 Tomcat インスタンスは Security Manager が実行されている状態で起動します。
pkispawn を実行し、独自の Tomcat セクションで pki_security_manager=false オプションを指定するオーバーライド設定ファイルを使用すると、Security Manager が無効になります。
以下の手順に従って、インストールされたインスタンスから Security Manager を無効にすることができます。
  1. # systemctl stop pki-tomcatd@instance_name.service
    または (nuxwdog ウォッチドッグを使用している場合)
    # systemctl stop pki-tomcatd-nuxwdog@instance_name.service
  2. /etc/sysconfig/instance_name ファイルを開き、SECURITY_MANAGER="false" を設定します。
  3. # systemctl start pki-tomcatd@instance_name.service
    または (nuxwdog ウォッチドッグを使用している場合)
    # systemctl start pki-tomcatd-nuxwdog@instance_name.service
インスタンスが起動または再起動すると、Java セキュリティーポリシーは、以下のファイルから pkidaemon により構築または再構築されます。
/usr/share/pki/server/conf/catalina.policy
/usr/share/tomcat/conf/catalina.policy
/var/lib/pki/$PKI_INSTANCE_NAME/conf/pki.policy
/var/lib/pki/$PKI_INSTANCE_NAME/conf/custom.policy
次に、/var/lib/pki/instance_name/conf/catalina.policy に保存されます。

2.3.3. インターフェイス

2.3.3.1. サーブレットインターフェイス

各サブシステムには、サブシステムのさまざまな部分との対話を可能にするインターフェイスが含まれています。すべてのサブシステムが共通の管理インターフェイスを共有し、エージェントに割り当てられたタスクを実行するエージェントインターフェイスがあります。CA サブシステムには、エンドエンティティーを PKI に登録することができるエンドエンティティーのインターフェイスがあります。OCSP Responder サブシステムには、エンドエンティティーとアプリケーションが現在の証明書失効ステータスをチェックできるエンドエンティティーのインターフェイスがあります。最後に、TPS には Operator インターフェイスがあります。
アプリケーションサーバーは接続エントリーポイントを提供しますが、Certificate System は各インターフェイスに固有のサーブレットを提供してインターフェイスを完了します。
各サブシステムのサーブレットは、対応する web.xml ファイルで定義されます。同じファイルは各サーブレットの URL と、サーブレットにアクセスするセキュリティー要件も定義します。詳細は、「Java Application Server」を参照してください。

2.3.3.2. 管理インターフェイス

エージェントインターフェイスは、エージェントのエントリーポイントからの HTML フォームの送信を処理する Java サーブレットを提供します。エージェントサーブレットは、各フォーム送信で提供された情報に基づいて、証明書の承認、証明書の更新、証明書の失効の要求の編集と承認、証明書プロファイルの承認などのエージェントタスクを実行できるようにします。KRA サブシステムまたは TKS サブシステムのエージェントインターフェイス、または OCSP Responder はサブシステムに固有のものです。
非 TMS セットアップでは、エージェントインターフェイスは、CA から KRA への信頼できる接続の CIMC 間境界通信にも使用されます。この接続は SSL クライアント認証によって保護され、Trusted Manager と呼ばれる信頼されている個別のロールによって区別されます。エージェントロールと同様、Trusted Manager (CIMC 間境界接続専用に作成された疑似ユーザー) は、SSL クライアント認証を受ける必要があります。ただし、エージェントのロールとは異なり、エージェント機能は提供されません。
TMS 設定では、CIMC 間境界通信は、TPS から CA、TPS から KRA、および TPS から TKS に送信されます。

2.3.3.3. エンドエンティティーインターフェイス

CA サブシステムでは、エンドエンティティーのインターフェイスは、エンドエンティティーエントリーポイントからの HTML フォームの送信を処理する Java サーブレットを提供します。フォーム送信から受け取った情報に基づいて、エンドエンティティーサーブレットにより、エンドエンティティーが証明書を登録、更新、独自の証明書を取り消します。OCSP Responder サブシステムの End-Entity インターフェイスは、OCSP リクエストを許可および処理するための Java サーブレットを提供します。KRA、TKS、および TPS サブシステムは、End-Entity サービスを提供しません。

2.3.3.4. Operator インターフェイス

オペレーターインターフェイスは、TPS サブシステムにのみあります。

2.3.4. REST インターフェイス

Hitsal state transfer (REST) は、HTTP を使用して Web サービスを定義し、整理する手段で、他のアプリケーションとの相互運用性を単純化します。Red Hat Certificate System は、サーバーのさまざまなサービスにアクセスするための REST インターフェイスを提供します。
Red Hat Certificate System の REST サービスは、RESTEasy フレームワークを使用して実装されます。RESTEasy は実際には Web アプリケーションのサーブレットとして実行されるため、RESTEasy の設定は、対応するサブシステムの web.xml にあります。RESTEasy の詳細は、http://resteasy.jboss.org/ を参照してください。
各 REST サービスは、個別の URL として定義されます。以下に例を示します。
  • CA 証明書サービス: http://<host_name>:<port>/ca/rest/certs/
  • KRA キーサービス: http://<host_name>:<port>/kra/rest/agent/keys/
  • TKS ユーザーサービス: http://<host_name>:<port>/tks/rest/admin/users/
  • TPS グループサービス: http://<host_name>:<port>/tps/rest/admin/groups/
一部のサービスは、プレーンの HTTP 接続を使用してアクセスできますが、セキュリティーに HTTPS 接続が必要になる場合があります。
REST 操作は HTTP メソッドとして指定されます (たとえば、GET、PUT、POST、DELETE)。たとえば、クライアントが GET /ca/rest/users リクエストを送信する CA ユーザーを取得する場合は、次のコマンドを実行します。
REST リクエストおよび応答メッセージは、XML または JSON 形式で送信できます。以下に例を示します。
{
	"id":"admin",
	"UserID":"admin",
	"FullName":"Administrator",
	"Email":"admin@example.com",
	...
}
CLI、Web UI、または汎用 REST クライアントなどのツールを使用して、REST インターフェイスにアクセスできます。Certificate System は、プログラムでサービスにアクセスするための Java、Python、および JavaScript ライブラリーも提供します。
REST インターフェイスは、2 種類の認証方法をサポートします。
  • ユーザー名およびパスワード
  • クライアント証明書
各サービスに必要な認証方法は、/usr/share/pki/ca/conf/auth-method.properties で定義されます。
REST インターフェイスでは、サービスへのアクセスに特定のパーミッションが必要になる場合があります。パーミッションは LDAP の ACL リソースで定義されます。REST インターフェイスは、/usr/share/pki/<subsystem>/conf/acl.properties の ACL リソースにマッピングされます。
REST インターフェイスの詳細は、http://www.dogtagpki.org/wiki/REST を参照してください。

2.3.5. JSS

Java Security Services (JSS) は、NSS が実行する暗号化操作の Java インターフェイスを提供します。Certificate System アーキテクチャーの JSS 以降は、Java Virtual Machine (JVM) 内からネイティブシステムライブラリーへのアクセスを提供する Java Native Interface (JNI) で構築されます。この設計により、システムの一部として配布される NSS などの FIPS で承認された暗号化プロバイダーを使用できます。JSS は、NSS でサポートされるセキュリティー標準および暗号化技術の多くに対応しています。JSS は、ASN.1 タイプと BER-DER エンコードの純粋な Java インターフェイスも提供します。

2.3.6. Tomcatjss

Red Hat Certificate System の Java ベースのサブシステムは、Tomcat Server HTTP エンジンと JSS 間のブリッジとして tomcatjss と呼ばれる単一の JAR ファイルを使用します。これは、NSS が実行するセキュリティー操作の Java インターフェイスです。Tomcatjss は、Tomcat の Java Security Services (JSS) を使用した Java Secure Socket Extension (JSSE) 実装です。
Tomcatjss は、TLS を使用して TLS ソケットを作成するために必要なインターフェイスを実装します。tomcatjss が実装するソケットファクトリーは、以下に挙げるさまざまなプロパティーを使用して、ソケットをリッスンして tomcat に戻ります。tomcatjss 自体は、Java JSS システムを利用して、最終的にマシン上のネイティブ NSS 暗号化サービスと通信します。
Tomcat サーバーおよび Certificate System クラスが読み込まれると、tomcatjss が読み込まれます。ロードプロセスの説明を以下に示します。
  1. サーバーが起動している。
  2. Tomcat は、Certificate System インストールにリスニングソケットを作成する必要がある場所に移動します。
  3. server.xml ファイルが処理されます。このファイルの設定は、Tomcatjs が実装するソケットファクトリーを使用するようシステムに指示します。
  4. Tomcajss は要求される各ソケットについて、ソケットの作成時に含まれる属性を読み取り、処理します。結果として生成されるソケットは、それらのパラメーターによって要求されているために動作します。
  5. サーバーが稼働したら、Tomcat ベースの Certificate System への着信接続を待機する必要なリッスンソケットのセットがあります。
ソケットが起動時に作成されると、Tomcat は、基礎となる JSS セキュリティーサービスと実際に処理される Certificate System の 最初 のエンティティーになります。最初のリスニングソケットが処理されると、後で使用できるように JSS のインスタンスが作成されます。
server.xml ファイルの詳細は、「Tomcat Engine および Web サービスの設定ファイル」 を参照してください。

2.3.7. PKCS #11

Public-Key Cryptography Standard (PKCS) #11 は、暗号化情報を保持するデバイスと通信し、暗号化操作を実行するのに使用する API を指定します。Certificate System は、PKCS #11 に対応しているため、Certificate System は、さまざまなハードウェアおよびソフトウェアデバイスと互換性があります。
Certificate System サブシステムインスタンスで、少なくとも 1 つの PKCS #11 モジュールが利用可能である必要があります。PKCS #11 モジュール (暗号化モジュールまたは暗号化サービスプロバイダーとも呼ばれる) は、暗号化や復号などの暗号化サービスを管理します。PKCS #11 モジュールは、ハードウェアまたはソフトウェアのいずれかで実装できる暗号化デバイスのドライバーに類似しています。Certificate System には、ビルトイン PKCS #11 モジュールが含まれており、サードパーティーモジュールに対応します。
PKCS #11 モジュールには、常に 1 つ以上のスロットがあり、スマートカードなどの物理リーダーの物理ハードウェアスロットとして、またはソフトウェアの概念スロットとして実装できます。PKCS #11 モジュールの各スロットには、トークンを追加できます。このトークンは、暗号化サービスを実際に提供し、必要に応じて証明書と鍵を保存するハードウェアまたはソフトウェアのデバイスです。
Certificate System は、内部外部 の 2 種類のトークンを定義します。内部トークンは、証明書トラストアンカーを保存するために使用されます。外部トークンは、Certificate System サブシステムに属するキーペアと証明書を保存するために使用されます。

2.3.7.1. NSS Soft Token (内部トークン)

注記
Certificate System は、証明書のトラストアンカーを保存する NSS ソフトトークンを使用します。
NSS Soft トークンは、内部トークンまたはソフトウェアトークンとも呼ばれます。ソフトウェアトークンは 2 つのファイルで設定されており、通常は証明書データベース (cert8.db) とキーデータベース (key3.db) と呼ばれる 2 つのファイルで設定されます。このファイルは、Certificate System サブシステムの設定時に作成されます。これらのセキュリティーデータベースは、/var/lib/pki/instance_name/alias ディレクトリーにあります。
NSS ソフトトークンが提供する暗号化モジュールは、Certificate System に含まれます。
  • デフォルトの内部 PKCS #11 モジュールには、2 つのトークンが含まれています。
    • 暗号化、復号化、ハッシュなどのすべての暗号化操作を実行する内部暗号化サービストークン。
    • 内部キーストレージトークン (証明書 DB トークン)。このトークンは、証明書および鍵を保存する証明書および鍵データベースファイルをすべて処理します。
  • FIPS 140 モジュールこのモジュールは、暗号化モジュール実装用の FIPS 140 政府標準に準拠します。FIPS 140 モジュールには、暗号化操作と証明書およびキーデータベースファイルとの通信の両方を処理する単一の組み込み FIPS 140 証明書データベーストークンが含まれています。
NSS ソフトトークンに証明書をインポートする方法の具体的な手順は、14章証明書/キー暗号トークンの管理を参照してください。
Network Security Services (NSS) の詳細は、同じ名前の Mozilla Developer の Web ページを参照してください。

2.3.7.2. ハードウェアセキュリティーモジュール (HSM、外部トークン)

注記
Certificate System は、HSM を使用して、Certificate System サブシステムに属する鍵のペアと証明書を格納します。
PKCS #11 モジュールは、Certificate System で使用できます。サブシステムで外部ハードウェアトークンを使用するには、サブシステムの設定前に PKCS #11 モジュールを読み込み、新しいトークンをサブシステムで利用できるようになります。
利用可能な PKCS #11 モジュールは、サブシステムの secmod.db データベースで追跡されます。modutil ユーティリティーは、署名操作に使用するハードウェアアクセラレーターのインストールなど、システムへの変更時にこのファイルを修正するために使用されます。modutil の詳細は、Mozilla Developer の Web ページで Network Security Services (NSS) を参照してください。
PKCS #11 ハードウェアデバイスは、ハードウェアトークンに保存されている情報に、主要なバックアップと復旧機能を提供します。トークンから鍵を取得する方法は、PKCS #11 ベンダーのドキュメントを参照してください。
証明書のインポートおよび HSM の管理方法の方法は、14章証明書/キー暗号トークンの管理を参照してください。
サポート対象のハードウェアセキュリティーモジュールは、「サポート対象のハードウェアセキュリティーモジュール」に記載されています。

2.3.8. Certificate System のシリアル番号管理

2.3.8.1. シリアル番号の範囲

証明書要求とシリアル番号は Java の大きな整数 で表されます。
デフォルトでは、効率性のために、証明書要求番号、証明書シリアル番号、およびレプリカ ID が CA サブシステムに順番に割り当てられます。
シリアル番号の範囲は、要求、証明書、およびレプリカ ID によって異なります。
  • 現在のシリアル番号管理は、連続したシリアル番号範囲の割り当てに基づいています。
  • インスタンスは、定義されたしきい値を下回る場合に新しい範囲を要求します。
  • インスタンスは、インスタンスに割り当てられたら、新たに取得した範囲に関する情報を保存します。
  • インスタンスは、すべての数字が使い切られるまで古い範囲を引き続き使用し、新しい範囲に移動します。
  • クローン作成されたサブシステムは、レプリケーションの競合を使用して範囲割り当てを同期します。
新しいクローンの場合
  • マスターの現在の範囲には、クローン作成のプロセスの新しいクローンに転送されます。
  • 転送範囲が定義されたしきい値を下回る場合に、新規クローンが新しい範囲を要求する可能性があります。
すべての範囲は、CA インスタンスのインストール中に設定可能です。これにより、PKI インスタンスの上書き設定ファイルに [CA] セクションを追加し、必要に応じて以下の name=value ペアをそのセクションに追記します。/etc/pki/default.cfg にすでに存在するデフォルト値を以下の例に示します。
[CA]
pki_serial_number_range_start=1
pki_serial_number_range_end=10000000
pki_request_number_range_start=1
pki_request_number_range_end=10000000
pki_replica_number_range_start=1
pki_replica_number_range_end=100

2.3.8.2. ランダムなシリアル番号管理

順次シリアル番号管理に加えて、Red Hat Certificate System は任意のランダムシリアル番号管理を提供します。乱数は、PKI インスタンスの上書きファイルに [CA] セクションを追加し、そのセクションに以下の name=value ペアを追加することによって、CA インスタンスのインストール時に選択可能です。
[CA]
pki_random_serial_numbers_enable=True
このチェックボックスを選択した場合、証明書要求番号と証明書のシリアル番号は、指定した範囲内で無作為に選択されます。

2.3.9. セキュリティードメイン

セキュリティードメイン は PKI サービスのレジストリーです。CA などのサービスは、これらのドメインに独自の情報を登録するため、PKI サービスのユーザーはレジストリーを確認して他のサービスを検索できます。RHCS のセキュリティードメインサービスは、Certificate System サブシステムの PKI サービスの登録と、共有信頼ポリシーのセットの両方を管理します。
詳細は、「セキュリティードメインの計画」を参照してください。

2.3.10. パスワードおよびウォッチドッグ (nuxwdog)

デフォルトの設定では、RHCS サブシステムインスタンスはクライアントとして機能し、LDAP 内部データベース (TLS クライアント認証が設定されていない限り、代わりに証明書が認証に使用されます、NSS トークンデータベース、またはパスワードを持つ HSM などの他のサービスに認証する必要があります。管理者は、インストール設定時にこのパスワードを設定するように求められます。このパスワードは、<instance_dir>/conf/password.conf ファイルに書き込まれます。同時に、識別文字列は、パラメーター cms.passwordlist の一部としてメインの設定ファイル CS.cfg に保存されます。
設定ファイル CS.cfg は Red Hat Enterprise Linux により保護され、PKI 管理者のみがアクセスできます。パスワードは CS.cfg に保存されません。
インストール時に、インストーラーは内部ソフトウェアトークンまたはハードウェア暗号化トークンのいずれかを選択してログインします。これらのトークンへのログインパスフレーズは、password.conf にも記述されます。
後で設定は、パスワードを password.conf に配置することもできます。LDAP 公開は、公開ディレクトリーに対して新たに設定された Directory Manager パスワードが password.conf に送信される一例です。
Nuxwdog (watchdog) は、サーバープログラムを起動、停止、監視、および再設定するために使用される軽量な補助デーモンプロセスです。サーバーを起動するためにユーザーにパスワードの入力を求める必要がある場合に最も役立ちます。これは、これらのパスワードをカーネルキーリングに安全にキャッシュし、サーバーがクラッシュした場合に自動的に再起動できるようにするためです。
注記
Nuxwdog は、唯一許可されるウォッチドッグサービスです。
インストールが完了したら、password.conf ファイルを完全に削除できます。再起動時には、nuxwdog ウォッチドッグプログラムは、プロンプトが表示されたら、パラメーター cms.passwordlist (および HSM が使用される場合は cms.tokenList) を使用して、必要なパスワードを要求します。その後、パスワードは、サーバークラッシュからの自動リカバリーを可能にするために、カーネルキーリングの nuxwdog によりキャッシュされます。制御されていないシャットダウン (クラッシュ) が原因で、この自動リカバリー (自動サブシステム再起動) が発生します。管理者が制御したシャットダウンの場合は、管理者がパスワードを再度要求します。
ウォッチドッグサービスを使用する場合は、RHCS インスタンスの起動と停止が異なります。詳細は、「Certificate System の Watchdog サービスの使用」 を参照してください。
詳細は、「システムパスワードの管理」 を参照してください。

2.3.11. 内部 LDAP データベース

Red Hat Certificate System は、証明書、要求、ユーザー、ロール、ACL、およびその他のさまざまな内部情報などの情報を格納するための内部データベースとして Red Hat Directory Server (RHDS) を採用しています。Certificate System は、パスワードを使用して内部 LDAP データベースと通信するか、SSL 認証により安全な方法で通信します。
Certificate System インスタンスと Directory Server 間で証明書ベースの認証が必要な場合は、これら 2 つのエンティティー間で信頼を設定する手順を実行することが重要です。このような Certificate System インスタンスのインストールにも、pkispawn の適切なオプションが必要です。
詳細は、「Red Hat Directory Server のインストール」 を参照してください。

2.3.12. SELinux (Security Enhanced Linux)

SELinux は、承認されていないアクセスと改ざんを制限するためにシステム全体で実施される、必須のアクセス制御ルールのコレクションです。SELinux の詳細は、Red Hat Enterprise Linux 7 SELinux ユーザーおよび管理者のガイド を参照してください。
基本的に、SELinux はシステム上の オブジェクト を識別します。これは、ファイル、ディレクトリー、ユーザー、プロセス、ソケット、または Linux ホスト上その他のリソースになります。これらのオブジェクトは Linux API オブジェクトに対応します。各オブジェクトは セキュリティーコンテキスト にマッピングされ、オブジェクトのタイプと、Linux サーバーでの機能が可能になります。
オブジェクトはドメインにグループ化でき、各ドメインには適切なルールが割り当てられます。各セキュリティーコンテキストには、実行できる操作、アクセスできるリソース、および所有するアクセス許可に制限を設定するルールがあります。
Certificate System の SELinux ポリシーは、標準のシステムの SELinux ポリシーに組み込まれています。これらの SELinux ポリシーは、Certificate System が使用するすべてのサブシステムとサービスに適用されます。SELinux で Certificate System を実行すると、Certificate System で作成および維持される情報のセキュリティーが強化されます。

図2.1 CA SELinux ポートポリシー

CA SELinux ポートポリシー
Certificate System SELinux ポリシーは、すべてのサブシステムインスタンスの SELinux 設定を定義します。
  • 各サブシステムインスタンスのファイルおよびディレクトリーには、特定の SELinux コンテキストのラベルが付けられます。
  • 各サブシステムインスタンスのポートは、特定の SELinux コンテキストでラベル付けされます。
  • すべての Certificate System プロセスは、サブシステム固有のドメイン内で制限されます。
  • 各ドメインには、ドメインに承認されたアクションを定義する特定のルールがあります。
  • SELinux ポリシーに指定されていないアクセスは、Certificate System インスタンスに対して拒否されます。
Certificate System の場合、各サブシステムは SELinux オブジェクトとして扱われ、各サブシステムには一意のルールが割り当てられます。定義済みの SELinux ポリシーを使用すると、Certificate System オブジェクトが Enforcing モードで SELinux を設定して実行できます。
pkispawn が実行されるたびに、Certificate System サブシステム、そのサブシステムに関連付けられたファイル、およびポートには、必要な SELinux コンテキストのラベルが付けられます。このコンテキストは、特定のサブシステムが pkidestroy を使用して削除されると削除されます。
SELinux ポリシーの中央定義は pki_tomcat_t ドメインです。Certificate System インスタンスは Tomcat サーバーであり、pki_tomcat_t ドメインは標準の tomcat_t Tomcat ドメインのポリシーを拡張します。サーバー上のすべての Certificate System インスタンスが同じドメインを共有します。
各 Certificate System プロセスが開始すると、最初に制限のないドメイン (unconfined_t) で実行され、次に pki_tomcat_t ドメインに移行します。その後、このプロセスには、pki_tomcat_log_t というラベルが付けられたログファイルへの書き込みアクセス、pki_tomcat_etc_rw_t というラベルが付いた設定ファイルへの読み書きアクセス、http_port_t ポートのオープンおよび書き込み機能など、特定のアクセスパーミッションが設定されます。
SELinux モードは、Enforcing から Permissive に変更できますが、これは推奨されません。

2.3.13. セルフテスト

Red Hat Certificate System は、起動時またはオンデマンド、あるいはその両方で PKI システムの整合性をチェックできるセルフテストフレームワークを提供します。クリティカルでない自己テストに失敗すると、メッセージはログファイルに保存されますが、重大なセルフテストに失敗すると、メッセージはログファイルに保存されますが、Certificate System サブシステムは適切にシャットダウンします。管理者は、起動時にセルフテストレポートを確認する場合、サブシステムの起動時にセルフテストログを監視する必要があります。起動後にログを表示することもできます。
セルフテストの失敗によりサブシステムがシャットダウンすると、自動的に無効になります。これは、サブシステムが部分的に実行されなくなり、誤解を招く応答を生成するために行われます。問題が解決されると、サーバーで以下のコマンドを実行してサブシステムを再度有効にできます。
# pki-server subsystem-enable <subsystem>
セルフテストの設定方法の詳細は、「セルフテストの設定」を参照してください。

2.3.14. ログ

Certificate System サブシステムは、管理、サーバーがサポートするプロトコルを使用した通信、およびサブシステムで使用されるその他のさまざまなプロセスなどのアクティビティーに関連するイベントを記録するログファイルを作成します。サブシステムインスタンスが実行中に、それが管理するすべてのコンポーネントの情報およびエラーメッセージのログを保持します。また、Apache および Tomcat の Web サーバーはエラーを生成し、ログにアクセスします。
各サブシステムインスタンスは、インストール、監査、およびその他のログに記録された機能に対する独自のログファイルを維持します。
ログプラグインモジュールは、Java™ クラスとして実装され、設定フレームワークに登録されるリスナーです。
監査ログを除くすべてのログファイルとローテーションされたログファイルは、pkispawn によるインスタンスの作成時に、pki_subsystem_log_path に指定されているすべてのディレクトリーに配置されます。 通常の監査ログは他のログタイプとともにログディレクトリーに置かれ、署名された監査ログは /var/log/pki/instance_name/subsystem_name/signedAudit に書き込まれます。ログのデフォルトの場所を変更するには、設定を変更してください。
インストール中のログ設定の詳細および追加情報は、17章ログの設定を参照してください。
インストール後のログ管理の詳細は、『Red Hat Certificate System 管理ガイド』 の サブシステムログの設定 セクションを参照してください。

2.3.14.1. 監査ログ

監査ログには、記録可能なイベントとして設定された選択可能なイベントのレコードが含まれます。監査ログを整合性チェック目的で署名するように設定することもできます。
注記
監査レコードは、「監査の保持」 に指定された監査保持ルールに従って維持する必要があります。

2.3.14.2. システムログ

このログは system です。サーバーへの要求に関する情報 (HTTP および HTTPS のすべてのリクエスト) とサーバーからの応答を記録します。このログに記録される情報には、サーバーにアクセスしたクライアントマシンの IP アドレス (IPv4 と IPv6 の両方)、検索、追加、編集などの実行される操作、返されたエントリーの数などのアクセスの結果が含まれます。
id_number processor - [date:time] [number_of_operations] [result] servlet: message

例2.1 TKS システムログ

10439.http-13443-Processor25 - [19/May/2020:14:16:51 CDT] [11] [3] UGSubsystem: Get User Error User not found
このログはデフォルトで有効になっています。

2.3.14.3. トランザクションログ

このログは transactions で、サブシステムに実行された操作または送信された操作をすべて記録します。
id_number.processor - [date:time] [number_of_operations] [result] servlet: message
これらのメッセージは、証明書要求を受信する CA、キーをアーカイブまたは取得する KRA、新しい TPS を登録する TKS など、証明書サービスに固有のものです。このログを使用して、承認されていないアクセスやアクティビティーを検出することもできます。

例2.2 トランザクションログ

11438.http-8443-Processor25 - [27/May/2020:07:56:18 CDT] [1] [1] archival reqID 4 fromAgent agentID: CA-server.example.com-8443 authenticated by noAuthManager is completed DN requested: UID=recoverykey,E=recoverykey@email.com,CN=recover key serial number: 0x3
このログはデフォルトで有効になっています。

2.3.14.4. デバッグログ

デフォルトで有効になっているデバッグログは、さまざまな程度と種類の情報とともに、すべてのサブシステムに対して維持されます。
各サブシステムのデバッグログは、システム、トランザクション、およびアクセスログよりも詳細な情報を記録します。デバッグログには、実行されるプラグインとサーブレット、接続情報、サーバーの要求と応答のメッセージなど、サブシステムによって実行されるすべての操作に関する非常に具体的な情報が含まれています。
デバッグログに記録されるサービスには、認可要求、証明書要求の処理、証明書ステータスの確認、キーのアーカイブおよび復元、Web サービスへのアクセスが含まれます。
デバッグログは、サブシステムのプロセスの詳細情報を記録します。各ログエントリーの形式は以下のとおりです。
[date:time] [processor]: servlet: message
メッセージ はサブシステムから返されたメッセージになるか、サブシステムに送信された値を含めることができます。
たとえば、TKS は、LDAP サーバーに接続するためにこのメッセージを記録します。
[10/Jun/2020:05:14:51][main]: Established LDAP connection using basic authentication to host localhost port 389 as cn=Directory Manager
processormain で、message は LDAP 接続に関するサーバーからメッセージであり、サーブレットはありません。
一方、CA は、証明書操作およびサブシステム接続に関する情報を記録します。
[06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.requestowner$ value=KRA-server.example.com-8443
この場合、プロセッサー は CA のエージェントポート上の HTTP プロトコルですが、プロファイルを処理するサーブレットを指定し、profile パラメーター (リクエストのサブシステム所有者) とその値 (KRA が要求を開始した) を示す メッセージ が含まれます。

例2.3 CA 証明書要求ログメッセージ

[06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.profileapprovedby$ value=admin
				[06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.cert_request$ value=MIIBozCCAZ8wggEFAgQqTfoHMIHHgAECpQ4wDDEKMAgGA1UEAxMBeKaBnzANBgkqhkiG9w0BAQEFAAOB...
				[06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.profile$ value=true
				[06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.cert_request_type$ value=crmf
				[06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.requestversion$ value=1.0.0
				[06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.req_locale$ value=en
				[06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.requestowner$ value=KRA-server.example.com-8443
				[06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.dbstatus$ value=NOT_UPDATED
				[06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.subject$ value=uid=jsmith, e=jsmith@example.com
				[06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.requeststatus$ value=begin
				[06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.auth_token.user$ value=uid=KRA-server.example.com-8443,ou=People,dc=example,dc=com
				[06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.req_key$ value=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDreuEsBWq9WuZ2MaBwtNYxvkLP^M
				HcN0cusY7gxLzB+XwQ/VsWEoObGldg6WwJPOcBdvLiKKfC605wFdynbEgKs0fChV^M
				k9HYDhmJ8hX6+PaquiHJSVNhsv5tOshZkCfMBbyxwrKd8yZ5G5I+2gE9PUznxJaM^M
				HTmlOqm4HwFxzy0RRQIDAQAB
				[06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.auth_token.authmgrinstname$ value=raCertAuth
				[06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.auth_token.uid$ value=KRA-server.example.com-8443
				[06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.auth_token.userid$ value=KRA-server.example.com-8443
				[06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.requestor_name$ value=
				[06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.profileid$ value=caUserCert
				[06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.auth_token.userdn$ value=uid=KRA-server.example.com-4747,ou=People,dc=example,dc=com
				[06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.requestid$ value=20
				[06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.auth_token.authtime$ value=1212782378071
				[06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.req_x509info$ value=MIICIKADAgECAgEAMA0GCSqGSIb3DQEBBQUAMEAxHjAcBgNVBAoTFVJlZGJ1ZGNv^M
				bXB1dGVyIERvbWFpbjEeMBwGA1UEAxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4X^M
				DTA4MDYwNjE5NTkzOFoXDTA4MTIwMzE5NTkzOFowOzEhMB8GCSqGSIb3DQEJARYS^M
				anNtaXRoQGV4YW1wbGUuY29tMRYwFAYKCZImiZPyLGQBARMGanNtaXRoMIGfMA0G^M
				CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDreuEsBWq9WuZ2MaBwtNYxvkLPHcN0cusY^M
				7gxLzB+XwQ/VsWEoObGldg6WwJPOcBdvLiKKfC605wFdynbEgKs0fChVk9HYDhmJ^M
				8hX6+PaquiHJSVNhsv5tOshZkCfMBbyxwrKd8yZ5G5I+2gE9PUznxJaMHTmlOqm4^M
				HwFxzy0RRQIDAQABo4HFMIHCMB8GA1UdIwQYMBaAFG8gWeOJIMt+aO8VuQTMzPBU^M
				78k8MEoGCCsGAQUFBwEBBD4wPDA6BggrBgEFBQcwAYYuaHR0cDovL3Rlc3Q0LnJl^M
				ZGJ1ZGNvbXB1dGVyLmxvY2FsOjkwODAvY2Evb2NzcDAOBgNVHQ8BAf8EBAMCBeAw^M
				HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMCQGA1UdEQQdMBuBGSRyZXF1^M
				ZXN0LnJlcXVlc3Rvcl9lbWFpbCQ=
同様に、OCSP には OCSP 要求情報が表示されます。
[07/Jul/2020:06:25:40][http-11180-Processor25]: OCSPServlet: OCSP Request:
				[07/Jul/2020:06:25:40][http-11180-Processor25]: OCSPServlet:
				MEUwQwIBADA+MDwwOjAJBgUrDgMCGgUABBSEWjCarLE6/BiSiENSsV9kHjqB3QQU

2.3.14.5. インストールログ

すべてのサブシステムはインストールログを保持します。
サブシステムが初期インストールで作成される場合や pkispawn によって追加のインスタンスを作成するたびに、インストールからの完全なデバッグ出力を含むインストールファイル (エラーを含む) と、インストールに成功すると、インスタンスの設定インターフェイスへの URL および PIN が作成されます。このファイルは、/var/log/pki/ ディレクトリーに、名前が pki-subsystem_name-spawn.timestamp.log の形式で指定します。
インストールログの各行は、インストールプロセスのステップに従います。

例2.4 CA インストールログ

				...
				2015-07-22 20:43:13 pkispawn    : INFO     ... finalizing 'pki.server.deployment.scriptlets.finalization'
				2015-07-22 20:43:13 pkispawn    : INFO     ....... cp -p /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg /var/log/pki/pki-tomcat/ca/archive/spawn_deployment.cfg.20150722204136
				2015-07-22 20:43:13 pkispawn    : DEBUG    ........... chmod 660 /var/log/pki/pki-tomcat/ca/archive/spawn_deployment.cfg.20150722204136
				2015-07-22 20:43:13 pkispawn    : DEBUG    ........... chown 26445:26445 /var/log/pki/pki-tomcat/ca/archive/spawn_deployment.cfg.20150722204136
				2015-07-22 20:43:13 pkispawn    : INFO     ....... generating manifest file called '/etc/sysconfig/pki/tomcat/pki-tomcat/ca/manifest'
				2015-07-22 20:43:13 pkispawn    : INFO     ....... cp -p /etc/sysconfig/pki/tomcat/pki-tomcat/ca/manifest /var/log/pki/pki-tomcat/ca/archive/spawn_manifest.20150722204136
				2015-07-22 20:43:13 pkispawn    : DEBUG    ........... chmod 660 /var/log/pki/pki-tomcat/ca/archive/spawn_manifest.20150722204136
				2015-07-22 20:43:13 pkispawn    : DEBUG    ........... chown 26445:26445 /var/log/pki/pki-tomcat/ca/archive/spawn_manifest.20150722204136
				2015-07-22 20:43:13 pkispawn    : INFO     ....... executing 'systemctl enable pki-tomcatd.target'
				2015-07-22 20:43:13 pkispawn    : INFO     ....... executing 'systemctl daemon-reload'
				2015-07-22 20:43:13 pkispawn    : INFO     ....... executing 'systemctl restart pki-tomcatd@pki-tomcat.service'
				2015-07-22 20:43:14 pkispawn    : INFO     END spawning subsystem 'CA' of instance 'pki-tomcat'
				2015-07-22 20:43:14 pkispawn    : DEBUG

2.3.14.6. Tomcat のエラーとアクセスログ

CA、KRA、OCSP、TKS、および TPS サブシステムは、それらのエージェントおよびエンドエンティティーのインターフェイスに Tomcat Web サーバーインスタンスを使用します。
エラーログとアクセスログは、Certificate System とともにインストールされ、HTTP サービスを提供する Tomcat Web サーバーによって作成されます。エラーログには、サーバーが検出した HTTP エラーメッセージが含まれます。アクセスログは、HTTP インターフェイスを介したアクセスアクティビティーをリスト表示します。
Tomcat によって作成されたログ:
  • admin.timestamp
  • catalina.timestamp
  • catalina.out
  • host-manager.timestamp
  • localhost.timestamp
  • localhost_access_log.timestamp
  • manager.timestamp
これらのログは、Certificate System 内では利用できません。それらは Apache または Tomcat 内でのみ設定可能です。これらのログの設定に関する詳細は、Apache ドキュメントを参照してください。

2.3.14.7. セルフテストログ

セルフテストのログは、サーバーの起動時またはセルフテストを手動で実行するときに取得した情報を記録します。このログを開くとテストを表示できます。このログはコンソールを介して設定できません。このログは、CS.cfg ファイルの設定を変更してのみ設定できます。このセクションのログに関する情報は、このログには関係しません。セルフテストについての詳細は、「セルフテスト」を参照してください。

2.3.14.8. journalctl ログ

Certificate System インスタンスを起動すると、ログサブシステムがセットアップされて有効になるまでに少し時間がかかります。この間に、ログの内容は標準出力に書き込まれます。これは systemd でキャプチャーされ、journalctl ユーティリティーを介して公開されます。
これらのログを表示するには、以下のコマンドを実行します。
# journalctl -u pki-tomcatd@instance_name.service
nuxwdog サービスを使用している場合は、以下を実行します。
# journalctl -u pki-tomcatd-nuxwdog@instance_name.service
多くの場合、インスタンスの起動時にこれらのログを監視すると便利です (たとえば、起動時にセルフテストが失敗した場合)。そのためには、インスタンスを起動する前に、別のコンソールでこれらのコマンドを実行します。
# journalctl -f -u pki-tomcatd@instance_name.service
nuxwdog サービスを使用している場合は、以下を実行します。
# journalctl -f -u pki-tomcatd-nuxwdog@instance_name.service

2.3.15. インスタンスのレイアウト

各 Certificate System インスタンスは、多数のファイルによって異なります。その一部はインスタンス固有のフォルダーにありますが、他のサーバーインスタンスと共有される共通フォルダーに置かれています。
たとえば、サーバー設定ファイルはインスタンス固有の /etc/pki/instance_name/server.xml に保存されますが、CA サーブレットは /usr/share/pki/ca/webapps/ca/WEB-INF/web.xml で定義されています。これはシステム上のすべてのサーバーインスタンスで共有されます。

2.3.15.1. Certificate System のファイルおよびディレクトリーの場所

Certificate System サーバーは、1 つ以上の Certificate System サブシステムで設定される Tomcat インスタンスです。Certificate System サブシステムは、特定の PKI 機能を提供する Web アプリケーションです。一般的な共有サブシステム情報は、再配置不可能な RPM 定義の共有ライブラリー、Java アーカイブファイル、バイナリー、およびテンプレートに含まれています。これらは固定された場所に保存されます。
ディレクトリーはインスタンスに固有のものでり、インスタンス名に関連付けられています。この例では、インスタンス名は pki-tomcat です。true の値は、pkispawn を使用したサブシステムの作成時に指定されます。
ディレクトリーには、カスタマイズされた設定ファイルとテンプレート、プロファイル、証明書データベース、およびサブシステムの他のファイルが含まれます。
表2.2 Tomcat インスタンス情報
設定
メインディレクトリー /var/lib/pki/pki-tomcat
設定ディレクトリー /etc/pki/pki-tomcat
設定ファイル
/etc/pki/pki-tomcat/server.xml
/etc/pki/pki-tomcat/password.conf
セキュリティーデータベース /var/lib/pki/pki-tomcat/alias
サブシステム証明書
SSL サーバー証明書
サブシステム証明書 [a]
ログファイル /var/log/pki/pki-tomcat
Web サービスファイル
/usr/share/pki/server/webapps/ROOT - メインページ
/usr/share/pki/server/webapps/pki/admin - 管理テンプレート
/usr/share/pki/server/webapps/pki/js - JavaScript ライブラリー
[a] サブシステム証明書はセキュリティードメインによって常に発行されるため、クライアント認証を必要とするドメインレベルの操作はこのサブシステム証明書をベースにします。
注記
/var/lib/pki/instance_name/conf/ ディレクトリーは、/etc/pki/instance_name/ ディレクトリーへのシンボリックリンクです。

2.3.15.2. CA サブシステム情報

ディレクトリーはインスタンスに固有のものでり、インスタンス名に関連付けられています。この例では、インスタンス名は pki-tomcat です。true の値は、pkispawn を使用したサブシステムの作成時に指定されます。
表2.3 CA サブシステム情報
設定
メインディレクトリー /var/lib/pki/pki-tomcat/ca
設定ディレクトリー /etc/pki/pki-tomcat/ca
設定ファイル /etc/pki/pki-tomcat/ca/CS.cfg
サブシステム証明書
CA 署名証明書
OCSP 署名証明書 (CA の内部 OCSP サービス用)
監査ログ署名証明書
ログファイル /var/log/pki/pki-tomcat/ca
ログのインストール /var/log/pki/pki-ca-spawn.YYYYMMDDhhmmss.log
プロファイルファイル /var/lib/pki/pki-tomcat/ca/profiles/ca
メール通知テンプレート /var/lib/pki/pki-tomcat/ca/emails
Web サービスファイル
/usr/share/pki/ca/webapps/ca/agent: エージェントサービス
/usr/share/pki/ca/webapps/ca/admin: 管理サービス
/usr/share/pki/ca/webapps/ca/ee: エンドユーザーサービス

2.3.15.3. KRA サブシステム情報

ディレクトリーはインスタンスに固有のものでり、インスタンス名に関連付けられています。この例では、インスタンス名は pki-tomcat です。true の値は、pkispawn を使用したサブシステムの作成時に指定されます。
表2.4 KRA サブシステム情報
設定
メインディレクトリー /var/lib/pki/pki-tomcat/kra
設定ディレクトリー /etc/pki/pki-tomcat/kra
設定ファイル /etc/pki/pki-tomcat/kra/CS.cfg
サブシステム証明書
トランスポート証明書
ストレージ証明書
監査ログ署名証明書
ログファイル /var/log/pki/pki-tomcat/kra
ログのインストール /var/log/pki/pki-kra-spawn.YYYYMMDDhhmmss.log
Web サービスファイル
/usr/share/pki/kra/webapps/kra/agent: エージェントサービス
/usr/share/pki/kra/webapps/kra/admin: 管理サービス

2.3.15.4. OCSP サブシステム情報

ディレクトリーはインスタンスに固有のものでり、インスタンス名に関連付けられています。この例では、インスタンス名は pki-tomcat です。true の値は、pkispawn を使用したサブシステムの作成時に指定されます。
表2.5 OCSP サブシステム情報
設定
メインディレクトリー /var/lib/pki/pki-tomcat/ocsp
設定ディレクトリー /etc/pki/pki-tomcat/ocsp
設定ファイル /etc/pki/pki-tomcat/ocsp/CS.cfg
サブシステム証明書
OCSP 署名証明書
監査ログ署名証明書
ログファイル /var/log/pki/pki-tomcat/ocsp
ログのインストール /var/log/pki/pki-ocsp-spawn.YYYYMMDDhhmmss.log
Web サービスファイル
/usr/share/pki/ocsp/webapps/ocsp/agent: エージェントサービス
/usr/share/pki/ocsp/webapps/ocsp/admin: 管理サービス

2.3.15.5. TKS サブシステム情報

ディレクトリーはインスタンスに固有のものでり、インスタンス名に関連付けられています。この例では、インスタンス名は pki-tomcat です。true の値は、pkispawn を使用したサブシステムの作成時に指定されます。
表2.6 TKS サブシステム情報
設定
メインディレクトリー /var/lib/pki/pki-tomcat/tks
設定ディレクトリー /etc/pki/pki-tomcat/tks
設定ファイル /etc/pki/pki-tomcat/tks/CS.cfg
サブシステム証明書 監査ログ署名証明書
ログファイル /var/log/pki/pki-tomcat/tks
ログのインストール /var/log/pki/pki-tomcat/pki-tks-spawn.YYYYMMDDhhmmss.log

2.3.15.6. TPS サブシステム情報

ディレクトリーはインスタンスに固有のものでり、インスタンス名に関連付けられています。この例では、インスタンス名は pki-tomcat です。true の値は、pkispawn を使用したサブシステムの作成時に指定されます。
表2.7 TPS サブシステム情報
設定
メインディレクトリー /var/lib/pki/pki-tomcat/tps
設定ディレクトリー /etc/pki/pki-tomcat/tps
設定ファイル /etc/pki/pki-tomcat/tps/CS.cfg
サブシステム証明書 監査ログ署名証明書
ログファイル /var/log/pki/pki-tomcat/tps
ログのインストール /var/log/pki/pki-tps-spawn.YYYYMMDDhhhmmss.log
Web サービスファイル /usr/share/pki/tps/webapps/tps - TPS サービス

2.3.15.7. 共有 Certificate System サブシステムファイルの場所

サーバー全般操作のために、すべての Certificate System サブシステムインスタンスで使用されるディレクトリーがあります (表2.8「サブシステムファイルの場所」 に記載されています)。
表2.8 サブシステムファイルの場所
ディレクトリーの場所 コンテンツ
/usr/share/pki Certificate System インスタンスの作成に使用する一般的なファイルとテンプレートが含まれます。すべてのサブシステムの共有ファイルとともに、サブディレクトリーにサブシステム固有のファイルがあります。
  • pki/ca (CA)
  • pki/kra (KRA)
  • pki/ocsp (OCSP)
  • pki/tks (TKS)
  • pki/tps (TPS)
/usr/bin Certificate System サブシステムが共有する pkispawn および pkidestroy インスタンス設定スクリプトおよびツール (Java、ネイティブ、およびセキュリティー) が含まれます。
/usr/share/java/pki ローカルの Tomcat Web アプリケーションが共有し、Certificate System サブシステムで共有される Java アーカイブファイルが含まれます。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.