「語られないデータベース暗号の抜け穴」高速トークナイゼー...

www.vormetric.co.jp

「語られないデータベース暗号の抜け穴」

高速トークナイゼーションと暗号化機能を

用いた情報漏洩対策

Vormetric,Inc. 東京オフィス

2 www.vormetric.co.jp

Vormetric

■Vormetric (ボーメトリック) 会社概要2001年設立。米国サンノゼ本社を拠点に北南米・アジア・欧州の21ヵ国でビジネス展開。

■製品暗号化製品 : ファイルサーバ・データベース・クラウド向け暗号化製品。

■顧客1,500社以上の顧客、Fortune30社のうち17社がVormetric製品を採用。連邦政府・金融企業・流通・製造業など多くの業種が顧客。

■日本2015年3月東京オフィス開設

http://www.google.com/url?sa=i&source=images&cd=&cad=rja&docid=Fvyy-9r9jlvxoM&tbnid=Siq1K5_NTEwtgM:&ved=0CAgQjRwwAA&url=http://en.wikipedia.org/wiki/File:GM,_logo.png&ei=YNybUZCaL4jq0AHQmIGYAQ&psig=AFQjCNGsb06gIJ7TDaKUat4vedVRe-kicg&ust=1369255392829329

http://www.google.com/url?sa=i&source=images&cd=&cad=rja&docid=Fvyy-9r9jlvxoM&tbnid=Siq1K5_NTEwtgM:&ved=0CAgQjRwwAA&url=http://en.wikipedia.org/wiki/File:GM,_logo.png&ei=YNybUZCaL4jq0AHQmIGYAQ&psig=AFQjCNGsb06gIJ7TDaKUat4vedVRe-kicg&ust=1369255392829329

http://www.prudential.com/index

http://www.prudential.com/index


Vormetric製品保護できる対象は ?

データベースクラウドファイルサーバ

その他

透過暗号

透過暗号アプリケーション暗号トークナイゼーション

クラウドストレージ暗号

www.vormetric.co.jp

内部犯行と情報漏洩


情報漏洩事故の傾向

■情報漏洩の主な原因

(1) 外部要因: 標的型攻撃やマルウェア感染。(2) 内部要因: IT部門/社員による操作ミスや機器紛失、盗難。(3) 内部要因: 特権ユーザーや委託先社員による内部犯行。

■内部犯行の特長

(1) 外部要因による情報漏洩は内部犯行と比較し約3倍以上のインシデント件数。(2) しかしながら内部犯行による情報漏洩の流出データ数は外部要因の約1.5倍。(3) IT部門によるミスが社員による情報盗難を引き起こしているケースもある。(4) サイバー攻撃とは異なり不正操作のパターン化が困難。(5) 故に内部犯行に対する対策は困難。調査にも多くの時間を費やしている。

■内部犯行は

インシデント件数は外部要因ほど多くはないものの、内部犯行による情報漏洩は流出データ数が多くなるだけでなく、社会的な企業価値の低下も招いてしまう。


内部犯行による情報漏洩

■IT部門は誰に対して脅威を感じているか ?

役員

一般社員

システム管理者 49%

45%

37%

※2016年売上50億円以上の日本企業100社のIT部門に対するVormetric調査結果※複数回答含む

■情報漏洩の犯人、その実態は ?

派遣社員

技術者/開発者

システム管理者 37.3%

35.5%

19.1%

※IPA 組織内部者の不正行為によるインシデント調査より

システム管理者または技術系社員が自分のスキルを使用し犯行に及ぶ


漏洩した情報

■最近発生した国内の内部犯行による情報漏洩事件

日付業種漏洩データ数漏洩したデータ

2016年 2月金融関係 18万件顧客情報

2015年12月医療関係 10万件健康保険証情報

2015年10月地方自治体 18万件住基/課税情報

2015年10月人材関係 1.7万件個人情報

