DBのキーベースの暗号化で保存時の暗号化を使用するのはなぜですか？
ゴール
暗号化されたデータをデータベースに保存したい。
制約
- アプリケーションレベルの暗号化（DBに送信する前の暗号化）は、私のユースケースでは適切なオプションではありません。
- 私が検討しているDBプロバイダーでは、支払う価格で複数のユーザー/管理権限を作成することはできません。つまり、ログの権限と読み取りと書き込みの権限を分離することはできません。
オプション
- MySQLが（
aes_encrypt/decryptを介して）AES暗号化を処理できるようにします（ECBブロックの問題と、正しく設定されていない場合、MySQLがプレーンテキストで機密データを記録するという事実の両方を知っています） - 保存時に暗号化を提供するDBプロバイダーを使用します（透過的に発生する種類です-
SETで自動的に暗号化し、SELECTで復号化します）。
ご質問
質問1
なぜaes_encryptではなく、このタイプの暗号化を選択するのですか？ （メモとして、私はクレジットカード情報や、保存時に合法的に暗号化することを合法的に奨励するものは何も保存していません）。
私が理解しているように、データベース内のデータを暗号化するポイントは、DB侵害が発生するという現実に直面することです。それを念頭に置いて、誰かが私のDBにアクセスした場合（クエリを実行できることを意味します）、このタイプの保管時の暗号化は、theySELECTのときに単にデータを復号化するだけなので、実際には役に立ちませんか？セキュリティを追加せずにクエリを遅くしているようです。
一方、aes_decryptは、侵入者が別の資格情報の背後にある別のマシンに保存されているキーにアクセスできる必要があります。もっと安全ではないですか？
質問2
質問1で説明したシナリオでは、攻撃者がDBへのクエリアクセスを取得しました。その場合は、ログ記録を有効にしてプレーンテキストのAESキーを取得するだけで、aes_encryptも役に立たないのではないでしょうか。
（ここで制約番号2を思い出してください。）
質問
SQLインジェクションを除いて、攻撃者がSELECTを実行せずに、したがって透過型の復号化をトリガーせずにデータベースの内容を表示できる他のシナリオはありますか？
推奨事項？
私の制約に適合する推奨事項がある場合は、お知らせください。ありがとうございました！
透過的暗号化と手動暗号化
透過的な暗号化は、プロバイダーがキー管理を担当するため、より簡単で安全です。彼らにとって、これはバックアップ、監視、複製などとともに、もう1つの運用上の義務です。
他の運用活動を台無しにするのが簡単であるのと同じように、鍵管理を台無しにすることは簡単です。また、バックアップと同様に、キーが失われると、データも失われます。解決に時間をかけたい問題はどれですか。
攻撃シナリオに関しては、攻撃者がアプリケーションとデータベース間のネットワーク上のトラフィックを受動的に監視する能力を持っている可能性があることを考慮すべき多くがあります。アプリケーションまたはデータベースファイルシステムからデータを読み取る機能を持つことができます。物理ディスクにアクセスできる可能性があります。アカウントの資格情報にアクセスできる可能性があります。アプリケーションでwebshellが動作している可能性があります。ほとんどのシナリオでは、透過的暗号化と手動暗号化は同じように脆弱です。
攻撃者がデータベースの資格情報にアクセスできてもアプリケーションにはアクセスできない可能性があるので、手動の暗号化の場合、攻撃者が克服する必要のある追加のハードルが潜在的に存在します。しかし、手動で暗号化を行う人は多くのことを正しく実行している必要があり、暗号化されたデータへのアクセス権を持つ断固とした攻撃者は、多くの潜在的な経路を前進させます。データが暗号化またはハッシュされたが、後で公開されたとされるデータ侵害の数は計り知れません。
クエリアクセスとクエリログ
データベースへのクエリアクセスは、通常ログを有効にするために必要な管理アクセスとは異なります。ただし、プロバイダーサービスについて具体的に説明する場合、クエリアクセスの資格情報を使用して、プロバイダーからのコントロールパネルを構成することもできます。これにより、クエリのログ記録を有効にすることができます。
ただし、一般的なケースでは一歩後退します。データベースへのアクセス、特に書き込みアクセスを達成する攻撃者の影響は、データが暗号化されているかどうかによって変わりません。ランサムウェア攻撃からページを取得して、彼らは独自の「UPDATE $ table SET $ encrypted_column = aes_encrypt（encrypted_column、 'attacker-key'）;」を実行する可能性があります。そして、暗号化されたデータの保管を返すために、被害者の復号化キー、または単にお金を必要とします。
SQLインジェクションまたはクエリエンジンの外部のデータへのアクセス
上記のように、攻撃者がクエリエンジンを経由せずにデータベースの内容を表示できる多くのシナリオがあります。誰かがネットワークの可視性を持っている可能性があります。誰かがデータベースが使用しているデータファイルを見ることができるかもしれません。物理ディスクがサービスを停止して回転すると、誰かが物理ディスクにアクセスできる可能性があります。誰かがバックアップを取得できる可能性があります。これらすべてのことは毎日起こります。
推奨：保存時の暗号化の要件がなく、防御する必要があり、特別な処理または考慮が必要な特定のシナリオがない場合は、プロバイダーにショーを実行させるだけです。