PR

 PCI DSSの要件6.3では,ソフトウエア・アプリケーションの開発において,開発ライフサイクル全体を通じて情報セキュリティの徹底を定めている。

6.3 ソフトウェア・アプリケーションは業界のベストプラクティスに基づいて開発し,ソフトウェアの開発ライフ・サイクル全体を通じて情報セキュリティを徹底する。

 つまり,分析・設計フェーズから実装・テストフェーズを経て,保守・運用フェーズに至るまでのシステム開発ライフサイクルにおける情報セキュリティを考慮する必要がある。その一例として,セキュリティ・パッチの適用やソフトウエアの設定変更は実行前にテストすること,開発環境,テスト環境,本番環境は分離することなどが定められている。表4に,PCI DSSの要求項目と要件項番を示す。

表4●開発ライフ・サイクルにおける情報セキュリティ
  要求項目 要件項番
1 すべてのセキュリティ・パッチとシステム・ソフトウェアの設定変更は実行前にテストする 6.3.1
2 開発環境,テスト環境,本番環境は分離する 6.3.2
3 開発環境,テスト環境,本番環境との間で役割を分離する 6.3.3
4 本番データ(有効なカード番号)をテスト/開発では使用しない 6.3.4
5 本番システムを稼動させる前にテスト・データやアカウントを取り除く 6.3.5
6 カスタム・アプリケーションのアカウント,ユーザー名,パスワードを,アプリケーションを実稼動させるか,顧客にリリースする前に取り除く 6.3.6
7 コーディングの脆弱性がないかどうか確認するために,本番または顧客へのリリースをする前に,カスタム・コードを見直す 6.3.7

 以下,開発ライフサイクルにおける情報セキュリティの実施内容について説明する。

6.3.1 すべてのセキュリティ・パッチとシステム・ソフトウェアの設定変更は実行前にテストする。

 各ベンダーが提供するセキュリティ・パッチを適用する際,直ちに本番環境へ適用するのではなく,あらかじめテスト環境下でセキュリティ・パッチを適用し,動作上の問題がないことを確認した上で本番環境へ適用しなければならない。各ベンダーが提供するセキュリティ・パッチは,あくまで自社製品の脆弱性を修正したものであり,製品を利用する企業のシステム環境下での動作を保証するものではないためである。そのため,テスト環境下でセキュリティ・パッチの適用,システム全体の動作検証が必要となる。

6.3.2 開発環境、テスト環境、本番環境は分離する。
6.3.3 開発環境、テスト環境、本番環境との間で役割を分離する。
6.3.4 本番データ(有効なカード番号)をテスト/開発では使用しない。
6.3.5 本番システムを稼動させる前にテスト・データやアカウントを取り除く。

 ソフトウエア・アプリケーションを開発する場合,開発環境,テスト環境,本番環境をそれぞれ独立した環境で用意する必要がある。そのうえで,各環境の役割を明確に分離し,本番データを開発・テスト環境で使用したり,本番環境に開発・テストで使用したテスト・データをそのまま残すようなことを防止しなければならない。これは,開発終了後の「バグの修正」「機能の追加」などの運用・保守段階でも同様に注意が必要である。

 PCI DSSでは,社内業務におけるソフトウエア開発のライフサイクルを定めているが,2008年4月にカスタマイズ不要のパッケージの支払いアプリケーションに対するセキュリティ基準を定めたPA-DSS(Payment Application Data Security Standard)がリリースされた。支払いアプリケーションを開発するソフトウエア・ベンダーは,PA-DSSに準拠することが求められる。

 要件6.4では,セキュリティ・パッチの適用およびシステム・ソフトウエアの設定変更を変更管理手順に従って実施することを定めている。

6.4 すべてのシステムおよびソフトウェア設定を変更する場合,変更管理手順に従う。手順には次の項目が含まれている必要がある。
6.4.1 影響の文書化
6.4.2 管理職による適切な承認
6.4.3 運用機能のテスト
6.4.4 回復手順

 カード会員データを扱うすべてのシステムで設定変更する場合,安全で確実に変更を実施するための標準化された手順を確立する必要がある。変更管理手順を確立するにあたり,ITILを活用するのもよいだろう。ITILで定められる変更管理は,システムの変更の許可と実装を変更管理プロセスに基づき確実に行うことであり,PCI DSSの要件を満たしている。ITILの変更管理プロセスを取り入れた変更管理ツールを活用することも有用である。

 また,PCI DSSでは,手順を確立するにあたって四つの要件が含まれていることを求めている。表5で,それぞれの要件について説明する。

表5●変更管理における要件
  要求項目 要求内容
1 影響の文書化 システム変更時の変更管理文書に顧客への影響に関する記述が含まれていることを確認する
2 管理職による適切な承認 システム変更要件について,管理職による適切な承認が存在することを確認する
3 運用機能のテスト システム変更後に,運用機能を検証するためのテストが実行されたことを確認する
4 回復手順 システム変更を失敗した場合の対応として,回復手順が用意されていることを確認する

 以上の変更管理プロセスが確実に適用されるように運用体制を整備し,変更管理プロセスを文書化して維持・管理する必要がある。参考までに表6に,PCI DSSで作成が求められている文書について示す。

表6●PCI DSSにおいて作成が求められている文書類
  作成が求められている文書の名称 要件項番
1 セキュリティ・ポリシー 12.1
2 データの保管と廃棄に関するポリシー 3.1
3 ファイアウォール設定基準 1.1
4 重要技術の使用ポリシー 12.3
5 システム・コンポーネント設定基準 2.2
6 脆弱性対策基準 6.2
7 暗号鍵管理手順書 3.6
8 システムおよびソフトウェア設定変更管理手順書 6.4
9 従業員識別に関する手順書 9.2
10 権限の付与に関する手順書 10.1
11 運用セキュリティ手順書 12.2
12 セキュリティ事故対応手順書 12.5.3
13 インシデント対応計画 12.9
14 業務上の制約の記述書 3.4
(代替コントロール)

 PCI DSSにおいて作成が求められている文書類は,概ねISMSで作成が求められている文書類と同類であるが,ファイアウオール設定基準(要件1.1)などの技術的に詳細な項目が要求事項に含まれている点に特徴がある。

表7●関連製品
分野 メーカー/ベンダー 製品/サービス
変更管理ツール IBM Tivoli Change and Configuration Management Database(CCMDB)
日立製作所 JP1

宇都 政樹
ネットワンシステムズ セキュリティ事業推進本部 コンサルティング部 第2チーム
大手ITベンダー傘下のグループ企業を経て,2008年1月,ネットワンシステムズ入社。前職では,ネットワーク・エンジニアとして,大手総合商社のネットワーク・インフラの構築・維持・保守を担当。現在はセキュリティ・コンサルタントとして,主に企業向けネットワーク脆弱性検査サービスに従事。