"K8S合规PCI-CSS：支付卡行业数据安全标准要求和测试程序 v4.0"

需积分: 0 136 浏览量更新于2024-01-11 收藏 4.37MB PDF 举报

K8S合规PCI-CSS（Payment Card Industry Data Security Standard）是一个关于支付卡行业数据安全标准的规范。该标准的最新版是v4.0，发布于2022年3月。本文主要对该标准进行了总结，全文共计2000字。 PCI-CSS标准的目的是确保支付卡行业中的各个参与方在处理和保存支付卡数据时采取了必要的安全措施，以保护持卡人的个人信息和交易数据。这个标准适用于所有接受、处理、存储或传输支付卡数据的实体，包括商户、服务提供商、支付网关和银行等。 PCI-CSS标准的v4.0版在之前的版本基础上进行了一些重要的更新和改进。首先，该标准将之前的两个文件合并为一个，以减少冗余和重复。这个合并使得标准更加简化和易于理解，便于实施和审计。其次，新的版本针对最新的安全威胁和攻击技术进行了更新，以保持与时俱进。此外，新的标准还提供了更多的指导和建议，帮助实体更好地满足合规要求。 PCI-CSS标准的要求主要包括以下几个方面：建立和维护安全策略、保护存储的支付卡数据、实施强密码机制、保护系统和网络安全、实施访问控制、监控和记录活动、保护应用程序开发过程、进行安全漏洞管理、实施物理安全措施等。通过遵守这些要求，实体可以最大程度地降低支付卡数据泄露和非法使用的风险。为了验证实体的合规性，PCI-CSS标准提供了测试程序和评估工具。这些工具可以帮助实体进行自我评估和审计，发现潜在的安全漏洞和风险，并采取相应的措施进行修复和改进。除了自我评估外，实体还需要定期进行外部审计，由第三方审核机构进行验证和认证。实施和维护PCI-CSS合规性需要各个参与方的共同努力。除了实体本身的责任外，相关的行业组织和监管机构也需要提供指导和支持。此外，合规性的实现还需要各方的持续投入和资源支持。总而言之，K8S合规PCI-CSS是一个关于支付卡行业数据安全的重要标准。通过遵守这个标准的要求，实体可以提高支付卡数据的安全性，减少数据泄露和非法使用的风险。然而，实现和维护合规性需要各方的共同努力和持续投入。希望该标准能够推动支付卡行业的安全发展，保护持卡人的权益。

Payment Card Industry Data Security Standard: Requirements and Testing Procedures, v4.0 March 2022

Annual PCI DSS Scope Confirmation

The first step in preparing for a PCI DSS assessment is for the entity to accurately determine the scope of the review. The assessed entity

must confirm the accuracy of their PCI DSS scope according to PCI DSS Requirement 12.5.2 by identifying all locations and flows of account

data, and identifying all systems that are connected to or, if compromised, could impact the CDE (for example, authentication servers, remote

access servers, logging servers) to ensure they are included in the PCI DSS scope. All types of systems and locations should be considered

during the scoping process, including backup/recovery sites and fail-over systems.

The minimum steps for an entity to confirm the accuracy of their PCI DSS scope are specified in PCI DSS Requirement 12.5.2. The entity is

expected to retain documentation to show how PCI DSS scope was determined. The documentation is retained for assessor review and for

reference during the entity’s next PCI DSS scope confirmation activity. For each PCI DSS assessment, the assessor validates that the entity

accurately defined and documented the scope of the assessment.

Note: This annual confirmation of PCI DSS scope is defined at PCI DSS Requirement at 12.5.2 and is an activity expected to be performed by

the entity. This activity is not the same, nor is it intended to be replaced by, the scoping confirmation performed by the entity’s assessor during

the assessment.

Segmentation

Segmentation (or isolation) of the CDE from the remainder of an entity’s network is not a PCI DSS requirement. However, it is strongly

recommended as a method that may reduce the:

 Scope of the PCI DSS assessment

 Cost of the PCI DSS assessment

 Cost and difficulty of implementing and maintaining PCI DSS controls

 Risk to an organization relative to payment card account data (reduced by consolidating that data into fewer, more controlled locations)

Without adequate segmentation (sometimes called a "flat network"), the entire network is in scope for the PCI DSS assessment. Segmentation

