Skip to content
⚡ Tenvo AI · 实时 · v0.16.27 · TLS · 每设备证书 · AGPL-3.0 · 免费方案 · 30 台设备 · 可自托管基础设施 · 自带 API 密钥 · MCP,适用于 CLAUDE & CURSOR
返回博客Enterprise

PCI DSS 远程访问:第 8 条与第 12 条解析

Tenvo Editorial Team9 分钟阅读
PCI DSS 远程访问:第 8 条与第 12 条解析

你需要对接触持卡人数据的系统进行远程支持并向审计员证明已符合 PCI DSS。通常需要证明谁进行了连接、他们被授权、使用了多因素认证与最小权限,以及会话及其范围被记录并获批准。

你需要对接触持卡人数据的系统进行远程支持并向审计员证明已符合 PCI DSS。通常需要证明谁进行了连接、他们被授权、使用了多因素认证与最小权限,以及会话及其范围被记录并获批准。本文引用相关的 PCI DSS 要求标题,说明这些要求对典型支持会话的含义,并提供可向审计员出示的实用控制清单。

引用的要求标题(短摘)

下面是我们在本文中作为锚点使用的 PCI DSS v4.0 的精确单行要求标题:

  • “Requirement 8:Identify users and authenticate access to system components.”
  • “Requirement 12:Maintain a policy that addresses information security for employees and contractors.”

这些标题是官方的简短表述。两个要求集都包含多个子要求;下文我把第 8 条和第 12 条中对厂商或支持技术员远程连接实际生效的部分逐条说明。

第 8 条对远程支持会话的要求

第 8 条关注身份与认证。对远程支持会话而言,实际含义为:

  • 仅允许唯一且可归属的账户 — 禁止共享登录。每位接触系统的技术员必须使用个人可审计的账户。如果允许厂商使用共享账户进行支持,即不符合第 8 条。
  • 强认证与在适用场景下的 MFA。PCI 要求从外部网络访问持卡人数据环境(CDE)或进行管理访问时使用多因素认证。实际执行上即支持技术员在支持工具打开到 CDE 系统的会话前,必须使用密码加第二因素(TOTP、推送或硬件令牌)完成认证。
  • 时限性与最小权限访问。用于厂商支持的账户或授权必须仅限于所需的系统和命令,并应为临时:仅在工作时间窗口创建或启用,并在工作完成后立即撤销。
  • 经批准的访问流程与会话发起记录。组织应有文件化且可审计的批准步骤(例如通过邮件批准或含经理/厂商签署的工单),将会话与业务理由及负责人关联起来。
  • 凭证处理规则。禁止在脚本中嵌入共享或硬编码凭证;支持人员使用的密钥/秘密应按你的凭证策略发放或存入保险库,并在一次授权结束后轮换。

换句话说:第 8 条把“谁连接了以及如何认证?”的问题转成一组二元检查——唯一身份、在需要时的 MFA、以及访问窗口——你必须向审计员出示这些证明。

第 12 条对远程支持会话的要求

第 12 条要求组织将安全管理做成制度化,包括对第三方与远程访问的管理。对支持会话重要的部分包括:

  • 文件化的远程访问策略与流程。你必须有书面策略,定义被批准的远程访问方法、批准工作流、所需的认证控制,以及厂商访问的证据保留期望。
  • 第三方/厂商管理控制。合同或工作说明书应规定任何访问 CDE 系统的厂商的安全义务:可接受的工具、认证方式、事件报告 SLA 以及审计日志保留要求。
  • 访问批准与定期复审。策略必须要求厂商访问由授权负责人批准,并定期复审访问权限,若不再需要则撤销。
  • 事件响应与取证准备。如果支持会话导致可疑活动,IR 计划必须涵盖如何保全会话日志、录像及相关证据,以便调查人员重建事件。
  • 培训与意识。授予或监控厂商会话的人员必须接受该策略培训,并了解如何验证厂商身份与工作范围。

第 12 条本质上是治理问题:书面规则、被接受的工具、合同义务,以及可重复的批准 + 审计流程。审计员会想要看到策略及其被执行的证据。

具体清单:一个便于审计的远程支持会话

下面是针对每次触及 CDE 的远程支持会话可遵循的实用清单。把证据放在工单或变更记录中——这是审计员期望查看的内容。

  • 授权证据:在会话开始前的工单、签名邮件或变更批准,注明请求者、批准者、范围与业务理由。
  • 用户身份证明:技术员的唯一账户名和显示成功 MFA 的认证时间戳。展示 MFA 成功的截图或日志可作为可接受证据。
  • 时间窗口与范围:会话的开始与结束时间戳;目标主机清单以及执行的具体工作(运行的命令或修改的文件)。
  • 最小权限执行证明:证明使用的账户仅具备所需权限(角色成员关系或权限快照),或提升是被明确授予且有时间限制的。
  • 会话录制与审计日志:连接日志(源 IP、目标主机、客户端版本)、行为审计轨迹,以及在策略要求下的会话录制或击键日志。将这些存放在防篡改的存储中。
  • 凭证更换与轮换:若厂商访问使用了共享凭证或特权密码,在交付完成后立即轮换并记录轮换事件。
  • 会后复核:经理或系统负责人验证工作已完成并证明无意外变更;在工单中添加简短的会后说明是理想做法。
  • 保留说明:按你的保留策略存储授权、日志与录制(参见你的 PCI 策略)。确保证据可按工单或资产标识检索,以便审计员能在几分钟而非几周内重建会话。

