clubdb2 第197回 dbセキュリティを一緒に考えよう

© 2015 IBM Corporation

ClubDB2 第197回

DBセキュリティーを一緒に考えよう！


例）ClubDB2サイト運営

- 2-

DBサーバ

Batchサーバ

L/B

DMZ領域

BackendWebService Frontend

その他テーブル

各種バッチ

Reverse Proxy

会員情報テーブル

Web APサーバ


会員情報扱って

るからさ、セキュ

リティ対策で暗

号化検討してね

© タイトル：ブラックジャックによろしく


情報保護に関する法律およびガイドライン

• PCI DSS （ Payment Card Industry Data Security Standards ）

「PCI DSS」は、法律ではなくクレジットカードを取り扱う事業を対象にしたセキュリティ基準。認定されることで損害賠償が＜免責＞される。ドキュメントには、PAN（Primary Account Number）を暗号化することが記載されている。

• カード会員データの保護要件3：保存されたカード会員データを安全に保護すること要件4：公衆ネットワーク上でカード会員データを送信する場合、

暗号化すること

4


• 特定個人情報の適正な取扱いに関するガイドライン（事業者編)

• [平成26年12月11日特定個人情報保護委員会]（別添）特定個人情報に関する安全管理措置

Ｅ物理的安全管理措置 ........................................... 54

ａ特定個人情報等を取り扱う区域の管理 .......................... 54

ｂ機器及び電子媒体等の盗難等の防止 ............................ 54

ｃ電子媒体等を持ち出す場合の漏えい等の防止 .................... 55

ｄ個人番号の削除、機器及び電子媒体等の廃棄 .................... 55

Ｆ技術的安全管理措置 ........................................... 56

ａアクセス制御 ............................................... 56

ｂアクセス者の識別と認証 ..................................... 57

ｃ外部からの不正アクセス等の防止 .............................. 57

ｄ情報漏えい等の防止 ......................................... 57



Ｅ物理的安全管理措置c電子媒体等を持ち出す場合の漏えい等の防止

特定個人情報等が記録された電子媒体又は書類等を持ち出す場合、容易に個人

番号が判明しない措置の実施、追跡可能な移送手段の利用等、安全な方策を講

ずる。

「持出し」とは、特定個人情報等を、管理区域又は取扱区域の外へ移動させる

ことをいい、事業所内での移動等であっても、紛失・盗難等に留意する必要が

ある。

≪手法の例示≫

＊特定個人情報等が記録された電子媒体を安全に持ち出す方法としては、持

出しデータの暗号化、パスワードによる保護、施錠できる搬送容器の使用等が

考えられる。ただし、行政機関等に法定調書等をデータで提出するに当たって

は、行政機関等が指定する提出方法に従う。

＊特定個人情報等が記載された書類等を安全に持ち出す方法としては、封緘

、目隠しシールの貼付を行うこと等が考えられる。



Ｆ技術的安全管理措置d情報漏えい等の防止

特定個人情報等をインターネット等により外部に送信する場合、通信経路における情報漏えい等を防止するための措置を講ずる。

≪手法の例示≫

＊通信経路における情報漏えい等の防止策としては、通信経路の暗号化等が考えられる。

＊情報システム内に保存されている特定個人情報等の情報漏えい等の防止策としては、データの暗号化又はパスワードによる保護等が考えられる。




• FISC金融機関等コンピュータシステムの安全対策基準

FISCとは金融庁の外郭団体である「金融情報システムセンター」（The Center of Financial Industry Information Systems）の略

• データ保護技28: 蓄積データの漏洩防止策を講ずること技29: 伝送データの漏洩防止策を講ずること

• 不正使用防止技33: 伝送データの改ざん検知策を講ずること技42: 暗号鍵の保護機能を設けること

『金融機関等コンピュータシステムの安全対策基準・解説書』第8版https://www.fisc.or.jp/publication/disp_target_detail.php?pid=225

8


9

個人番号の管理方法

個人番号（マイナンバー）をセキュアに管理し利用するという要件を充足する仕組みが必要となります。

2014年4月のFISCレポートでは以下の２通りの格納方式が例示されています。

