Database Security for PCI DSS

Copyright©2017 NTT Corp. All Rights Reserved.

Database Security for PCIDSS- NTT Database Summit -

大山真実 (@ooyamams1987) – NTT OSS センター

　

https://twitter.com/ooyamams1987

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


セキュリティって必要？

必要です！ 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/

引用：このデス・スター破壊のエピソードを、セキュリティの観点から詳しく見ていきましょう。～省略～また、最終兵器の設計図がそっくりそのまま漏洩して敵の手に渡ったことも、陥落の真の要因ではありません。もちろん大失態ではありますが。要は「情報が知られなければ安全」という法則は成り立たない、のです。

「完璧なセキュリティ対策」は存在しない。多層防御の考え方が大事！

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 ExpressDiscoverJCBMasterCardVISA

が共同で設立した PCI SSC(Payment Card Industry Security Standards Council) によって運用、管理されています。

クレジットカードを扱わないシステムであったとしても、セキュリティについて考える時は、この PCI DSS を参考にすることができる。

http://www.jcdsc.org/pci_dss.php より

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

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

毎年１００億円を超える被害額


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/cd/E49329_01/

network.121/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 DBDB

監査ログ管理サーバ

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

Software

Database Security for PCI DSS