Database Security for PCI DSS
-
Upload
ohyama-masanori -
Category
Software
-
view
75 -
download
1
Transcript of Database Security for PCI DSS
Copyright©2017 NTT Corp. All Rights Reserved.
Database Security for PCIDSS- NTT Database Summit -
大山真実 (@ooyamams1987) – NTT OSS センター
2Copyright©2017 NTT Corp. All Rights Reserved.
セキュリティって必要?
必要です!
約 1 割の DB 管理者が DB を破壊するかもしれない !?
引用元: DBSC 「 DBA 1,000 人に聞きました」アンケート調査報告書 http://www.db-security.org/report/dbsc_dba_ver1.0.pdf
3Copyright©2017 NTT Corp. All Rights Reserved.
セキュリティって必要?
必要です! IPA 「組織における内部不正対策」 http://www.ipa.go.jp/files/000047237.pdf
4Copyright©2017 NTT Corp. All Rights Reserved.
セキュリティは投資!
必要です!METI IPA 「サイバーセキュリティ経営ガイドライン Ver 1.0 」http://www.meti.go.jp/press/2015/12/20151228002/20151228002-2.pdf
抜粋:• セキュリティ対策に対して経営者が十分なリーダーシップを発揮していない。• セキュリティ投資へのリターンが見えにくい性質のものであるため、
経営者がリーダーシップを取らなければ、積極的に話が上がりにくい
5Copyright©2017 NTT Corp. All Rights Reserved.
セキュリティを考える上で大事なこと
必要です!「スター・ウォーズ:帝国のサイバーセキュリティ問題」https://blog.kaspersky.co.jp/star-wars-cybersecurity-problems/13511/
引用:このデス・スター破壊のエピソードを、セキュリティの観点から詳しく見ていきましょう。~ 省略 ~また、最終兵器の設計図がそっくりそのまま漏洩して敵の手に渡ったことも、陥落の真の要因ではありません。もちろん大失態ではありますが。要は「情報が知られなければ安全」という法則は成り立たない、のです。
「完璧なセキュリティ対策」は存在しない。多層防御の考え方が大事!
6Copyright©2017 NTT Corp. All Rights Reserved.
免責事項
本発表は PCI DSS を参考にデータベースのセキュリティについて考えることを目的にしています。
本資料の記載通りに対策を施しても、 PCI DSS の要件を満たすかどうかは保証できません。実際に PCI DSS の審査を受ける時は、最寄りの QSA にご相談ください。
http://www.intellilink.co.jp/security/services/consulting/09.html
1 日研修もあるよ!
7Copyright©2017 NTT Corp. All Rights Reserved.
PCI DSS とは?
クレジットカード業界のセキュリティ基準です。Payment Card Industry Data Security Standard の頭文字をとったもので、国際カードブランド 5 社
American ExpressDiscoverJCBMasterCardVISA
が共同で設立した PCI SSC(Payment Card Industry Security Standards Council) によって運用、管理されています。
クレジットカードを扱わないシステムであったとしても、セキュリティについて考える時は、この PCI DSS を参考にすることができる。
http://www.jcdsc.org/pci_dss.php より
8Copyright©2017 NTT Corp. All Rights Reserved.
PCI DSS の用語
カード会員データ ( 保存可 )プライマリアカウント番号 (PAN) (読み取り不可、暗号化)カード会員名サービスコード有効期限
機密認証データ ( 保存不可 )磁気ストライプデータなど
代替コントロール
QSA = Qualified Security Assessors• 審査機関 (QSAC)• 審査人( QSAP )
9Copyright©2017 NTT Corp. All Rights Reserved.
クレジットカードの不正使用
期間 偽造カード
番号盗用 その他 合計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
H.26 H.27 H.28(1-9月 )0
20406080
100120140
番号盗用偽造カード列 1
(億円 )
(億円 )
日本クレジット協会 クレジットカード不正使用被害額の発生状況http://www.j-credit.or.jp/information/statistics/download/toukei_03_g_161228.pdf
毎年100億円を超える被害額
10Copyright©2017 NTT Corp. All Rights Reserved.
PCI DSS の要件
PCI DSS の12要件
安全なネットワークの構築・維持要件 1 :カード会員データを保護するためにファイアウォールを導入し、最適な設定を維持すること要件 2 :システム・パスワードと他のセキュリティ・パラメータにベンダー提供のデフォルトを使用しないことカード会員データの保護要件 3 : 保存されたカード会員データを安全に保護すること要件 4 : オープンなパブリック・ネットワーク経由で転送されるカード名義人データを暗号化する脆弱性を管理するプログラムの整備要件 5 : アンチウイルス・ソフトウェアを利用し、定期的に更新すること要件 6 : 安全性の高いシステムとアプリケーションを開発し、保守すること強固なアクセス管理手法の導入要件 7 : カード会員データへのアクセスを業務上の必要範囲内に制限すること要件 8 : コンピュータにアクセスする利用者ごとに個別の ID を割り当てること要件 9 : カード会員データへの物理的アクセスを制限すること定期的なネットワークの監視およびテスト要件 10 : ネットワーク資源およびカード会員データに対するすべてのアクセスを追跡し、監視すること要件 11 : セキュリティ・システムおよび管理手順を定期的にテストすること情報セキュリティ・ポリシーの整備要件 12 : 情報セキュリティに関するポリシーを整備すること
http://www.pci-dss.jp/require.html
これらはシステムを構成する全てのハード / ソフト / 運用プロセスに適応される。では、データベースではどのように考えるべきか?
11Copyright©2017 NTT Corp. All Rights Reserved.
データベースのセキュリティにおいて考えるべき観点
データベースへの PCI DSS 適応を以下の観点で考える
1.データベースをセキュアな状態に保つ2.データの保護、暗号化と鍵の管理3.ユーザーの識別、認証、認可、アカウント管理4.監査
12Copyright©2017 NTT Corp. All Rights Reserved.
1.データベースをセキュアな状態に保つ
13Copyright©2017 NTT Corp. All Rights Reserved.
1.データベースをセキュアな状態に保つ
PCI DSS 要件2 ざっくりまとめ• デフォルトアカウント、パスワードの使用禁止• 既知の脆弱性が修正された状態を保つ• 不要な機能、プロトコルの使用禁止• 管理アクセスは暗号化する。
要件2から考えるデータベースですべきこと• デフォルトのユーザはログイン禁止• 最新マイナーバージョンへのアップデート• IP アドレス制限、必要最低限のアクセスのみを許可• 管理アクセスは暗号化
(例えば psql による DB への接続など )
基本的なセキュリティ対策はちゃんとやろう!
14Copyright©2017 NTT Corp. All Rights Reserved.
2.データの保護、暗号化と鍵の管理
15Copyright©2017 NTT Corp. All Rights Reserved.
2.データの保護、暗号化と鍵の管理
PCI DSS 要件3 ざっくりまとめ• PAN の保護
• PAN は以下の状態で保存する。 不可逆的に読み取り不可な状態にする ・ワンウェイハッシュ ・トランケーション ・代替番号 暗号化する
• 暗号鍵を使う• 業務上必要な人のみが復号できる
16Copyright©2017 NTT Corp. All Rights Reserved.
2.データの保護、暗号化と鍵の管理
PCI DSS 要件3 ざっくりまとめ• 暗号鍵は以下の要件に従って管理する
• 業務上必要な人だけが鍵にアクセスできる• 暗号鍵は鍵暗号鍵で暗号化 (2層鍵管理 )• 暗号鍵と鍵暗号鍵は別々の場所に保存• 鍵は最小限の場所に保存• 鍵は使用期限を設け、一定期間で更新する• 鍵は安全に保存、配布する• 鍵へのアクセス /使用の記録を残して監査する
17Copyright©2017 NTT Corp. All Rights Reserved.
2.データの保護、暗号化と鍵の管理
要件3から考えるデータベースですべきこと• 以下の機能を持つデータベース外部の鍵管理ソフトウェアと連携すべき
2層鍵管理方式による鍵管理可能 システム全体のユーザ認証と連携した鍵管理機構可能 DB 管理者と鍵管理者は分けることができる(権限分掌) 鍵の利用状況を監査できる
https://docs.oracle.com/cd/E49329_01/
network.121/b71313/asotrans.htm
鍵交換時の再暗号化時にもメリットあり
2層鍵管理方式
このような要件を満たす鍵管理 OSS が欲しい…
18Copyright©2017 NTT Corp. All Rights Reserved.
2.データの保護、暗号化と鍵の管理
• 透過的暗号化機能 (TDE) が使えるとベスト! 実際の案件では需要大 現実の案件では AP にパスワードや鍵を埋め込むことが多い→セキュリティ的に大問題なので避けるべき→ AP への変更をなるべく抑えたい
クラウド上での DB利用拡大に伴い、 DB の暗号機能、 TDE の要望は多い。
19Copyright©2017 NTT Corp. All Rights Reserved.
3.ユーザーの識別、認証、認可、プロファイル管理
20Copyright©2017 NTT Corp. All Rights Reserved.
3.ユーザーの識別、認証、認可、プロファイル管理
PCI DSS 要件7,8 ざっくりまとめると• 識別: Identification
全てのユーザーに各個人を一意に識別できるユーザー ID を与える• 認証: Authentication
パスワード トークンデバイス 生体認証
• 認可: Authorization 業務上必要なユーザーに最小限の権限を与える。
• プロファイル管理→ユーザー ID の削除、凍結、接続断
移動 /退職者 一定数の認証失敗 長時間アクセスなし 一定時間アイドル状態
有効なパスワードの要件は…
21Copyright©2017 NTT Corp. All Rights Reserved.
3.ユーザーの識別、認証、認可、プロファイル管理
8.2.3 パスワードは7文字以上、数字と英文字を両方含むこと
22Copyright©2017 NTT Corp. All Rights Reserved.
3.ユーザーの識別、認証、認可、プロファイル管理
8.2.4 90日に一回パスワードを変更すること
23Copyright©2017 NTT Corp. All Rights Reserved.
3.ユーザーの識別、認証、認可、プロファイル管理
8.2.5 直近に使用した4つの lパスワードは使用できない
24Copyright©2017 NTT Corp. All Rights Reserved.
3.ユーザーの識別、認証、認可、プロファイル管理
要件7,8から考えるデータベースですべきこと• 以下の機能を持つデータベース外部のソフトウェアと連携すべき
システム全体のユーザ、権限を一括管理可能 鍵管理機能と連携可能 単純なパスワードの制限 / 有効期限設定可能 プロファイル管理可能
DB と連携してユーザアカウントの削除、凍結が行える 利用状況の監査可能
• ユーザ管理者と DB 管理者は分けるべき• 業務に応じた細かい単位の権限を持つロール、ユーザを作成する
AP から接続するユーザ、運用者、バックアップ、 DB 管理者など
このような機能を持つ OSS が欲しい…OpenLDAP ?
25Copyright©2017 NTT Corp. All Rights Reserved.
4.監査: Auditing
26Copyright©2017 NTT Corp. All Rights Reserved.
4.監査
PCI DSS 要件10 ざっくりまとめると• 以下を監査する
カード会員データ、監査証跡へのアクセス 管理者の全てのアクション 無効なアクセス試行 識別・認証に関わる操作
• 以下の情報を取得する ユーザ識別 イベントの種類 日時 成功 / 失敗 イベントの発生元 影響を受けるデータ、リソース ID
• 監査証跡を保護する 参照、変更権限の制限 監査ログファイルの変更の検知 監査証跡は変更が困難な一元管理ログサーバに保存
27Copyright©2017 NTT Corp. All Rights Reserved.
4.監査
要件10から考えるデータベースですべきこと• 前述の要件を満たす監査ログ出力機能を導入すべき
特権ユーザの完全な監査をどのように実現するかが課題• 以下を可能にするため監査ログ管理サーバにログを集約すべき
システム全体の監査ログを集約 監査ログは監査権限を持つユーザ以外にはアクセスさせない 監査者と DB 管理者は分ける 監査ログの監査
28Copyright©2017 NTT Corp. All Rights Reserved.
1〜4をまとめると
DB DBDB
監査ログ管理サーバ
DBA
DBA DBA
監査者
認証情報
監査ログ
識別、認証、認可、プロファイル管理
暗号鍵管理
鍵管理者
ユーザ管理者
鍵情報
暗号化データ
暗号化データ
暗号化データ
29Copyright©2017 NTT Corp. All Rights Reserved.
Oracle での対応
「狙われているのはデータ」──企業の機密情報、個人情報を効果的に守るには?http://www.atmarkit.co.jp/ait/articles/1511/24/news014_4.html
30Copyright©2017 NTT Corp. All Rights Reserved.
PostgreSQL での対応
以下の点を除けば PostgreSQL は十分に PCI DSS に対応できる。
• 権限分掌が不十分スーパーユーザ(特権ユーザ)権限無しでの運用が困難→PostgreSQL コミュニティでも改善を検討中
• DB外部の鍵管理機構との連携した暗号化機能がない• DB外部のユーザ管理機構と連携したプロファイル管理機能がない• 監査ログ出力機能がない
いずれも代替コントロールできる可能性が高い!詳しくは OSS センターにお問い合わせください。
TDE もほしい!
31Copyright©2017 NTT Corp. All Rights Reserved.
pgaudit について
PCI DSS の監査要件を満たす監査ログ出力機能をOSS センターで開発中。
https://github.com/ossc-db/pgaudit/tree/refactored
ポイント• 監査要件を満たす出力対象、出力情報。• スーパーユーザであっても監査設定を容易に変更すること
はできない。• Syslog 経由で監査ログをログ管理サーバに送信。• 性能への影響を極力軽減するログフィルタリング機能。
32Copyright©2017 NTT Corp. All Rights Reserved.
END