個人番号

個人番号

(案1) (案2)


10

(参考)先行する他国での実装例

既に実装されている国アメリカ、イギリス、ドイツ、ベルギー、スウェーデン、ノルウェー、韓国など

1962年施行の韓国での例：住民登録番号13桁

番号そのものが個人のプロファイルを示している

My Numberそのものが重要な個人情報になる可能性が高い

①悉皆性（住民票を有する全員に付番）②唯一無二性（1人1番号で重複の無いように付番）③「民-民-官」の関係で流通させて利用可能な視認性（見える番号）④最新の基本４情報（氏名、住所、性別、生年月日）と関連付けられている

1~6:生年月日

11~12:登録順番

8 ~10:誕生地域

7: 性別, 内外国人

13: Check Bit

例 011224-3076911 2001年12月24日男性 076地生まれ

710212-2042224 1971年2月12日女性 042地生まれ

日本での方針


11

(参考)先行する韓国での教訓

当初はプライバシー保護の認識が甘く、当住民登録番号の取得や管理に規制が無かった住民番号取得がマーケティング戦略の一つとして利用された住民登録番号の流出が多発

5年間で1億2700万人分が流出（韓国人口は5000万人なので、国民一人当たり2回以上流出した計算）

住民番号保護の法律が後に制定

事例時期内容流出規模（人）

NEXEN 2011.11 ハッキングで顧客情報1320万人分流出 1320万

SK コムズ(ハッグ） 2011.7ハッキング（中国所在IP）でネイトとサイワールド会員3500万人の情報流出

3500万

ローン会社、貯蓄銀行、チャットサイトなど（ハック）

2011.6個人情報DB販売商が中国のハッカーに依頼しローン会社のサイトなどで1900万人の顧客情報流出

1900万

新世界モール（ハック） 2010.3個人情報DB販売商が中国のハッカーに依頼し新世界モールなどで2000万人の個人情報を購入

2000万

GSカルテックス（故意） 2008.9GSカルテックスの子会社の従業員がGSカルテックス相談ホームページで顧客情報1151万人分をDVDに保存

1151万

オークション（ハック） 2008.9ハッカーは、オークションのWebサーバーで会員1863万人の個人情報流出

1863万


暗号化と言うけれど…

12

• DB暗号化

• DBテーブルや列の暗号化

• アプリケーションでデータを暗号化する方法例) ENCRYPT 関数の利用

• DBサーバー側で実装する方法例) DB2 Native Encryption

• バックアップデータの暗号化

• HDD暗号化

• RDBMSがデータを書き込むファイルを暗号化する。例) DB2 Native Encryption

• ハードウエアの機能でHDDを暗号化

• OSの機能でファイルシステムを暗号化例) AIX 暗号化ファイル・システム (EFS)

• 通信経路の暗号化


13

DB2暗号化関数

• ENCRYPT関数

• DB2が標準で提供する機能

• SQLアプリケーション内で暗号化・復号化操作が可能

• パスワードは列単位にもデータ値毎にも持たせることが可能

• 例：データ値毎の暗号化

• 利点・目的：

• パスワードも共に盗まれなければまず解読される恐れはない

• ユーティリティは暗号化されたデータを復号化せずに扱う

• 万一 UNLOADデータ・ファイルを不正入手されても安全性が高い

COL1 COL2

1 0034CC0..

INSERT INTO T1 VALUES(1, ENCRYPT('機密', 'PASSWORD'));

SELECT DECRYPT(COL2, 'PASSWORD') FROM T1 WHERE COL1 =1;

暗号化

復号化

VARCHAR FOR BIT DATA型で定義(列長は所定の計算式で算出、十分なサイズを確保しておく)

