回答編集履歴
1
大幅に追記しました
test
CHANGED
|
@@ -1,3 +1,85 @@
|
|
|
1
|
+
雑に回答してしまいましたが、反響があるようでしたのでもう少し詳しく回答します。
|
|
2
|
+
|
|
3
|
+
|
|
4
|
+
|
|
5
|
+
ウェブサイトを想定しておられるようですが、この場合「暗号化」にはざっと3通りの方法があります。
|
|
6
|
+
|
|
7
|
+
|
|
8
|
+
|
|
9
|
+
# 1. ストレージ暗号化
|
|
10
|
+
|
|
11
|
+
|
|
12
|
+
|
|
13
|
+
ハードディスクやSSDの単位で暗号化する方法です。AWSなどクラウドも対応していることが多いですが、レンタルサーバーではこの方法は利用できません（一般的に）。よくノートPCのハードディスクをbitlocker等で暗号化しますが、原理としてはそれと同じです。
|
|
14
|
+
|
|
15
|
+
この方法だとOSに乗っているソフトウェアは暗号化を気にしなくていいのがメリットですが、外部からSQLインジェクションやOSコマンドインジェクションで攻撃された場合も、自動的に復号されて漏れるので、防御効果がありません。
|
|
16
|
+
|
|
17
|
+
|
|
18
|
+
|
|
19
|
+
だめじゃんと思うかもしれませんが、データセンターからハードディスクが盗難されたり、ハードディスクの廃棄の際に作業員がネコババしたり（ありましたね）する際には効果があります。
|
|
20
|
+
|
|
21
|
+
詳しくは、以下の記事が素晴らしいのでぜひお読みください。
|
|
22
|
+
|
|
23
|
+
|
|
24
|
+
|
|
25
|
+
[AWSボリュームの暗号化の必要性について](https://qiita.com/shun0157/items/84e16035f9199ee36480)
|
|
26
|
+
|
|
27
|
+
|
|
28
|
+
|
|
29
|
+
ここでAWSボリュームを暗号化する理由としてAmazonに問い合わせた結果の筆頭に以下が載っています
|
|
30
|
+
|
|
31
|
+
|
|
32
|
+
|
|
33
|
+
> 多くのユーザーはこのコンプライアンス基準へ準拠のためだけに、ストレージ暗号化の機能を利用しているのが現実らしい
|
|
34
|
+
|
|
35
|
+
|
|
36
|
+
|
|
37
|
+
つまり、セキュリティポリシーやお客様の指定要件に「暗号化すること」となっているからそうしているということですね。Amazonのこういう正直なところは大好きです。
|
|
38
|
+
|
|
39
|
+
一方、「とにかく暗号化しろと言われているから暗号化する」という考え方は、私は大嫌いです。
|
|
40
|
+
|
|
41
|
+
|
|
42
|
+
|
|
43
|
+
# 2.データベースの透過的暗号化
|
|
44
|
+
|
|
45
|
+
|
|
46
|
+
|
|
47
|
+
Oracle等が熱心に推進している方法です。こちらはストレージ（ハードディスク等）を丸ごと暗号化するわけではなく、データベースの単位で暗号化するものです。SQL問い合わせの際は暗号化を意識することなく、平文でINSERTすれば自動的に暗号化されて格納され、SELECTすれば自動的に復号されて平文で結果が返ります。なので、SQLインジェクション攻撃を受けた場合は平文データが漏洩します。
|
|
48
|
+
|
|
49
|
+
|
|
50
|
+
|
|
51
|
+
透過的暗号化も主なカバー範囲はストレージの盗難ですが、加えてデータベースの中身を格納するファイル単位での盗難もカバーします。
|
|
52
|
+
|
|
53
|
+
|
|
54
|
+
|
|
55
|
+
注意点は暗号鍵の保存場所でして、暗号鍵をデータベースと同じストレージに保存していると、ストレージの盗難の際に復号されてしまうことになりますね。なので暗号鍵は教科書的にはハードウェアセキュリティモジュール(HSM)に置いとけということになりますが、かなり面倒にはなります。
|
|
56
|
+
|
|
57
|
+
|
|
58
|
+
|
|
59
|
+
# 3.アプリケーションによる暗号化
|
|
60
|
+
|
|
61
|
+
|
|
62
|
+
|
|
63
|
+
ウェブアプリケーション側のプログラムによりデータを暗号化・復号する方法です。データベースの場合ですと、INSERTの前に暗号化して保存し、SELECTの結果を復号して利用するという形になります。この方法だと、OSコマンドインジェクションやSQLインジェクション攻撃を受けても、攻撃者が得られる情報は暗号化されたものなので、生データ（メールアドレス）は簡単には漏洩しないことになります…
|
|
64
|
+
|
|
65
|
+
|
|
66
|
+
|
|
67
|
+
しかし、この場合も難しいのは暗号鍵の管理です。アプリケーションのソースコードにハードコードしていたりすると（よくある）、結局簡単に生データが取られてしまいます。ではどうすればよいかというと、各社秘伝の方法があるのでしょう。攻撃者にばれると意味がないので、残念ながら公にするのは難しいです。HSMを使う方法もありますが、リモートコード実行攻撃を受けた場合に十分な保護になるかという疑いがあります（ウェブアプリケーションと攻撃者は同じ権限を持つため）。
|
|
68
|
+
|
|
69
|
+
|
|
70
|
+
|
|
71
|
+
|
|
72
|
+
|
|
73
|
+
ということで、暗号化と一口に言っても、どの脅威を対象にするかで方法が変わってきますし、雑に実装してもあまり効果はありません。
|
|
74
|
+
|
|
75
|
+
ですが、きちんと実装すれば効果はあるわけでして、「要件による」ということに加えて「実装も極めて重要」というのが結論です。
|
|
76
|
+
|
|
77
|
+
|
|
78
|
+
|
|
79
|
+
---
|
|
80
|
+
|
|
81
|
+
【こちらは元の回答】
|
|
82
|
+
|
|
1
83
|
良し悪しは別として、実情としては平文が多いと思います。
|
|
2
84
|
|
|
3
85
|
メールアドレスは検索条件になっている場合も多いので、暗号化しにくいという事情もあります。（暗号化の方法しだいではありますが）
|