2015年 9月地方自治体 68万件有権者情報等

データベースからの情報盗難が多い■何が漏洩したのか ?

ID/パスワード

社内情報

顧客情報 52.6%

15.8%

15.8%

※IPA 組織内部者の不正行為によるインシデント調査より


企業のセキュリティに対する投資の状況

■IT投資におけるセキュリティ投資の割合 (国別)

アクセス権管理・暗号化

監査ログ・可視化・監視

クライアント制御

アクセス制限

エンドポイント/モバイルの防御( アンチウイルス/MDMなど )

ネットワークの防御( Firewall/IPS/DLPなど )

29%

47%

18%

25%

48%

45%

相関分析ツール( SIEM製品 )

19%

46%

43%

保存データの防御( ファイルサーバ/DB対策 )

18%

45%

40%

※2016年売上50億円以上の日本企業100社のIT部門に対するVormetric調査結果※複数回答含む

日本米国世界平均

・日本のセキュリティ投資は全体的に他国と比較して低い。・Firewall・IPS・アンチウイルスといった投資が多いにも関わらず、情報漏洩は年々増加。


内部犯行の実態

■実態は・アクセス可能なところからデータを盗んでいる。・マルウェアや侵入に対する検知は行っていても内部犯行に対する対策や検知は ?・ログを取得していてもデータ自体は盗むことが可能。

故にその気になればいつでもデータを盗むことができてしまう。

■傾向: 犯行に及ぶ社員とその対象・一般社員は共有ファイルサーバ内のファイルを盗難。 (盗難データ数少)・システム(DB)管理者はデータベース内のデータを盗難。(盗難データ数多)

■統計データには出てこない不正なアクセス・システム管理者による管理者権限を利用したデータの閲覧。(盗難ではない)

米国の展示会において某ベンダーがIT管理者に対してアンケートを実施。

「自分の管理者権限を用いてサーバ内の機密データを見たことがあるか ?」

約60%のシステム管理者が「見たことがある」と回答。

www.vormetric.co.jp

Vormetric 製品概要


Vormetric製品の主要機能

防御

検知無効化

アクセス制御

監査ログの取得暗号化トークナイゼーション

鍵

鍵の作成 / 管理


他社暗号化製品鍵の管理 (KMIP)

Vormetric製品システム構成

ファイルサーバ透過暗号

データベース透過暗号

アプリケーション暗号

データベーストークナイゼーション


他社データベース製品鍵の管理 (TDE)

暗号化トークナイゼーション

他社暗号化製品の鍵管理

HA

暗号鍵

DSM (ハード版/仮想版を選択可) 管理者

・鍵の作成/管理・ポリシーの作成/管理など

仮想VMアプライアンス仮想VMアプライアンス

エージェント

利用する対象製品に応じてライセンスを投入


DSM (Data Security Manager)

■DSMの役割・鍵の作成/管理・ポリシーの作成/管理・ログ管理・管理者による各コンポーネントの集中管理

※最小構成台数は2台より最大8台まで。(HA構成: Failover Cluster)

■DSMの種類・3タイプのDSMを提供。

・仮想アプライアンス (FIPS Level1) : VMWare / Hyper-V / Amazon AMI・ハードウェアアプライアンス (FIPS 140-2 Level 2)・ハードウェアアプライアンス (HSM – FIPS 140-2 Level 3)

※FIPSFederal Information Processing Standardの略。アメリカ合衆国の連邦政府機関が軍事以外の用途で購買・利用する情報・通信機器が満たすべき技術標準を定めた規格。暗号・セキュリティ関連の標準の例として、FIPS 46(DES)、FIPS 140(暗号モジュールのセキュリティ要件)、FIPS 197(AES)などがある。


鍵の管理について

■鍵はDSMで一元管理

①鍵の作成・保管・鍵はすべてDSM上で作成され、DSM内部に保管。・鍵の内部を見ることはDSM管理者であっても不可能。

