PCI DSS要件6.4.2開発/テスト環境間の義務の分離
6.4.2開発/テスト環境に割り当てられた担当者と本番環境に割り当てられた担当者の間で職務の分離はありますか？
ここでの職務の分離とはどういう意味ですか？ http://www.sans.edu/research/security-laboratory/article/it-separation-duties という意味ですか？ 「テスト環境と本番環境の間」という定式化は本当に混乱します。テストと本番環境では異なるシステム管理者がいる必要があるという意味ですか？それとも、開発者が本番環境にアクセスできないようにする必要があるということですか？
もちろん、判断を下す際には常にQSAの判断を受け入れることが最も賢明ですが、社内でのコンプライアンス作業中は、以下を確認することをお勧めします PCI-DSSのナビゲート：要件の意図の理解 要件によって混乱した場合はいつでも文書化してください。
そのドキュメントの32ページを見ると、要件6.4.2に関して次のように記述されています。
運用環境とカード会員データにアクセスできる担当者の数を減らすと、リスクが最小限に抑えられ、アクセスをビジネスの知る必要のある個人に限定することができます。
この要件の目的は、開発/テスト機能を本番機能から分離することです。たとえば、開発者は、開発環境で使用するために昇格された特権を持つ管理者レベルのアカウントを使用し、本番環境へのユーザーレベルのアクセス権を持つ別のアカウントを持っている場合があります。
1人の個人が複数の役割を実行する環境（たとえば、アプリケーション開発と本番システムへの更新の実装）では、1人の個人が独立したチェックポイントなしにプロセスをエンドツーエンドで制御できないように、職務を割り当てる必要があります。たとえば、開発、承認、監視の責任を個別の個人に割り当てます。
だから、最も厳密な読書によって、はい。開発者は開発システムへのアクセス権を持ち、本番環境へのユーザーロールアクセス権を持っている場合がありますが、実際には別の個人が本番環境のアプリケーションのインストール/管理とシステム管理を実行します。このすべての本当の目的は、前の段落で説明したように、サービスのエンドツーエンドの管理制御を持つ単一の個人が存在しないことです。彼らがwantとは、プロセスを可視化する複数の人であり、1人の人が開発に変更を加えて問題のない本番環境に投入することはできません。
したがって、可能な場合はいつでも、公式の助言は写真で要約するのが最善です。
ただし、真剣な実践では、プロセスを文書化し、最終的にはQSAによって適切に処理されるようにしながら、監査や分離を管理する最善の方法を理解する必要があります。
PCI-DSSは非常に広い（そして解釈的な）ルールのセットです-したがって、この回答はおそらくQSA（意見/異端以外のもの）によって最もよく回答されます。
ただし、私たちの解釈では、環境は分離する必要がありますが、必ずしも物理的に分離したハードウェア上にある必要はありません。 VPS /仮想化の使用は、物理サーバーを安全に分割し、「各役割のマシン」ルールに該当せずにPCIコンプライアンスを維持するための優れた方法です。
この特定のアイテムの問題は次のとおりです。言い回しだけで評価すると、異なる環境には異なる人々が必要であることは明らかです。ただし、多くの企業やQSAは、これが一方通行であるとさえ信じています。開発へのアクセス権があり、開発を行う場合、本番環境へのアクセス権はありません。
これに関する問題は、生産へのアクセス権を持つ個人も開発へのアクセス権を持つべきではないということです。開発環境へのアクセスにより、環境内のデータを保護するために実施されているセキュリティ対策をリバースエンジニアリングすることができます。したがって、コードとデータのモデルを見ると、2つをすべてのレベルで分離する必要があります。コードにアクセスできる人はデータにアクセスできません。データにアクセスできる人はコードにアクセスできません。開発環境は、他の企業の運用から分離する必要があります。本番DBAは、開発DBにアクセスしたり、制御したりしてはなりません。