PCI DSS準拠のためにデータベースができること
要件1:カード会員データを保護するために、ファイアウォールをインストールして構成を維持すること
ファイアウォールによってすべてのネットワークトラフィックを検査し、指定されたセキュリティ基準を満たさない通信をブロックすることは不可欠なことですが、従来のネットワークファイアウォールだけでなく、「データベースファイアウォール」というアプローチも注目されています。
IBMが2009年末にGuardiumを買収し、2010年5月にはオラクルがSecerno買収を発表するなど、データベースファイアウォールベンダの取り込みが活発になっています。これらのベンダのファイアウォール製品は、いわゆるパケットキャプチャ方式でSQLコマンドのモニタリングを行い、不正な攻撃からデータベース内のカード会員データを保護するものです。
Webサーバを経由した攻撃だけでなく、企業内部からの不正なリクエストを含むさまざまな不正データベースクエリーを検知し、内部からのデータベース侵害も防御できるのがデータベースファイアウォールの特徴です。上記の2製品以外では、同じ方式によるImperva、Chakraなどがあります。
要件3:保存されるカード会員データを保護すること
カード会員データを保護するためには、まずカード会員データがどのデータベースに、どのように格納されているかをしっかりと管理し、コントロールされなければなりません。
データベースセキュリティ製品の脆弱性評価機能は、データベースインスタンスを自動的に検出し、その用途や保持しているデータの内容をしっかりと把握し、すべてのデータベースをセキュリティのコントロール下に置くことができます。特にデータベースインスタンスのテーブルやデータベース構造をチェックし、クレジットカード番号が格納されていることを認識できる機能を持つ製品もあります。これを利用すれば、どのデータベースインスタンスの、どのテーブル、どのカラム、フィールドがクレジットカード番号であるかをきちんとリストアップすることができます。
クレジットカード番号が格納されているテーブルを明確に把握できれば、そのテーブルに対するあらゆるアクティビティをモニタリングし、アクセスログを取得するとともに監査を実施する仕組みを構築できます。それゆえ、保存されるカード会員データを保護するという要件において、データベースセキュリティ製品の持つモニタリングおよび監査機能を大いに活用することが可能です。
また、PCI DSSでは保管データの暗号化、少なくともカード番号は判読不可能にしなければならないと指示していますが、実際にはデータをすべて暗号化できない状況もあり得ます。そうした場合でも、データアクセスのモニタリングおよび監査を確実に実施できる仕組みを実装することが有効な代替策として認められるとされています。
要件6:安全性の高いシステムとアプリケーションを開発し、保守すること
要件6で具体的に述べられていることは、
- すべてのコンポーネントとソフトウェアにベンダ提供の最新セキュリティパッチを迅速に適用すること
- インターネット上の無料で利用できる警告サービスに加入するなど、新たに発見された脆弱性を特定するためのプロセスを確立すること
- 業界のベストプラクティスに基づいたアプリケーションを開発し、ソフトウェア開発ライフサイクル全体を通して情報セキュリティを実現すること
という3点です。これらの要件に対して、データベースセキュリティ製品のリスク診断機能およびモニタリング機能を活用することによって、次のような点をカバーできます。
- ベンダ供給のセキュリティパッチが確実に適用されているかを確認する
- デフォルト設定を使用していないかを確認する
- 新しく見つかったセキュリティ脆弱性を特定するプロセスを確立する
- アカウント、IDの設定状況が正しいか監査し、特権ユーザーにはシステムの管理もしくは開発業務に必要な最低限の権限だけを付与する
- 開発環境、テスト環境、本番環境で役割を分離する(アカウントの職務分掌)
要件7:カード会員データへのアクセスを、業務上必要な範囲内に制限すること
具体的には、特権ユーザーに関するアクセス権が、職務の実行に必要な最小限の特権に制限されていること。また、その特権の付与は、個人の職種と職能に基づいていることです。
データベースセキュリティ製品では、データベース内での権限設定がポリシー通りに設定がされているかどうかを明らかにし、特権ユーザーカウントなどによる業務上必要のないアクセスを見張ることが可能です。
要件10:ネットワークリソースおよびカード会員データへのすべてのアクセスを追跡および監視する
要件10は、カード会員データへのすべてのアクセスおよび監査ログを毎日レビューするとともに、カード会員データにアクセスしたアクセスログを監査ログとして保全し、フォレンジックできることを強制しています。
データベースセキュリティ製品は、これに対して次のような情報を含むアクセスログを取得し、保全することができます。
誰が | データにアクセスしたユーザー名(OSユーザー、DBユーザー、Web認証ユーザーなど) |
---|---|
いつ | 実行日時の記録(タイムスタンプ) |
何を | 処理内容(SELECT、INSERT、UPDATE、DELETEなど) |
どのように | 参照範囲(対象データ、件数、更新内容など) |
どのような手段で | 使用したアプリケーションやツール |
どこから | マシン名やIPアドレス |
要件10は、監査証跡が確保されていることを求めています。データベースセキュリティ製品では、データベース監査ログをデータベース側から完全に隔離して保全します。これによりDBAアカウントによる監査ログの削除や改ざんなどの行為から監査ログを守り、さらにアーカイブ機能によって日々増えていく監査ログの運用を容易にすることができます。
2/3 |
Index | |
PCI DSS準拠のためにデータベースができること | |
Page 1 完全対応の期限が迫るPCI DSS データベース監査で対応するPCI DSSの要件 |
|
Page 2 要件1:カード会員データを保護するために、ファイアウォールをインストールして構成を維持すること 要件3:保存されるカード会員データを保護すること 要件6:安全性の高いシステムとアプリケーションを開発し、保守すること 要件7:カード会員データへのアクセスを、業務上必要な範囲内に制限すること 要件10:ネットワークリソースおよびカード会員データへのすべてのアクセスを追跡および監視する |
|
Page 3 DBセキュリティ製品は体制確立の一手段として活用可能 |
ここがポイント! DBセキュリティの実装 |
- Oracleライセンス「SE2」検証 CPUスレッド数制限はどんな仕組みで制御されるのか (2017/7/26)
データベース管理システムの運用でトラブルが発生したらどうするか。DBサポートスペシャリストが現場目線の解決Tipsをお届けします。今回は、Oracle SE2の「CPUスレッド数制限」がどんな仕組みで行われるのかを検証します - ドメイン参加後、SQL Serverが起動しなくなった (2017/7/24)
本連載では、「SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は、「ドメイン参加後にSQL Serverが起動しなくなった場合の対処方法」を解説します - さらに高度なSQL実行計画の取得」のために理解しておくべきこと (2017/7/21)
日本オラクルのデータベーススペシャリストが「DBAがすぐ実践できる即効テクニック」を紹介する本連載。今回は「より高度なSQL実行計画を取得するために、理解しておいてほしいこと」を解説します - データベースセキュリティが「各種ガイドライン」に記載され始めている事実 (2017/7/20)
本連載では、「データベースセキュリティに必要な対策」を学び、DBMSでの「具体的な実装方法」や「Tips」などを紹介していきます。今回は、「各種ガイドラインが示すコンプライアンス要件に、データベースのセキュリティはどのように記載されているのか」を解説します
|
|