暗号化すべき値とパスワードを与える(文字ストリング型－定数よりホスト変数の方が機密上望ましい


PassW0rd

DB2 native Data Encryption

A Keystore is created locally and has a strong password associated with it:

Keystore

Master Keys with Labels are created in order to encrypt database keys:

The keystore must be available to the

DB2 instance in order to get the Master

Keys required for encryption and

decryption.

SECRET.DB2INST1.2015.02.01

Key Label Key

Keystore

DB2 can generate Master Keys and

Labels automatically for the user.

Creating your own labels will

require that you generate an

encryption key.

Database Keys are generated internally by DB2 and are used to encrypt the database:

DB2 Key SECRET.DB2INST1.2015.02.01

Key Label Key

The DB2 encryption key is itself

encrypted within the database

image by using the Master Key

found within the keystore.


データベース暗号化で防ぐことの出来る脅威

15

• 物理的な盗難

• データベースサーバーから物理的にストレージを抜き去る

• OSレベルでファイルをコピー

• ログやバックアップデータ、ロード元データなど

対応箇所 HDD抜き取りバックアップ盗難

メモリダンプ解析

悪意のあるDBAの犯行

DBテーブルや列の暗号化RDBMSで実装

● ● ● ×DBテーブルや列の暗号化アプリで実装

● ● × ×HDD暗号化

● × × ×


暗号化すべきデータは何か？

• 氏名、住所、電話番号、携帯電話番号、Eメールアドレス、クレジットカード番号、ログインID、パスワードその他、個人が特定できる、または、間接的に特定できる可能性のあるデータが対象

• 暗号化の懸念事項

• パフォーマンスの低下（フル・テーブルスキャン等）

• 導入コスト、工数

• 導入、暗号鍵更新に伴うシステム停止

• 暗号鍵の管理

16


暗号鍵の管理

• 暗号強度＝アルゴリズム強度とはちょっと違う

• 大事なのはアルゴリズムよりも「鍵」の管理

• 「鍵」の管理を一人の管理者に与えるのは危険

• 暗号データと「鍵」を同一プラットフォーム上で管理するのはリスク

17 http://www.db-security.org/img/DBSCblog03_Figure.JPG


暗号化はアクセスコントロールではない

18

http://www.oracle.com/technetwork/jp/database/articles/pickup/index-1622025-ja.html


暗号化だけが対策ではない。

-19-

DBサーバ

Batchサーバ

L/B

DMZ領域



各種バッチ

Reverse Proxy


Web APサーバ

ClubDB2サイトの暗号化要件を整理する


データベース・セキュリティー対策アプローチ

20

http://www.jnsa.org/seminar/seckey/120703/takaoka.pdf


データベースへのアクセス権限の悪用・盗用に対抗するために

– 利用者の識別(Identification)

– 利用者の認証(Authentication)

– アクセス制御と操作制限(Authorization)

– アクセス・操作履歴取得・保管(Accounting)

– アクセス履歴，操作履歴の監査(Auditing)

アクセス権限粒度・管理を細かくすることでＤＢアクセス制限を強化

不正アクセスが起こった場合に被害の最小化・検知・追跡を可能とする

４Ａ＋Ｉの検討

データベース・セキュリティー対策アプローチ


ステップ1 各データベース

インターフェースの分類

アクセス・インターフェースを分類する

OLTP、webアプリ,CLI、BATCH,etc.

ステップ2 各インターフェースに

おける4A+Iを確認

各インターフェース毎に….

ユーザーIDの識別方法

IDの認証方法

持つべきアクセス権限

可能な監視、監査方法

を明白にする

ステップ3 各インターフェースに

おける現状を確認

各インターフェースの現状調査を実施し

4A+Iの観点からセキュリティ・ホールなどが無いかの検討を行い改善点の洗い出しを

実施

ステップ4 改善または実装方法の

決定

各改善を行うための方法、手段を明らかにし実装またはルールの策定を検討する

→ 暗号化もその一つ

データベース・セキュリティー・アプローチ方法


暗号化だけが対策ではない。

-23-

DBサーバ

Batchサーバ

L/B

DMZ領域



各種バッチ

Reverse Proxy


Web APサーバ

ClubDB2サイトの暗号化要件を整理する


データベース・アクセス・インターフェースの分類

24

データベース1.アプリケーション

(Webアプリケーション)

2.業務ユーザー(Webアプリケーション)

3.バッチプログラム

4.データベース管理者(コンソール)

JDBC

JDBC

CLI

CLI

5.OS管理者(コンソール)

ログファイルバックアップ


モニタリング、ロギング、監査レポートの作成

ユーザー権限の管理アクセス制御

データベース・セキュリティー・ソリューション

SQL文をリアルタイム監視し、必要に応じて対応・ロギング・警告

・マスキング・遮断

データベース・ファイアウォール

接続要求

通常のSQL

構文エラーや失敗SQL

権限外のアクセス

Applications

データベース

データの暗号化、マスキング

DBデータ暗号化バックアップ暗号化

NAME,xxx,SSN,xxx

照会結果マスキング

データベース暗号化

テストデータマスキング

データベース・サーバー・アクセス制御

データベース・ログ管理

他システムへの転送データマス

キング

内部からの実行


アクセス権の適切な管理(三権分立)

DB管理者、セキュリティ管理者、アプリユーザーの三者の権限を分離するDB2機能

• DB管理者からのデータ漏洩を抑止するため、DB管理者にデータアクセス権限を持たせない。

• アクセス権限の設定管理は、DB管理者とは独立したセキュリティ管理者によって実施する。

■デフォルトの設定(一般的な多くのDBシステム）

DB作成ユーザー = DB管理者

あらゆる操作が可能

■セキュリティを強化した設定

データベース管理者とセキュリティ管理者、データを読み書きするアプリケーション・ユーザーを分離する

DB管理者（データアクセス権限なし)

バックアップ等のDB管理

セキュリティ管理者（データアクセス権限なし)

