ユーザーが特定のデータにアクセスするために使用できるアクセスキーとしてUNIQUEIDENTIFIER
を使用するつもりです。その意味で、キーはパスワードとして機能します。
INSERT...SELECT
ステートメントの一部として、このような識別子を複数生成する必要があります。この場合、アーキテクチャ上の理由から、サーバー側の識別子を生成したいと思います。
安全にランダムにUNIQUEIDENTIFIER
を生成するにはどうすればよいですか? NEWID
は、セキュリティプロパティをまったく保証しないため、ランダムではないことに注意してください。推測できないIDが必要なため、SQL Serverで System.Security.Cryptography.RandomNumberGenerator に相当するものを探しています。 CHECKSUM
、Rand
、またはGETUTCDATE
に基づくものも対象外です。
SELECT CAST(CRYPT_GEN_RANDOM(16) AS UNIQUEIDENTIFIER)
私は考えていたトリックを行う必要があります。
Crypto API(CAPI)によって生成された暗号化乱数を返します。
私の2セントだけですが、これは良い考えではないかもしれません。 GUIDのEric Lippertの優れたシリーズ( パート1 、 パート2 、 パート )を言い換えると、頭字語はGUIDであり、GSUIDではありません-グローバルに一意Globally Secure Unique Identifierではなく、識別子。
問題は、GUIDがNEWID()を使用するすべてのユーザーなどの非敵対的なスコープ内で生成される場合、すべての値が一意であることが保証されることです(まあ、なんとなく、Ericの記事、パート3を参照)。ただし、悪意のあるエンティティがそのスコープに入ると、次に生成されるGUIDを予測できるだけでなく、独自に衝突を引き起こす可能性があります。
GUIDのように見える構造内に格納する値を生成する独自のメソッドを作成することにより、本質的に敵対的なエンティティになります。 GUIDの契約がuniqueからrandomに変更されました) 数学で私がおそらくあなたよりもユニークであることを証明できるよりも優れた人ですが、それはあなたの生成方法の範囲内に限られます。これらの疑似GUIDをNEWID()GUIDと混合すると、すべてベットはオフです。
私はこれをmayとは言いませんが、値の使用方法のスコープ全体がわからないためです。あなたが値を生成している唯一のエンティティである場合(混合と一致なし)、および/または値を保持しない場合、および/または衝突を気にしない場合、これは問題ではない可能性があります。これらの項目のいずれかが当てはまらない場合は、再評価することをお勧めします。
https://blogs.msdn.Microsoft.com/sqlprogrammability/2006/03/23/newsequentialid-histrorybenefits-and-implementation/ によると、NEWID()関数はWindows関数CoCreateGuidをラップするだけです。これは、v4スタイルのGUIDを返します。そして https://msdn.Microsoft.com/en-us/library/bb417a2c-7a58-404f-84dd-6b494ecf0d13#id11 によると、1999年のWindows 2000以来、
「Windowsに組み込まれているすべてのバージョン4 GUIDのランダムビットは、Windows CryptGenRandom暗号化APIまたは同等の暗号化キーの生成に使用されるものと同じソースを介して取得されます。」
したがって、NEWID()は暗号的に安全であると考えることができます-少なくともそれが提供する122ビットのエントロピーの範囲まで。