Corda Enterprise Network Manager1.4のリリースノートの翻訳文を掲載いたします。

原文はこちらよりご確認ください。

Corda Enterprise Network Manager 1.4.4

CENM 1.4.4 では、Apache Log4j 2 の依存関係に起因する緊急のセキュリティ問題を修正しました。この修正では、Log4j の依存関係がバージョン v2.17.1 に更新されています。

修正された問題点Log4j の依存関係がバージョン 2.17.1 に更新され、既存の Log4j の問題が修正されました。

Corda Enterprise Network Manager 1.4.3

CENM 1.4.3 では、Apache Log4j 2 の依存関係に起因する緊急のセキュリティ問題 - CVE-2021-44228 - を修正しました。この修正では、Log4j 依存関係をバージョン 2.16.0 に更新しています。

修正された問題点CVE-2021-44228 を緩和するために、Log4j の依存関係をバージョン 2.16.0 に更新しています。

※Corda Enterprise Network Manager 1.4.2の公式リリースはありません。

Corda Enterprise Network Manager 1.4.1

CENM 1.4.1 は、CENM 1.4 の既知の問題に対する修正を含んでいます。

Corda Enterprise Network Manager 1.4

CENM 1.4では、CENMエラーコンディションのナレッジベース、多数のネットワークマップサービスのパフォーマンス強化、SMR（Signable Material Retriever）サービスに代わる新しいSigning Serviceプラグイン機能EKS、CloudHSM、AWS PostgreSQLを使用したAWSネイティブネットワーク展開の拡張サポートなどの新機能と機能強化が導入されています。

このリリースは下位互換性がありますが、Corda Enterprise Network Managerの以前のバージョンからこのリリースにアップグレードすることをお勧めします。

アップグレードに関する重要な注意事項

CENM 1.3 から CENM 1.4 へのアップグレードには、以下の操作が必要です。

• Signing Serviceに関する設定のマニュアル更新

署名データのプラグインを処理するために、CENM 1.4以前に使用されていたSMR(Signable Material Retriever)サービスは、Signing Service内のプラグインロードロジックに置き換えられました。その結果、CENM 1.4へのアップグレード時には、すべてのユーザーは既存のSigning Serviceの設定を更新する必要があります。詳細については、CENMアップグレードガイドを参照してください。

• Zoneサービス・データベースの移行

CENM 1.3 から CENM 1.4 にアップグレードする場合、データベース構成で runMigration = true を設定する必要があります。詳細については、CENMアップグレードガイドを参照してください。Zone Service データベーススキーマが更新されたことで、この作業が必要となりました。

その他改善点については、以下を参照してください。

新機能と機能強化

CENMエラーコンディション・ナレッジベース

Corda 4.5 および Corda Enterprise 4.5 で導入された Corda ノード用のエラー処理ロジックが、CENM 1.4にも導入されました。

その結果、CENM の例外は CENM のエラーコードとして扱われるようになり、各例外に対してエラーコードが生成されるようになりました。設定の解析/検証エラーに関連するエラーコードの初期セットは、新しいCENMエラーコードのドキュメントページに記載されています。これは、将来のリリースで更に拡張される予定です。

ネットワークマップサービスのパフォーマンス向上

CENM 1.4では、ネットワーク内に多数のアクティブな参加者が存在する場合にも、安定した運用を確保するために、ネットワークマップサービスのパフォーマンスを向上させています。

データベース項目のうち、シリアライズする項目を減らすことで、ネットワークマップから、新しく加入したノードへのレスポンスに関して、パフォーマンスと信頼性の向上をもたらします。これにより、以前のCENMバージョンで潜在的に発生する可能性のあったデッドロックを回避することが可能です。このデッドロックは、複数の新規ノード登録が同時に実行された場合に発生する可能性がありました。

パフォーマンスは、以下の変更の組み合わせによって強化されています。

• 新しいオプションのタイムアウト・パラメータを使用して、ネットワーク・マップで定義された署名プロセス内で使用される各サー ビスへの通信に対して、個別にSigningサービスのタイムアウトを設定できるようになりました。また、timeout パラメータを使用して、Identity Manager および Revocation サービスとネットワーク マップ サービス間の通信のタイムアウトを設定することもできます。タイムアウト パラメータの値は、ゾーン サービス用のＤＢに含まれる socket_config テーブルおよび signer_config テーブルに追加されたtimeout 列に保存されます。 (ゾーン サービス データベースのCENM 1.3 からの移行に関する詳細については、『CENM アップグレード ガイド』を参照してください)
• 新しい API エンドポイントである GET network-map/node-infos を使用すると、ネットワーク内のすべてのノードの署名付き NodeInfo オブジェクトのリストを一度に取得することができます。
• Network Map API レスポンスに追加されたヘッダにより、レスポンスが、よりHTTP の標準的な使用法に準拠するようになりました。
• 新しいヘッダ X-Corda-Server-Version が、すべての Network Map API 応答 (コード 5xx の内部エラー応答を除く) に追加され、Network Map のバージョンと利用可能な呼び出しを示します。既定値は 2 です。
• 新しいヘッダ X-Corda-Platform-Version が Platform-version に置き換わりました。古いヘッダ名は引き続きサポートされます。
• 新しいヘッダ X-Corda-Client-Version が Client-version に置き換わります。古いヘッダ名は引き続きサポートされます。

