Database Security for PCI DSS

Copyright©2017 NTT Corp. All Rights Reserved.
Database Security for PCIDSS
- NTT Database Summit -
大山真実(@ooyamams1987) – NTT OSSセンター

1Copyright©2017 NTT Corp. All Rights Reserved.
セキュリティって必要？
 必要です！
Q: 将来、データベースを壊して業務を妨害することがあるかも知れない。（図 3-21）
Q: 将来、データベースに格納されている情報をこっそり改ざんするかも知れない。（図 3-22）
そう思う
2.9%
ややそう思う
6.5%
どちらとも
いえない
15.5%
あまりそう
思わない
9.6%
そう思わない
65.5%
そう思う
2.4%
ややそう思う
7.4%
約1割のDB管理者がDBを破壊するかもしれない!?
引用元：DBSC 「DBA 1,000 人に聞きました」アンケート調査報告書
http://www.db-security.org/report/dbsc_dba_ver1.0.pdf

セキュリティって必要？
 必要です！ IPA 「組織における内部不正対策」 http://www.ipa.go.jp/files/000047237.pdf

セキュリティは投資！
 必要です！
METI IPA「サイバーセキュリティ経営ガイドライン Ver 1.0」
http://www.meti.go.jp/press/2015/12/20151228002/20151228002-2.pdf
抜粋：
• セキュリティ対策に対して経営者が十分なリーダーシップを発揮していない。
• セキュリティ投資へのリターンが見えにくい性質のものであるため、
経営者がリーダーシップを取らなければ、積極的に話が上がりにくい

セキュリティを考える上で大事なこと
 必要です！
「スター・ウォーズ：帝国のサイバーセキュリティ問題」
https://blog.kaspersky.co.jp/star-wars-cybersecurity-problems/13511/
引用：
このデス・スター破壊のエピソードを、セ
キュリティの観点から詳しく見ていきま
しょう。
～省略～
また、最終兵器の設計図がそっくりそのま
ま漏洩して敵の手に渡ったことも、陥落の
真の要因ではありません。もちろん大失態
ではありますが。要は「情報が知られなけ
れば安全」という法則は成り立たない、の
です。
「完璧なセキュリティ対策」は存在しない。
多層防御の考え方が大事！

免責事項
 本発表は PCI DSS を参考にデータベースのセキュリティに
ついて考えることを目的にしています。
 本資料の記載通りに対策を施しても、PCI DSS の要件を満たすか
どうかは保証できません。実際に PCI DSS の審査を
受ける時は、最寄りの QSA にご相談ください。
http://www.intellilink.co.jp/security/services/consulting/09.html
1日研修もあるよ！

PCI DSS とは？
 クレジットカード業界のセキュリティ基準です。
Payment Card Industry Data Security Standardの頭文字をとったも
ので、国際カードブランド5社
American Express
Discover
JCB
MasterCard
VISA
が共同で設立したPCI SSC(Payment Card Industry Security
Standards Council)によって運用、管理されています。
 クレジットカードを扱わないシステムであったとしても、セキュリティ
について考える時は、この PCI DSS を参考にすることができる。
http://www.jcdsc.org/pci_dss.php より

PCI DSS の用語
 カード会員データ (保存可)
プライマリアカウント番号(PAN) （読み取り不可、暗号化）
カード会員名
サービスコード
有効期限
 機密認証データ (保存不可)
磁気ストライプデータなど
 代替コントロール
 QSA＝Qualified Security Assessors
• 審査機関(QSAC)
• 審査人（QSAP）

クレジットカードの不正使用
期間偽造カード番号盗用その他合計
H.26 19.5 66.7 27.7 113.9
H.27 23.0 71.4 25.6 120.0
H.28(1-9月) 22.7 67.2 16.9 106.8
0
50
100
150
H.26 H.27 H.28(1-9月)
その他
番号盗用
偽造カード
(億円)
(億円)
日本クレジット協会
クレジットカード不正
使用被害額の発生状況
http://www.j-
credit.or.jp/informati
on/statistics/downloa
d/toukei_03_g_1612
28.pdf
毎年１００億円
を超える被害額

