回答編集履歴
2
追記
test
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
|
|
4
4
|
|
|
5
|
-
MySQL側ですが、カラムの暗号化は有効な対策のひとつですが、ENCODE関数は強度的に非推奨で将来的に廃止予定となっているのでAES_ENCRYPT関数を使用してください。
|
|
5
|
+
MySQL側ですが、カラムの暗号化は有効な対策のひとつですが、対象のカラムにおいてSQLでの検索に制限がかかったり索引が効かなくなるデメリットもあります。また、ENCODE関数は強度的に非推奨で将来的に廃止予定となっているのでAES_ENCRYPT関数を使用してください。
|
|
6
6
|
|
|
7
7
|
|
|
8
8
|
|
|
@@ -10,7 +10,7 @@
|
|
|
10
10
|
|
|
11
11
|
|
|
12
12
|
|
|
13
|
-
|
|
13
|
+
MySQLであればテーブル全体に対する透過的暗号化という手段もあります。
|
|
14
14
|
|
|
15
15
|
|
|
16
16
|
|
|
@@ -18,7 +18,7 @@
|
|
|
18
18
|
|
|
19
19
|
|
|
20
20
|
|
|
21
|
-
こちらではアプリケーション
|
|
21
|
+
こちらではアプリケーションやSQLで暗号化・複合化を気にせず使うことができます。一方、防御の対象はDISKやファイルへの直接アクセスのみであり、DBに対するアクセス権限を利用された時点でデータの漏洩となってしまいます。（透過的暗号化を使う場合に限りませんが）DBへのアクセス制御やアクセス履歴の監査等と組み合わせて防御することになります。
|
|
22
22
|
|
|
23
23
|
|
|
24
24
|
|
1
追記
test
CHANGED
|
@@ -18,7 +18,7 @@
|
|
|
18
18
|
|
|
19
19
|
|
|
20
20
|
|
|
21
|
-
こちらではアプリケーション側で暗号化・複合化を気にせず使うことができます。一方、防御の対象はDISKやファイルへの直接アクセスのみであり、DBに対するアクセス権限を利用された時点でデータの漏洩となってしまいます。
|
|
21
|
+
こちらではアプリケーション側で暗号化・複合化を気にせず使うことができます。一方、防御の対象はDISKやファイルへの直接アクセスのみであり、DBに対するアクセス権限を利用された時点でデータの漏洩となってしまいます。（透過的暗号化を使う場合に限りませんが）DBへのアクセス制御やアクセス履歴の監査等と組み合わせて防御することになります。
|
|
22
22
|
|
|
23
23
|
|
|
24
24
|
|