ここがポイント！ DBセキュリティの実装（5）

PCI DSS準拠のためにデータベースができること

 

フォーティネットジャパン株式会社
セールスエンジニアリング部 シニアコンサルティングSE
成田泰彦
2010/8/2

DBセキュリティ製品は体制確立の一手段として活用可能

　PCI DSS遵守を実現するためには、手順、プロセス、および技術的制御の組み合わせが必要になります。どのようなベンダも、単独ではPCI DSSの12要件をすべてカバーできる解決法を提供することは不可能です。そのような中で、カード会員データ保護にかかわる要件については、データベースセキュリティ製品が大いに役に立つことが期待でき、費用対効果に優れた実践的なソリューションであるといえます。

　実際には、今回述べた項目以外の要件に対してデータベースセキュリティ製品を広く適用することが可能です（表2参照）。また、今後PCI DSSには新たな要件が追加されることも予想されます。そうしたことに備えて、いまからでもデータベースセキュリティ製品を導入して体制を確立することをお勧めします。

●表2 PCI DSSの要件とDBセキュリティ対策製品で検出／改善すべき内容
  PCI DSS要件　 DBセキュリティ製品リスク診断機能で検出／改善すべき内容
要件2 システムパスワードおよびほかのセキュリティパラメータにベンダ提供のデフォルト値を使用しないこと。
2.1 システムをネットワーク上に導入する前に、ベンダ提供のデフォルト値を必ず変更する（パスワード、簡易ネットワーク管理プロトコル（SNMP）コミュニティ文字列の変更、不必要なアカウントの削除など）。
  • デフォルトポートを変更する
  • デフォルトで作成される不要なアカウントを削除または無効化する
  • デフォルトパスワードを変更する
  • サンプルDBを削除する
  • パブリックなロールから不要な権限を削除する
2.2.4 スクリプト、ドライバ、機能、サブシステム、ファイルシステム、不要な Web サーバなど、不要な機能をすべて削除する。
  • 使用しないDBMS機能、オブジェクトなどは削除または無効化する
  • DBサーバのOSレベルにおいても、不要な機能、サービスを削除する
要件6 安全性の高いシステムとアプリケーションを開発し、保守すること。
6.1 すべてのシステムコンポーネントとソフトウェアに、ベンダ提供の最新セキュリティパッチを適用する。重要なセキュリティパッチは、リリース後 1カ月以内にインストールする。【注1】
  • 最新のDBMSのセキュリティパッチを適用する
6.2 新たに発見された脆弱性を特定するためのプロセスを確立する（インターネット上で無料で入手可能な警告サービスに加入するなど）。新たな脆弱性の問題に対処するために、PCI DSS 要件 2.2 で要求されているとおりに構成基準を更新する。
  • DBに関するセキュリティの事故や脆弱性の最新情報を常に収集する
6.3.1.5 適切な役割ベースのアクセス制御（RBAC）の検証
  • ロール、または各アカウント別に、最低でもテーブル、可能であれば列（カラム）単位でアクセス制御する
6.3.5 本番環境システムがアクティブになる前にテストデータとテストアカウントを削除する。
  • DB内のテストデータ、テスト用DBアカウントを削除する
要件7 カード会員データへのアクセスを業務上の必要な範囲内に制限すること。
7.1.1 特権ユーザーIDに関するアクセス権が、職務の実行に必要な最小限の特権に制限されていること。
  • 管理者用DBアカウントについて、DBへのアクセス要件に基づき、必要最低限のアクセス権限を付与する
  • 管理者権限は、DBアカウントを限定して付与する
7.1.2 特権の付与は、個人の職種と職能に基づくこと。
  • 役割ごと、利用者ごとに、適切な権限を持ったアカウントを整理する
  • DB管理者アカウントは特定の者しか、利用できないようにする
  • DB管理者アカウントを担当者別に割り当てる。
7.2.2 職種と職能に基づく、個人への特権の付与。
  • 役割ごと、利用者ごとに、適切な権限を持ったアカウントを整理する
  • DB管理者アカウントは特定の者しか、利用できないようにする
  • DB管理者アカウントを担当者別に割当てる
要件8 コンピュータにアクセスする利用者ごとに個別のID を割り当てること
8.5.5 少なくとも90日ごとに非アクティブのユーザーアカウントを削除／無効化する。
  • 少なくとも90日ごとに不要なDBアカウントを削除、または無効化する