PCI DSS の要件
PCI DSS の１２要件
安全なネットワークの構築・維持
要件1：カード会員データを保護するためにファイアウォールを導入し、最適な設定を維持すること
要件2：システム・パスワードと他のセキュリティ・パラメータにベンダー提供のデフォルトを使用しないこと
カード会員データの保護
要件3：保存されたカード会員データを安全に保護すること
要件4：オープンなパブリック・ネットワーク経由で転送されるカード名義人データを暗号化する
脆弱性を管理するプログラムの整備
要件5：アンチウイルス・ソフトウェアを利用し、定期的に更新すること
要件6：安全性の高いシステムとアプリケーションを開発し、保守すること
強固なアクセス管理手法の導入
要件7：カード会員データへのアクセスを業務上の必要範囲内に制限すること
要件8：コンピュータにアクセスする利用者ごとに個別のIDを割り当てること
要件9：カード会員データへの物理的アクセスを制限すること
定期的なネットワークの監視およびテスト
要件10：ネットワーク資源およびカード会員データに対するすべてのアクセスを追跡し、監視すること
要件11：セキュリティ・システムおよび管理手順を定期的にテストすること
情報セキュリティ・ポリシーの整備
要件12：情報セキュリティに関するポリシーを整備すること
http://www.pci-dss.jp/require.html
これらはシステムを構成する全てのハード/ソフト/運用プロセスに適応される。
では、データベースではどのように考えるべきか？

データベースのセキュリティにおいて考えるべき観点
データベースへの PCI DSS 適応を以下の観点で考える
１．データベースをセキュアな状態に保つ
２．データの保護、暗号化と鍵の管理
３．ユーザーの識別、認証、認可、アカウント管理
４．監査

PCI DSS 要件２ざっくりまとめ
• デフォルトアカウント、パスワードの使用禁止
• 既知の脆弱性が修正された状態を保つ
• 不要な機能、プロトコルの使用禁止
• 管理アクセスは暗号化する。
要件２から考えるデータベースですべきこと
• デフォルトのユーザはログイン禁止
• 最新マイナーバージョンへのアップデート
• IPアドレス制限、必要最低限のアクセスのみを許可
• 管理アクセスは暗号化
(例えばpsqlによるDBへの接続など)
基本的なセキュリティ対策はちゃんとやろう！

PCI DSS 要件３ざっくりまとめ
• PANの保護
• PANは以下の状態で保存する。
 不可逆的に読み取り不可な状態にする
・ワンウェイハッシュ
・トランケーション
・代替番号
 暗号化する
• 暗号鍵を使う
• 業務上必要な人のみが復号できる

PCI DSS 要件３ざっくりまとめ
• 暗号鍵は以下の要件に従って管理する
• 業務上必要な人だけが鍵にアクセスできる
• 暗号鍵は鍵暗号鍵で暗号化(２層鍵管理)
• 暗号鍵と鍵暗号鍵は別々の場所に保存
• 鍵は最小限の場所に保存
• 鍵は使用期限を設け、一定期間で更新する
• 鍵は安全に保存、配布する
• 鍵へのアクセス/使用の記録を残して監査する

要件３から考えるデータベースですべきこと
• 以下の機能を持つデータベース外部の鍵管理ソフトウェアと連携すべき
 ２層鍵管理方式による鍵管理可能
 システム全体のユーザ認証と連携した鍵管理機構可能
 DB管理者と鍵管理者は分けることができる（権限分掌）
 鍵の利用状況を監査できる
https://docs.oracle.com/c
d/E49329_01/network.12
1/b71313/asotrans.htm
鍵交換時の再暗号化時
にもメリットあり
２層鍵管理方式
このような要件を満たす鍵管理OSSが欲しい…

• 透過的暗号化機能(TDE)が使えるとベスト！
 実際の案件では需要大
 現実の案件ではAPにパスワードや鍵を埋め込むことが多い
→セキュリティ的に大問題なので避けるべき
→APへの変更をなるべく抑えたい
 クラウド上でのDB利用拡大に伴い、DBの暗号機能、TDEの要望は多い。