アクセス権限の設定

業務データの読み書き

アプリ・ユーザーID （データアクセス権限あり)

26


DBの行・列レベルのアクセス制御

• ユーザー毎に参照可能な列・行を絞り込むことで万一の被害を極小化

• アクセス権限の無い行員はデータは見えない

• システム管理者もデータが見えない

• 行・列単位で各表のデータ・アクセスを制御

• アクセス権限のない列データは検索結果をマスキングする

• アクセス権限のない行データは検索結果に表示しない

アプリケーションを変更することなく、データセキュリティを強化するDB2機能

27

CUSTID EMPNAME CUSTNAME My Number BALANCE

001 MARY SALLY 0123-88888 100000

002 MARY MICHAEL 1123-99999 5000

003 PETER EMILY 2123-77777 0

行員B

My Number が‘XXXX-XXXXX’

に見える

特別な権限

全ての情報が見える

セキュリティ管理者

アクセス制御を担当データは全く見えない

行員A

担当顧客の情報だけ見える


シナリオ: 列レベルのアクセス制御

以下の重要なデータに対して、ユーザーごとに参照権限を設定

• 残高データの列

• ユーザーAはデータを参照できる

• その他のユーザーには、0.00としか見えない

• 顧客番号の列

• ユーザーBはデータ参照可能

• その他のユーザーには、 ‘XXXXXX‘ + 顧客番号の下3桁

1

2

・マスキングの設定は、セキュリティ管理者のみが可能

・データベース管理者とセキュリティ管理者、業務ユーザーの分離が可能

- データベース管理者： DBの起動停止やバックアップ等、DB管理を行う。データ読み書き不可（とすることができる）

- セキュリティ管理者：アクセス権や監査の設定を行う。データ読み書き不可

- 業務ユーザー： SQLによって実際にデータを読み書きする

28


CREATE MASK acct_balance_mask ON customer FOR

COLUMN acct_balance RETURN

CASE

WHEN SESSION_USER=‘A’ THEN acct_balance

ELSE 0

END

ENABLE;

CREATE MASK custid_mask ON customer FOR

COLUMN custid RETURN

CASE

WHEN SESSION_USER= ‘B’ THEN custid

ELSE

‘XXXXXX‘ || right(custid,3)

END

ENABLE;

ALTER TABLE customer ACTIVATE COLUMN ACCESS CONTROL;

シナリオ: 列レベルのアクセス制御設定例

1

2

29

前頁の要件に合うように、DB側にユーザー別のアクセス権を登録


シナリオ: アクセス管理された表からの検索結果例

• 列アクセス制御により：

• ユーザーAは残高情報を見ることができる

• ユーザーAは顧客番号を見ることができない

SELECT * FROM customer

