Jira Data Center クラスター認証
Jira Data Center クラスタ内のノードは、TCP の Java RMI 経由でキャッシュ レプリケーション メッセージを相互に交換します。この通信は暗号化されていません。さらに、Jira 8.17 までは、キャッシュ レプリケーション プロセスで使用される RMI ポートが外部ソフトウェアからアクセスすることを意図していないため、認証されていませんでした。
Jira Data Center クラスタのセキュリティを向上させるために、Jira 8.17 ではクラスタ認証メカニズムを導入しました (Jira 8.13.8 と 8.5.16 にもバックポートされています)。自動生成されたキーに基づく認証を使用して、キャッシュ レプリケーションに使用される RMI ポートを保護します。このキーは、Jira データベースを介してクラスタ内のノード間で共有されます。
認証は、クラスタのノード間での各 RMI 接続を開始する相互対称チャレンジ - レスポンス プロトコルとして実装されます。このような接続内で交換される後続のメッセージは、追加のセキュリティで保護されません。接続ペイロードには、追加の暗号化や署名はありません。
RMI ポートへのアクセス制限の重要性
Jira クラスタ認証でも、ネットワーク レベルで RMI ポートへのアクセスを制限することをお勧めします。詳細については、Jira Data Center のインストール (「セキュリティ」セクション) をご参照ください。
Jira クラスタ認証の有効化
Jira 8.17 (8.13.8 と 8.5.16 も同様) 以降は初期設定でクラスタ認証が有効になっているため、アクションは実行不要です。
初めて Jira インスタンスを起動すると、Jira によって認証キーが生成されてデータベースに格納されます。ゼロ ダウンタイムのアップグレードを使用している場合は、アップグレードのプロセス終了時にキーが生成されます。キーが生成されると、後続のキャッシュ レプリケーション RMI 接続が認証されます。
認証キーの再生成
セキュリティが侵害された、またはセキュリティ ポリシーで定期的に実行する必要がある場合は、認証キーを再生成する必要があります。データベースから既存のキーを削除することで、認証キーを再生成できます。
認証キーを再生成するには、以下を実行します。
Jira データベースで次の SQL ステートメントを発行して、コミットします。
delete from securityproperty where property_key = 'rmi.socket.cluster.auth.secret.key';Jira を再起動する必要はありません。新しいキーは 1 分以内に生成されます。通信は一時的に古いキーを使用し続けますが、その後、認証されていない通信を許可しないために、新しいキーへの切り替えが行われます。
Jira クラスタ認証の無効化
トラブルシューティングの目的などで Jira クラスタ認証を無効にするには、2 つの方法があります。最大の違いは、Jira インスタンスの再起動を許可できるかどうかです。
再起動が必要 (推奨)
各 Data Center ノードで、com.atlassian.jira.cluster.distribution.localq.rmi.auth.disabledシステム プロパティをtrueに設定します。
(これは Java のシステム プロパティで、取得するためには JVM 引数を設定する必要があります。UI からは設定できません。)
再起動が不要 (一時的)
もう一つの方法は、次の例のように、securityproperty テーブルを編集して、その値を空のキーに設定することです。
update securityproperty set property_value = '' where property_key = 'rmi.socket.cluster.auth.secret.key';ただし、この方法では以下の結果を招く可能性があります。
パフォーマンスが低下するリスク
警告の記録:
WARN [c.a.j.c.d.l.rmi.auth.DefaultClusterAuthSharedKeySupplier] Cluster Authentithentication disabled due to missing security properties key rmi.socket.cluster.auth.secret.key, warning counter: 1. Note the frequency of this warning is controlled by com.atlassian.jira.cluster.distribution.localq.rmi.auth.warn.min system property
各ノードでこれらの警告の頻度を制御するには、次のシステム プロパティを使用します。
com.atlassian.jira.cluster.distribution.localq.rmi.auth.warn.min.
この方法 (空のキー) を使用した後に Jira クラスタ認証を再度有効にするには、上記のセクションで説明した認証キーを再生成する必要があります。
サーバー側ソケット タイムアウトの変更
RMI 接続を作成する Jira クラスタ認証フェーズで使用されるサーバー側ソケット タイムアウトは、既定では 10 秒に設定されています。
タイムアウトを変更するには、次を実行します。
各ノードで次のシステム プロパティの値を変更します。
com.atlassian.jira.cluster.distribution.localq.rmi.server.auth.so.timeout.millis
Jira クラスタ認証統計
次の表に記載されているとおり、Jira 統計ログは Jira クラスタ認証に関連するメトリックで拡張されました。詳細については、 Jira 統計ログをご参照ください。
| メトリック | 説明 |
|---|---|
startTimestampMillis | 統計累積期間のタイムスタンプ。 |
authsTotal | クラスタ認証の試行回数。 |
authsSkippedNoSecret | キーがないためにスキップされた認証の数。通常は 0 と表示されますが、ZDU アップグレード中は多く表示される場合があります。 |
authsFailed | 認証の失敗回数 (タイムアウトによる失敗は含まない)。 |
authsFailedByTimeout | タイムアウトにより失敗した認証の数。 |
authsSuccess | 成功した認証の数。 |
timeToAuthMillis | 認証時間 (ミリ秒):
|
これらの統計はどのように収集されますか?
これらのメトリック統計は、ノードごとに個別に収集されて、com.atlassian.jira.stats.logging.interval システム プロパティで指定された間隔 (各ノード単位、既定では 5 分) で、特定のノードのプライマリ Jira ログファイルに書き込まれます。
RMI 通信では、各ノードがサーバーとクライアントの両方として機能するため、統計はクライアント側とサーバー側で別々に収集されます。統計は、ノードの開始以降 (total) と最後のログエントリ以降 (snapshot) の次の 2 つの方法で蓄積されます。そのため、これらの統計情報として、次の 4 カテゴリがログ ファイルに表示されます。
Cluster authentication server snapshot statsCluster authentication client snapshot statsCluster authentication server total statsCluster authentication client total stats
次の例のように、クラスタ認証統計データは JSON 形式で、[JIRA-STATS] [JIRA-RMI-AUTH] プレフィックスでログファイルにタグ付けされます。
INFO [c.a.j.c.d.l.rmi.auth.ClusterAuthStatsManager] [JIRA-STATS] [JIRA-RMI-AUTH] Cluster authentication client snapshot stats: {"startTimestampMillis":1618398658051,"authsTotal":37,"authsSkippedNoSecret":0,"authsFailed":0,"authsFailedByTimeout":0,"authsSuccess":37,"timeToAuthMillis":{"count":37,"min":0,"max":45,"sum":665,"avg":17,"distributionCounter":{"0":3,"1":2,"5":3,"10":8,"50":21,"100":0,"500":0,"1000":0,"5000":0}}}