②鍵の可用性・HA構成によって鍵は同期され、各DSM内に鍵を保管。・Primary DSMの障害時はSlave DSM内の鍵が使用される。

③鍵のバックアップ・鍵を含むDSMの設定ファイルを外部のサーバへ定期バックアップ。・鍵単体を外部へExport保管。・バックアップファイルやExportした鍵ファイルはキーコードにより・暗号化され、いずれもDSMの中でのみ復元可能。・鍵のExport操作は鍵の名称含めDSM上のログに記録。

設定ファイル

+鍵

鍵

■運用においてはバックアップしたDSMの設定ファイルやExportした鍵を保管しているサーバやフォルダに対するアクセス制御や監査ログの取得を行っておくことも重要。


Vormetric製品どのような暗号化が可能か ?

&3xHyｲﾟ

a

ﾃ脳ｨｷUｾ

虞 2k

社員情報

01 鈴木

02 山田

03 佐藤

顧客名カード番号鈴木 1111-2222-3333-4444

顧客名カード番号鈴木 &3xHy a

顧客名カード番号鈴木 1111-2222-3333-4444

顧客名カード番号鈴木 2419-6457-7150-6319

ファイルサーバやクラウド内の文書ファイルの暗号化

データベースファイルの暗号化

データベースカラムの暗号化

トークナイゼーション

透過暗号

ファイルを暗号化

透過暗号

データベースファイルや

実行ファイル等を暗号化

アプリケーション暗号

特定のカラムを暗号化


特定のカラムをトークン化

マスキング復号


ファイルを暗号化

www.vormetric.co.jp

トークナイゼーションTokenization


一般的なトークナイゼーションの仕組み

・指定されたデータをトークンデータで置き換え。・既存のデータベースには置き換えられたトークンデータが保管される。・原本データは暗号化されトークンボルトと呼ばれるデータベースに暗号化保存される。・データの呼び出し時にマスキング機能を用いることもできる。

顧客データベースユーザー

カード番号

1111-2222-3333-4444

アプリケーションサーバ

トークナイゼーションサーバ

トークンデータ

2419-6457-7150-6319

トークンボルト

カード番号

2419-6457-7150-6319

カスタマーサポートクレジットカード番号

****-****-****-4444

入力

表示 (マスキング)

トークナイゼーションシステム

HSM

鍵

暗号化

トークンデータで置換


トークナイゼーションのメリット

■コスト面トークナイゼーションされた箇所はPCIDSSの監査対象から除外。

入力アプリケーションユーザー Webアプリケーションデータベース

決済システム注文処理システム顧客サポートシステム

PAN TKN



トークナイゼーションシステム

HSM

TKN

TKN

PAN

TKNTKN

監査範囲監査範囲外

PAN

TKN

PANデータ

トークンデータ


トークナイゼーションのメリット

氏名カード番号鈴木 1111-2222-3333-4444

氏名カード番号鈴木 w6ｶ｡ru?!PJQRMqｨ2ﾁﾀﾂ

氏名カード番号鈴木 2419-6457-7150-6319

暗号化 (データベースカラム暗号 )の場合

トークナイゼーション (トークナイズ)

・データ長が変わってしまう・データタイプが変わってしまう・既存プログラムの改修工数が大きい・復号すると原本データが表示される

・データ長は変わらない・データタイプは同じ・既存プログラムの改修工数は小さい

氏名トークン番号鈴木 2419-6457-7150-6319

氏名カード番号鈴木 ****- ****- ****-4444

トークナイゼーション (デトークナイズ)

・ユーザー別に表示内容を変更可能・マスクデータからの復号は不可

■技術面・既存データベースのカラム改修は不要。・組み込みがカラム暗号と比較して容易。・マスキング機能によって表示内容の制御が可能。

氏名カード番号鈴木 1111-2222-3333-4444


Vormetricトークナイゼーション (VTS) の特徴