custid Name ADDRESS ACCT_BALANCE

XXX XXX 234 MAX First St. 89.70

XXX XXX 812 MIKE Long St. 8.30

XXX XXX 856 SAM Big St. 12.50

XXX XXX 454 DOUG Good St. 7.68

XXX XXX 789 BOB 123 Some St. 9.00

ユーザーA

30

• 列アクセス制御により：

• ユーザーBは残高情報を見ることができない

• ユーザーBは顧客番号を見ることができる

SELECT * FROM customer

custid Name ADDRESS ACCT_BALANCE

123 551 234 MAX First St. 0

123 589 812 MIKE Long St. 0

123 119 856 SAM Big St. 0

123 191 454 DOUG Good St. 0

123 456 789 BOB 123 Some St. 0

ユーザーB

行列レベルにアクセス制御した表からの検索結果例


31

階層を設定した、より強固な権限構造を設定可能

• SET型

• 依存関係のない集合

• ARRAY型

• 権限強弱の順番有り

• TREE型

• 階層構造の権限強弱

営業製造研究開発

極秘部外秘社外秘一般

Ａ

B C

D E F G


32

優先度の高い処理

優先度の低い処理

システム全体に影響を与えてしまうような大規模処理は事前に実行停止

ワークロードを管理し、限られたリソースの有効活用とシステムの安定稼動を実現する。

– 目的に応じてワークロードを分類

– 実行優先度の制御

– 閾値管理

– 個別レポーティング

きめ細やかなワークロード

分類

さまざまなタイプの閾値管理（大規模クエリー、暴走クエリーの抑

制、同時実行数管理など）

同時実行数の管理実行中アプリケーションの閾

値監視

実行優先度の制御

ワークロードの分類

ワークロードの分類

目的に応じたレポーティング

高優先度実行環境

低優先度実行環境

運用容易性とパフォーマンス向上

Workload Manager機能概要

Workload 管理機能を応用した要件に応じたアクセス制御


33

しきい値説明

Predictive （予測的） ESTIMATEDSQLCOST 見積もりコスト

Proactive（並列度） CONCURRENTDBCOORDACTIVITIES 同時並行実行数

QUEUEDACTIVITIES キュー待機

Reactive（反応的） SQLROWSRETURNED 結果行数

ACTIVITYTOTALTIME 合計実行時間

CONNECTIONIDLETIME 接続アイドル時間

SQLTEMPSPACE 一時表スペース使用量

AGGSQLTEMPSPACE 一時表スペース使用量

（サービスクラス毎）

CPUTIME CPU時間

SQLROWSREAD 読み込み行数

CPUTIMEINSC CPU時間

（REMAP ACTIVITY用）

SQLROWSREADINSC 読み込み行数

（REMAP ACTIVITY用）

（参考） Workload Manager

設定可能なしきい値の種類

例えば「1000行以上の大量検索は許可しない」という制

限を追加できる


(参考)開発環境での漏洩防止

34

ID 氏名生年月日年齢 Credit Card No. Credit Card Type

1 山田太郎 1983/08/06 25 ############## Diners Club

2 松本洋子 1977/04/25 31 ############## Diners Club

3 鈴木和也 1950/10/07 58 ################ VISA

4 柴田彩 1964/09/23 44 ############### American Express

5 斉藤健司 1955/06/24 53 ################ Master Card

1. データ持出時にも個人を特定不可能にする

2. データのルールの維持により実環境に近いテストの実行

カード会社によりクレジットカード番号の上4桁と、その後の数字の生成規則が決まっている

＜既存のマスキング＞＜IBM Optim＞

トランザクションに影響実環境と同等のトランザクション


1 山田太郎 1983/08/06 25 30000071598431 Diners Club

2 松本洋子 1977/04/25 31 30000034924526 Diners Club

3 鈴木和也 1950/10/07 58 4980119237944480 VISA

4 柴田彩 1964/09/23 44 376100627834155 American Express

5 斉藤健司 1955/06/24 53 5200007632070380 Master Card

例）生年月日とクレジットカード番号をマスキング


1 山田亮二 1983/08/06 25 30000071598431 Diners Club

