Firebird 3 のワイヤ暗号化と VPN は別々の境界

VPN がつながり、クライアントがセッションを開くと、誰もがデータベース接続は保護されていると決めつけます。ここで三つの異なる事柄が混同されました。リスナーにそもそも到達できるのか、サーバーがユーザーを受け入れたのか、Firebird がワイヤ暗号化を交渉したのかは、それぞれ別の仕組みであり、証拠も別です。トンネルが答えるのは最初の一つだけで、しかも許可した送信元に対してだけです。

二つの境界は重ならない

VPN の境界はクライアントとゲートウェイの間のパケットを守ります。Firebird のワイヤ暗号化は、クライアントライブラリとサーバープロセスの間のデータベースプロトコルを守ります。両方が同時に存在でき、どちらかが他方を代替することはありません。

トンネルがデータベースホストの手前で終わるなら、その先の通信はデータベースセッションが交渉した内容だけで守られます。レビューが意外な発見をするのは、まさにこの隙間です。トンネルの図はゲートウェイで終わり、クエリを運ぶ接続はその先へ続きます。その図を後から読む人は、この前提を引き継いでしまいます。

境界その一: リスナーを開けるのは誰か

実際のサーバーアドレスと設定されたポート（変更されていなければ 3050）を特定し、ホストとネットワークのファイアウォールで承認済みの VPN 送信元だけを許可します。VPN ゲートウェイでのアドレス変換も考慮し、ゲートウェイが別ならデータベースホストにクライアントプールへの戻り経路を与えます。

次に、否定を証明します。拒否されるべき外部経路は、トンネルを開けてもそれ自体では Firebird のリスナーを制限しないため、拒否されたままである必要があります。

境界その二: Firebird が交渉するもの

Firebird 3 は、無効・有効・必須を選べるサーバーポリシーを伴うワイヤ暗号化の枠組みを導入しました。ポリシーが下限を決めます。実際のセッションは、アプリケーションが読み込むクライアントライブラリと、双方が対応するプラグインに依然として依存します。

Firebird 3 の リリースノート では、Arc4 がこのリリースの既定のワイヤ暗号化プラグインとして挙げられています。Arc4 は歴史的な既定値であり、現代的な暗号の推奨ではなく、外側の VPN 保護とは同じものではありません。

認証は同じ交渉における三つ目の変数です。サーバーは認証プラグインの集合を受け入れ、クライアントライブラリはその一部を提示し、両者が重ならなければなりません。

Legacy_Auth の罠

Legacy_Auth を支えるには、サーバーの既定の必須暗号化ポリシーを緩める必要があります。それが文書化された互換性のコストであり、接続エラーを黙らせるためにポリシーを下げるのは修正ではなくセキュリティの変更なのです。

サーバー更新後にクライアントが突然失敗するなら、何かを弱める前にプラグインの一覧を比べてください。失敗はたいてい交渉の不一致で、答えは双方で対応しているプラグインです。

重要な接続を確認する

コンテキスト変数を提供するビルドでは、このクエリが現在の接続の暗号化状態を報告します:

SELECT RDB$GET_CONTEXT('SYSTEM', 'WIRE_ENCRYPTED')
FROM RDB$DATABASE;

同じサーバー上の管理者セッションではなく、アプリケーション自身の接続で実行してください。暗号化された管理者の接続は、別のクライアントライブラリのセッションについて何も語りませんし、その変数に対応しない古いビルドは暗号化が無効である証拠になりません。

どれか一つだけでは読めないため、クライアントライブラリのバージョン、サーバーのビルド、結果をまとめて記録してください。

権限とアップグレードの道筋

送信元の制限と通信の暗号化は、認証や最小権限の許可を置き換えるものではありません。通常のデータベースユーザーが実際に触れるオブジェクトに対する権限を確認してください。

最後に、長く使う配備を保守の問題として扱ってください。トンネルは古いクライアントライブラリをいつまでも安全にはしませんし、対応済みのアップグレード経路のほうが、必要なプラグインが削除されたと気づくより安く済みます。