データベースへの侵入を検出するための最良の戦略は何ですか？
ファイルシステムへの侵入は、Snortなどのツールを使用して検出できますが、行の削除、テーブルの変更など、データベースへの侵入を検出することはより困難です。これを監視してDBの不要な変更を検出するための最良の方法は何ですか？
私はMySQLを使用しているので、データベースに依存しないものはすべてMySQLを対象にするのが理想的です。
データベースへの接続方法によって異なります。 Webアプリケーションを使用している場合、Snort（およびその他のNIDS）は、HTTPを介して発生するSQLインジェクションやその他の攻撃を検出できます。
問題は、データベースへのSSLまたは暗号化された接続を使用している場合、NIDSはトラフィックを認識しないことです。
そのため、ログ分析は非常に重要です。あなたのデータベースがあなたに話しかける唯一の方法はログを通してであり、多くのDBAはそれに精通していません。なぜ誰もがWebロギングをなじみのあるものとして受け入れるのか、私は本当に理解していませんが、dbロギングを無視しています（これについてはまた別の機会に説明します）。
Mysqlログを有効にするには： http://www.ossec.net/wiki/index.php/SQL_Logging#MySQL_Logging
また、オープンソースのOSSECを使用してMySQLログを監視していますが、うまく機能しています。
このために設計された商用製品があります。 DbProtect（www.appsecinc.com）を見て、実装するのに多額の費用がかかったと思いますが、結局それをしませんでした。 Guardium（www.guardium.com）も見ました。どちらもMySQLの一部のバージョンをサポートしていると主張しています。
私はMySQLを使用していないので、プラットフォームの特定の機能について話すことができません。
ある種の監査証跡が必要なようです。一般的なRDBMSの意味で言えば、トリガーを使用して、探している機能の一部を取得できる場合があります。 MySQLがスキーマをテーブルとして表し、そのテーブルにトリガーを配置できない限り、スキーマ変更の監査証跡を取得することはないと思います。
もちろん、誰かがデータベースへの「ルート」レベルのアクセスを取得し、データを操作し始める前にトリガーのフックを解除した場合、そのトリガーのナンセンスはすべて意味がありません。その時点で、すべての賭けはオフになっています。 （...そしてそれは、データベースをホストしているOSへの「ルート」レベルのアクセスを取得する誰かに対処し始めません...データベースファイルのバイトレベルの操作、セキュリティを備えたデータベースインスタンスにそれらをマウントしますそれから「ハッキング」された機能など...smile）
テーブルへのすべての変更を本当に追跡したい場合は、MySQLクエリログを有効にし、Simple EventCorrelatorなどを使用して悪いものをスキャンするなどのクレイジーなことを行う必要があります。ただし、これを行わないでください。サーバーのパフォーマンスが低下します。
正直なところ、最善の策は、MySQLのアクセス許可を使用して、最初から不要な変更を防ぐことです。
Snortはまだ役に立ちます。キャッチは、データベーストラフィックがどこから来るかを知っていることです。承認されたもの以外のソースからのものである場合は、明らかに、MySQL内でブロックできます。ただし、IDSにアラートを設定して、この種のことを確認することもできます。
許可されたIPアドレスからの攻撃に関しては、それは少し難しいことです。重要な質問は、接続に何を許可する必要があり、何を許可しないかということです。そして、それは適切な権限の設定に戻ります。正当なユーザーが正当なIPから接続し、DELETE権限を必要とし、悪意のあるユーザーになりたい場合、実際の変更中にそれについてできることはそれほど多くありません。監査の提案がありましたが、それはあなたのパフォーマンスを傷つけます。ユーザーがデータベースに直接アクセスして変更を加えることができるかどうかを効果的に制御できるかどうかはわかりません。 MySQLだけでなく、すべてのデータベースプラットフォームがこれに苦労しています。信頼できるユーザーが許可された変更を行っています。できることはたくさんあります。
MySQLでこれを行うための適切な方法はないと思います。ある種の秘密鍵を使用して、ある種のセキュリティチェックサムがすべての正当な変更に適用されていることを確認する必要があります。そのため、行データがチェックサムと異なる場合は、不正な変更が行われたことがわかります。
チェックサムの方法とキーの秘密の保持方法については、これはまったく別の話です。このサイトから、またはこのサイトを介してそれを理解した場合は、遠慮なく私にメールしてください（私はここで新しく、設定されていません）まだ適切に）。
現実的には、オフサイトのバックアップのみが行の削除を防ぐのに役立ちます。また、mysqldumpを使用することが「公式に」サポートされている唯一の方法であることに注意してください。
基になる（MyISAM）ファイルのコピーは、そのテーブルタイプのほとんどの場合に機能しますが、場合によっては失敗するため、ミッションクリティカルなものについてはそれだけでは信頼できません。
SQL Server 2005ではDDLトリガーが導入されました。これらは、テーブルの変更、インデックスの追加、ビューの削除など、誰かがデータ定義言語コードを実行するたびに起動できます。
SQLServerデータベースにDbProtectを実装しました。それほど難しくはなく、監査のためのかなりきめ細かいポリシーが可能でした。しかし、ボブウッドが述べたように、それは安くはありません。