データベースIdの暗号化

Question

データベース内の特定のテーブルのIDを、データベース内の特定のエントリにアクセスするためにクライアントに返す必要があるRESTfulなサービスの開発に取り組んでいました。私は、自動インクリメントを使用し、直接IDを返すに対して助言ので、私が代わりに次のようにイドを暗号化して送信するために行ってきました -

SET @secretKey1 = "some key"; 
SET @secretKey2 = CONCAT("some other key", AccountNo); 
SET @encryptedAccountNo = TO_BASE64(AES_ENCRYPT(AccountNo, @secretKey1)); 
SET @encryptedId = TO_BASE64(AES_ENCRYPT(Id, @secretKey)); 
RETURN CONCAT(@encryptedAccountNo, @encryptedId); 

（注意：口座番号がにさらされないように十分にランダムフィールドですクライアント）

プライマリキーとしてUUIDを使用する方が適切でしょうか？もしそうなら、UUIDを十分に使用しているか、それとも暗号化すべきか？

あなたは完全に他のデザインを使用しますか？

また、既存のデザインのセキュリティまたはパフォーマンス面を改善するためのヒントはありますか？私はあなたがそのアドバイスを誤解しているかもしれないと思う

Answer 1

....

あなたは「私は自動インクリメントを使用し、直接IDを返すに対して助言された」と言う

。

あなたは確かに必ずIDをチェックしてください。使用する前に、サーバー側を使用するのが正しいです。あなたのAPIは、暗号化されたものに対処する必要がありますよう

は（つまり、そのIDで文書がそれを編集しようとするユーザーに属していることを確認してください）、

が、ID自体を暗号化し、実際には有用な目的を果たしていませんあなたが暗号化されたバージョンを送信して、まったく同じ結果を得ることができるように、（悪意のある）クライアントは暗号化/復号化クライアント側でない限り、セキュリティ上何もしません）...

あなたのセキュリティのコメントはできませんあなたのデータベースロジックの（小さな）部分を見ることからのコード。適切なレビューが必要な場合は、実際にインタラクションを行うコードを投稿する必要があります。