2 松本洋子 1969/11/25 39 30000034924526 Diners Club

3 鈴木和也 1950/10/07 58 4980238451075690 VISA

4 柴田和隆 1964/09/23 44 376100436726423 American Express

5 斉藤恵利 1980/06/24 28 5200007632070380 Master Card

クレジットカード番号のルールは組込済、自動で反映

生年月日と年齢の同期を取ることも可能

その他、ニーズに応じた項目をマスキング可能

ルールをプログラミングで反映させる必要あり（開発アプリケーションごとに個別開発等が必要）

時間・コスト・技術面での制約から簡略化する場合が多数

機密性を守りながら実環境のトランザクションを簡単に再現


データベース監査

特権ユーザー/ローカルコンソール一般端末

IPS/FW/WAF

不正侵入者/社内端末

Webアプリ

外部からの侵入を防ぐ対策(入口/境界防衛)

侵入後or内部犯行の対策

OS、ネットワーク Webアプリ階層データベース

SQLインジェクション、脆弱性をついた攻撃、Brute Force Attack、Dos/DDoSなど

SQLインジェクション、Brute Force Attack

脅威侵入者による不正アクセス、特権ユーザーによる不正アクセス、想定外のSQLの発行、DBへのブルートフォース

パッチの適用アクセスの制限(Firewall)攻撃の検出（IPS、IDS）

アプリケーションの修正、機能の作り込み

対応策

内部監視：アクセス監視 , 監査攻撃の検出 (個人情報テーブル、SQLエラー、過度のログインエラー)出口対策：情報漏洩の検知

外部ネットワーク内部ネットワーク

データベース層での対応が必要

データベース・サーバー

データベース不正アクセス対策としての多層防御


36

セキュリティ・ソリューションのカバー範囲

脅威のレベル / ソリューション行列レベルの

アクセス制御

アプリケーション(SQL)

レベル暗号化

ファイル(OS)

レベル暗号化

物理デバイス(HDD)

レベル暗号化

DB監視・検知

ソリューション

ソリューション概要DB内の行列の単位で、ユーザーのアクセス可否を制御する

DBの暗号化機能により、特定列の暗号化を実施

DBサーバーのOSのファイルレベルで暗号化を実施

HDDのレベルで暗号化。OSより上位からは通常のデバイスとして振る舞う

DB監視ソリューションによる不正アクセス検知

想定する攻撃手段（外部/

内部)

①アプリの利用権限を奪われるケース

（例：ゼロデイ攻撃等の未知の攻撃）△ × × × ○

② DBユーザーIDを奪われるケース

（例：サーバーからのSQL発行によるデータ盗難）

一般ユーザ ○

○ × × ○DB管理者 ○

特権(root) ×

③ OSユーザーIDを奪われるケース

（例：ファイルコピーによるデータ持ち出し）× ○ ○ × ×

④ データセンターIDを奪われるケース

（例：ディスクの物理盗難）× ○ ○ ○ ×

考慮点

アプリの変更不要必要不要不要不要

システムへの負荷極小大小小極小

○ ・・・有効、 △ ・・・一部効果あり、× ・・・効果無し

DBを取り巻くセキュリティ上のリスクに応じた各種対応策があります。監査、暗号化、アクセス権管理、行・列レベルアクセス制御、マスキング

・暗号化対策のみでは、①のケースは完全に防ぐ事は出来ない。GuardiumなどのDB監視・検知ソリューションのような対策が必要

・暗号化については、DB列暗号化(アプリケーションレベル)が最も対応範囲が広い。ただしパフォーマンスなど、再度エフェクトの影響がある。

想定する攻撃手段に対する対策ソリューションのカバー範囲


まとめ

• 暗号化だけが対策ではない

• セキュリティ対策は組み合わせ

• DBを取り巻くセキュリティ上のリスクに応じた各種対応策

• 監査、暗号化、アクセス権管理、行・列レベルアクセス制御、マスキング

• DBセキュリティー対策の実装は常にパフォーマンスやシステム資源とのトレードオフである

37

clubdb2 第197回 dbセキュリティを一緒に考えよう

Data & Analytics