(1) ボルトレス・トークンボルトは不要。・トークンボルト削減によるコスト削減・運用負荷の低減。

( PANなどの原本データやトークンデータはVTS内部には保管されない。)

(2) パフォーマンス / 高可用性・ボルトレスにより高パフォーマンスを提供。・ロードバランサーとの連携で容易にスケールアップ、高可用性の構築が可能。

( 稼働中のVTS Clusterへ新規VTSを追加するだけ。)



従来のトークナイゼーションシステム

HSM DSM

VTS

トークンボルト不要

Vormetric では

ロードバランサー( ラウンドロビン )

同期同期

スケールアップ

VTSCluster


Vormetricトークナイゼーション (VTS) の特徴

(3) 汎用性・使用するデータベースの種類は問わない。・REST-APIを用いた容易な組み込み。

顧客データベース

VTSトークナイゼーション用仮想VMアプライアンス

アプリケーションサーバ

RESTAPI

トークンデトークン処理

HA

DSM(ハード版/仮想版を選択可)

鍵

管理者

Webログイン

VTSの管理・ユーザー設定・マスキング設定など

DSMの管理・鍵の作成/管理・VTSの登録など

Webログイン

Cluster

OracleMS-SQLMy SQLなど制限なし

SSL


VTSによるトークナイズ

■トークナイズのワークフロー例

1

2

3

ユーザーアプリケーションサーバ

VTS DSM

カード番号

1111-2222-3333-4444

カード番号

1111-2222-3333-4444

トークン番号

2419-6457-7150-63194

トークン番号

2419-6457-7150-6319


トークン番号

2419-6457-7150-6319

鍵REST-API (SSL)

