長年のリスナー、初めての発信者。
'ユーザーアクティビティのログ記録を担当するデータベーステーブルがあるとします。このログの整合性は重要であるため、誰かがテーブルのデータを変更したかどうかを検出できるようにする必要があります。さらに面白くするために、この惨めなシステムを完全に制御している邪悪なSQL管理者によってシステムが操作されている可能性があるという事実も考慮してください。うわぁ...
データをどのように保護しますか？
誰かがあなたのデータを改ざんしたかどうかをどのように検出しますか？
無制限のツールを自由に使用できます。（つまり、ハッシュ、暗号化など）
改ざんが発生したことを本当に検出する必要がある場合は、テーブルにチェックサム フィールドを追加します。新しい各行のチェックサムには、前の行のチェックサムが含まれている必要があります。次に、内容を確認するために、先に進むときにチェックサムを計算するデータセットを調べます。計算されたチェックサムが表の値と一致しない場合、値が改ざんされています。
-マイク
「悪意のある管理者」がデータベースに入力するアプリケーションにアクセスできない場合、残りの列の暗号化署名で構成される各テーブルの余分な列が機能します。秘密鍵を抽出して偽のデータに署名できないように、「アクセスなし」の状態が必要です。
編集: ああ、コメンターが指摘しているように、管理者が行を削除するだけだとは考えていませんでした。このためには、毎回更新する暗号署名された行数 (または、残りのテーブル コンテンツの署名付きハッシュ、最終アクセス時間、または選択した任意のインジケーター) を含む追加の行が 1 つ必要になります。
あなたとアプリケーションだけが知っているキー/ソルトですべてのフィールドをハッシュするシャドーテーブルを作成します。データの改ざんをチェックする場合は、ユーザー テーブルを再ハッシュし、シャドー テーブルと比較します。
本当に安全にしたい場合は、そのテーブルの Write once Read Many Media を使用します。
トランザクション ID を使用して紙のログを実行し、キーが 1 つしかない部屋にプリンターを保管するだけです。金融システムを扱うと、それらの多くがまだ紙のバックアップに依存していることがわかります。紙のログを追跡できないように「ハッキング」することはほとんど不可能です...それが、人々が投票機で紙のログを求め続ける理由です.
多くの人が「別のデータベースを追加するだけ」と言っています。私は実際にこの種のログ記録を自分で練習していますが、信頼していません。悪意のあるインサイダーは、さまざまな方法でその保護手段を打ち破る可能性があります。
ここで行っていることは、何かが起こったことを明らかにする方法を見つけようとしているだけです。ログを失うことになります。それらを信頼することはできません。万全のロギング システムを備えたシステムに出くわしたら、ガベージ データで埋めるか、完全に消去します。マジノ線の考え方に陥らないでください。
しかし、あまりにも多くの障害が発生しなければならないほど十分に準備すれば、妨害行為を内部ソースに絞り込むことができます。データベースの周りをログに記録する必要がある、大規模なシステム ログを保持する必要がある、IP トラフィックを監視する必要がある、サーバー ルームにカメラを設置する、コンソールにキーロガーを残すなどの必要があります。ネズミ捕りが十分にあると、どこかで偶然捕まえることができます。
はっきりさせておきます: 悪意のあるシステム管理者を想定している場合、システム上のデータを追跡不可能な方法で変更できないようにする暗号化ソリューションはありません。情報を復号化できないようにするソリューションはありますが、彼らが適切だと思う方法で新しい情報を書くのを防ぐことができます。
この状況には、次の条件が必要です。
システムが必然的にスタンドアロンであること。悪意のあるシステム管理者がログ ホスト (たとえば、syslog サーバー) としてアクセスできない別のシステムを追加できる場合、問題は突然、ログまたはハッシュを定期的に転送するという些細なケースになります。
システムに非ソフトウェアのライトワンス コンポーネントがないこと。他の人が示唆しているように、最も単純なものはプリンターのようなものですが、CDまたはカスタムの追記型ハードウェアを使用して問題を防ぐことができます. 悪意のあるシステム管理者がマシンに物理的にアクセスできる場合、これらはより厄介になりますが、克服できないわけではありません。
統計的可能性ではなく、確実性が必要であること。#1 と #2 が不可能な場合、残された唯一の解決策は隠蔽です。つまり、悪意のあるシステム管理者がトラップについて知らない場合に、改ざんをキャッチするように設計されたトリッキーなトラップを実装することです。
効果的な #3 の秘訣は戦術的な奇襲です。目的は、攻撃者に、攻撃者が対策についてすべて知っているという印象を与えることです。一般に、これには最低でも 2 つのレベルのカバーが必要です。悪意のあるシステム管理者がそれを探しているため侵害される可能性があるため、少なくとも 1 つの保護レイヤーが必要です。疑わしく、彼らがそうするまで深く掘り下げます。
重要な点は、このカバーは、悪意のあるシステム管理者を満足させるほど説得力があり、見つけたらもう見る必要がないということです。次に、第 2 層が別の手法を使用して改ざんを識別し、適切なアラートを生成します。このスレッドには、実装できるトランザクションなどに関するさまざまな提案があります。ソリューションのレベルが低いほど、成功する可能性が高くなります (つまり、データベースのソース コードにパッチを適用することは、接続とクエリを実行する標準プロセスよりもはるかに目立たなくなり、カーネルにパッチを適用することは再び目立たなくなり、ファームウェアを変更します.. ）。
これが完全な解決策ではないことを強調することが重要です。セットアップがどれほど複雑であっても、誰かが対策を実施するのに十分な情報を見つけ出したり、侵害したりする可能性があります。#1 と #2 の場合はそうではありません (適切に行われています)。とはいえ、保護している情報の価値が十分に低く、必要なスキルを持つ人々がそれを取得することに興味を示さない場合、それは実行可能な防御を提供するはずです。
挿入、更新、および削除を監査するトリガーを使用できます。ここで、「悪意のある SQL 管理者」がトリガーを無効にすると、さらに難しい問題が発生します。自分のデータを保護したいのであれば、悪意のある管理者がシステムを完全に制御することは許しません。
ローリング、高速、オフサイト、自動化されたデータのバックアップを作成することを検討してください。最近のS3は非常に安価であるためmysqldump、データのリポジトリ全体を Transatlantic バックアップ ストアに頻繁に転送するために、タイプのプロセスを cron で作成することがあります。正確な頻度は、DBA の悪意によって異なります。
このプロセスを可能にするには、悪意のある管理者が何も知らないか、何か疑わしいと思っても気にしないマシンをネットワーク内で見つけるか、設置するだけです。プラグ コンピューターのシンプルさと優雅さは、ここでは誇張することはできません。
実際のエクスポート メカニズムに関する注意: 特定のシステムについて何も知らないので、最も単純で馬鹿げた解決策としてmysqldumpOracleを提案しました。アプリケーションがデータをネイティブ形式 (XML、JSON、さらにはプロトコル バッファなど - つまり、SOA アプリケーションの一部が相互に通信するために使用する任意の形式)expでエクスポートする方法を備えている場合、format は、ローリング ダンプの形式として使用できます。
私は自分のgitosisボックスにこのアプローチを実装しました。3 時間ごとにコンテンツがヨーロッパの S3 バケットにダンプされます。別のVCSの貧乏人のVCSです。
このトピックに関する興味深い研究論文が 2 つあります。そのうちの 1 つは、HMAC アルゴリズムの使用を提案しています。もう 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
どちらも、認識されたリスクの量に基づいた有効なソリューションだと思います。--キラン・クマール
電源/デュアル電源コントロールの分離。
私はこれまでに提示されたアイデアが好きです。私は自分の2セントを追加したかった.
金融業界では、権力の分離が、一人の人間が完全に悪者になるのを防ぐ鍵となってきました。私たちのコア処理ソリューションは、簿記部門によって管理されているため (彼らの心に祝福を)、私たちプログラマーはライブ データにあまりアクセスできません。
さらに、第三者がシステムの主要部分とのやり取りを記録します。
全体として、すべての抑制と均衡に影響を与えるのに十分なコントロールを持っている人は 1 人もいません。
これは素晴らしい質問だと思います！しかし、あなたのシナリオはデータベースの設計原則に反しています。
行のチェックサム、他のデータベースへのエクスポートのトリガー - 何をしても妥協になります!
既成概念にとらわれない提案しかできませんが、 PCIコンプライアンスなどの何らかの標準を適用すると役に立ちますか?
それでもだめなら、次の仕事を探すことをお勧めします！私たちの業界には、このようなタイプの人々と一緒に働く必要のない仕事がたくさんあります...
私は MikeMontana のソリューションが気に入っていますが、補遺を追加する価値があると思いました。残念ながら、まだコメントを残すことができないので、新しい回答に投稿しました。元の回答は以下に引用されています。
改ざんが発生したことを本当に検出する必要がある場合は、テーブルにチェックサム フィールドを追加します。新しい各行のチェックサムには、前の行のチェックサムが含まれている必要があります。次に、内容を確認するために、先に進むときにチェックサムを計算するデータセットを調べます。計算されたチェックサムが表の値と一致しない場合、値が改ざんされています。
-マイク
何人かの人々が指摘しました: システム管理者はチェックサムを再計算することができます (システム管理者のサーバーでコードを実行する場合はさらに問題になります)。これに次の機能強化を追加します。
データがテーブルに挿入されると、公開鍵で暗号化されるため、誰でもデータベースに追加できます (複数の人が使用していると仮定します)。定期的に秘密鍵を使用してデータを復号化し、チェックサムを計算します。異なる場合は、データベースが変更されたことを意味します (テストしたいもの)。次に、チェックサムを再計算してテーブルに挿入します (もちろん、公開鍵も暗号化されます)。
悪意のあるシステム管理者が新しいチェックサムを再計算しようとすると、暗号化されたデータに対して実行されます。
さらに、このデータにリモートでアクセスしている場合、このアプローチは、ローカル ボックスで復号化とチェックサムの計算を行うことにより、中間者攻撃の影響を受けません。傍受されたデータは暗号化されたままになるため、使用できなくなります。
このシステムの唯一の欠点は、データベースへのトランザクションが検出されることです。抽象化によってこれを解決し、次のように言うことができます。
ただし、これにより、秘密鍵を提供せずにデータにアクセスしたい人が誰でもアクセスできるという利点がなくなります。
この問題を別の方法で解決できるようになりました。
グリッド コンピューティングにおける信頼の非対称性の問題への対処
ピーター・ディンダ
http://portal.acm.org/citation.cfm?id=1066656
ただし、実装の詳細は長くなります。
悪意のある SQL 管理者が制御できないリモート システムにログ データを書き込むようにシステムを設定します。これは、管理者がロギング プログラムを削除したり改ざんしたりするのを防ぐものではありませんが、事後に変更することはできません。
これは、一般的なデータ セキュリティの問題です。簡単な答えは、1 人の「悪意のある SQL 管理者」が環境全体にアクセスできる状況にある場合、データを保護する方法がないということです。
ミッション クリティカルなデータの一般的な方法は、複数のバックアップにログを記録し、1 人の人物がアクセス許可を持たないようにすることで保護することです。
ここには非常に優れた提案がいくつかありますが、それらはすべてほこりをかむでしょう.
「信頼できない」アクター、つまり悪意のある管理者がデータの管理者であるため、自分自身を保護することはできません。信頼できないトランスポート/クーリエによる改ざんからデータを保護するために、ネットワーク プロトコルと現実世界にはさまざまなスキームがあります。しかし、私の知る限り、「こんにちは。私はマドフ氏です。ニューヨーク証券取引所の会長を務めていました。私を信頼してください....」.
私はこの記事を見つけました。これは興味深いようで、解決策になる可能性がありますが、まだエクスプロイトを試したり考えたりする時間はありませんでした。
頭のてっぺんから、2 つの別個のデータベースがあり、「邪悪な」システム管理者がアクセスできるのは 1 つだけだと想像できました。
一方のデータベースは、もう一方のデータベースにワンタイム パッドを提供し、誰がいつパッドを要求したかを記録します。このパッドは、現在の時刻と行データとともにハッシュできます。
このようにして、邪悪なシステム管理者が何かを変更した場合、ハッシュはチェックアウトされず、彼が再ハッシュを試みた場合、いつ発生したかのログが得られます。
システム管理者が時間とワンタイムパッドを保存できる場合、このシステム全体が崩壊します。
これは一見難しい問題です。どのプロトコルも実際に機能するかどうかはわかりませんが、物理的なセキュリティと監査ログを追加することは良い考えです。
まず、システムの管理を誰に依頼するかについて十分に注意してください。
トリガーによって入力された次の監査テーブル。彼が変更のトリガーを回避したとしても、少なくとも彼が変更する前のデータ (特にバックアップから) を見ることができます。
オフサイトで削除される 3 番目の自動バックアップ。これにより、たとえ悪意のある人物がデータベースを落としてオンサイトのバックアップを消去したとしても、フォールバックの立場を確保できます。データベース管理者がオフサイト バックアップにアクセスできないことを確認してください。データベース サーバーに対する実稼働権限を持たない他のユーザーのみが権限を持っています。
次に、管理者以外のテーブルに対する直接的な権限はありません。これは、動的 SQL なしでストアド プロシージャを使用することを意味します。これにより、少なくとも他人が不正にデータを変更することを防ぎます。これで、会計担当者が不正を行うのは難しくなりました。
管理者とバックアップとしての他の 1 人を除いて、誰にも運用管理者権限はありません。このようにして、トリガーが変更されたことがわかった場合、誰がそれを行ったのかがわかります。何もかもがうまくいかず、容疑者は 2 人しかいません。
SQL Server 2008 には、誰が構造的な変更を行ったかを知らせる DDL トリガーがあります。繰り返しになりますが、トリガーが変更を記録しなかった場合は、デフォルトで管理者によって行われました。
バックアップと特定の個人データを暗号化して、盗むのを困難にします。これで、オフサイトのバックアップ配信担当者がデータを盗むのが難しくなります。
たとえそれが信頼できないデータでなくても、信頼できないことが証明された管理者をクビにします。タイムシートを偽造したり事務用品を盗んだりすると、データを盗みます。彼が重大な犯罪 (交通違反ではない) で逮捕された場合、告発が立証されているかどうかを確認する必要がある場合は、彼を停職処分にすることができます。
管理者が別の仕事に移ることを決定した場合、彼が行くことをあなたに告げた瞬間からシステムへのアクセスを許可しないでください。彼を解雇する場合、これは特に重要です。
自動化されたアプローチが必要な場合は、まず、ユーザー タイプに許可されているアクションとコンテキストを知る必要があります。適切なコンテキストではドロップは許容されますが、日常のユーザーにとってはそうではないため、これは非常に困難です。
私は紙のバックアップのアイデアが好きですが、生成される情報量は、大規模なユーザーベースと大量の DB 使用により、非常に急速に大きくなる可能性があります。
アプリケーションが常に実行されている場合は、データベースでトランザクションを開始し、アプリが閉じるまで解放しないことができます...そのようにすると、アプリ以外のテーブルを表示することさえできなくなります...
また、時間がある場合は、プログラムに出入りするすべてのテキスト文字列データを暗号化してください...
私は BobbyShaftoe の回答も気に入っています...もう少し進んで、「スリープ」などのトリガーを取得できるかどうかを確認してください。数分後にすべてのレコードが元の状態に戻ります...だから私たちの邪悪な管理者は考えます彼は変更を加えましたが、元に戻すだけです。
悪意のある管理者もアクセスできない非本番データベースにデータが入力されたときに、データのコピーを送信するトリガーを追加できます。管理者はトリガーの機能を停止できますが、問題は操作を阻止するのではなく、どのように検出するかでした。
まさにそのようなソリューションを実装する方法を調査しているときに、このスレッドを見つけました。私が考えた 1 つの (非常に理論的な) 解決策は、完全転送秘密鍵システムを使用するのとよく似ています。
秘密鍵と公開鍵のペア (Kpr と Kpb と呼びます) と一連のアルゴリズム (A と B) があるとしたら、次のようになります。
(ここで、K'pr と K'pb は、Kpr と Kpb とは異なる有効な秘密鍵と公開鍵のペアです)
これを使用すると、データベース内のすべての行に署名し、使用後にすべての秘密鍵を破棄できますが、署名付きの公開鍵を保存できます。次に、悪意のある管理者が変更できない場所に最初の公開鍵を保存することができます (つまり、知っている人全員に送信する、新聞に印刷する、顔にタトゥーを入れる、上記のすべて)。
秘密鍵がなくなったため、すべてのレコードに再署名する方法はなく、公開鍵がすべて連続しているかどうかを確認できます。私が考えることができる唯一の2つの欠陥があります：
問題は、私が説明したような一連のアルゴリズムを認識していないことです。ただし、私は暗号学者ではないので、可能かもしれません。
編集：
もう少し考えた後、既存のツールでこれを可能にする方法を見つけたかもしれません。(n-1) 番目のレコードに n 番目のレコードの公開鍵とその署名を含める場合 (レコードを書き込む時点で次の秘密鍵にアクセスできるため、可能です) 、 d 前のレコードですべてのレコードを保護します。秘密鍵を削除した後、署名を再作成することはできないため、最初の公開鍵を持っている限り、いつでもテーブル全体を検証できます。これにより、「連続した」秘密鍵を持つ必要もなくなります。単純にすべての行に対して新しい秘密鍵を生成することができます (ただし、これには非常にコストがかかります)。同じ欠陥がまだ適用されます。
この質問に対する 2016 年の答えは、ブロックチェーンデータベースを使用することです。ウィキペディアによると：
ブロック チェーンは主に、最近の有効なトランザクションのバッチのハッシュにタイムスタンプを付けて「ブロック」にすることで改ざんを防止し、データがその時点で存在していたに違いないことを証明します。各ブロックには以前のタイムスタンプが含まれており、ブロックのチェーンを形成しており、追加のタイムスタンプごとにその前のタイムスタンプが補強されています。
悪意のある管理者はサーバーを完全に制御できるため、特権 SQL Server ユーザーのアクティビティを監視するように設計された外部監査ソリューションが必要になる可能性があります。
Guardiumは、データベースまたはサーバー上のすべてのクエリ アクティビティをログに記録できるネットワーク アプライアンスを作成します。これはネットワーク レベル (ローカル接続を含む) で行われるため、SQL Server レベルで干渉するようなことはできません。
これはあなたの悪意のある管理者がテーブルを変更するのを防げませんが、それはロックダウンされたアプライアンスであるため、悪意のある管理者はテーブルを変更することができず、アプライアンスに彼がそれをしなかったと言わせることはできません.
監査、チェックサムなどのトリガーと同様に、データベースを別のスレーブ db に複製することを検討できます。データベースに対して直接アクションを実行することはできません。
誰かがトリガーなどをいじるリスクはまだありますが、いじられた場合は非常に目立つため、レプリケーションがどの時点で壊れたかを検出できます。