３．ユーザーの識別、認証、認可、プロファイル管理

PCI DSS 要件７，８ざっくりまとめると
• 識別：Identification
 全てのユーザーに各個人を一意に識別できるユーザーIDを与える
• 認証： Authentication
 パスワード
 トークンデバイス
 生体認証
• 認可： Authorization
 業務上必要なユーザーに最小限の権限を与える。
• プロファイル管理
→ユーザーIDの削除、凍結、接続断
 移動/退職者
 一定数の認証失敗
 長時間アクセスなし
 一定時間アイドル状態
有効なパスワードの要件は…

８．２．３パスワードは７文字以上、数字と英文字を両方含むこと

８．２．４９０日に一回パスワードを変更すること

８．２．５直近に使用した４つのlパスワードは使用できない

要件７，８から考えるデータベースですべきこと
• 以下の機能を持つデータベース外部のソフトウェアと連携すべき
 システム全体のユーザ、権限を一括管理可能
 鍵管理機能と連携可能
 単純なパスワードの制限/有効期限設定可能
 プロファイル管理可能
DBと連携してユーザアカウントの削除、凍結が行える
 利用状況の監査可能
• ユーザ管理者とDB管理者は分けるべき
• 業務に応じた細かい単位の権限を持つロール、ユーザを作成する
APから接続するユーザ、運用者、バックアップ、DB管理者など
このような機能を持つOSSが欲しい…
OpenLDAP？

４．監査： Auditing

４．監査
PCI DSS 要件１０ざっくりまとめると
• 以下を監査する
 カード会員データ、監査証跡へのアクセス
 管理者の全てのアクション
 無効なアクセス試行
 識別・認証に関わる操作
• 以下の情報を取得する
 ユーザ識別
 イベントの種類
 日時
 成功/失敗
 イベントの発生元
 影響を受けるデータ、リソースID
• 監査証跡を保護する
 参照、変更権限の制限
 監査ログファイルの変更の検知
 監査証跡は変更が困難な一元管理ログサーバに保存

４．監査
要件１０から考えるデータベースですべきこと
• 前述の要件を満たす監査ログ出力機能を導入すべき
 特権ユーザの完全な監査をどのように実現するかが課題
• 以下を可能にするため監査ログ管理サーバにログを集約すべき
 システム全体の監査ログを集約
 監査ログは監査権限を持つユーザ以外にはアクセスさせない
 監査者とDB管理者は分ける
 監査ログの監査

１～４をまとめると
DB
DB
DB
監査ログ管理サーバ
DBA
DBA
DBA
監査者
認証情報
監査ログ
識別、認証、認可、
プロファイル管理
暗号鍵管理
鍵管理者
ユーザ
管理者
鍵情報
暗号化
データ
暗号化
データ
暗号化
データ

Oracleでの対応
「狙われているのはデータ」──企業の機密情報、個人情報を効果的に守るには？
http://www.atmarkit.co.jp/ait/articles/1511/24/news014_4.html

PostgreSQLでの対応
以下の点を除けばPostgreSQLは十分に PCI DSS に対応できる。
• 権限分掌が不十分
スーパーユーザ（特権ユーザ）権限無しでの運用が困難
→PostgreSQLコミュニティでも改善を検討中
• DB外部の鍵管理機構との連携した暗号化機能がない
• DB外部のユーザ管理機構と連携したプロファイル管理機能がない
• 監査ログ出力機能がない
いずれも代替コントロールできる可能性が高い！
詳しくはOSSセンターにお問い合わせください。
TDEもほしい！

pgauditについて
PCI DSS の監査要件を満たす監査ログ出力機能を
OSSセンターで開発中。
https://github.com/ossc-db/pgaudit/tree/refactored
ポイント
• 監査要件を満たす出力対象、出力情報。
• スーパーユーザであっても監査設定を容易に変更すること
はできない。
• Syslog経由で監査ログをログ管理サーバに送信。
• 性能への影響を極力軽減するログフィルタリング機能。

END

Database Security for PCI DSS

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Database Security for PCI DSS

Similar to Database Security for PCI DSS (20)

Database Security for PCI DSS