SMR（Signable Material Retriever）サービスに代わる新しいSigning Serviceのプラグイン機能

SMR(Signable Material Retriever)サービスは、署名データのプラグインを処理する目的でCENM 1.2に導入されました。CENM 1.4では、従来のSMRをSigning Serviceの一部として機能するプラグインロードロジックに置き換えました。このロードロジックは、Identity ManagerサービスとNetwork Mapサービスから署名可能なデータをフェッチし、新しいプラグイン（指定されている場合）またはデフォルトのSigningサービス処理ロジックに送信します。

その結果、SMRサービスを完全に削除し、CENMサービスの数を減らし、デフォルトのSMRプラグインで作成されたRPCサーバーとストレージを維持する必要がなくなりました。

上記の変更に伴う一連の新機能と変更点については、以下に説明します。詳細については、Signingサービスのドキュメントを参照してください。

設定の変更

• serviceLocationAlias から serviceLocation へのリプレース

Signing Serviceの設定方法が変更され、各署名タスクが serviceLocationAlias の代わりに serviceLocation プロパティを使用しなければならないようになりました。新しいプロパティを使用して、CA以外の署名タスク(ネットワークマップ、ネットワークパラメータ)に対して、複数のロケーション(サブゾーンごとに1つ)を定義することができます。serviceLocationAliasプロパティは、CENM 1.4では使用できません（使用すると設定エラーが発生します）。

• プラグインベースまたはデフォルトの署名を設定するオプションの追加

各署名タスクは pluginJar と pluginClass からなる plugin と呼ばれる新しいプロパティを持っています。pluginプロパティが設定されている場合、Signing Serviceはプラグインを使用してデータに署名を行います。設定されていない場合、Signing Serviceはデフォルトの署名メカニズムを使用します。プラグイン・プロパティが使用されている場合、デフォルトのSigningサービス・キーは使用されないため、signedKeyAlias は存在してはいけません。CA タイプの署名タスク(CSR や CRL)同士では同じプラグインプロパティを設定する必要があります。同様に、非CAタイプの署名タスク（(ネットワークマップやネットワークパラメータ)同士 でも同じである必要があります。例えば、CAタイプの署名についてはプラグインを用いつつ、非ＣＡタイプの署名にはデフォルト署名を適用することができます。CA と非 CA の両方の署名タスクがプラグインを使用する場合、signingKeys プロパティを設定してはいけません。

非同期署名

非同期署名はプラグインAPI内の新機能で、Signing Serviceプラグインの使用時に署名を遅延させることができます。

下記のように機能します。

1. Signing Serviceは、署名要求のステータス変更をポーリングします。プラグインから返されたステータスがPENDINGの場合、Signing Serviceはポーリングを続けます。リクエストのステータス変更が返されるための最大設定タイムアウトはありません - Signingサービスは、ステータスがCOMPLETEDまたはFAILEDになるまでポーリングを続けます。
2. 返されたステータスがFAILEDの場合、リクエストは停止されます。
3. ステータスがCOMPLETEDの場合、リクエストは完了とマークされ、署名は、それぞれのCENMサービス (Identity Managerサービスまたはネットワークマップサービス)に保存されます。

非同期署名の導入に伴い、以下の変更が行われました。

• APIの変更。Signing Serviceがプラグインから署名ステータスを問い合わせることができるように、CAと非CAプラグイン用の新しい関数が追加されました。プラグインからの返答（ステータス）が PENDING となっているにもかかわらず、requestId (トラッキング ID) が含まれなかった場合、署名サービスからのポーリングは停止し、リクエストは破棄されます。
• シェル署名。シェル経由で署名が行われた場合、非同期トラッキングのIDとステータスがコンソールに出力されるようになりました。さらに、各署名タスクに新しいシェルメニュー項目が追加され、非同期署名リクエストのステータスを追跡できるようになりました。
• RPC機能の変更。RPC経由で署名が行われた際に、非同期署名のトラッキングIDとステータスを返すという複雑なタスクを可能にするために、リクエストの変更や、RPC経由で各リクエストのステータスを問い合わせるために使用される4つの新しいRPCリクエストの追加など、RPC機能に多くの変更が加えられました。詳細はSigning Serviceのドキュメントを参照してください。

コードの変更

