オフショア開発へのPCIコンプライアンス
私は、多数の金融商品を生産するオフショア開発チームを運営しています。現在、PCIコンプライアンスを取得するために必要な作業を計画しています。
オフショアチームは、スタッフを直接雇用するアウトソーシングオペレーションによって運営されています。言い換えれば、開発者は私たちに直接雇用されているのではなく、私たちの会社のプロジェクトのリソースにすぎません。
当社のインフラストラクチャはすべて英国ベースです（ソース管理、開発マシンなど）。開発者/テスターは、リモートデスクトップを使用する必要のある開発環境にオフショアします。
この設定で、PCIの観点から懸念すべきことはありますか？
まず第一に、頑張ってください。
より具体的な回答を提供できるように、どのセクションを満たそうとしているのかを正確に把握しておくとよいでしょう。
PCIは、主に職務の分離に関係しています。 （2番目に関係するのは監査人の意見ですが、それは別の問題です）。つまり、開発者はQAにアクセスできないようにし、QAは本番環境にアクセスできないようにする必要があります。ここでのもう1つの考慮事項は、コードを本番環境にプロモートするために使用するソフトウェアライフサイクルです。私たちはMicrosoftSDLCに基づいており、ぜひご覧になることをお勧めします。
基本的にはこのようなものに従います。
- チケットが届き、「要件収集」のためにba/devに割り当てられます
- セキュリティ評価が行われます。これはアンケートの形式です。基本的に、コードはカード処理などに関係するものに触れますか？.
- セキュリティアンケートの結果に基づいて、特定のセキュリティ要件が決定されます。つまり、コードレビューが必要ですか？ （もちろん外部）。等
職務の分離は次のようになります。
- コードは、QAがチェックアウト/ビルドするためにソース管理システムで利用できるようになります。
- QAはコードを「テスト」します。これには、アンケート結果によるセキュリティテストが含まれる場合があります。
- 必要に応じて、サードパーティがコードレビューを実施します。選択できるサードパーティはたくさんあります
- QAは、ドキュメントとビルドされたバイナリを本番サポートチームに渡します
- 生産サポートが実装されます。
あなたが見つけるものは、PCI「ゾーン」を作成したいと思うでしょう。 IE：高リスクゾーンとは、クレジットカードを扱うシステム/プロセスに接触/相互作用するコードのことです。明らかに、この領域での変更には、サードパーティによるコードレビューが必要になります（特に、開発を管理していない場合など）。次に、セカンダリゾーンがあります。この領域で変更されたコードは、プライマリゾーンで変更されたコードと同じ厳密さを必要としません。
上記は、PCI要件のいくつかのサブセクションのみを実際に扱っています。本当に、PCIは標準とそれらの標準の文書化に関するものであることを覚えておく必要があります。 「ベストプラクティス」を選択し、そのベストプラクティスに準拠していることを示します。コードレビューは、この分野での大きな勝利です。
あなたの場合の監査人は、あなたのソースコードに誰がアクセスできるか、そして彼らがどのようにソースコードにアクセスできるかを心配するかもしれません。もちろん、誰かがスクリーンショットを撮ったり、コードを手でコピーしたりするのを防ぐことはできませんが、誰かがすべてのコードをUSBにコピーしてそのままにしておくことができないように、いくつかのコントロールを配置したい場合があります。
私はこれに関する法律の専門家ではありませんが、主要なオンライン小売業者をPCIコンプライアンスに適合させるための技術リーダーでした。
だから私の2ペニーワースのために：
PCIコンプライアンスは、データ保護に関するものです。
基本的に-開発者に個人データへのアクセスを許可しないでください。これは、社内でも社外でも適用されます。開発環境でライブデータを使用する必要がある場合は、最初にすべてのクレジットカード番号を削除し、顧客名、住所の詳細、電話番号などを変更して、ライブデータをサニタイズします。