データベースクライアントがクエリを送信したり、クエリの結果セットを受け取ったりするたびに、そのデータはネットワークを経由して送受信されます。外部からアクセスされない、隔離されたプライベートネットワーク上であれば、暗号化されていない接続であっても危険度はおそらく許容範囲内と見なされるでしょう。しかし、通信が共有インフラ、クラウドネットワーク、あるいは一般のインターネットを経由する現実的な環境では、暗号化されていないデータベース接続は重大なセキュリティリスクとなります。SSL/TLSによる暗号化はこの脆弱性を解消します。そして、これを正しく設定することは、データベース環境を保護する上で極めて重要でありながら、しばしば見落とされがちな手順の一つです。
なぜ暗号化されていない接続が深刻なリスクとなるのか
暗号化が行われない場合、データベースの利用者とサーバーの間でやり取りされるデータは平文のまま送受信されます。同じネットワーク経路上にいる者であれば――例えばハッキングされたルーター、設定ミスのあるクラウド仮想ネットワーク、あるいは内部関係者による脅威など――誰でもその通信内容を読み取ることが可能です。これにはクエリの結果だけでなく、認証情報も含まれます。暗号化されていないデータベース接続から盗み取られたログイン情報は、さらなる手間をかけずに有効なユーザー名とパスワードを悪意ある者に提供することになります。このリスクは非現実的なものでは決してありません。ネットワークレベルでの傍受は広く知られた攻撃手法であり、傍受された通信がデータベースからのものである場合、その深刻度はいっそう高まります。
デジタル証明書の構造（証明チェーン）について
TLS（Transport Layer Security）は、デジタル証明書に基づく認証システムです。暗号化された通信を成立させるためには、まずサーバーが自身の身元を証明する「デジタル証明書」をクライアント（接続先）に提示します。これは、いわば「私は自称する通りの存在であり、それを証明するために信頼できる認証機関の発行した暗号署名付き文書を添付します」と宣言するようなものです。その信頼できる機関は「認証局（CA：Certificate Authority）」と呼ばれ、その役割は、発行する証明書の身元を保証することです。
実際の運用において、データベースサーバーで適切に検証された TLS 接続を確立するには、次の 3 つの要件が満たされている必要があります。
- サーバーは、CA によって発行された有効な証明書を持っている必要があります。
- クライアントは、サーバーの身元を検証できるよう、CA の証明書のコピーを持っている必要があります。
- （必要に応じて）相互認証（mTLS）の場合、サーバーはクライアントにも自身の証明書の提示を求め、双方向で認証が行われます。これは「証明書ベースの認証」とも呼ばれ、パスワードベースの認証のみの場合よりもはるかに高い信頼性を保証します。
知っておくべき重要な設定項目
TLSをデータベース通信に導入する際、データベースシステムやクライアントに関わらず、共通して設定される主なパラメータは以下の通りです：
- CA証明書（認証局証明書）は信頼の基盤とみなされます。サーバーの身元を確認する際、どの認証局の発行した証明書であれば信頼できるかをクライアントが判断するためのものです。
- 相互TLSが義務付けられている場合、クライアントはクライアント証明書とクライアント鍵が必要となります。これにより、サーバー側もクライアントの身元を確認できるようになります。
- 暗号スイート（cipher specification）によって通信セッションで利用可能な暗号アルゴリズムが決定されます。古い暗号スイートには既知の脆弱性が存在する可能性が考えられるため、デフォルト設定を受け入れるのではなく、強固で最新の暗号スイートを指定することが推奨されます。
PostgreSQL の SSL オプション
PostgreSQL では、SSL 使用モードの設定により、接続のセキュリティレベルを厳密に定義できるため、特に有用な機能となっています。オプションには、次のような段階があります。「allow」（最初はSSLなしで接続を試み、必要に応じてSSLに切り替える）、「prefer」（最初にSSL接続を試み、失敗した場合は非暗号化接続に切り替える）、「require」（SSLのみを使用するが、証明書の検証は行わない）、「verify-ca」（SSLを使用し、証明書が信頼できるCA（認証局）から発行されたものであることを検証する）、「verify-full」（SSLを使用し、CAの検証に加え、サーバーのホスト名が証明書に記載されたものと一致することを検証する）。実稼働環境では、「require」よりも制限の緩い設定は通信中間者攻撃の余地を残すため、「verify-ca」または「verify-full」が適切な選択となります。
SSHトンネリングという代替策
SSL/TLSはデータベースプロトコル自体を暗号化します。一方、SSH（Secure Shell）トンネリングは異なるアプローチをとります。この手法では、データベース接続全体を暗号化されたSSHセッション内において保護します。データベースクライアントはローカルポートに接続し、SSHトンネルがその通信を暗号化された接続を介してリモートサーバーへ転送します。その結果、データベースサーバー側からは、トンネルの最終地点からのローカル接続として認識されます。SSHトンネリングは、データベースサーバーにTLSが設定されていない場合や、セキュリティ上必要なファイアウォールなどの理由からデータベースポートを外部に公開できない場合に特に有効です。なぜなら、データベースレベルでのTLS設定を必要とせず、SSH接続環境さえあれば機能するからです。同様に、要塞ホスト（バステイオンホスト）に保護されたデータベースにインタラクティブ接続が必要な管理者が、リモート接続をセキュリティ保護するためのシンプルな解決策でもあります。
NavicatによるSSL/TLSおよびSSHトンネリングのサポート
Navicat Premium や各種データベース向けのクライアントを含むNavicatのデスクトップ製品では、接続設定画面内で直接SSL/TLSの設定を行うことができます。接続の設定または変更時に、SSL専用タブからアクセス可能です。ユーザーはそこでSSLを有効にし、サーバーの身元を確認するために必要となるCA証明書を準備できるほか、必要に応じて相互TLS用のクライアント証明書やクライアント鍵も用意できます。さらに「暗号スイート」を指定する設定項目では、接続時に使用可能な暗号スイートを管理者が直接指定できるため、デフォルト設定に制限されることなく、接続のセキュリティレベルを細かくカスタマイズできます。特にPostgreSQL接続においては、前述のSSLモードオプションが全て利用可能であり、管理者は接続の認証レベルを厳密に管理できます。
SSHトンネリングも、Navicatの全製品ラインで標準サポートされています。接続設定ダイアログの「SSH」タブでは、経由するSSHサーバーを経由したトンネルを設定でき、パスワード認証だけでなく公開鍵と秘密鍵のペアによる認証もサポートされています。これにより、外部ネットワークに直接公開されていないデータベースでも、安全かつ簡単に接続することが可能になります。
Navicat On-Prem Server は、このSSL/TLSサポートを共同作業環境においても同様に展開しています。On-Prem Serverとクライアント間の接続はSSL/TLSを使用して暗号化でき、管理者はそれらのセッションで使用する暗号スイートを具体的に設定可能です。なお、SSL/TLSはNavicat On-Prem Serverとその基盤となるリポジトリデータベースとの接続にも適用できるため、エンドユーザーからの接続だけでなく、共同作業プラットフォームの内部通信経路においても完全なエンドツーエンドでの暗号化が徹底されるのです。
結論
データベース接続のためのSSL/TLSの設定は、それほど複雑な作業ではありませんが、証明書の管理、モードの選択、暗号スイートの設定など、間違えやすい部分や、セキュリティ上のリスクを伴うデフォルト設定のままになりがちな点に細心の注意を払う必要があります。これらを適切に設定することで、ネットワークレベルでの傍受による認証情報の不正取得やデータ漏洩のリスクを大幅に低減することができます。機密データを扱うデータベースや、完全にプライベートで隔離されたネットワーク以外からのアクセスを受けるデータベースにおいては、適切に設定された TLS はオプションではなく、必須の要件です。
