回答編集履歴
5
説明ミスっとった…
answer
CHANGED
@@ -1,6 +1,6 @@
|
|
1
1
|
情報セキュリティ要件を実装する上で、実践的規範として[PCI DSS](http://www.atmarkit.co.jp/fdb/rensai/09_dbsec/05/dbsec02.html)というものがあります。
|
2
2
|
|
3
|
-
これは
|
3
|
+
これはクレジットカード会社間からスタートした取り決めではありますが、
|
4
4
|
現在では情報セキュリティを導入する上でのグローバルスタンダードとなっています。
|
5
5
|
|
6
6
|
話が脱線してしまいましたが、
|
4
追記5
answer
CHANGED
@@ -32,7 +32,21 @@
|
|
32
32
|
後、暗号化とは少し話が変わりますが、
|
33
33
|
ビューなどを利用して実テーブルの定義を隠ぺい(顧客の機密情報の入ったカラムを除いたビューを定義など)してセキュリティを確保するケースもありますね。
|
34
34
|
|
35
|
+
###さらに追記
|
36
|
+
暗号化と聞くと対外的な対策とイメージしやすいですが、
|
37
|
+
対内的にも牽制の意味で用いるとかはあるのかもですね。
|
35
38
|
|
39
|
+
**(以下某試験問題の受け売り)**
|
40
|
+
例えば普段はクレジットカード番号は暗号化し、
|
41
|
+
内部スタッフでも普段は参照は不可とする。
|
42
|
+
|
43
|
+
ある顧客(当然クレジットカード持ち主であることの本人確認はしっかり行うこと)から、
|
44
|
+
クレジットカード番号に関する問い合わせがあった場合、
|
45
|
+
オペレータはその顧客情報から検索した番号のみを復号して得る。
|
46
|
+
|
47
|
+
クレジットカード情報レベルとなると、
|
48
|
+
社内オペレータに対しても**必要以上情報を開示してはいけない**という考えによるものです。
|
49
|
+
|
36
50
|
###蛇足
|
37
51
|
IPAの主催している情報処理技術者試験の区分のひとつに、
|
38
52
|
「情報セキュリティスペシャリスト」(今年限りでこの名前の試験はなくなるのですが^^;)という試験があります。
|
3
追記3
answer
CHANGED
@@ -30,4 +30,13 @@
|
|
30
30
|
**カラム暗号化**のように柔軟な仕組みを提供しているDBMSも存在します(Oracleなど)。
|
31
31
|
|
32
32
|
後、暗号化とは少し話が変わりますが、
|
33
|
-
ビューなどを利用して実テーブルの定義を隠ぺい(顧客の機密情報の入ったカラムを除いたビューを定義など)してセキュリティを確保するケースもありますね。
|
33
|
+
ビューなどを利用して実テーブルの定義を隠ぺい(顧客の機密情報の入ったカラムを除いたビューを定義など)してセキュリティを確保するケースもありますね。
|
34
|
+
|
35
|
+
|
36
|
+
###蛇足
|
37
|
+
IPAの主催している情報処理技術者試験の区分のひとつに、
|
38
|
+
「情報セキュリティスペシャリスト」(今年限りでこの名前の試験はなくなるのですが^^;)という試験があります。
|
39
|
+
確か2年ほど前の試験だったと思いますが、
|
40
|
+
ちょうど午後Ⅱの試験で**PCI DSSとデータベースセキュリティ**をテーマとした問題が出題されました。
|
41
|
+
|
42
|
+
興味があればこの辺りの設問を読んでみるだけでも面白いかもしれません^^
|
2
追記2
answer
CHANGED
@@ -27,4 +27,7 @@
|
|
27
27
|
データベース暗号化技術を利用しても基本的には**現在のSQLをそのまま用いて暗号化・復号化の実施**を行えるような機能を提供しております。[テーブル暗号化](http://it-trend.jp/encryption/article/merit)
|
28
28
|
|
29
29
|
また顧客情報の内クレジットカード情報のみ暗号化したい等といった場合は、
|
30
|
-
**カラム暗号化**のように柔軟な仕組みを提供しているDBMSも存在します(Oracleなど)。
|
30
|
+
**カラム暗号化**のように柔軟な仕組みを提供しているDBMSも存在します(Oracleなど)。
|
31
|
+
|
32
|
+
後、暗号化とは少し話が変わりますが、
|
33
|
+
ビューなどを利用して実テーブルの定義を隠ぺい(顧客の機密情報の入ったカラムを除いたビューを定義など)してセキュリティを確保するケースもありますね。
|
1
追記
answer
CHANGED
@@ -17,4 +17,14 @@
|
|
17
17
|
一つ突破されても次で防御できるという状態を保つことが望ましいです。
|
18
18
|
|
19
19
|
コスト削減と利便性とはトレードオフの関係なので、
|
20
|
-
どこで妥協点を定めるかと言うのが一番難しい所ではあるのでしょうが^^;
|
20
|
+
どこで妥協点を定めるかと言うのが一番難しい所ではあるのでしょうが^^;
|
21
|
+
|
22
|
+
###追記
|
23
|
+
コメントを受けまして少し追記をば。
|
24
|
+
|
25
|
+
データベース暗号化について、
|
26
|
+
DBMS(Oracle、SQL Serverなど)にもよるかもしれませんが、
|
27
|
+
データベース暗号化技術を利用しても基本的には**現在のSQLをそのまま用いて暗号化・復号化の実施**を行えるような機能を提供しております。[テーブル暗号化](http://it-trend.jp/encryption/article/merit)
|
28
|
+
|
29
|
+
また顧客情報の内クレジットカード情報のみ暗号化したい等といった場合は、
|
30
|
+
**カラム暗号化**のように柔軟な仕組みを提供しているDBMSも存在します(Oracleなど)。
|