该清单同时回答了第 8 条(谁认证以及如何)和第 12 条(是否有批准的、文件化的流程和合同保障)。

中继或云服务的位置 —— Tenvo 的定位

如果你的支持工具使用中继——无论是厂商运行的中继还是你自建的——你必须理解两个硬性事实。第一,直接 P2P 连接在两个端点之间实现端到端。第二,当流量回退到中继时,TLS 连接在中继处终止,因此运营该中继的一方在技术上可以访问会话流量。这是任何托管中继型远程桌面服务的现实;除非你自行运营并控制密钥,否则不应宣称中继“无法解密”。

Tenvo 建议将我们托管的多区域中继作为大多数客户的默认选项,因为它能减少运维工作量:无需对中继服务器值班、无需承担证书续期负担,并且 Tenvo 为 Windows、macOS 与 Linux 提供原生客户端,且浏览器客户端处于公测阶段。我们的定价档为 Free $0、Lite $2.99/mo、和 Pro $7.99/mo。除非你有书面的合规性要求禁止第三方基础设施,否则请使用托管中继。如果存在此类书面要求——数据驻留强制、隔离的离线网络,或合同条款禁止第三方托管——自建是正确的选择,但它会带来审计员期望你能证明的运维成本。

如果你选择 Tenvo 的托管中继,请在你的厂商管理文档中记录该选择,并将中继运营方列入第三方合同语言中的相关方名单。透明度正是审计员在第 12 条下查验的内容。

示例证据包(交给审计员的内容)

当审计员要求提供支持会话证明时,向他们提供一个压缩文件夹(或含链接的工单),其中包含:

  • 策略摘录:定义批准、MFA 与日志的远程访问策略条款(第 12 条证据)。
  • 批准证据:清单中引用的工单或签名变更批准。
  • 认证日志:导出的单一文件,显示技术员的唯一 ID、MFA 事件与时间戳(第 8 条证据)。
  • 会话日志与录制:连接日志、操作日志,以及在策略要求下的会话录制(或未录制的原因与补偿控制说明)。
  • 权限快照:会话期间适用于技术员账户的角色或 ACL,以及访问为时限性的声明。
  • 合同条款:规定安全要求与事件上报义务的厂商协议或 SOW(第 12 条证据)。
  • 会后证明:经理或资产负责人确认工作与范围一致,并在必要时确认凭证已轮换。

以清晰的文件名和一份简短的索引文档将这些证据交付,索引将每个文件映射到清单项——审计员会很感激你节省的时间。

常见陷阱与会触发审计员关注的问题

这些是我们经常看到且会立即延长审计工作的错误:

  • 共享账户。如果多位技术员使用相同登录,就无法归属行为,审计员会在第 8 条上给出不合格项。
  • 对外部访问无 MFA。如果技术员从外部网络认证且未使用 MFA 进入 CDE,这将构成明确的不合格项。
  • 缺乏预先批准。允许事后补签(“我们先让他们进,然后再记录”)不符合第 12 条对文件化流程的期望。
  • 无日志或时间戳不完整。存在缺口、不一致的时钟或缺失开始/结束标记的日志,会迫使审计员要求补充证据。
  • 未登记的厂商工具使用。如果厂商使用的连接工具未列入你的策略且未在合同中涵盖,审计员会提升厂商管理层面的质询。

在评估前修复这些问题:消除共享账户,要求对每次进入 CDE 的远程连接使用 MFA,使厂商窗口获得预先批准,并集中收集日志。

何时自建中继——以及为什么这不是默认选项

当你有正式约束时,自建中继(或使用本地代理)是合理的:书面合规语言禁止第三方基础设施;你在隔离网络中运营;或数据驻留法律迫使你将中继保留在你可控的区域内。如果你自建,中继的安全运营将成为审计员的考察点:补丁频率、证书生命周期、高可用性、备份,以及包含中继的事件响应计划。

对大多数组织来说,考虑到值班、补丁、密钥保管、证书续期以及单区域无故障切换的风险后,托管中继的总体成本通常更低。Tenvo 的托管中继能减少这些运维负担——但务必将该选择文件化,并在第三方控制中包含中继运营方。

延伸阅读与相关指南

如果你需要实用操作手册与配置参考,请先阅读这些 Tenvo 文章: Remote Desktop Audit Logging(有关日志格式与保留);How to Give Someone Remote Access(有关安全会话工作流);以及 Remote Desktop Security: What You Need to Know(有关总体威胁模型与 MFA 选项)。

这些资料将帮助你构建审计员期望的证据,以及安全团队所需的运维习惯。

结论与下一步

PCI DSS 第 8 条要求你为每次支持会话证明身份、MFA 与最小权限。第 12 条要求你有书面的、可执行的策略来管控这些会话与厂商。结合强制的批准工作流、带 MFA 的个人账户、时限性的权限、会话日志/录制以及合同化的厂商控制,你将涵盖审计员对远程支持最关注的部分。

如果你想要一个可操作的起点:文件化你的批准流程,要求对所有访问 CDE 系统的远程连接使用唯一账户 + MFA,将会话日志集中在防篡改的存储中,并在每次会话后记录一份会后证明。除非书面规则要求自建,否则使用像 Tenvo 这样的托管中继以降低运维开销。

下载 Tenvo 以测试合规工作流: 下载。

获取 Tenvo

准备自己试用吗?

免费支持 30 台设备,无需信用卡。两分钟内即可运行并连接。