削除後にデータが残っていないことを確認する
ユーザーに関するデータをできる限り少なくするサービスを作ろうとしています。そのために、フォレンジックツールを使用している誰かが私のデータベースやファイルシステムを見るよりも多くの情報を取得しないようにしたいと思います。つまり、16進エディタでハードドライブを調べて、ユーザーが昨日削除したメッセージを見つけることはできません。
私がすでに取った措置：
識別情報を含むログファイルを30分以内に削除します。スワップをオフにしました。 RAMディスクに/tmp、/home、/root、/var/logをマウントしています。 rmを削除し、代わりにsrmへのハードリンクを追加しました。
不良セクターがない限り、ブロックを再割り当てしないハードドライブがあります。
現在の私のシステムの問題：
- 機密ファイルが変更されて小さくなった場合、（AFAIK）セクターの割り当てが解除されます。そのファイルで
srmが呼び出されても、そのセクターは細断されません。 rmを変更しても、unlinkを直接呼び出すプログラムでは何も起こりません。MySQLに機密データを含む行があります。それらの行を削除しましたが、MySQLが何らかの方法でそれらを保持しているのではないかと心配しています。
編集：SQLiteにはsecure_deleteという config設定 があるようです。代わりにSQLiteを使用します。
可能な改善：
- Chattr属性を設定します
s（安全な削除）chattrマニュアルではext2/3/4がこのフラグを無視するように指示されているため、今は設定していません。 ext4がサポートしているかどうかについて、矛盾する情報を見つけました。どのファイルシステムがそれを尊重していますか？ - 空き領域をワイプします。一種のハンマーアプローチのように見えますが、それ以外の場合は＃1を解決する方法を理解できません。また、これを行うために私が見た方法には、非常に大きなファイルを作成してからそれを削除することが含まれます。このシステムの空き容量がほとんどなくなると、プログラムがクラッシュするのではないかと心配しています。
MySQLデータベースのテキストバックアップを作成し（削除された行は含まれていません）、元のデータベースを削除してから復元します。別のSQLデーモンに切り替えますか？- 再起動してRAM=ディスクをクリアします。ただし、頻繁にダウンタイムをしたくありません。また、ハードドライブに残っているデータをクリアすることはできません。
これらを修正する最良の方法は何ですか 三 2つの問題？私は現在ext3でArch Linuxを使用しており、 MySQL SQLite。私はそれらのいずれかを変更する用意があります。
ご清聴ありがとうございました！
メディアを物理的に損傷することなくデータを適切に破棄することは、特にHDDがブロックの再割り当てを開始しているため、非常に困難な作業です。 SSDの場合、ファームウェアは実際にフラッシュに格納されているものと文字通り魔法をかけているため、これは桁違いに困難です（不可能ではないにしても）。セットアップに関するより詳細な情報を求める私のコメントが答えなしであったので、SSDが関係していると仮定しましょう。
あなたはできないデータを本当に破壊するので、次善の策それらをアクセス不可能にします。これは通常、暗号化がかなり適切な方法です（正しく行われた場合）。したがって、あなたの一般的なソリューションは、簡単に忘れられるようにしたいすべてのデータを暗号化し、そのような時間が来たらキーを捨てることです。
さまざまなサービスの実装は大きく異なる場合があり、インフラストラクチャに大幅な変更が必要な場合と必要でない場合があります。ただし、すべての場合に2つのルールが適用されます。
適切な暗号化アルゴリズムと構成を使用する（操作モード、IV生成）
キー（実際には機密性の高いプレーンテキストデータ！）を本当に適切に破棄できることを確認してください。これは、基本的にRAMに物理的に保存し、不要な場合は他のもので上書きすることを忘れないようにすることを義務付けています。もう1。
ユーザーのホームディレクトリに関する簡単な例（Linuxの場合）
通常のファイルを作成します-そのサイズはユーザーの家のサイズを決定し、（疑似）ランダムデータで埋めます（そのための1つの方法は、そのファイルに支えられたdm-cryptデバイスにゼロを書き込むことです）
ファイルによってバックアップされたdm-cryptデバイスを作成し、パスワードをRAMにのみ保存してください（参照 1）。前のステップでバッキングファイルを「ランダム化」するためにdm-cryptデバイスを使用した場合は、ここで異なるパスワードを使用します。
暗号デバイス上にファイルシステムを作成します。
ユーザーの家にマウントします。
ホームを削除する、アンマウントする、キーを捨てる、ファイルを削除する場合（おそらくランダムデータで再び埋めますが、これはSSDではそれほど意味がありません）。
1むしろトリッキーな部分とマイレージは異なる場合があります（常にセキュリティに関して）。ポイントは、サーバーであっても、そのキー（または他の機密データ）がメモリに存在する場合があるべきでない場合があるということです。あなたの場合、これはたとえばサービス（データベース...）がクラッシュした（またはメンテナンスのために停止された）場合、またはコメントで提案されているように、電源オフの場合、特に強制された場合-つまり攻撃者が分析のためにサーバーを物理的にその場所から移動します。
最初のケースは アプリケーションが所有しているメモリページを解放した後、それらを消去するカーネル （したがって、あらゆる形式のアプリケーション停止を含む）によって解決できます。
2つ目はさらにトリッキーです。電源オフ後にRAMを使用する理由を尋ねるかもしれませんが、それが最初ではありません-読み取り データ残留 、 コールドブート攻撃 そして、例えば 電源を切った後にデータを保持しない揮発性メモリチップはありますか？ 。一般的な答え：特別に設計されたハードウェアなしでは、電源オフ時にRAMを消去することはできません。そして、それでも-攻撃者がハードウェアレベルで実行中のマシンにフックする可能性を排除できますか？
これは偏執的に聞こえるかもしれませんが、そのようなサービスを実装するときにあなたが考慮したいことについてのヒントにすぎません。何が理にかなっているか、どのような脅威にリソースを費やしたくないのか、どのトレードオフが許容できるかを決定する必要があります。たとえば、マシンを無人で再起動できるようにしたい場合、少なくとも一部の暗号化されていない機密データ（暗号化キーとしましょう）にアクセスする必要があるため、ほとんどうまくいきません。プライバシーチェーン全体。
別の問題は、それがスワップアウトされないことを確認する必要があることです-少なくとも暗号化されていないスワップストレージではありません。
要約すると、問題は、攻撃者がデータを取得することを不可能にすることができるかどうかではありません。それを作成するのがいかに難しいかです。 どのくらいの部分を指定して、何が意味をなすかを確認する必要があります。
最善の解決策は、本当に最も簡単です。
最初に他の人の手に渡りたくない情報を保存しないでください。削除後にログを回復可能にしたくないですか？ログに記録しないでください。 Cookieを使用してあなたを追跡したくないですか？クッキーを使用しないでください。削除したメッセージを後で復元できるようにしたくないですか？メッセージは削除される前に保存する必要があったので、それはあなたを助けることができません。
これは、「プライバシーモード」のWebブラウザが使用する方法です。彼らはそれらを最初に残さないのでそれらのトラックは回復可能ではない。キャッシュは使用されず、履歴は保存されず、パスワードは記憶されません。もちろん、コンピューターから送信されたデータは引き続き傍受される可能性があることも警告しているため、制御できないアクションを実行するサードパーティが常に存在します。