1

、、、の3つのemployees列を持つテーブルがあります。FirstNameLastNameSSN

データは、.Netサービスによって毎晩このテーブルに送られますが、これは私が更新するのが苦手です。

次のようなトリガーが欲しいのですが。

ねえ、あなたはSSN列に何かを挿入しようとしているようです...それが入る前にそれをハッシュしましょう。

4

2 に答える 2

4

1 つの方法は、INSTEAD OF TRIGGER を使用することです。

CREATE TRIGGER dbo.HashSSN
ON dbo.tablename
INSTEAD OF INSERT
AS
BEGIN
  SET NOCOUNT ON;

  INSERT dbo.tablename(FirstName, LastName, SSN)
    SELECT FirstName, LastName, HASHBYTES('SHA1', SSN)
    FROM inserted;
END
GO
于 2012-08-20T19:24:43.693 に答える
3

ビジネス ルールのコンプライアンスとステージング テーブル

もう 1 つの方法は、最終テーブルに挿入するのではなく、ステージング テーブルを使用することです。ステージング テーブルは一種の永続的な一時テーブルであり、制約がなく、NULLs が許可され、 のようなスキーマimportにあり、外部データ ソースがデータをドロップするための単なるコンテナーです。概念は、適切なビジネス ロジックを備えたビジネス プロセスをセットアップして、コンテナー内のデータを操作できるようにすることです。

これは、SSN ハッシュを実行できる一種の「データ スクラビング」レイヤーであり、null 可能性や省略の許可、大文字化、長さ、命名、重複排除、キー ルックアップ、変更などの他のビジネス プロセスの運用またはビジネス ルールが適用されます。通知などを行い、最後に挿入を実行します。利点は、一連の不良データが、挿入が試行され、強制的にロールバックされ、元のプロセスが破壊されるのではなく、検出され、失われることなくそのまま保存され、最終的に適切に処理される (移動されるなど) ことができることです。エラーキューへの送信、通知の送信など)。

多くの人がこのようなタスクに SSIS を使用しますが、個人的には SSIS を使用するのは非常に難しいと感じています。脆弱性、一時テーブルを含む SP の使用の難しさ、展開の課題、データベース バックアップの一部ではないなどの問題があるためです。

そのようなスキームがやり過ぎのように思えて、それを考慮に入れることさえできない場合は、少し戻って考えてみてください。データをテーブルに。しかし、それはしていません。代わりに、ビジネス ルールに準拠しないデータを挿入しています。トリガーを平手打ちすることはそれを処理する方法になると思いますが、これはシステムのアーキテクチャについてもっと考え、そもそもなぜこの問題を抱えているのかを探る機会でもあります.

信頼されていないデータやビジネス ルールに準拠していないデータを、信頼できるビジネス ルールに準拠させるにはどうすればよいと思いますか? SSN 列のハッシュなどの変換タスクはどこに属しますか?

挿入プロセスは、そのようなビジネス ルールを認識する必要がありますか? もしそうなら、これは組織、アーキテクチャー、挿入者がいるプロセスのタイプ全体で一貫していますか? そうでない場合、どうやってこれに対処しますか?

SSN ハッシュの不安定性

さらに、もう一つ指摘したいことがあります。TIN がない場合、可能な SSN は約 8 億 8900 万 (8 億 8893 万 1098) のみです。それらすべてを実行して、ハッシュをテーブル内のハッシュと比較するには、どれくらいの時間がかかると思いますか? ハッシュは確かに素早い暴露を減らします.SSNを簡単に読み取ることはできません. ただし、10 億回の試行しかかからないことを考えると、リソースと計画に応じて、すべてをポップするのに数日または数時間かかることもあります。

すべての SSN とその SHA1 ハッシュを含むレインボー テーブルは、25 ～ 30 GB のオーダーしか必要としません。比較的安価な家庭用コンピューターでも十分に達成できます。より長い、またはより計算コストの高いハッシュを使用しても、あまり役に立ちません。数日または数週間で、レインボー テーブルを構築できます。今日では、数百ドルで数テラバイトのストレージを購入できます。

SSN ハッシュをソルトすることができます。これは、誰かがテーブルに対してブルート フォース クラックを実行した場合、一度にすべての行を取得するのではなく、行ごとに 1 回実行する必要があることを意味します。これは確かに優れていますが、避けられないことを遅らせるだけです。真面目なハッカーは、単純な SSN + ソルトをほんの数秒でクラックできるボット軍団をバックアップしている可能性があります。

更なる考察

一方で SSN を検証してパスワードの一種として使用できるようにする必要がある一方で、完全な値を保存することを許可しないビジネス ルールに興味があります。データベースに関するセキュリティ上の懸念はありますか? これらが従業員であると言うように質問を更新したので、非SSN保有者の除外がなぜ議論の余地があるのか​​ についての私の質問. ただし、なぜ値をハッシュする必要があり、値を保存するだけではないのか、まだ興味があります。それは良いことではありませんが、政府に収入と控除を報告できるように、雇用主は従業員の SSN を持っている必要があります。

一方、あなたの懸念が実際にはセキュリティではなく、拒否可能性 (「あなたの SSN は決して私たちのサーバーに保存されない!」) である場合、それは本当ではありませんよね? あなたが行ったのは、ブルートフォースによって元に戻すことができる方法でそれを変換することだけであり、検索スペースは十分に小さいため、ブルートフォースは非常に合理的です. 誰かがあなたに 42 という数字を与え、あなたがそれを 2 倍して 84 を引いた場合、その数字は保存されていないことをその人に伝えます。完全に簡単です。

確かに、「一方向」ハッシュは、乗算よりも元に戻すのがはるかに困難ですが、「そのハッシュから元の 20 万文字のドキュメント (または何でも) を見つける」などの問題を扱っているのではなく、「9 桁の数字を見つける」などの問題を扱っているわけではありません。そのハッシュからの番号」。確かに、多くの異なる入力が 1 つの特定の SSN と同じ値にハッシュされますが、数字だけで構成される正確に 9 文字の文字列の衝突が非常に多くあるとは思えません。

実際の SHA-1 SSN ハッシュ反転テスト

私はちょうどいくつかのテストをしました。約 3200 の実際の SSN を含むテーブルがあります。SHA1 を使用してそれらをハッシュし、それらのハッシュを 1 つの列だけを含む一時テーブルに入れました。から上に向かって検索すると、約 8 分で SSN の 1% をポップできました001-01-0001。処理速度と総検索スペースに基づいて、3 時間以内に完了します (1,000 万の SSN ごとに約 2 分かかるため、88.89 * 2 分)。これはSQL Server の内部からのものであり、はるかに高速なコンパイル済みプログラムを実行していません。それはあまり安全ではありません！

于 2012-08-20T21:20:09.243 に答える