can be achieved using a number of physical or logical methods, such as properly configured internal network security controls, routers with

strong access control lists, or other technologies that restrict access to a particular segment of a network. To be considered out of scope for

PCI DSS, a system component must be properly segmented (isolated) from the CDE, such that the out-of-scope system component could not

impact the security of the CDE, even if that component was compromised.

An important prerequisite to reduce the scope of the CDE is a clear understanding of business needs and processes related to the storage,

processing, and transmission of account data. Restricting account data to as few locations as possible by eliminating unnecessary data and

consolidating necessary data may require reengineering of long-standing business practices.

Payment Card Industry Data Security Standard: Requirements and Testing Procedures, v4.0 March 2022

Wireless

If wireless technology is used to store, process, or transmit account data (for example, wireless point-of-sale devices), or if a wireless local

area network (WLAN) is part of or connected to the CDE, the PCI DSS requirements and testing procedures for securing wireless

environments apply and must be performed.

Rogue wireless detection must be performed per PCI DSS Requirement 11.2.1 even when wireless is not used within the CDE and the entity

has a policy that prohibits the use of wireless technology within its environment. This is because of the ease with which a wireless access

point can be attached to a network, the difficulty in detecting its presence, and the increased risk presented by unauthorized wireless devices.

Before wireless technology is implemented, an entity should carefully evaluate the need for the technology against the risk. Consider

deploying wireless technology only for non-sensitive data transmission.

Encrypted Cardholder Data and Impact on PCI DSS Scope

Encryption of cardholder data with strong cryptography is an acceptable method of rendering the data unreadable according to PCI DSS

Requirement 3.5. However, encryption alone is generally insufficient to render the cardholder data out of scope for PCI DSS and does not

remove the need for PCI DSS in that environment. The entity’s environment is still in scope for PCI DSS due to the presence of cardholder

data. For example, for a merchant card-present environment, there is physical access to the payment cards to complete a transaction and

there may also be paper reports or receipts with cardholder data. Similarly, in merchant card-not-present environments, such as mail-

order/telephone-order and e-commerce, payment card details are provided via channels that need to be evaluated and protected according to

PCI DSS.

The following are each in scope for PCI DSS:

 Systems performing encryption and/or decryption of cardholder data, and systems performing key management functions,

 Encrypted cardholder data that is not isolated from the encryption and decryption and key management processes,

 Encrypted cardholder data that is present on a system or media that also contains the decryption key,

 Encrypted cardholder data that is present in the same environment as the decryption key,

 Encrypted cardholder data that is accessible to an entity that also has access to the decryption key.

Payment Card Industry Data Security Standard: Requirements and Testing Procedures, v4.0 March 2022

Note: A PCI-listed P2PE solution can significantly reduce the number of PCI DSS requirements applicable to a merchant’s cardholder data

environment. However, it does not completely remove the applicability of PCI DSS in the merchant environment.

Encrypted Cardholder Data and Impact to PCI DSS Scope for Third-Party Service Providers

Where a third-party service provider (TPSP) receives and/or stores only data encrypted by another entity, and where they do not have the

ability to decrypt the data, the TPSP may be able to consider the encrypted data out of scope if certain conditions are met. This is because

responsibility for the data generally remains with the entity, or entities, with the ability to decrypt the data or impact the security of the

encrypted data. Determining which party is responsible for specific PCI DSS controls will depend on several factors, including who has access

to the decryption keys, the role performed by each party, and the agreement between parties. Responsibilities should be clearly defined and

documented to ensure both the TPSP and the entity providing the encrypted data understand which entity is responsible for which security

controls.

As an example, a TPSP providing storage services receives and stores encrypted cardholder data provided by customers for back-up

purposes. This TPSP does not have access to the encryption or decryption keys, nor does it perform any key management for its customers.

The TPSP can exclude any such encrypted data when determining its PCI DSS scope. However, the TPSP does maintain responsibility for

controlling access to the encrypted data storage as part of its service agreements with its customers.

Responsibility for ensuring that the encrypted data and the cryptographic keys are protected according to applicable PCI DSS requirements is

often shared between entities. In the above example, the customer determines which of their personnel are authorized to access the storage

