要点
- Webサーバーが侵害された場合に攻撃者がデータベースへアクセスするのを防ぐため、データベースサーバーとWebサーバーを分離します。(セクションへ移動）
- 不審な挙動を検知して対応できるよう、データベースのアクティビティを定期的に監査・監視します。(セクションへ移動）
- 最小権限の原則に基づく厳格なアクセス制御を実装し、ユーザー権限を定期的に見直します。(セクションへ移動）
データベースには組織が保有する中でも特に機密性の高いデータが含まれているため、サイバー攻撃や内部関係者によるデータ窃取からデータを守るには、データベースセキュリティのベストプラクティスに従うことが重要です。
効果的なデータベースセキュリティでは、複数層の制御によって機密情報を保護し、侵害のリスクを低減するとともに、侵害が成功した場合の被害を抑えます。本稿では、相互に重なる制御を実現するデータベースセキュリティのベストプラクティス7つに続いて、関連システム向けの追加のベストプラクティス7つを解説します。これにより、組織全体のリスクを最小限に抑える、堅牢な多層防御を実現できます。
データベースセキュリティとは？
データベースセキュリティとは、データベースファイル、データベース管理システム（DBMS）、接続されたシステムへの不正アクセスやデータ侵害を防ぐために組織が実装する制御を指します。セキュリティ制御には、データへのアクセスや利用を困難にするアーキテクチャ技術、アプリケーション設計、手順、プロセス、ツールなどが含まれます。
データベースセキュリティが不十分だと、運用効率、アプリケーションのパフォーマンス、ユーザーエクスペリエンスに悪影響を及ぼします。使いやすさを維持しながらリスクを許容可能なレベルまで低減することを目標に、セキュリティと運用上のニーズのバランスを取る必要があります。
データベースセキュリティのベストプラクティスと制御は、データベースに特化したものです。しかし、データベースは完全に孤立して存在するわけではないため、組織はより広範なエコシステムも防御しなければなりません。十分な防御を実現するには、関連システムに適用される、より一般的なセキュリティのベストプラクティスも実装する必要があります。
こちらもご覧ください：データベースセキュリティの主要ソリューション
データベースセキュリティのベストプラクティス7選
データベースを保護するには、専用の境界セキュリティで守られた安全な環境に配置し、安全なユーザーからアクセスできるようにする必要があります。以下の7つのベストプラクティスは、データベースとデータベース内のデータを直接保護するものです。
1. データベースサーバーを分離する
Webサーバーは、利用するために一般公開されていなければなりませんが、そのため攻撃の主な標的にもなります。攻撃が成功すると、攻撃者はWebサイトやアプリケーションのホストサーバーにアクセスできるようになり、サーバー上でホストされている他のあらゆるものにもアクセスできる可能性があります。
データベースは、追加の強化対策を可能にし、Webサイトやアプリケーションが侵害された場合のアクセスを防ぐため、別のコンテナ、物理サーバー、または仮想サーバーに分離すべきです。分離したサーバーでは必要なポートだけを開き、可能であれば、攻撃の実行を困難にするため、組織はデフォルトの通信ポートを変更すべきです。
データベースとクエリの間にHTTPSプロキシサーバーを設置することを推奨する人もいますが、Webサーバーとデータベースサーバーの機能を分離するだけでも同じ結果が得られます。ただし、承認されたネットワークユーザーやデバイスが直接クエリを実行する可能性のある内部ネットワーク上のデータベースでは、プロキシサーバーが有効な場合があります。
データベースをさらに保護するには、アクセス権限を厳しく制限した別の物理ネットワークセグメントまたは仮想ネットワークセグメントに、データベースサーバーを配置することを検討してください。マイクロセグメンテーションによって、より広範なネットワークアクセスを取得した攻撃者が、侵害されたユーザーのネットワーク上には表示されない可能性のあるデータベースサーバーへ、容易にラテラルムーブメントするのを防げます。
2. データベースファイアウォールを使用する
データベースはアクセスされて初めて役立ちますが、そのアクセスは保護しなければなりません。最初の防御層となるのは、デフォルトでアクセスを拒否するデータベース専用のファイアウォールです。ファイアウォールを通過できるトラフィックは、データへのアクセスが必要な特定のアプリケーション、Webサーバー、またはユーザーからのものだけにすべきです。また、明確な必要性がない限り、ファイアウォールはデータベースからの外向き接続開始も拒否すべきです。
用途上許される場合、データベースへの直接アクセスは制限または拒否すべきです。ファイアウォールルールの変更は変更管理手順で制御し、セキュリティ監視用のアラートを発生させる必要があります。
組織は、専用ファイアウォールを含む特殊なデータベースツールを導入できます。これには、Oracle Audit Vault and Database Firewallのほか、専用の物理または仮想次世代ファイアウォール（NGFW）、Webアプリケーションファイアウォール（WAF）ソリューションなどがあります。リソースが限られている組織では、データベースサーバーのオペレーティングシステムに搭載されたファイアウォールを強化版として導入するだけでもよいでしょう。
3. データベースユーザーのアクセスを保護する
データベースにアクセスできるユーザー、アプリケーション、アプリケーションプログラミングインターフェース（API）の数は、可能な限り少なくすべきです。アクセスは、ネットワークまたはアプリケーションによる承認後にのみ許可し、その場合でも、すべてのアクセスは最小権限の原則に基づき、必要な最短時間だけ付与すべきです。このベストプラクティスは、ユーザー認可、特権アクセス、開発・運用（DevOps）におけるデータベース利用という3つのサブカテゴリーに分けられます。
ユーザー認可
データベースへのアクセス制御は、システム管理者（管理者）が管理します。管理者は、ロールによって定義された権限を付与し、ユーザーアカウントをデータベースのロールに追加します。例えば、行レベルセキュリティ（RLS）というロールでは、ユーザーのID、ロールメンバーシップ、クエリ実行コンテキストに基づき、データ行への読み取り・書き込みアクセスを制限します。
専用のデータベースセキュリティソリューションでは、IDと権限を一元管理したり、パスワードの保存を最小限に抑えたり、パスワードローテーションポリシーを有効にしたりできます。包括的なアクセス管理は小規模な組織には現実的でない場合もありますが、個々のユーザーではなくロールやグループを通じて権限を管理することは、依然として重要です。
管理者は、データベースへのアクセスルールも強化する必要があります。
- 空のパスワードを許可しない
- パスワードを含む可能性のある一時インストールファイルを削除する
- デフォルトアカウントが不要であれば削除し、必要であればデフォルト設定のパスワードを変更する
- 追跡とログ記録のため、すべてのユーザーに一意のIDを要求する
- ユーザーとアプリケーションには別々のアカウントを使用させる
- 非アクティブなユーザーを定期的に無効化または削除する
- 昇格されたデータベース権限をログに記録・報告し、必要に応じてセキュリティアラートを生成する
- ユーザーグループとアクセス権を定期的に見直す
- ログインに一定回数失敗した後にアカウントを自動的にロックする。通常は6回のログイン失敗が推奨される
特権アクセス
管理者には、必要なタスクを実行するために必要最小限の権限だけを、アクセスが必要な期間に限って付与すべきです。特権アクセスは一時的に付与し、継続的に取り消す必要があります。大規模な組織では、特権アクセス管理（PAM）ソフトウェアを使用してアクセス管理を自動化します。PAMは、承認されたユーザーに一時的なパスワードを提供し、アクティビティを記録して、パスワードの共有を防ぎます。
DevOpsにおけるデータベース利用
通常、ユーザーとは見なされませんが、DevOpsチームは、アプリケーションがデータベースに正しくアクセスし、利用できることを検証するため、テスト環境を作成する必要があります。しかし、ライブ環境または本番データベースのデータを使用すると、偶発的なデータ漏えいにつながることが少なくありません。
問題を避けるため、DevOpsでは次のプラクティスを使用すべきです。
- 機密データは本番環境に限定する
- テスト環境を本番環境から物理的かつ論理的に分離する
- テスト環境では、本番環境とは別のロールと権限を使用する
- 開発者には、絶対に必要な場合を除き、本番環境へのアクセスを与えない
- テスト環境に実際の本番データを含めてはならず、代わりに合成データセットまたは匿名化済みデータセットを使用する
4. データベースを強化する
サーバーを強化する必要があるのと同様に、単純な攻撃やエクスプロイトを防ぐため、データベースも強化すべきです。
データベースの強化方法はデータベースプラットフォームの種類によって異なりますが、一般的な手順には、パスワード保護とアクセス制御の強化、ネットワークトラフィックの保護、データベース内の機密フィールドの暗号化などがあります。
認識されていない悪用を防ぐため、データベースの未使用または不要なサービスや機能はすべて削除または無効化すべきです。
データベースが提供するすべてのデータベースセキュリティ制御を有効にすべきです。デフォルトで有効になっているものもあれば、無効にする明確な理由があるものもありますが、それぞれを評価し、無効化した制御についてはその理由をすべて文書化する必要があります。可能であれば、管理者は機密データに対する行レベルセキュリティと動的データマスキングを有効にできます。
DevOpsは、機密情報が分離されたテーブルに残るようデータベースを設計すべきです。管理者もデータを継続的に監査し、機密データを発見して、分離されたテーブルの変更や追加のセキュリティ対策が必要かどうかを判断する必要があります。一部の規制またはコンプライアンス基準では、コンプライアンスを証明するために実装、遵守、文書化すべき具体的なデータ検出要件が定められています。
こちらもお読みください：ネットワーク保護：ネットワークを安全にする方法
5. データベースアクティビティを監査し、継続的に監視する
DevOpsでは一定の前提に基づいて設計しますが、データベースをアプリケーションと統合し、本番環境に移行した後は、予期しないアクセスやユーザークエリ、データの挙動が発生することがあります。管理者は、次のようなデータベースのログ、データ、アクティビティを継続的に監視・監査する必要があります。
- ユーザーのログインログ、特にログインの試行と失敗
- ロックされたアカウント（ログイン失敗が過度に繰り返された場合）
- データベース権限の昇格
- データベースデータの抽出、コピー、削除（特に大規模な変更や抽出）
- 機密データまたは規制対象データへのアクセス（コンプライアンス上必要になる場合があります）
- 新しいアカウントの作成
監査によって異常なアクティビティを検出できることが多く、セキュリティチームは、セキュリティチームに警告したり、セキュリティ情報・イベント管理（SIEM）ツールのアラートを有効にしたりするために、重要なイベントに対するセキュリティアラートを設定できます。データベースアクティビティ監視（DAM）やファイル整合性監視ソフトウェアを使用すれば、データベース固有のロギングや監査機能とは独立した、専門的なセキュリティアラートを提供できます。
6. データベースセキュリティをテストする
監査によって進行中の悪意あるアクティビティを検出できるとしても、組織はデータベースのデプロイをテストするために攻撃を待つべきではありません。データベースベンダーの更新を監視し、パッチ管理プロセスによって、遅延を最小限に抑えてデータベースを更新する必要があります。
ただし、パッチ適用で対処できるのは、公表された脆弱性だけです。一部のデータベースベンダーは、Oracleのデータベースセキュリティ評価ツールなど、リスクの特定に役立つセキュリティ・設定テストツールを提供しています。ただし、こうしたツールだけで100%の保証が得られると考えず、その後、脆弱性スキャンとペネトレーションテストを使って補完する必要があります。これらのテストでは、潜在的な攻撃をシミュレーションし、設定ミスや意図せずアクセス可能になっているデータ、その他の問題を明らかにします。
7. データベースデータのベストプラクティス
データベースはデータを構造化しますが、データベース内に含まれるデータも保護する必要があります。最初のステップでは、業務機能に必要な保護対象データだけを組織が保存するようにします。過剰なデータを排除したり、不要な履歴情報を削除したりすることで、リスクへのさらされ方を最小限に抑えられます。
次に、データを意図的に管理する必要があります。保護対象データの冗長性はシステム全体から排除し、可能な限り、記録システムの外部で保護対象データをシャドーコピーすることは避けなければなりません。システム外部に照合用のデータを保存する必要がある場合は、保存前に保護対象データの要素へハッシュ関数を適用できます。可能な限り、医療情報やクレジットカード番号などの保護対象データは、個人を特定できる情報（PII）から分離すべきです。
暗号化も追加の保護策として実施すべきです。多くのベンダーが提供するソリューションによって、保存データ、転送中のデータ、さらには使用中のデータも暗号化できます。データベース内では、DevOpsが暗号化やデータマスキングを使用して、テーブル内のデータを見えにくくできます。暗号化を解除せずにデータを処理・検索できる暗号化ツールもあり、データを常に暗号化して保護された状態に保てます。
Oracleなど一部のクラウドベンダーは、保存データを暗号化することをデフォルトにしたり、次のような暗号化キー管理ツールを提供したりします。Azure Key Vaultただし、データストレージおよびデータ転送のプロセス全体で十分な保護を確保する責任は、組織自身にあります。
7. 関連システムのセキュリティベストプラクティス
あるセキュリティプラクティスがデータベースに特化したものでなければ、データベースセキュリティだけの構成要素とは見なせません。しかし、だからといって、こうしたプラクティスの重要性や、データベースセキュリティを確保するために導入すべきであることが薄れるわけではありません。
1. 物理セキュリティのベストプラクティス
見落とされがちですが、物理セキュリティを軽視してはなりません。攻撃者がデータセンターへ物理的にアクセスできれば、最善のサイバーセキュリティ対策やテクノロジーさえも無力化される可能性があります。サーバーやネットワーク機器が置かれた物理環境の保護は、基本的なITセキュリティにおける最初のベストプラクティスであるべきです。
オンサイトのデータセンターでは、カメラ、施錠設備、常駐の警備員などの物理セキュリティ対策が必要です。また、サーバーへの物理的なアクセスは管理・記録し、定期的に見直す必要があります。通常とは異なるアクセスがあった場合は、アラートを生成すべきです。
クラウドでホストされる資産は、組織が直接物理的に管理できる範囲外にあるかもしれませんが、組織の責任の範囲外になるわけではありません。組織は引き続き、十分な物理セキュリティを確認する必要があります。通常は、次のようなコンプライアンスガイドラインに含まれる物理セキュリティ基準にクラウドベンダーが準拠することで要件を満たせます。
- ISO 27001
- ISO 20000-1
- NIST SPs（SP 800-14、SP 800-23、SP 800-53）
- 米国国防総省情報保証技術フレームワーク
- SSAE 18 SOC 1 Type II、SOC 2 Type II、SOC 3
2. Webアプリケーションファイアウォールとネットワークファイアウォールを使用する
ファイアウォールは、すべてのIT資産に基本的な保護を提供します。データベースにファイアウォールを導入するだけでなく、組織はネットワークを保護するために次世代ファイアウォール（NGFW）を、データベースにアクセスするWebサイトやアプリケーションを保護するためにWebアプリケーションファイアウォールを導入する必要があります。
こうした汎用的なファイアウォールは、データベースだけでなく、次のような他のシステムにも影響を及ぼす攻撃から、組織全体を保護します。SQLインジェクション攻撃や分散型サービス拒否（DDoS）攻撃などです。
3. ユーザー認証
データベースがアクセスのためにユーザーを認可する際、ユーザーはすでに認証され、本人確認を済ませているという前提があります。セキュリティのベストプラクティスでは、ゲスト、従業員、顧客、管理者など、あらゆる種類のユーザーについて認証またはID検証を行う必要があります。ユーザー認証セキュリティのサブカテゴリーには、内部脅威管理、ユーザー検証、特権アクセス管理（PAM）があります。
内部脅威管理
一部のデータは非常に価値が高いため、犯罪組織が従業員にデータを漏えいするよう金銭を支払ったり、データへのアクセスを得るため、虚偽の身分を装って組織内に構成員を送り込んだりすることがあります。こうした内部脅威の問題を最小限に抑えるため、組織はプログラマー、請負業者、セキュリティ専門家、データベース管理者、その他機密情報にアクセスまたは転送できる可能性のあるすべての人について、身元調査を実施すべきです。
こちらもご覧ください：データ損失防止（DLP）の主要ソリューション
従業員の身元を確認したら、組織は次にユーザーとエンティティの行動分析（UEBA）ツール、他のセキュリティツールに搭載されたUEBA機能、監査ログを導入して、不適切または異常な行動の兆候を探します。ハッカーが盗んだ認証情報を使用しても、異常な行動が検出されるまでは、ほとんどのセキュリティツールには承認済みのアクセスとして表示されることに注意してください。最後に、従業員が別の役割に移ったり退職したりした場合に、アカウントや不要なアクセスを無効化するポリシーを策定します。
ユーザー検証
確認済みのIDの完全性を維持するため、ユーザーは定期的に、または（ゼロトラストの場合は）常に本人確認を行う必要があります。パスワードは依然として最も一般的な本人確認方法ですが、一部の組織ではパスワードレス認証を導入し始めています。
管理者アカウントやその他の特権アカウントでは、常に多要素認証（MFA）を使用すべきです。最も重要なデータについては、磁気カードやUSBトークンなど、リモートの攻撃者が盗んだり簡単に複製したりできない物理的なMFAの利用を検討すべきです。
パスワードを使用する組織では、強力なパスワードとパスワード管理を使用すべきです。
- パスワードの複雑性（大文字・小文字、数字、特殊文字の組み合わせ）またはパスワードフレーズ（大幅に長いパスワード）を必須とする
- パスワードは少なくとも8文字とし、特権アカウントではさらに長くする
- パスワードハッシュは暗号化し、ソルトを付加して保存する
- ログインの失敗が繰り返された後にアカウントをロックする。通常のユーザーアカウントでは最大6回、特権アカウントや管理者アカウントでは最少3回とする
- パスワードを期限切れにする
組織がパスワードマネージャーを導入すれば、ユーザーが安全でない、または脆弱な場所にパスワードを保存する心配なく、より複雑なパスワードや、より頻繁なパスワードの有効期限を要求できます。古くなったユーザーやデバイス、忘れられたユーザーやデバイスからのアクセスを防ぐため、ユーザーアクセスも定期的に更新すべきです。
特権アカウント管理
管理者アクセスの悪用は甚大な被害をもたらす可能性があるため、管理者の認証情報は追加の対策で保護する必要があります。パスワード要件を強化するだけでなく、組織は特権アクセス管理（PAM）ツールの利用も検討すべきです。これらのツールは権限を制限した一時パスワードを生成するため、承認されたユーザーはデータベースにアクセスするたびに認証しなければなりません。
専用ツールを使用するかどうかにかかわらず、特権アクセスには追加のルールを適用すべきです。
- パスワードを共有しない
- すべてのセッションとアクティビティを記録し、定期的に確認する
- すべてのユーザー権限の昇格を記録し、定期的に確認する
4. デバイスセキュリティ
データベースにアクセスするすべてのデバイスと、ネットワーク全般について、侵害の可能性がないか検証し、継続的に監視する必要があります。ウイルス対策による保護は最低限の保護レベルですが、より強固な保護を実現するため、組織はエンドポイントの検出と対応（EDR）ツールや拡張検出と対応（XDR）ツールを導入することがよくあります。これらは、よりプロアクティブな検出を実現します。
管理者のデバイスについては、IPアドレスやMACアドレスの制限、ホワイトリスト登録、またはネットワークアクセス制御（NAC）を使用して、さらに制限すべきです。これらの対策によって、機密領域へのアクセスを許可するデバイス数を制限し、盗まれた認証情報がハッカーにとって有用になりにくくします。
データベース（またはその他の機密システム）に関連するインフラストラクチャについて、組織はすべてのデバイス、アプリケーション、ツールを文書化すべきです。さらに、設定ファイルとソースコードは厳格に保護し、保護された管理者アカウントだけがアクセスできるようにするとともに、変更管理ポリシーとツールで保護する必要があります。
最後に、すべてのシステムを監視すべきです。ネットワークは、XDRまたは侵入検知・防御システム（IDPS）ツールで監視します。すべてのセキュリティシステムは、アラートをセキュリティ情報・イベント監視（SIEM）ツール、セキュリティオペレーションセンター（SOC）、またはマネージド検知・対応（MDR）チームに送信すべきです。
5. アプリケーションとAPIのセキュリティ
データベースやその他のITリソースに接続するアプリケーションとAPIは、安全に保護する必要があります。DevOpsではまず、社内開発のWebサイトとアプリケーションに脆弱性スキャンツールを適用します。大規模な組織では、システムをさらに保護・監視するためにアプリケーションセキュリティツールとAPIセキュリティツールを導入します。
こちらもお読みください：アプリケーションセキュリティ：完全な定義、種類、ソリューション
6. オペレーティングシステムとパッチを定期的に更新する
最適なセキュリティツールや戦略も、保守が不十分であれば効果を損ないます。すべてのシステム、アプリケーション、ツール、ファームウェアについて、新たにリリースされたパッチや公表された脆弱性がないか監視すべきです。データベースシステムに接続するシステムなど、重要なシステムについては、定期的なパッチ管理と脆弱性管理を優先すべきです。オープンソースライブラリなど、ソフトウェアサプライチェーンのコンポーネントについても追跡し、脆弱性や更新に対応する必要があります。
7. 事業継続性のベストプラクティス
どれほど優れた計画でも、問題に直面することがあります。問題の原因が不満を抱えた従業員、悪意あるハッカー、停電、洪水のいずれであっても、事業継続性と災害復旧のベストプラクティスによって、システムのレジリエンスと迅速な復旧を実現できます。
冗長アーキテクチャの設計により、システム障害が発生した場合も稼働時間を維持できます。フェイルオーバー復旧用のアクティブ・パッシブ冗長化や、想定される負荷を複数のサーバーに分散するロードバランシングサーバーを使用することで、サーバーのレジリエンスを高めることができます。
データとシステムのバックアップは、システムの完全な障害や悪意ある活動から保護します。バックアップは定期的に実行し、厳重に保護すべきです。ベストプラクティスでは、バックアップデータを3つのコピーで保持し、2種類のストレージを使用し、少なくとも1つのコピーをオフサイトかつオフラインで保管する、3-2-1バックアップルールに従います。バックアップには、いかなる場合もパブリックアクセスを許可せず、暗号化キーとは分離して暗号化・保管する必要があります。
バックアップにはデータだけでなく、影響を受けたシステムを迅速に復旧できるよう、基盤となるインフラストラクチャの設定、ソフトウェアアプリケーション、構成も含める必要があります。ミッションクリティカルなインフラストラクチャのバックアップは、バックアッププロセスの有効性を検証するとともに、復旧に要する時間の目安を設定するため、定期的にテストすべきです。
こちらもお読みください：ランサムウェアに強いアーキテクチャの構築
まとめ：データベースセキュリティのベストプラクティス
データ侵害は、さまざまな罰金、事業への悪影響、訴訟につながる可能性があります。残念ながら、十分な準備をしている企業でも事故やセキュリティインシデントは起こり得るもので、そのコストは組織が受け入れることを選択したリスクに直接関係します。攻撃と経済的な影響が増大する中でも、優れたデータベースセキュリティの実践は、データ侵害の高まるリスクを相殺します。組織は、侵害のリスクを下げ、将来のインシデントで予想されるコストを削減するため、可能な限り多くのベストプラクティスを確認、採用、維持すべきです。
次に読む：データレイクに関するセキュリティ上の考慮事項。
この記事はもともとPaul Rubensが執筆し、Chad Kimeが2023年4月21日に更新したものです。