8.5.6 リモート保守のためにベンダが使用するアカウントは、必要な期間のみ有効にする。
  • 一時的な利用者にはその都度、DBアカウントに対し一時的なパスワードを与える
8.5.9 少なくとも90日ごとにユーザーパスワードを変更する。
  • 少なくとも90日ごとにDBアカウントのパスワードを変更する
8.5.13 最大6回の試行後にユーザーIDをロックアウトして、アクセス試行の繰り返しを制限する。
  • DBMSの機能により、ロックアウトを設定する
要件11 セキュリティ・システムおよび管理手順を定期的にテストすること
11.2 内部および外部ネットワークの脆弱性スキャンを少なくとも四半期に一度およびネットワークでの大幅な変更（新しいシステムコンポーネントのインストール、ネットワークトポロジの変更、ファイアウォール規則の変更、製品アップグレードなど）後に実行する。【注2】
  • DBサーバ（OSレベル、DBMS製品）、およびデータが格納されるインスタンスに対して、少なくとも四半期に一度脆弱性をスキャンする
11.3.2 アプリケーション層のペネトレーションテストの実施
  • DBサーバ（OSレベル、DBMS製品）、およびデータが格納されるインスタンスに対して、少なくとも年に一度ペネトレーションテストを実施する
要件12 情報セキュリティに関するポリシーを整備すること
12.1.2 脅威、脆弱性、結果を識別する年に1度のプロセスを正式なリスク評価に含める。
  • DBセキュリティ対策の有効性を評価する
12.1.3 レビューを少なくとも年に1度含め、環境の変化に合わせて更新する。
  • 環境の変化に合わせてDBアカウントを見直す
  • 不適切なアカウントや権限を再度整理する
12.5.4 追加、削除、変更を含め、ユーザーアカウントを管理する。
  • DBアカウント管理する
  • DB利用者の整理
  • DBアカウントの整理


【注1】
組織は、パッチインストールの優先順位を付るために、リスクに基づくアプローチの適用を検討できる。例えば、重要なインフラストラクチャ（一般に公開されているデバイス、システム、データベースなど）に重要性の低い内部デバイスよりも高い優先順位を付けることで、優先順位の高いシステムおよびデバイスは 1 カ月以内に対処し、重要性の低いシステムおよびデバイスは 3 カ月以内に対処するようにする。

【注2】
四半期に一度の外部の脆弱性スキャンは、PCI（Payment Card Industry）セキュリティ基準審議会（PCI SSC）によって資格を与えられた Approved Scanning Vendor（ASV）によって実行される必要があります。ネットワーク変更後に実施されるスキャンは、会社の内部スタッフによって実行することができます。

筆 者 略 歴

成田泰彦 （なりた　やすひこ）
フォーティネットジャパン株式会社
セールスエンジニアリング部 シニアコンサルティングSE

株式会社アシストにてRDBMSを使ったアプリケーション開発の技術支援エンジニアとしての経験を基に、後年ではシングルサインオン・アクセスコントロールシステムの構築支援・コンサルタントを担当。

その後アイピーロックスジャパン、日本オラクルにてDBセキュリティ、ID管理セキュリティソリューションをプリセールスエンジニアおよびセールスマンとして担当。

さらにはDBセキュリティコンソーシアムの研究員も務めるなどして、ここ最近の約10年間はセキュリティソリューションにどっぷり漬かってきている。

現在はフォーティネットジャパンにてコンサルタントとして奮闘中。つい最近ゴルフを始めたばかりで、下手くそな自分と一緒にラウンドしていただける忍耐力の強い方を募集中。
前のページへ 3/3  

Index
PCI DSS準拠のためにデータベースができること

Page 1
完全対応の期限が迫るPCI DSS
データベース監査で対応するPCI DSSの要件

Page 2
要件1：カード会員データを保護するために、ファイアウォールをインストールして構成を維持すること
要件3：保存されるカード会員データを保護すること
要件6：安全性の高いシステムとアプリケーションを開発し、保守すること
要件7：カード会員データへのアクセスを、業務上必要な範囲内に制限すること
要件10：ネットワークリソースおよびカード会員データへのすべてのアクセスを追跡および監視する
→
 Page 3
DBセキュリティ製品は体制確立の一手段として活用可能

ここがポイント！ DBセキュリティの実装


Database Expert フォーラム 新着記事
＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

注目のテーマ

Database Expert 記事ランキング

本日月間
＠IT