media, and the storage facility is responsible for managing the physical and/or logical access controls to ensure that only persons authorized

by the customer are granted access to the storage media. The specific PCI DSS requirements applicable to a TPSP will depend on the

services provided and the agreement between the two parties. In the example of a TPSP providing storage services, the physical and logical

access controls provided by the TPSP will need to be reviewed at least annually. This review could be performed as part of the merchant’s

PCI DSS assessment or, alternatively, the review could be performed, and controls validated, by the TPSP with appropriate evidence provided

to the merchant. For information about “appropriate evidence,” see Options for TPSPs to Validate PCI DSS Compliance for TPSP Services

that Meet Customers’ PCI DSS Requirements.

As another example, a TPSP that receives only encrypted cardholder data for the purposes of routing to other entities, and that does not have

access to the data or cryptographic keys, may not have any PCI DSS responsibility for that encrypted data. In this scenario, where the TPSP

is not providing any security services or access controls, they may be considered the same as a public or untrusted network, and it would be

the responsibility of the entity(s) sending/receiving account data through the TPSP’s network to ensure PCI DSS controls are applied to

protect the data being transmitted.

Payment Card Industry Data Security Standard: Requirements and Testing Procedures, v4.0 March 2022

Use of Third-Party Service Providers

An entity (referred to as the “customer” in this section) might choose to use a third-party service provider (TPSP) to store, process, or transmit

account data or to manage in-scope system components on the customer’s behalf. Use of a TPSP may have an impact on the security of a

customer’s CDE.

Note: Use of a PCI DSS compliant TPSP does not make a customer PCI DSS compliant, nor does it remove the customer’s responsibility for

its own PCI DSS compliance. Even if a customer uses a TPSP to meet all account data functions, that customer remains responsible for

confirming its own compliance as requested by organizations that manage compliance programs (for example, payment brands and

acquirers). Customers should contact the organizations of interest for any requirements.

Using TPSPs and the Impact on Customers Meeting PCI DSS Requirement 12.8

There are many different scenarios where a customer might use one or more TPSPs for functions within or related to the customer’s

CDE. In all scenarios where a TPSP is used, the customer must manage and oversee the PCI DSS compliance status of all their TPSPs

in accordance with Requirement 12.8, including TPSPs that:

 Have access to the customer’s CDE,

 Manage in-scope system components on the customer’s behalf, and/or

 Can impact the security of the customer’s CDE.

Managing TPSPs in accordance with Requirement 12.8 includes performing due diligence, having appropriate agreements in place,

identifying which requirements apply to the customer and which apply to the TPSP, and monitoring the compliance status of TPSPs at

least annually.

Requirement 12.8 does not specify that the customer’s TPSPs must be PCI DSS compliant, only that the customer monitor their

compliance status as specified in the requirement. Therefore, a TPSP does not need to be PCI DSS compliant for its customer to meet

Requirement 12.8.

Impact of Using TPSPs for Services that Meet Customers’ PCI DSS Requirements

When the TPSP provides a service that meets a PCI DSS requirement(s) on the customer’s behalf or where that service may impact the

security of the customer’s CDE, then those requirements are in scope for the customer’s assessment and the compliance of that service

will impact the customer’s PCI DSS compliance. The TPSP must demonstrate it meets applicable PCI DSS requirements for those

requirements to be in place for its customers. For example, if an entity engages a TPSP to manage its network security controls, and the

TPSP does not provide evidence that it meets the applicable requirements in PCI DSS Requirement 1, then those requirements are not

in place for the customer’s assessment. As another example, TPSPs that store backups of cardholder data on behalf of customers

剩余359页未读，继续阅读

信安成长日记

粉丝: 640
资源: 2

"K8S合规PCI-CSS：支付卡行业数据安全标准要求和测试程序 v4.0"

K8S

指定pod扩展到k8s-master-03

使用命令指定pod扩展到k8s-master-03

kubectl drain k8s-3-219 --delete-local-data --ignore-daemonsets --force

将name为auth-uat-58b6f5957f-djvxr的pod扩展到k8s-master-03

把node-586节点上正在运行的pod名为auth-uat调度到k8s-master-03节点

k8s 安装ingress-nginx

k8s安装ingress-nginx

k8s的tail -f

k8s部署xxl-job

最新资源