DBSCからの緊急提言解説
DBSC緊急提言プロジェクト

Agenda 提言書について

 1章解説 2章解説 3章解説 4章解説

2

Copyright © 2011 データベース・セキュリティ・コンソーシアム(DBSC),
All Rights Reserved.

緊急提言：オンラインサービスにおけるデータベースと機密情報の保護

境界防御を中心として考えられてきたインターネッ
ト上のセキュリティ対策であるが、攻撃者がそれらを突破し、情報を格納しているデータベースそのものを攻撃することがあるという事実が、今我々の眼前に突きつけられている。
境界防御を乗り越えてくる攻撃者の存在を想定し、さらに進化した多層防御の仕組みを構築しなければならない。
最近の事件、事故の動向を踏まえた上で、改めてデータベースに対する管理策はどうするべきかを見直すための提言を行うこととした。

情報の活用と保護がバランスよく実現され、インターネットを通じたビジネスと経済活動の健全な発展を願っています。

3

Copyright © 2011 データベース・セキュリティ・コンソーシアム(DBSC),
All Rights Reserved.

1.1 定量化しやすい直接的被害の例


サービスが停止することで、停止期間中のオンラインゲーム、物品・サービスの販売等による売上げと利益が失われる。
セキュリティ専門会社等に依頼し、原因究明・解析・証拠保全などを行うコスト
個人情報の漏えいについては、個人（情報主体）に対する問い合わせ対応委託費用や、謝罪等の費用が必要。
JNSAの試算による30万人顧客情報漏洩の場合の緊急対応費用（例）
事件発生後に改善策として多額の投資を迫られることになる。

出典：日本ネットワークセキュリティ協会「２００３年度 情報セキュリティインシデントに関する調査報告書 第二部」

4

Copyright © 2011 データベース・セキュリティ・コンソーシアム(DBSC),
All Rights Reserved.

1.2 定量化が難しい間接的損害の例


顧客企業や個人顧客からの問い合わせ対応、広報（顧客向け、マスコミ向け等）対応にかかる内部人件費が必要となる。業務効率の低下や事件の対応、苦情対応などに関わる人的コスト（営業対応なども含む）が発生する。
社会的な企業イメージ・風評の問題が起きる。事件の原因となった情報保護体制への批判、事件発生後の対応に関する批判など、当該企業は多くの厳しい社会的批判にさらされることになる。またこれらに伴う株価への影響は明確な根拠がないものの、事業形態によっては大きな影響を及ぼす懸念も払拭できない。
事業内容・規模によっては、単一のサービスやシステムが攻撃されるだけでなく、 その後、当該企業が提供する他のサービスやシステムも次々と攻撃対象となり 「標的型攻撃」の対象となってしまう場合がある。
あるネット系企業が攻撃を受け、サイトを閉鎖している間に株価が18%程度下落した例（赤枠内が閉鎖期間）

5

Copyright © 2011 データベース・セキュリティ・コンソーシアム(DBSC),
All Rights Reserved.

大前提 重要なデータ（情報）がデータベースに含まれる前提 以下は極端な例

じゃがいも in データベース

6

ダイヤ in データベース

Copyright © 2011 データベース・セキュリティ・コンソーシアム(DBSC),
All Rights Reserved.

2.1 想定される攻撃シナリオ

7

Copyright © 2011 データベース・セキュリティ・コンソーシアム(DBSC),
All Rights Reserved.

2.2 最近の動向を踏まえて認識すべきこと


攻撃に至るまでのプロセスや技術は複雑化・簡易化
辞書アタックでの成りすましは当然、暗号化通信経由での攻撃も 攻撃コード難読化／多様化⇒防御ツール側とのいたちごっこが発生
 攻撃ツールが容易に入手可能⇒誰でもスーパーハッカーに※詳細についてはセキュリティ専門企業や独立行政法人情報処理推進機構（IPA）による解説を参照下さい。

境界システム中心での防御の限界
念のため：境界システム（Webサーバ、App サーバ）の防御も重要
 考える事：境界防御システムの防御機能が万全でない状態が発生する

データ量の増加傾向
事業が成長期に突入すると、サービス増強、追加が頻繁に 気づいた時にはDBMSが機密データの宝庫になっている可能性も

8

Copyright © 2011 データベース・セキュリティ・コンソーシアム(DBSC),
All Rights Reserved.

技術的に考えるべきこと
境界システムでの防御策は攻撃を軽減する仕組みの一つ
 格納庫（データベース）への安全対策も含めた多層防御へ

境界防御システム

境界防御システム

データベース
保護管理策

境界システム側のみで防御策を検討した場
合、突破された際に深刻な被害を受ける

データベース
9

境界システムが破られる可能性がある事を念頭に置き、防御策を実施
Copyright © 2011 データベース・セキュリティ・コンソーシアム(DBSC),
All Rights Reserved.

3.1 不正アクセス検知の導入
 データベースアクセスに特化した不正を検知する機構
 データベースアクセスに特化した場合、境界システム上でのそれと比較した際に攻撃の特定が容易
 監視対象や必要スキルセットの単純化⇒必要スキル軽減
 セキュリティルールの数が短くなる⇒運用負荷軽減
不正アクセス検知
システム(Web)不正アクセス検知
システム(DBMS)

Webサーバ
Appサーバ•監視対象はSQL Injection以外に多数存在•攻撃コード対応の増加でルール数増加
10

DBサーバ

•基本はデータベースに対するSQLに特化して監視ルールを設計

Copyright © 2011 データベース・セキュリティ・コンソーシアム(DBSC),
All Rights Reserved.

