データベースシステムを安全に保つには、単独のセキュリティ対策だけでは不十分です。例えばファイアウォールは設定ミスが起きる可能性がありますし、認証情報はフィッシング攻撃の標的となる恐れがあります。以前は安全と見なされていた製品からも、ソフトウェアの脆弱性が発見されることがあります。「多層防御(Defense-in-depth)」戦略は、こうした現実を踏まえ、複数の保護層を重ね合わせて構成することにより、ある層が侵害されても、他の層が機能して被害を食い止める仕組みです。特にデータベースインフラにおいて、この方法は単なる最善策にとどまらず、法規制の対象となる業界において、コンプライアンス要件としてますます重要視されています。
ネットワークペリメーター（境界防御）からスタート
データベースセキュリティ戦略の最も外側にある層は、ネットワークレベルの制御です。これは、最初から許可されたシステム以外はデータベースサーバーにアクセスできないようにすることを意味します。具体的には、データベースサーバーをパブリックインターネットから直接アクセスできないプライベートネットワークセグメントに置き、ファイアウォールを介して特定のIP範囲からのみ受信接続を許可し、リモートアクセスについては直接接続ではなくVPNや中継ホスト（バステイオンホスト）を経由することを義務付けるといった対策が挙げられます。
ネットワークの分離（セグメンテーション）は、複数のアプリケーションがインフラを共有する環境において特に重要です。機密性の高い顧客データを保有するデータベースサーバーは、組織内のすべてのシステムからアクセス可能にすべきではありません。アクセスできるのは、そのサーバーへの接続が必要な特定のアプリケーションサーバーや管理ツールに限るべきです。ネットワークレベルで攻撃対象領域を制限することで、システム環境内の他の場所でセキュリティ侵害が発生した場合の影響を大幅に抑えることができます。
送受信中および非アクティブ時のデータ暗号化
データ暗号化は、たとえ他のセキュリティ対策が破られた状況でもデータを保護する重要な防御層です。送受信中のデータ（クライアントとデータベースサーバーの間をやり取りするクエリ、結果、認証情報など）は、常にTLS（Transport Layer Security）を介して暗号化する必要があります。TLSを使用しない場合、同じネットワーク経路上に存在する者であれば誰でも、ログイン認証情報を含むその通信を傍受し、読み取ることが可能になります。保存中のデータ（バックアップを含む、ディスク上に実際に保存されているファイル）についても、記憶媒体への物理的なアクセスがデータの漏洩につながらないよう、暗号化する必要があります。
単に暗号化を有効にするだけでなく、暗号スイート（cipher suite）の選択にも注意を払う価値があります。古い暗号スイートには脆弱性が知られるものが多く、AES-256-GCMやChaCha20-Poly1305ベースの暗号スイートなど、最新かつ強力な暗号を使用するようにシステムを構成することは、初期設定のまま使用する場合よりも、はるかに優れたセキュリティ対策となります。
強力な本人認証の徹底
パスワードだけでは、推測されたり、複数のサービスで再利用されたり、フィッシング攻撃の標的になったり、第三者によるデータ侵害で漏洩したりする可能性があるため、脆弱な認証手段です。強固な認証レイヤーを構築するには、まず強力なパスワード規定（最小文字数、構成の複雑さに関する要件、管理者レベルのアカウントの定期的な変更）を徹底することから始め、可能な限り多要素認証を導入し、パスワードが正しく入力された場合でも、追加の検証ステップを要求する必要があります。
企業環境においては、データベースツールの認証を、LDAP ディレクトリや Active Directory などの中央認証システムと統合することで、重要な運用管理の層が実現されます。ユーザーアカウントを一元管理することで、退職した従業員のアクセス権を、その従業員が利用していたすべてのシステムで個別に削除するのではなく、一箇所で取り消すことが可能になります。
厳格な役割ベースのアクセス制御（RBAC:Role-Based Access Control）の実践
本人認証は、システムへアクセスできる人物を制限します。一方、アクセス制御は、システム内に入った後にその人物が操作できる範囲を制御します。役割ベースのアクセス制御（RBAC）、いわゆる個人ではなく役割に権限を割り当てる方式は、大規模なデータベース権限管理における基本的な手法です。その指針となるのは「最小権限の原則」です。すべてのユーザーおよびアプリケーションアカウントは、その役割を遂行するために必要最低限の権限のみを持ち、必要以上の権限を持たないことが原則です。
実際の運用においては、利便性を理由に安易に幅広く管理権限を付与するという、最も陥りやすい手抜きを避ける必要があります。アプリケーション運用アカウントには、使用する特定の図式（スキーマ）や表（テーブル）に対する読み取り／書き込みアクセス権のみを与えます。読み取り専用の分析担当者は、SELECT権限は与えますが、データの変更や削除を行う権限は与えるべきではありませ ん。より高い権限を持つ管理アカウントは、本当にその権限が必要な状況でのみ使用し、日々の業務用アカウントとして継続的に使用するべきではありませ ん。
監視、監査、アラート
これまでに説明した防御層は、すべて不正アクセスを未然に防ぐことを目的としていましたが、ここでは、それらの防御が破られた場合にそれを検知することにフォーカスします。これは、いかなる防御策も破られる可能性が存在するためです。データベースのアクセス状況（誰が、いつ、どこから接続し、どのようなクエリを実行したか）を総合的に記録する監査ログは、問題の原因を究明したり、コンプライアンスの遵守を証明したりするために必要となる、事後検証のための証拠となります。不審な動き（異常な量のクエリ、営業時間外のログイン、データエクスポートの急激な増加など）を検知してアラートを発生させるリアルタイム監視により、深刻な被害が生じる前に、進行中の脅威を表面化させることができます。
監査ログは、侵害されたデータベースサーバーがアクセスできない場所に保存されてこそ価値があります。監視対象のシステムそのものにログを記録すると、そのシステムに侵入した攻撃者がログを改ざんできることになります。アクセスが制御された別のシステムにログを送信することは、基本的でありながら見落とされがちな手順です。
Navicat On-Prem Server 3.1 と多層防御
データベース共同作業環境も同様に、保護範囲の一部であり、切り離された存在ではありません。そのため、Navicat On-Prem Server 3.1 には、前述の多層防御の仕組みが既に組み込まれて設計されています。
データ送受信層において、Navicat On-Prem Server はサーバーとクライアント間の接続を暗号化するために SSL/TLS をサポートしており、管理者はその暗号化に使用する暗号スイートを指定することができます。幅広く最新の高度な暗号化アルゴリズムがサポートされているため、管理者はただデフォルト設定を適用するのではなく、暗号化の強度を有効に管理することができます。
認証層において、当プラットフォームはユーザーアカウント向けの二段階認証をサポートしており、二つ目の人証手段として認証アプリ、SMS、Eメールなどのオプションが用意されています。ユーザーを一元管理する企業向けには、Navicat On-Prem ServerはLDAPおよびActive Directory経由の認証もサポートしているため、ユーザーのアクセス権限を企業の既存のID管理インフラに直接紐付けることが可能です。パスワードの強度設定要件についても管理者が設定できるため、企業の総合的なセキュリティ基準に沿ったポリシーを適用することが可能です。
アクセス制御層において、当プラットフォームは役割ベースのプロジェクト操作権限（「管理および編集可能」、「編集可能」、「閲覧可能」の3段階システム）を提供しており、管理者は各チームメンバーの共有データベースへのアクセス権限を、その役割に必要な範囲に厳密に限定することができます。サーバーは第三者のクラウドサービスではなく、企業の自社インフラ上で稼働するため、これらのセキュリティ設定はすべて企業の直接的な管理下に置かれ、データやそれを管理する設定に対して外部からアクセスされることはありません。
結論
多層防御戦略とは、製品として購入したり、一回行えば完了するチェックリストのようなものではなく、永続的な取り組みです。各層を慎重に設計し、脅威の進化に合わせて設定を最新の状態に保ち、監視を積極的に行い、時間の経過とともに避けられない方向性のずれを常に見直すことが求められます。多層防御戦略の価値は、決して一つの対策が完璧であることに依存しない点にあります。むしろ、攻撃者が目的を達成するためには、互いに独立した複数の層を突破しなければならないという点にこそ、その価値があるのです。多くのデータベース環境において、こうした層を構築し維持することは、セキュリティ意識の高い企業が実施できる最も重要な投資の一つです。