{ “tokengroup” : “TOKENGROUP1” , “data” : “1111-2222-3333-4444” , "tokentemplate" : “TEMPLATE1" }

{ “token” : “2419-6457-7150-6319” , “status” : “Succeed” }

2 で送信しているデータ

3 で受信しているデータ


VTSによるデトークナイズ (復号)

■デトークナイズのワークフロー例

4

社員

トークン番号

2419-6457-7150-63193

トークン番号

2419-6457-7150-6319


トークン番号

2419-6457-7150-6319

2

DSM

鍵

VTS

1

データの要求

5

デトークン番号

****-****-****-4444

6


****-****-****-4444 アプリケーションサーバ

4 で送信しているデータ

{ “tokengroup” : “TOKENGROUP1” , “token” : “2419-6457-7150-6319” , "tokentemplate" : “TEMPLATE1" }

5

{ “data” : “****-****-****-4444” , “status” : “Succeed” }

で受信しているデータ

REST-API (SSL)


既にマスキングシステムを導入している場合

1

2

3

ユーザーアプリケーションサーバ

VTS DSM

カード番号

1111-2222-3333-4444

カード番号

1111-2222-3333-4444

トークン番号

8681-5580-7828-44444

トークン番号

8681-5580-7828-4444


トークン番号

8681-5580-7828-4444

鍵REST-API (SSL)

■既存マスキングシステムが右4桁のみを原本表示する場合の例

社員

表示される番号

****-****-****-4444

VTSのデトークン機能は使用せず、変換されたデータより右4桁(原本)を取得・表示する。

VTSでは右4桁のみ原本維持を設定。

マスキングシステム


よりセキュアに

トークン用アプリケーション

サーバVTS-1

Cluster-1

社員用アプリケーション

サーバ

決済用アプリケーション

サーバ

トークン変換用

デトークン社員用

デトークン決済用

・トークンデータへの変換専用・顧客データベースのトークン用・デトークンは無効化

・デトークン専用・一般社員向け・デトークンはマスキングのみ

****-****-****-4444

・デトークン専用・決済システム向け・デトークンは原本のみ

1111-2222-3333-4444

それぞれ別のClusterグループ


トークン番号

2419-6457-7150-6319

VTS-2Cluster-2

VTS-3Cluster-3

用途に応じてVTSを完全に分離することで、よりセキュアに運用することができる。例えば仮に鍵が盗まれたとしてもトークン用アプリケーションサーバや社員用アプリケーションサーバ経由では原本への復号は不可能。

鍵

各VTSが使用するDSMは同じ


ユーザー認証

■2つのユーザー認証に対応・VTSローカルユーザー認証。・Active Directory/LDAPユーザー認証。

4

user1 アプリケーションサーバ

トークン番号

2419-6457-7150-63193

トークン番号

2419-6457-7150-6319


トークン番号

2419-6457-7150-6319

2

DSM

鍵

VTS

1

データの要求

6


****-****-****-4444

7


****-****-****-4444

Active DirectoryLDAP

認証

グループvtsUsers

ユーザーuser1

5

REST-API (SSL)


可用性

■トークナイゼーション(VTS)の可用性・Cluster(Active-Active)構成による設定情報の同期。・ロードバランサーを用いたVTS障害時の継続稼働。

■鍵の可用性・DSM HA機能によるSlave DSMへの複製(鍵を含む全情報)。・Primary DSMに障害時はSlave DSMの鍵を使用。・Primary DSM復旧時はPrimary DSMに対して鍵通信を再開。

DSM Primary

DSM

ロードバランサー同期

同期

VTSCluster

DSM Slave

鍵

鍵

VTS

✖

同期

✖

www.vormetric.co.jp

データベースの対策例


データベースの暗号化

■データベースの暗号化は大きく3つに大別される

透過暗号 &L[ﾁﾉv +w6ｶ｡rｵ8#ﾘ・u?!PJQRMqｨ2ﾁﾀﾂ_獪皂ｿﾁ:0.ﾟ


顧客名カード番号鈴木 2419-6457-7150-6319

カラム暗号

トークナイ

ゼーション

顧客名カード番号鈴木 1111-2222-3333-4444

顧客名カード番号鈴木 1111-2222-3333-4444

顧客名カード番号鈴木 1111-2222-3333-4444

■それぞれ・どこに対して有効な対策なのかを理解しておく必要がある。・( 1つのコンポーネントで全ての対策がとれるわけではない )

・対策箇所はデータベースだけでなく、複数のサーバに渡る場合もある。・バックアップサーバ、ファイルサーバなど。


透過暗号の保護対象

■透過暗号復号時の動作

&L[ﾁﾉv +w6ｶ｡rｵ8#ﾘ・u?!PJQRMqｨ2ﾁﾀﾂ_獪皂ｿﾁ:0.ﾟ

暗号化

復号化

透過暗号エージェントデータベースファイルごと暗号化

・データベースファイルの盗難・データをExportして盗難といった行為に対しては有効な対策。

・データベースの外ではデータが復号される。・クライアント向けの対策ではない。

■導入時は・データベースサーバへ透過暗号エージェントの導入が必要。・データベースやアプリケーションの改修は不要なため実装し易い。

■効果は・鍵を持たないユーザーによるデータベースファイルの盗難に対しては有効な対策。・クライアントやデータベースコンソール内では全てのデータが復号表示されてしまう。

データベースサーバ

顧客名カード番号鈴木 1111-2222-3333-4444

顧客名カード番号鈴木 1111-2222-3333-4444

復号データ

復号データ

クライアント一般社員

データベース管理者


カラム暗号の保護対象

■カラム暗号復号時の動作


カラム暗号エージェント特定カラムを暗号化

・データベースファイルの盗難やExportは可能。・但し暗号化したカラムデータは保護されている。


顧客名カード番号鈴木 1111-2222-3333-4444

一般社員

・データベースの外でも暗号化は維持できる。・復号許可ユーザーは原本データが表示。



復号データ

暗号化を維持

■導入時は・データベースサーバへカラム暗号エージェントの導入が必要。・データベースのカラム改修やアプリケーションの改修が必要で実装には多くの工数を要する。

■効果は・データベース側だけでなく、クライアント側も鍵が無いユーザーに対しては有効な対策。・権限(鍵)を所有するユーザーは原本データが復号表示される。(暗号 or 復号の組み合わせのみ)

クライアント

暗号化

復号化


トークナイゼーションの保護対象

■トークナイゼーションデートクン(復号)時の動作

顧客名カード番号鈴木 ****- **** - **** -4444

顧客名カード番号鈴木 2419-6457-7150-6319

トークナイズ

デトークナイズ

トークナイゼーション特定カラムをトークナイズ

・データベースファイルの盗難やExportは可能。・但しトークナイズしたカラムデータは変換済。

・データベースの外でもデータはマスキング。・ユーザーに応じて表示内容の制御が可能。

顧客名カード番号鈴木 ****- **** - **** -****


■導入時は・トークナイゼーションシステムを新規導入。データベースサーバへは何も導入しない。・アプリケーションの改修は必要だが実装はし易い。

■効果は・データベース側はトークンデータに置換されるためデータの盗難には有効な対策。・ユーザーに応じてデトークナイズ(復号)時の表示パターンを制御することでデータの盗難が対策可能。

変換済データ

マスキングデータ

マスキングデータ

クライアント一般社員



Vormetricのデータベースに対する不正対策は ?

■Vormetricではどのような対策が可能か ?

(1) 見せない・トークナイゼーションで原本データを変換。・デトークン(復号)時におけるマスキング。

(2) 盗ませない・データベースファイルを透過暗号。・Exportデータを透過暗号。・データベースの実行ファイルを透過暗号。・ftpなどのデータ転送を無効化。

(3) 権限を悪用させない・システム管理者による「鍵の悪用」を禁止。

TransparentEncryptionTokenization

DSM


透過暗号

今回の対策例で用いる製品群


データベースに対する不正対策

■不正対策の対象者(例)

データベースサーバシステム管理者

( root )


( dbadmin )

一般社員

OSを含めたインフラ管理

データベースのメンテナンス

データアクセス

不正対策の対象


対象外セキュリティ管理者

( secadmin )

セキュリティ監査



データベース管理者に対する対策

■データベース内のデータを無効化 ( トークナイズ )

データベースへアクセス

カード番号は変換済みの無効なデータ

無効なデータへ変換1111-2222-3333-4444 (原本データ) から2419-6457-7150-6319 (変換データ) へ。


トークナイゼーションを用いることで・データベースへ保存されるデータは変換後のランダムデータ。

見せない

データベースサーバ内

顧客名カード番号鈴木 2419-6457-7150-6319

( 変換済みのデータ )

例えデータベース管理者がデータを盗んでもカード番号は原本データではない。


一般社員に対する対策

■表示データを無効化 ( デトークナイズ )

ヘルプデスク社員クライアント

決済担当社員クライアント

顧客名カード番号鈴木 ****-****-****-4444

( マスク+下4桁表示 )

顧客名カード番号鈴木 1111-2222-3333-4444

( 原本データを表示 )

トークナイゼーションのマスキング機能を用いることで・原本データの表示が不必要な社員へはマスキングや下4桁のみ表示などの制御が可能。・ユーザー/グループ単位でのマスキング設定が可能。


顧客名カード番号鈴木 2419-6457-7150-6319

( 変換済みのデータ )

一般社員による機密データ/個人情報の持ち出しを対策。( 表示データの印刷やスマートフォンなどによる画面の写真撮影に対しても有効 )

見せない

データの表示


データベース管理者に対する対策

■データベースの透過暗号 + ファイルの透過暗号


データベースの透過暗号-

-

+

データベースフォルダ

+

データベース管理者フォルダ

ファイルの透過暗号


データベース管理者フォルダの復号鍵は持っていない×


&L[ﾁﾉv +w6ｶ｡rｵ8#ﾘ・u?!PJQRMqｨ2ﾁﾀﾂ_獪皂ｿﾁ:0.

①DBファイルごとコピー

②DBデータをExport

メンテナンス操作は可能

データベースフォルダの復号鍵は持っている

データの盗難対策・抽出データの書き込み時にファイルの透過暗号を用いて再暗号化、但し復号鍵は与えない。・①データベースファイルのコピーや ②データのExport(抽出) によるデータは復号不可。

データの復号は不可

盗ませない

顧客名カード番号鈴木 2419-6457-7150-6319

復号

再暗号

復号される


システム管理者に対する対策

■実行ファイルを無効化

デーベースコマンド実行不可

データベースコマンド実行可能


-

+

データベースフォルダ実行ファイル


( dbdmin )

鍵を持っている

システム管理者

( root )

鍵を持っていない×

システム管理者( root ) には使わせない・実行ファイルは暗号化済。・鍵を持たないシステム管理者はデータベースのコマンド類を実行することはできない。

データベースの透過暗号

暗号化

盗ませない


システム管理者への対策

■対策前「なりすまし」例


セキュリティ管理者

( secadmin )

セキュリティ管理者の鍵を使用



( root )

システム管理者は鍵を持っていない

secadmin へ suセキュリティ管理者へ×

復号できない復号できる

顧客名カード番号鈴木 2419-6457-7150-6319


システム管理者(root) によるデータの盗難・システム管理者(root)は鍵を所有していない。・但し “su” を実行し鍵を持つセキュリティ管理者(secadmin)としてデータを盗めてしまう。


対策前

抽出抽出


システム管理者への対策

■対策後「なりすまし」を禁止


( secadmin )


( root )

システム管理者は鍵を持っていない

secadmin へ suセキュリティ管理者へ×


Vormetric の「なりすまし」対策・元のユーザーの鍵の状態を維持。・どのユーザーへ変更しても鍵は持てないため鍵の悪用を禁止できる。

対策: システム管理者の鍵の状態を維持


×

権限を悪用させない




復号できない抽出復号できない抽出


システム管理者 / データベース管理者に対する対策

■アクセス制御


ftpサーバ

データ転送を禁止・アクセス制御機能を用いてftpクライアントのデータアクセスを制御。・例えば、特定ユーザーが実行する特定プロセス(ftpなど)に対して、指定したパス内にある・データへのアクセスを禁止させることが可能。

盗ませない

ftpクライアントデータアクセスを禁止

×


( dbdmin )


( root )


まとめ (トークナイゼーション+透過暗号で機密データを保護 )

透過暗号ファイルシステム

データベース内

ID 顧客名カード番号

0001 鈴木 2419-6457-7150-6319

0002 田中 6433-3388-9507-8257

-

+

+

・・・・

クライアント

・・・・・

・・・・・

・・・・・

・・・・・

ID 顧客名カード番号

0001 鈴木 ****-****-****-4444

0002 田中 ****-****-****-5555

トークナイゼーション(デトークナイズ)

&L[ﾁﾉv +w6ｶ｡rｵ8#ﾘ・u?!PJQRMqｨ2ﾁﾀﾂ_獪皂ｿﾁ:0

・・・・・

・・・・・

・・・・・

・・・・・

・・・・・

・・・・・

・・・・・

・・・・・

トークナイゼーション(トークナイズ)

見せない

見せない

盗ませない

権限を悪用させない

変換データ

暗号化

マスキング



あまり語られないデータベース暗号のポイント

(1) データベースの透過暗号のみだと・鍵を持ったユーザーがデータベースに入ってしまえば原本データは丸見え。・利用者(クライアント)も原本データが丸見え。・鍵を持ったユーザーであればデータをまるごと持ち出すことも可能。・実データを狙うサイバー攻撃、マルウェア感染によるデータ盗難に対しては脆弱。

透過暗号を用いるならファイルレベルでの透過暗号を用いた対策も同時に必要。

(2) カラム単位での暗号化・大量のカラムデータを暗号化することは困難。( 性能上・運用上の理由 )・暗号と復号の二者択一のみ。復号表示させないデータに対する業務への影響は・・・鍵を持った一般社員がマルウェア感染した場合の復号リスク。

(3) トークナイゼーション・性能が悪ければ保護できるカラムデータは限定的になってしまう。・トークナイズ用、デトークナイズ用を分けて設置すると実はセキュリティが向上する。・一般社員に対して原本(PAN)データへのデトークナイズを直接許可させなければ・マルウェア感染時の復号リスクをかなり落とせる。

www.vormetric.co.jp

鍵は本当に盗めないのか ?


鍵の管理

■権限分掌例


( administrator/root )


( secadmin )

DSM / HSM

鍵の管理やポリシーの管理

通信機器・サーバ・ソフト

インフラや認証の管理

ログイン不可

システム管理者は・通信機器やサーバ、認証サーバ等のシステムを管理。・鍵が格納されている “DSM/HSM” へは「ログインできない」。

よって鍵は盗むことはできない ? 安心・安全 ?


暗号化製品における鍵の留意点

■今日の暗号化製品は・利便性を高めるために鍵は何らかの情報と紐づけされている。・( 複数の情報を紐づけするケースも有り )

■例えば

鍵 – 人事部用 Active Directory人事グループ

鍵 – Oracle用 Oracle プロセス

人事グループに属するユーザーは「人事部用の鍵」を用いて暗号/復号を行う。

Oracleプロセスが読み/書きするデータは「Oracle用の鍵」を用いて暗号/復号を行う。


間接的な鍵の盗難

■ファイルサーバの例

人事部

&3xHyｲﾟ

aﾃ

脳ｨｷUｾ虞

2k 哮

共有フォルダ

人事グループ

人事ユーザー 1

人事ユーザー 2

Active Directory

DSM / HSM

鍵 – 人事部用

暗号化管理者グループ


システム管理者が自分を人事グループへ追加すると ?

こういった操作はシステム管理者による鍵の盗難に等しい。対策ができていなければならない。

鍵はActive Directory

人事グループと紐づけ


鍵の管理について

■よくある鍵のQ&A

質問: 鍵は安全な専用装置に保管できるか ?回答: できます。

質問: 鍵へアクセスできる担当者を限定できるか ?回答: できます。

質問: 生成される鍵は強固か ?回答: 強固です。xxx に準拠しており yyy 暗号アルゴリズムを使用できます。

鍵が強固に生成されセキュアに保管できていても、

「第三者によって鍵が紐づく情報が操作でき、それによって復号できてしまう。」

という製品や運用では ✖。


まとめ

■暗号化製品の導入時(検討時)に留意する点

(1) 目的の明確化データベースのどこを誰に対して何のために ?

(2) 管理者の操作を棚卸復号リスクとなる操作は存在しないか ?

(3) 一般社員の操作を棚卸データベースだけでなく、一般社員がメモ保存しているような機密データはファイルサーバに存在していないか ?

■その他の望ましい対策 (暗号化に関わらず)

(1) 操作の監視監査ログと監視・監査ログはファイルサーバやデータベースだけ ?・経過監視は ?

(2) アラート通知メールなどを用いたリアルタイム通知・認証サーバの特定操作・データベース内の特定条件に合致する操作

(3) データの可視化ファイルサーバ内に点在する機密ファイルの可視化・特定キーワードに合致するファイルの有無や場所・カード番号等に合致するファイルの有無や場所


Thank youhttp://www.vormetric.co.jp

「語られないデータベース暗号の抜け穴」 高速トークナイゼー...

Documents

「語られないデータベース暗号の抜け穴」高速トークナイゼー...