データベースの改ざんを検出することは可能ですか？
長年のリスナー、初めての発信者。
'ユーザーアクティビティのログ記録を担当するデータベーステーブルがあるとします。このログの整合性は重要であるため、誰かがテーブルのデータを変更したかどうかを検出できるようにする必要があります。さらに面白くするために、この惨めなシステムを完全に制御している邪悪なSQL管理者によってシステムが操作されている可能性があるという事実も考慮してください。うわぁ...
データをどのように保護しますか？
誰かがあなたのデータを改ざんしたかどうかをどのように検出しますか？
無制限のツールを自由に使用できます。 （つまり、ハッシュ、暗号化など）
改ざんが発生したことを本当に検出する必要がある場合は、チェックサムフィールドをテーブルに追加します。新しい各行のチェックサムには、前の行のチェックサムが含まれている必要があります。次に、コンテンツを確認するために、データセットをウォークスルーしてチェックサムを計算します。計算されたチェックサムがテーブルの値と一致しない場合、一部の値が改ざんされています。
-マイク
「悪意のある管理者」がデータベースにデータを入力するアプリケーションにアクセスできない場合、残りの列の 暗号署名 で構成される各テーブルの追加の列がその役割を果たします。 「アクセスなし」の条件は、秘密鍵を抽出して偽のデータに署名するだけでは不十分であるために必要です。
編集：ああ、コメント投稿者が指摘しているように、私は管理者が行を削除するだけだとは考えていませんでした。このためには、毎回更新する暗号署名された行数（または、残りのテーブルコンテンツの署名されたハッシュ、最終アクセス時間、または選択したインジケーター）を含む1つの追加行が必要になります。
あなたとアプリケーションだけが知っているキー/ソルトですべてのファイルをハッシュするシャドウテーブルを作成します。データの改ざんをチェックする場合は、ユーザーテーブルを再ハッシュして、シャドウテーブルと比較します。
本当に安全にしたい場合使用-一度書き込みますそのテーブルの多くのメディアを読み取ります。
トランザクションIDを使用して紙のログを実行し、キーが1つしかない部屋にプリンターを保管するだけです。金融システムを使用すると、それらの多くが依然として紙のバックアップに依存していることがわかります。紙のログを追跡不可能に「ハッキング」することはほとんど不可能です...それが人々が投票機で紙のログを押し続ける理由です。
多くの人が「別のデータベースを追加するだけ」と言っていますが、実際には 練習 この種のロギングは自分自身で、私はそれを信用していません。悪意のある内部関係者は、そのセーフガードを12の方法でノックアウトする可能性があります。
ここで行っているのは、何かが起こったことを明らかにする方法を見つけようとすることだけです。ログが失われます。それらを信頼することはできません。絶対確実なログシステムを備えたシステムに出くわした場合は、ガベージデータで埋めるか、完全に消去します。マジノ線の精神に陥らないでください。
しかし、あなたが準備すれば 足りる、非常に多くの障害が発生する必要があるため、サボタージュを内部ソースに絞り込むことができます。ログに記録する必要があります 周り データベース、大量のシステムログを保持する必要がある、IPトラフィックを監視する、サーバールームにカメラを置く、コンソールにキーロガーを残すなどが必要です。最高のものでさえどこかに滑り落ちます。マウストラップが横になっていると、偶然どこかでそれらを捕まえる可能性があります。
明確にしましょう：Evil Sysadminを想定している場合、追跡不可能な方法でシステム上のデータを変更できないようにする暗号化ソリューションはありません-情報を復号化できないようにするソリューションはありますが、それは何もありません彼らが適切と思う方法で新しい情報を書くのを防ぐことができます。
この状況では、次の条件が必要です。
システムが必然的にスタンドアロンであること。 Evil Sysadminがログホスト（たとえば、syslogサーバー）としてアクセスできない別のシステムを追加できる場合、突然、ログまたはハッシュを定期的に転送するという些細なケースになります。
システムにソフトウェア以外のライトワンスコンポーネントがないこと。他の人が提案しているように、最も単純なものはプリンターのようなものですが、CDまたはカスタムの1回限りのハードウェアを使用して問題を防ぐことができます。邪悪なシステム管理者がマシンに物理的にアクセスできる場合、これらはトリッキーになりますが、克服できないわけではありません。
統計的な可能性ではなく、確実性が必要であること。 ＃1と＃2が不可能な場合、残っている唯一の解決策は不明瞭化です。つまり、悪のシステム管理者がトラップについて知らない場合に改ざんをキャッチするように設計されたトリッキーなトラップの実装です。
効果的な＃3の秘訣は、戦術的な驚きです。目的は、攻撃者に、あらゆる対策についてすべて知っているという印象を伝えることですが、実際には、彼らが気付いていないことはもっとあります。一般に、これには少なくとも2つのレベルのカバーが必要です-Evil Sysadminはそれを探しているので、妥協することが予想される保護の層を少なくとも1つ持つ必要があり、見つからない場合は取得します疑わしいと彼らがするまで深く掘ります。
重要な点は、このカバーは、邪悪なシステム管理者を満足させるほど説得力があり、一度見つけたら、もう探す必要がないということです。次に、第2層は、代替手法を使用して改ざんを識別し、適切なアラートを生成します。このスレッドには、実装可能なトランザクションなどのさまざまな提案があります。ソリューションのレベルが低いほど、成功する可能性が高くなります（つまり、データベースのソースコードにパッチを適用すると、接続とクエリを実行する標準プロセスよりもはるかに見えにくくなり、カーネルにパッチを適用すると、ファームウェアが変更されて見えにくくなります。 ）。
これは完全な解決策ではないことを強調することが重要です。セットアップがどれほど複雑であっても、誰かが対策を実行するのに十分な情報を見つけて妥協した可能性があります。これは、＃1と＃2（適切に行われた）には当てはまりません。とはいえ、保護している情報の価値が十分に低く、必要なスキルを持つ人々がそれを取得するために働くことに興味がない場合、それは実行可能な防御を提供するはずです。
データのローリング、迅速、オフサイト、自動バックアップを作成することを検討してください。 S は最近非常に安価であるため、mysqldumpタイプのプロセスをcronして、データのリポジトリ全体を大西洋横断のバックアップストアに頻繁に転送する可能性があります。どのくらいの頻度で正確にあなたのDBAの悪に依存します。
このプロセスを可能にするには、ネットワーク内で、悪意のある管理者が何も知らないか、何かを疑った場合に調べたくないマシンを見つけるか、設置するだけです。 プラグコンピュータ のシンプルさとエレガンスはここで誇張することはできません。
実際のエクスポートメカニズムに関する注意：特定のシステムについて何も知らないので、最も単純で愚かな解決策としてmysqldumpまたはOracleexpを提案しました。アプリケーションにネイティブ形式（XML、JSON、さらにはプロトコルバッファなど）でデータをエクスポートする方法がある場合、つまり、たとえば、SOAアプリケーションは相互に通信するために使用します）の一部である場合、その形式をローリングダンプの形式として使用できます。
このアプローチをgitosisボックスに実装しました。 3時間ごとに、コンテンツはヨーロッパのS3バケットにダンプされます。それは別のVCSの貧乏人のVCSです。
挿入、更新、および削除を監査するトリガーを使用できます。ここで、「邪悪なSQL管理者」がトリガーを無効にすると、さらに難しい問題が発生します。データを保護したい場合は、悪意のある管理者がシステムを完全に制御することを許可しません。
これは一般的なデータセキュリティの問題です。簡単な答えは、1人の「邪悪なSQL管理者」が環境全体にアクセスできる状況にある場合、データを保護する方法がないということです。
ミッションクリティカルなデータの一般的な方法は、複数のバックアップにログを記録し、1人のユーザーに権限がないことを確認して保護することです。
アプリケーションが常に実行されている場合は、データベースでトランザクションを開始し、アプリが閉じるまでトランザクションを解放しないでください...そうすれば、アプリ以外にテーブルを表示することさえできません...
また、そうです。時間があれば、プログラムに出入りするすべてのテキスト文字列データを暗号化してください...
BobbyShaftoeの答えも好きです...もう少し進んでください。トリガーを「スリープ」させることができるかどうかを確認してください。数分後にすべてのレコードが元の状態に戻ります...だから私たちの邪悪な管理者は考えます彼は変更を加えましたが、それらは元に戻されます。
数時間ごとに、テーブルの内容のハッシュを作成します。また、開始行と終了行を記録します。 2番目以降のハッシュでは、テーブル全体の内容と、前のハッシュでハッシュされた行（チェックハッシュ）の両方のハッシュを作成します。前のハッシュとチェックハッシュが一致しない場合、データベーステーブルは改ざんされています。これらのハッシュをメールで送信するので、不正な管理者がすべてのハッシュを処理して再生成したかどうかを確認できます。ギャップがあることは承知していますが、これまたはすでに述べたものよりも、（アクセスを削除する以外に）実行できることはそれほど多くないと思います。
ここにはいくつかの非常に良い提案がありますが、それらはすべてほこりをかみます。
あなたには「信頼できない」アクター、邪悪な管理者がいるので、あなたは自分自身を守ることができないあなたのデータの管理者です。ネットワークプロトコルと現実の世界には、信頼できないトランスポート/宅配便によるデータの改ざんからデータを保護できるようにするためのさまざまなスキームがあります。しかし、私の知る限り、「こんにちは。私はニューヨーク証券取引所の会長を務めていたマドフさんです。あなたが私を信頼できます...」のように、信頼できないカストディアンからあなたを守ることができるものは何もありません。
まず、システムを管理するために誰を雇うかについて非常に注意してください。
トリガーによって設定された次の監査テーブル。彼が変更のトリガーを回避したとしても、少なくとも彼が変更する前のデータ（特にバックアップから）を見ることができます。
オフサイトで削除される3番目の自動バックアップ。このようにして、悪者がデータベースを削除してオンサイトバックアップを消去した場合でも、フォールバックポジションがあります。データベース管理者がオフサイトバックアップにアクセスできないことを確認してください。他の誰かだけが権限を持っており、誰かがデータベースサーバーに対する本番権限を持っていません。
次に、管理者以外の誰もがテーブルに直接アクセスすることはできません。これは、動的SQLを使用せずにストアドプロシージャを使用することを意味します。これにより、少なくとも他の人が不正な方法でデータを変更するのを防ぐことができます。今、あなたの経理担当者が詐欺を犯すのはより困難です。
管理者とバックアップとしての1人を除いて、本番管理者の権限はありません。このようにして、トリガーが変更されたことがわかった場合、誰がそれを行ったかがわかります。今、何かがうまくいかない、あなたには2人の容疑者しかいない。
SQL Server 2008には、構造を変更したユーザーを通知するDDLトリガーがあります。繰り返しますが、トリガーが変更を記録しなかった場合、デフォルトで管理者によって作成されました。
バックアップと特定の個人データを暗号化して、盗みにくくします。これで、オフサイトのバックアップ配信担当者は、データを盗むのに苦労することになります。
信頼できないデータでなくても、信頼できないことが証明された管理者を解雇します。彼がタイムシートを偽造したり、事務用品を盗んだりする場合、彼はデータを盗みます。彼が（交通違反ではなく）重大な犯罪で逮捕された場合、告発が証明されているかどうかを確認する必要がある場合は、彼を停職処分にすることができます。
管理者が別の仕事に移ることを決定したときは、彼が行くと言った瞬間からあなたのシステムにアクセスできないようにしてください。あなたが彼を解雇しているなら、これは特に重要です。
このトピックに関する2つの興味深い研究論文があります。そのうちの1つは、HMACalogrithの使用法を提案しています。もう1つは、Condensed-RSAスキームとBGLS署名スキームの使用を提案しています。
アウトソーシングされたデータベースの認証と整合性
http://www.isoc.org/isoc/conferences/ndss/04/proceedings/Papers/Mykletun.pdf
リレーショナルデータベースのための一般的な歪みのない透かし技術
http://www.dsi.unive.it/~cortesi/paperi/iciss09.pdf
どちらも、認識されているリスクの量に基づいた有効な解決策だと思います。 --Kiran.Kumar
私はMikeMontanaのソリューションが好きですが、それに補遺を追加する価値があるかもしれないと思いました。残念ながら、まだコメントを残すことができないので、新しい回答で投稿しました。オリジナルは以下に引用されています。
改ざんが発生したことを本当に検出する必要がある場合は、チェックサムフィールドをテーブルに追加します。新しい各行のチェックサムには、前の行のチェックサムが含まれている必要があります。次に、コンテンツを確認するために、データセットをウォークスルーしてチェックサムを計算します。計算されたチェックサムがテーブルの値と一致しない場合、一部の値が改ざんされています。
-マイク
何人かの人々が指摘しました：システム管理者はチェックサムを再計算することができました（彼のサーバー上に存在するようにコーディングしたい場合はさらに問題です）、それに次の拡張機能を追加します：
データがテーブルに挿入されると、公開鍵で暗号化されるため、誰でもデータベースに追加できます（複数のユーザーがデータを使用している場合）。定期的に秘密鍵を使用してデータを復号化し、チェックサムを計算します。異なる場合は、データベースが変更されていることを意味します（テストしたいもの）。次に、チェックサムを再計算してテーブルに挿入します（もちろん、公開鍵も暗号化されています）。
邪悪なシステム管理者が新しいチェックサムを再計算しようとすると、暗号化されたデータに対して実行します。
さらに、このデータにリモートでアクセスしている場合、このアプローチは、ローカルボックスで復号化とチェックサムの計算を行うことにより、中間者攻撃の影響を受けません。傍受されたデータは暗号化されたままになるため、使用できなくなります。
このシステムの唯一の欠陥は、データベースへのトランザクションが検出されることです。これは抽象化によって解決し、次のように言うことができます。
- チェックサムを確認する
- データを挿入
- チェックサムを再計算する
ただし、これにより、秘密鍵を渡さずにデータにアクセスしたい人がいるという利点がなくなります。
これで、この問題を別の方法で解決することが可能になりました。そのために、次のことをお勧めします。
グリッドコンピューティングにおける信頼の非対称性の問題への対処
ピーター・ディンダ
http://portal.acm.org/citation.cfm?id=1066656
ただし、実装の詳細は長くなります。
自動化されたアプローチが必要な場合は、最初に、ユーザータイプに許可されるアクションとコンテキストを知る必要があります。適切な状況ではドロップは許容されますが、日常のユーザーには受け入れられないため、これは非常に困難です。
私は紙のバックアップのアイデアが好きですが、生成される情報の量は、ユーザーベースが大きく、DBの使用量が多いと、非常に急速に静かになります。
権力分立/二重権力分立。
私はこれまでに提示されたアイデアが好きです。私は自分の2セントを追加したかった。
金融業界では、権力分立は、一人の人間が完全に悪になるのを防ぐための鍵でした。私たちのコア処理ソリューションは、簿記部門によって管理されているため（彼らの心を祝福します）、プログラマーは実際に私たちのライブデータにあまりアクセスできません。
さらに、サードパーティがシステムの主要部分とのやり取りをログに記録します。
全体として、すべてのチェックとバランスに影響を与えるのに十分なコントロールを持っている人は誰もいないため、（うまくいけば）調整する価値がないほどペイオフが減少します。
私はこれを見つけました 記事 、それは面白そうです、私はまだエクスプロイトを試して考えるのに時間をかけていませんが、可能な解決策である可能性があります。
頭のてっぺんから、2つの別々のデータベースがあることを想像できましたが、「邪悪な」システム管理者は1つにしかアクセスできませんでした。
一方のデータベースは、もう一方のデータベースにワンタイムパッドを提供し、誰がいつパッドを要求したかをログに記録します。このパッドは、現在の時刻と行のデータとともにハッシュできます。
このように、邪悪なシステム管理者が何かを変更した場合、ハッシュはチェックアウトしません。また、彼が再ハッシュを試みた場合、すべき時間が発生しました。
システム管理者が時間とワンタイムパッドを保存できる場合、このシステム全体が崩壊します。
これは一見難しい問題です。どのプロトコルでも実際に機能するかどうかはわかりませんが、物理的なセキュリティと監査ログを追加することをお勧めします。
これは素晴らしい質問だと思います！しかし、あなたのシナリオはデータベースの設計原則に反しています。
行のチェックサム、他のデータベースへのエクスポートのトリガー-何をしても妥協点になります！
私は箱の外で何かを提案することしかできません [〜＃〜] pci [〜＃〜] コンプライアンスなどのある種の標準を適用する場合に役立ちますか？
それが失敗した場合は、別の仕事を探すことをお勧めします！私たちの業界には、このようなタイプの人々と一緒に仕事をする必要がない十分な仕事があります...
悪意のあるSQL管理者が制御できないリモートシステムにログデータを書き込むようにシステムを設定します。これにより、管理者がログプログラムを削除したり改ざんしたりすることを防ぐことはできませんが、事後に管理者がそれらを変更することはできません。
監査、チェックサムなどのトリガーだけでなく、データベースを別のスレーブデータベースに複製することも検討できます。データベースに対して直接アクションを実行することはできません。
誰かがトリガーなどをいじるリスクはまだありますが、それらがいじられたときに非常に目立つので、レプリケーションがどの時点で壊れたかを検出できます。
このようなソリューションを正確に実装する方法を調査しているときに、このスレッドを見つけました。私が考えた（非常に理論的な）解決策の1つは、完全転送秘密鍵システムを使用するようなものです。
秘密鍵と公開鍵のペア（KprとKpbと呼びます）と次のようなアルゴリズムのセット（AとB）がある場合、私が考えたのは次のとおりです。
（K'prとK'pbは、KprとKpbとは異なる有効な秘密公開鍵ペアです）
これを使用すると、データベースのすべての行に署名し、使用後にすべての秘密鍵を破棄し、公開鍵を署名とともに保存することができます。次に、最初の公開鍵を、邪悪な管理者が実行可能な方法で変更できない場所に保存できます（つまり、知っているすべての人に送信し、新聞に印刷し、顔に入れ墨をします）。
秘密鍵がなくなったため、すべてのレコードに再署名する方法はありません。また、公開鍵がすべて順次であるかどうかを確認できます。私が考えることができる欠陥は2つだけです。
- 邪悪な管理者が秘密鍵のコピーを入手した場合、彼はその瞬間から任意のレコードを変更できるようになります。これは、ハードウェアモジュールを使用して署名を作成することで回避できるため、ソフトウェアから秘密鍵にアクセスできません。
- 邪悪な管理者はあなたのテーブルにデータを追加することができます。
問題は、私が説明したような一連のアルゴリズムを認識していないことです。しかし、私は暗号学者ではないので、それは可能かもしれません。
編集：
もう少し考えた後、私は既存のツールでこれを可能にする方法を考え出したかもしれません。 （n-1）番目のレコードのn番目のレコードの公開鍵とその署名を含める場合（レコードを書き込む時点で、可能性がありますにアクセスできるためです。次の秘密鍵）、前のレコードですべてのレコードを保護します。秘密鍵を削除した後は、署名を再作成できません。最初の公開鍵を持っている限り、テーブル全体をいつでも検証できます。これにより、「順次」秘密鍵を使用する必要もなくなります。すべての行に対して新しい秘密鍵を生成するだけで済みます（ただし、これは非常にコストがかかります）。同じ欠陥がまだ当てはまります。
邪悪な管理者がサーバーを完全に制御できるため、特権SQLServerユーザーのアクティビティを監視するように設計された外部監査ソリューションが必要になる可能性があります。
Guardium データベースまたはサーバー上のすべてのクエリアクティビティをログに記録できるネットワークアプライアンスを作成します。これはネットワークレベル（ローカル接続を含む）で実行されるため、SQLでは何も実行できません。それを妨害するサーバーレベル。
これは、悪意のある管理者がテーブルを変更することを妨げるものではありませんが、ロックダウンされたアプライアンスであるため、悪意のある管理者はテーブルを変更できず、アプライアンスに変更しなかったと説得できません。
悪意のある管理者もアクセスできない非本番データベースに入力されたデータのコピーを送信するトリガーを追加できます。管理者はトリガーの機能を停止できますが、問題は操作を阻止するのではなく、どのように検出するかでした。
この質問に対する2016年の回答は、 blockchain データベースを使用することです。ウィキペディアによると：
ブロックチェーンは主に、最近の有効なトランザクションのバッチのハッシュを「ブロック」にタイムスタンプすることで改ざんされにくく、データがその時点で存在していた必要があることを証明します。各ブロックには前のタイムスタンプが含まれ、ブロックのチェーンを形成します。追加のタイムスタンプごとに、前のタイムスタンプが補強されます。