• 共通のSignerー共通モジュールがあり、Signerクラスを抽象化し、各Signerに2つの実装を追加しています - 1つはデフォルトロジック用、もう1つはプラグインロジック用です。
• SigningServicePluginLoader。このクラスは、設定から定義されたプラグインをロードするために使用します。Java URLClassLoaderと、コンストラクタの引数として与えられる親ClassLoaderを使用します。

CAプラグインの例

CENM 1.4にはCAプラグインのサンプルが同梱されており、ユーザーが独自のプラグインを作成する際に必要なすべての情報を提供しています。詳細は Signing Service のドキュメントを参照してください。

AWSへの実装

ーAWS EKS、CloudHSM、PostgreSQLを利用した標準実装方法の提供ー

Kubernetes & Helmを利用した標準実装を提供しました。以下のコンポーネント使ったAWS環境へのサポートを拡大しています。

• EKS
• CloudHSM
• AWS PostgreSQL

CENM 1.4でサポートされている実装シナリオは以下の3つになります。

• AWSで外部PostgreSQLを利用
• AzureにPostgreSQLをクラスタでデプロイ
• AzureにPostgreSQLを外部接続

一方、以下のシナリオはサポートしません。

• AWSにPostgreSQLをクラスタでデプロイ

CENM のデプロイのセクションを参照してください。

その他の変更点

• CENMデータベースとCENMサポートマトリックスに記載されているように、PostgreSQL 10.10と11.5(JDBC 42.2.8)のサポートを追加しました。
• Artifactory の signing-service-plugins に non-ca-plugin.jar が追加されました。
• CENM 1.3で導入されたFARMサービスをGatewayサービスに名称変更しました。その結果、CENM 1.3 から CENM 1.4 にアップグレードする場合は、CENM 1.3 で使用していた FARM Service .jar ファイルを CENM 1.4 で使用していた Gateway Service .jar ファイルに置き換える必要があります。
• CENM 1.4では、Signingサービスの設定でsubZoneIDを設定する方法が変更されました - 詳細はCENMアップグレードガイドを参照してください。

問題の修正

• PostgreSQLのデータベーススキーマ初期化中にAuthサービスが起動できない問題を修正しました。
• SMR(Signable Material Retriever)サービスを使用せずにセットアップを行った場合に、Signingサービスの起動に失敗し、serviceLocations設定エラーが発生する問題を修正しました。SMRサービスはCENM 1.4で削除され、その機能はSigningサービスと統合されました。
• azure-keyvault-with-deps.jarとout.pkcs12ファイルがpki-podにコピーされず、結果としてPKI生成に失敗する問題を修正しました。
• HSMのパスワードがサービスログに隠されていない問題を修正しました。
• ZoneサービスがUtimacoとのSigningサービスの設定からmodeフィールドを削除した後、このフィールドをエンジェルサービスに戻すのに失敗していた問題を修正しました。
• 以前は何も情報を返さなかったIdentity Managerサービスとネットワークマップ・サービスのコマンドが、データが利用できない場合に表示されるようになりました。
• Gatewayサービス（以前のCENM 1.2ではFARMサービスと呼ばれていました）のログがlogs-farmコンテナで利用できない問題を修正しました。
• CENMコマンドラインインターフェイスツールでCRRリクエストの送信に失敗し、予期しないエラーメソッドパラメータが無効になる問題を修正しました。
• 各タスクに複数のアカウントがあり、すべてのユーザーを認証するオプションが選択されている場合、Signingサービスを使用して手動でSigningタスクを実行する場合、Signingサービスは、どのユーザーがパスワードを入力する必要があるかを表示するようになりました。
• context current コマンドは、現在のアクティブなユーザーと現在の URL を表示するようになりました。

既知の問題