3.2 脆弱性管理の見直し境界システムに対しては実施している要綱が多いと思いますが、データベースに対しても見直しを脆弱性パッチは（出来る限り）早急に適用
 通信ポート、接続元IPアドレスの制限
 必要な（最小限の）ソフトウェアモジュールのみを導入
 初期設定情報の排除（例：アカウント、サンプルテンプレート）
 不要なアカウントの排除（メンテナンス用途で作成したアカウントなど） パスワードポリシ見直し（推測しにくいパスワード、定期的な変更）
 データベース製造各社のセキュリティガイドも参照に システム構築時だけでなく、継続的な対応を
●例：安易な初期設定のままでは、不正アクセスを許すことになる(OracleDBの場合)$ sqlplus scott/tiger@10.0.0.1:1521/sampledb
SQL*Plus: Release 11.2.0.2.0 Production on 水 x月 yy 08:55:57 2011
Copyright (c) 1982, 2010, Oracle. All rights reserved.
:に接続されました。
SQL>

11

Copyright © 2011 データベース・セキュリティ・コンソーシアム(DBSC),
All Rights Reserved.

3.3 OSにまで攻撃の手が及んだ場合の対応
 OSレベルでの侵入=> DB関連ファイルの奪取
 暗号化（OSの権限からみて透過的だと無意味な可能性）

 データベースレベルでの侵入=>DBMS 内データ奪取
 アプリケーションの接続情報から侵入される場合もある（OS権限を奪取しなくても侵入できる可能性）
 権限最小化 DBMS管理（システム管理）とデータアクセスの分離
 アプリケーション用ユーザと情報を格納するオブジェクトの分離
 権限に応じた最小レベルのアクセス許可

 アクセス最小化 接続可能な時間帯、接続元IPアドレス・ホスト等の絞込み

 暗号化
12

Copyright © 2011 データベース・セキュリティ・コンソーシアム(DBSC),
All Rights Reserved.

3.4 ログの保全管理見直し
攻撃者特性：犯罪行為の足跡（ログ）を消す
 ログ保全管理見直し


ログを生成するシステムとは別の安全なシステムで保全
 当該システム上でのログ保持期間は最低限に
 ログ管理システム上でのログ保全
 取るだけでなく見る（モニタリングの実施）
ログ保全策(改ざん検知、暗号化、二重化)

アクセスログ・いつ？
・だれが？
・何に？
・どこから？
削除・改ざん ・どうやって？

別システムへ転送(逐次)

ログ管理システム

ログの確認

3.5 機密データの最小化
 原理原則：「余分な機密データは持たない」
 本番環境にのみ存在する事があるべき姿 こんなこと、ありませんか？
 開発者向け環境とかテスター向け環境での本番データ利用

 本番環境／テスト環境の混在
 新旧システム入替え時に、アプリケーションは入替えを行ったが、データベース領域はそのまま残存／休止状態
 データマスキング、トークナイゼーションの検討

14

Copyright © 2011 データベース・セキュリティ・コンソーシアム(DBSC),
All Rights Reserved.

3.6 各種コンプライアンス対応の管理策見直し
 コンプライアンス対応実施済みの企業は多い
 ISMS(ISO/IEC 27001）
 個人情報保護法(及びガイドライン）
 内部統制報告制度
 FISC安全対策基準
 PCIDSS
 etc…

 対応の見直しを
 データベースに関連する管理策の見直し

 仕組み（マネジメントシステム）としての再考
15

Copyright © 2011 データベース・セキュリティ・コンソーシアム(DBSC),
All Rights Reserved.4.1 経営リスクとしての情報セキュリティと情報保護の責任の理解

万一事件・事故が発生した際に、経営者が「そんなに大量の個人情報があるとは知らなかった。」「適切な対策をしていると思っていた（が、実はしていなかった）。」というような事態に陥らないことが重要である。したがって経営者のガバナンス（情報セキュリティガバナンス）という点では以下のような点について経営者自らが把握している必要がある。
保有・管理している情報にはどんなものが、どれくらいの量で存在するのか。
 保有・管理している情報にはどの程度の機密性があるか、それらに侵害が 起きた場合、その事業インパクトはどの程度深刻か。それらはレベル分けされているか。
 機密性の高さと事業インパクトの大きさに見合った保護対策が適切に行われているか。
 保有・管理している情報の管理・保護責任者は誰か。社内でオーナーシップは明確になっているか。
16

Copyright © 2011 データベース・セキュリティ・コンソーシアム(DBSC),
All Rights Reserved.

4.2 情報の格納場所「金庫」としてのデータベース
 経営資源として非常に重要な「情報」の入れ物、いわば 「金庫」に相当するのがデータベースであること。
 金庫に鍵をかけない人がいないように、データベースに対しても適切な鍵をかける、つまり適切なセキュリティ対策が重要であること。
（経営者の方々へ）
上記は、よりよい情報保護、個人情報、クレジットカード情報などにかかわる事業リスクの最適化に役立つことを是非ご理解頂きたい。
17

Copyright © 2011 データベース・セキュリティ・コンソーシアム(DBSC),
All Rights Reserved.

DBSC緊急提言プロジェクト（社名50音順）
リーダ
サブリーダ

日本オラクル株式会社
伊藤忠テクノソリューションズ株式会社
株式会社アクアシステムズ
伊藤忠テクノソリューションズ株式会社
株式会社インサイトテクノロジー
タレスジャパン株式会社
富士通株式会社
株式会社富士通九州システムズ
株式会社ラック

北野 晴人
伊藤 英二
安澤 弘子
加藤 昇平
岸本 拓也
上野 隆幸
平野 秀幸
片山 裕昭
西本 逸郎

事務局

株式会社ラック

小林 香織
須田 堅一