• Azure または AWS 上の CENM 1.4 のCloudデプロイは、CENM 1.2 または 1.3 が既にそのクラスタ上で実行されている場合には、同じクラスタ上では動作しません (その逆もあります)。これは、両方のデプロイで使用されているいくつかのKubernetesコンポーネントの名前の競合が原因で、現在のところバージョン1.2/1.3と1.4が同じクラスタ上で動作しないようになっています。
• serviceLocationsの既知の問題により、新しいオプションのタイムアウト・パラメータがSigningサービスのserviceLocations構成ブロックを介してゾーン・サービスに渡されると、最初のserviceLocationsロケーションのタイムアウト値のみが考慮され、他のすべてのサービス・ロケーションに使用されます。
• コマンドラインインタフェースツールのリクエストステータスコマンドは、完了したリクエストに対しては機能しません。
• signer-ca の設定が間違っていたり、ca-plugin が停止していたりすると、問題の説明の代わりに例外が表示されます。
• Gatewayサービスのエラーは、メソッド名に無効な文字が見つかりました。HTTPメソッド名がトークンでなければならないエラーは、CENMをKubernetes上に正常にデプロイし、新しいノードを登録し、フローを実行した後に発生する可能性があります。しかし、このエラーによる副作用はなく、ユーザーはコマンドラインインタフェースツールに接続してコマンドラインインタフェースのコマンドを実行することができます。
• 現在、サービスコンソールのエラーコードには2つの不整合があります。
• config-parse-error はヘルプを表示しませんが、config-file-not-readable は表示します。
• config-parse-error はエラーコードを赤く表示しませんが、config-file-not-readable は赤く表示します。
• CENMサービスが、新しいエラーコードを処理し、ログに書き込む際に矛盾が発生します。Signing Service、Identity Manager Service、Network Map ServiceがDUMPログにエラーコードを書き込みます。AuthサービスとGatewayサービスは、OPSログとDUMPログの両方にエラーコードを書き込みます。
• config-substitution-errorコードは、正しくトリガされません。Signingサービス用のエンジェルサービスは、DUMPログにconfig-file-doesnt-existエラーコードを表示し、ZoneサービスはOPSログとDUMPログに例外をスローします。
• config-parse-and-validation-errorコードはトリガできず、config-parse-errorとして表示されます。
• AuthサービスとGatewayサービスは、設定が存在しない場合に2つの異なるエラーメッセージを表示します。Auth サービスの正しいエラーは以下の通りです。ERROR: Config file does not exist。Gateway サービスの正しいエラーは次の通りです。ERROR: The file does not exist.。
• 約2,500ノードの登録後にネットワークマップサービスの更新が滞る。
• コマンドラインインタフェース(CLI)ツールのsmrコマンドはCENMバージョン1.3でのみ使用されています。それ以降のバージョンでは、CENM 1.4でSMR(Signable Material Retriever)サービスが削除されたため、SMRコマンドの使用は推奨されていません - 詳細は上記の新機能と機能強化のセクションを参照してください。
• Admin RPC クライアントが GENERAL_ERROR コードと NULL メッセージを持つ RpcServerException を誤ってスローしています。SIGNER_SIGNABLE_SIGNABLE_MATERIAL_SOURCE_UNREACHABLE エラーコードを持つ RpcServerException をスローすべきです。
• Identity Manager Service の構成に REVOCATION ワークフローがない場合に submitCertificateRevocationRequestWithLegalName を実行すると、Admin RPC クライアントは期待どおりに例外をスローせず、代わりに空の応答を返します。IDENTITY_MANAGER_INVALID_REVOCATION_REASON および IDENTITY_MANAGER_CERTIFICATE_NOT_FOUND コードを持つ 2 つの RpcServerException 例外、または REVOCATION ワークフローが設定されていないことを示す例外をスローする必要があります。
• config-file-doesnt-exist エラーコードは、存在しない設定ファイルで Signing Service を起動したときには表示されません。コンソールやログにエラーコードや関連ドキュメントへのリンクが表示されません。
• CENM User Admin Toolでユーザーを作成する際に、"Role Name"の通知に誤りがあります。通知は次のように読み上げられます。"ロール名フィールドには空のスペースが含まれてはいけません!
• 複数の CRR 要求が送信され、plugin-ca/signer-ca を使用する場合、CRR 付き CRL に署名を行い、 workflow_crr テーブルのレコードを更新し、証明書ステータスを VALID から REVOKED に更新する必要がある。しかし、現在、signer-ca には失効したノードの詳細が表示され、workflow_crr テーブルのレコードは Pending であり、証明書のステータスは REVOKED ではなく VALID となっている。
• 構成の検証が正しくないtrustStoreの場所を処理する方法に矛盾があります。いくつかのパラメータでは、サービスが起動しません。他のパラメータでは、サービスが起動しようとして失敗します。
• コマンドライン・インタフェース（CLI）ツールは、間違ったファイル名の追加やファイルのパスにスペースがあるなどの問題に対して、Java DUMP例外（java.io.FileNotFoundExceptionなど）をスローするのではなく、エラー・コードを生成する必要があります。
• CENMコンポーネントの実行中のバージョンに関する情報がログから失われています。
• Helm Chartsを実行するとアプリのバージョンが表示されません。
• 不完全または不正な設定でSigningサービスが開始されると、スタックトレースが発生します。これは例外として処理されるべきです。
• CENM コマンドライン・インタフェース・ツールは、Identity Manager サービスではサポートされていない、以下の追加の証明書失効理由をサポートしています。CERTIFICATE_HOLD、UNUSED、REMOVE_FROM_CRL、AA_COMPROMOMISE、およびUNSPECIFIED。
• AWS Postgresデータベースを作成する際に、EKSクラスタのVirtual Private Cloud(VPC)を選択していると、データベースに接続できません。ただし、デフォルトのVPCを選択している場合は接続できます。

Edited by yoshino