®01
基于 HSM 和点对点加密的支付安全
已界定 PCI 审计范围的支付流程分析
了解更多
服务于您所在行业的从业者。
- 连锁零售企业与多门店商户
- 餐饮业与酒店业
- 活动场所与休闲娱乐企业
- 网络零售商与电商平台
您的重点领域
理解任务。设计方案。
我们依据 PCI DSS，使用加密技术和硬件安全模块保护银行卡支付。
从战略到系统
六个服务模块
六大行动领域。您可以选择想要深入了解的方向。
01基于 HSM 和点对点加密的支付安全Thales payShield 10K · Utimaco Atalla AT1000 · Futurex Excrypt
我们的方法
只要终端密钥、解密和令牌化都在经认证的硬件安全模块中完成，卡数据就能从终端到支付服务商全程保持加密。我们按照 PCI P2PE 规划点对点加密，以可控方式加载终端密钥，并用令牌替换收银系统、商店和进销存系统中的卡号。对于拥有自有支付平台的商户，我们提供厂商中立的咨询，涉及 payShield 10K、Atalla AT1000 和 Futurex Excrypt，并建立带角色分工和记录的密钥仪式。PCI 审计范围因此缩小到真正接触明文的系统。
服务范围详情
- 覆盖终端、收银系统、网上商店、自助设备和后台系统的支付流程分析，并界定 PCI 审计范围
- 依照 PCI P2PE 的点对点加密，可采用已列入 PCI 名录的方案或在 HSM 中自建解密环境
- 使用 KeyBRIDGE POI 或 Futurex SKI Series 3 进行终端密钥注入和远程密钥加载，密钥块符合 TR-31
- 为客户账户、订阅和退货对卡号进行令牌化，令牌库存放在 HSM 中
- 涵盖密钥轮换、固件版本、监控以及 QSA 审计或 SAQ 所需证明的运维手册
一家连锁零售企业将其终端改造为点对点加密，并对收银系统和进销存系统中的卡号进行令牌化。下一次 PCI 审计将只涉及解密环境。
02从收银到 ERP 的全渠道整合SAP S/4HANA · Shopware · commercetools
我们的方法
只有当收银系统、网上商店、App、电商平台和进销存系统看到相同的库存、价格和客户档案时，全渠道才能真正运转。我们在收银系统、ERP、商店平台和库存管理之间建立带版本化接口和事件处理的集成层，使门店自提、门店退货和门店下单无需依赖夜间文件核对。现有收银系统和 ERP 系统得以保留，通过适配器接入，其中包括依据 KassenSichV 要求配备的技术安全装置。
服务范围详情
- 覆盖收银系统、ERP、商店平台、库存管理、订单管理和电商平台的接口目录，含数据契约
- 使用 Apache Kafka 实时处理销售、库存和价格事件，取代批量核对
- 通过 API 网关接入 Shopware 或 commercetools 等商店平台，以及 SAP S/4HANA 等 ERP 系统
- 支持门店自提、门店发货和全渠道退货的订单管理
- 针对每个接口的自动化测试、版本管理和发布审批流程，变更无需停用收银系统
一家连锁零售企业通过事件平台连接收银系统、Shopware 和 SAP。门店和网上商店的库存在数秒内保持一致，来自网店的退货可在任意一台收银台处理。
03符合 GDPR 的客户账户、忠诚与卡片计划Keycloak · OpenID Connect · FIDO2 与 Passkey
我们的方法
忠诚计划、礼品卡和客户账户会收集购买记录和联系方式，因此完全适用 GDPR。我们开发和运维客户 App、客户门户和奖励系统，其中的同意管理、角色权限和删除规则从一开始就写入数据模型。使用实体忠诚卡或礼品卡的卡片计划，其卡密钥和余额校验均在 HSM 中处理，防止卡片被复制、余额被篡改。
服务范围详情
- 包含合法性基础、处理活动记录和针对画像的数据保护影响评估的数据保护方案
- 支持 OpenID Connect 登录、Passkey 和同意管理的客户 App 与客户门户
- 带卡密钥、余额签名并在 HSM 中校验的奖励与储值系统
- 面向分析场景的删除方案、查询流程和假名化处理
- 在德国数据中心运维相关应用，包含监控、更新和支持
一家餐饮集团推出配备 App 和礼品卡的奖励计划。同意记录、删除期限和余额校验在上线前均已记录在案，余额签名在 HSM 中完成。
04面向多门店的云端运维Microsoft Azure · AWS · Google Cloud
我们的方法
当收银后台系统、进销存系统和客户门户集中运行、各门店只需配备终端和网络设备时，门店网络和多门店企业将从中受益。我们将这些应用迁移到 Microsoft Azure、AWS、Google Cloud 或德国数据中心，集中搭建门店连接、身份管理和监控，并为收银系统预留离线模式，确保线路中断时销售仍能继续。
服务范围详情
- 包含 Landing Zone、网络分段以及通过 SD-WAN 或 VPN 实现门店连接的目标架构
- 使用 Terraform 以基础设施即代码方式迁移收银后台系统、进销存系统和客户门户
- 收银系统的离线能力，含本地缓存和事后同步
- 面向所有门店的集中监控、补丁管理和备份
- 针对促销日和季节性高峰的成本控制与弹性扩展
一家酒店集团将旗下所有酒店的预订和收银系统迁移到德国数据中心。更新可在当天送达每家酒店，线路中断时前台仍能以离线方式继续办理预订。
05结合 AI 的欺诈检测与销售预测Apache Kafka · Apache Flink · XGBoost
我们的方法
零售业中的欺诈表现为网上商店的账户接管、退货欺诈、忠诚积分和优惠券滥用，以及收银台的异常撤单。我们将交易、账户和设备数据汇总到一个数据平台，训练模型在订单、退货和积分兑换获批前进行评分。同一平台还为补货和排班提供销售与需求预测。每项决策都可解释并留有记录，方便客服和数据保护团队追溯。
服务范围详情
- 通过流式接入商店、收银系统、客户账户、支付服务商和设备数据的数据平台
- 针对订单、退货和积分兑换的评分模型，并对照历史欺诈案例和误报进行验证
- 按门店和商品提供的销售与需求预测，用于补货和人员调度
- 面向客服、投诉处理和数据保护的逐项决策可解释性
- 模型运维包含版本管理、漂移监控，以及符合 GDPR 和欧盟《人工智能法案》的文档记录
一家网络零售商根据账户年龄、设备和退货历史对退货进行评分，而不是一律退款。可疑案例会被审查，诚实的客户则能立即拿回款项。
06面向门店网络和电商的网络安全Microsoft Sentinel · Microsoft Defender for Endpoint · OPSWAT MetaDefender
我们的方法
门店、商店平台和后台系统构成庞大的攻击面，涉及收银终端、访客 WLAN、供应商接入和可公开访问的接口。我们对门店网络进行分段，加固收银系统和商店服务器，用 Web 应用防火墙（Web Application Firewall）保护接口，并通过攻击检测和事件响应对所有门店进行集中监控。对于依据 NIS2 属于重要实体的企业，例如食品零售商或电商平台，我们提供风险管理、报告流程以及依据 ISO 27001 的证明。
服务范围详情
- 按门店划分网络分段的安全架构，将收银、访客 WLAN、后台系统和楼宇设备分开
- 对收银系统、终端和商店服务器进行加固，用 Web 应用防火墙和机器人防护保护接口
- 通过 SIEM 和端点检测对所有门店进行安全监控，配备报告路径的事件响应
- 针对网上商店、客户 App 和门店网络的渗透测试，供应商接入遵循双人复核原则
- 依据 ISO 27001 建立的 ISMS，以及针对适用企业的 NIS2 差距分析
一家食品零售商在每家门店将收银网络、访客网络和楼宇设备网络分离，并进行集中事件上报。NIS2 差距分析显示，报告路径是唯一尚待完善的事项。
典型项目场景
变革真正落地之处。
项目往往始于一个具体的挑战。以下示例将典型的现状、可能的解决思路和期望达成的结果结合在一起。
示例性现状说明，并非客户案例。
01 / 商贸行业
某连锁零售企业的 P2PE 改造
卡号以明文形式流经收银软件和进销存系统，收单机构要求提供完整的 PCI DSS 证明。
解决方案
支付流程分析、从终端开始的点对点加密、收银系统和进销存系统中的令牌化，以及带记录的密钥仪式。
审计范围缩小到解密环境，QSA 审计所需资料齐全，并为客户自有团队编写了运维手册。
02 / 商贸行业
某时尚零售商的全渠道整合
门店、网上商店和电商平台各自维护库存，核对工作在夜间进行，网店退货在收银台常被拒收。
解决方案
带事件平台的集成层、覆盖收银、商店和 ERP 的接口目录，以及支持门店自提和退货的订单管理。
库存数秒内完成核对，任意收银台均可处理退货，发布更新无需停用收银系统。
03 / 商贸行业
某餐饮集团的奖励计划
一项配备 App 和礼品卡的奖励计划即将上线，同意记录和删除期限尚未明确，余额数据存放在表格中。
解决方案
含处理活动记录的数据保护方案、带同意管理的客户 App，以及在 HSM 中生成密钥和签名的储值系统。
计划以明确的合法性基础上线，余额具备防篡改保护，查询和删除请求已纳入常规运营流程。
协作
清晰的路径。与您的团队同行。
从初步了解情况到日常运维：我们会共同商定各阶段的优先事项、职责分工和成果。
我们的工作方式
- 01
评估
支付流程、收银与商店系统环境、客户数据和门店网络
优先级排序的措施清单、PCI 审计范围、针对 GDPR 和 NIS2 的差距分析 - 02
方案
目标架构、加密、接口、运维模式
目标架构、接口目录、数据保护方案、运维模式、审计方案 - 03
实施
按门店分组、分阶段实施 HSM、集成层、应用和云端部署
已整合的系统、试点门店、测试、文档，以及各阶段的发布审批 - 04
运维
监控、审计、知识转移
监控、密钥轮换、审计陪同、分步移交
- 01
您希望改变什么？
当前面临的挑战，以及您期望达成的结果。
- 02
涉及哪些系统？
站点、应用和接口的概览。
- 03
有哪些约束条件？
项目时间安排、维护窗口和已知的依赖关系。
- 04
哪些人需要参与？
来自 IT、安全和运维部门的合适联系人。
背景与决策参考
什么是面向商贸行业的 IT 解决方案？
六个行动领域，从支付加密到欺诈检测，由 OTOKO® 为门店、网上商店、餐饮和活动场所规划、集成并运维。每笔刷卡交易从终端到结算全程加密。整套方案运行在德国数据中心。
商贸行业的 IT 解决方案将收银系统、网上商店、进销存系统和客户账户整合到一个平台，同时保护刷卡支付和个人数据。OTOKO® 为此涵盖六个行动领域：符合 PCI DSS 的 HSM 支付安全、从收银到 ERP 的全渠道整合、符合 GDPR 的客户账户与忠诚计划、面向多门店的云端运维、结合 AI 的欺诈检测与销售预测，以及面向门店网络和电商的网络安全。
与普通系统集成商的区别在于密码学和证明能力。卡数据从终端到结算全程加密，密钥保存在经认证的设备中，每个接口、每条删除规则和每次变更都为 PCI 审计人员和数据保护官留有记录。密码学和硬件安全模块是我们的核心能力，因此我们缩小 PCI 审计范围，而不只是描述它。
为什么选择 OTOKO® 服务商贸行业
- 密码学与 HSM
密码学和硬件安全模块是我们的核心能力。终端密钥、令牌化和余额签名保存在经认证的设备中，正如 PCI DSS 和 PCI P2PE 所要求的那样。
- 德国数据中心
整套方案运行在德国数据中心，从支付 HSM、事件平台到客户 App 和数据平台。
- 关键基础设施（KRITIS）与受监管行业
与关键基础设施运营方和受监管行业合作是我们的日常工作。我们在金融行业中熟悉了 PCI 审计人员、数据保护官和卡组织的期望，并将其应用到商贸和餐饮酒店业。
- 同一团队负责到运维
集成开发人员、密码学专家和云工程师为您提供从咨询到运维的全程支持，不会转交给第三方。
框架条件与详情
商贸行业项目启动前的典型现状
大多数企业失败的原因不在于缺少技术，而在于历史积累的收银系统、分散的门店，以及面向卡组织和数据保护的证明缺口。
01
卡数据以明文形式存在
终端、收银软件和商店后台系统处理未加密的卡号，因此 PCI 审计范围几乎覆盖整个网络。
02
各渠道数据不互通
收银系统、网上商店和电商平台各自维护库存和价格，数据核对靠夜间文件传输完成，退货常常进错系统。
03
忠诚计划缺少数据保护方案
客户账户在没有有记录的同意的情况下收集购买记录，删除期限未落实，查询请求要等上数周。
04
每家门店一台服务器
每个门店都运行自己的收银服务器和网络设备，安全更新到达得很晚，也没有人能看到跨门店的攻击。
三种运维模式
| 本地部署 | 德国云 | 超大规模云服务商 | |
|---|---|---|---|
| 数据存储 | 您的数据中心、您的收银服务器和 HSM | 德国数据中心，依据 ISO 27001 运营 | Azure、AWS 或 Google Cloud，可选择区域 |
| 运维 | 您的团队，或由 OTOKO® 以托管服务形式运维 | OTOKO® 运维，并为您的 PCI 和数据保护审计提供报告 | 共同承担，平台服务由云服务商提供 |
| 工具 | payShield 或 Atalla 部署在本地，以及 Kafka、Kubernetes | 德国境内的托管 HSM、事件与数据平台 | 云端 HSM 服务、payShield Cloud HSM、托管数据服务 |
| 适用于 | 自有支付平台、要求较高的收银后台系统 | 需要在德国存储数据的商户 | 商店平台、数据分析、有负载高峰的促销日 |
| 合规 | 完全掌控，证明材料来自您的 ISMS 和 PCI 审计范围 | 依据 GDPR 签订数据处理协议，数据位于德国 | 数据处理协议、标准合同条款，以及各服务的 PCI 责任划分矩阵 |
合作方式
项目
边界清晰的项目，例如收银系统迁移、切换至 P2PE 或新建网上商店，具有明确的成果、里程碑和验收。
- 评估、方案、实施、移交
- 固定价格，或按里程碑以实际工作量计费
- 适用于收银系统更换、商店重新上线和 PCI 准备工作
团队扩充
集成开发人员、云工程师或安全专家加入您的团队，使用您的工具，融入您的发布周期。
- 熟悉您的收银、商店和 ERP 系统环境
- 可随季节和项目进展灵活调整规模
- 适用于拥有自有 IT 团队但存在人力缺口的商户
托管服务
OTOKO® 负责运维支付平台、集成层、客户 App 或云环境，提供约定的服务水平和报告，以及支持 PCI 和数据保护审计的证明材料。
- 监控、更新、密钥轮换和支持
- 在促销日和活动期间保持待命
- 适用于没有自有运维团队的企业
标准与证明材料
商贸行业各项要求的内容，以及 OTOKO® 为此提供的交付物。
| 标准项 | 要求 | OTOKO® 提供 |
|---|---|---|
| PCI DSS | 通过网络分段、加密、访问控制、日志记录以及每年由 QSA 审计或自评估，保护持卡人数据 | 界定审计范围、在 HSM 中完成加密与令牌化、对门店网络进行分段，以及 QSA 审计和 SAQ 所需资料 |
| PCI P2PE | 在终端对卡数据加密，只能在配备 HSM 的经认证环境中解密，并进行受控的密钥注入和设备管理 | 采用已列入 PCI 名录的方案或自建解密环境的 P2PE 架构、带记录的密钥注入、设备清单和运维流程 |
| GDPR | 合法性基础、针对画像的用户同意、数据最小化、数据主体权利、数据处理协议以及数据保护影响评估 | 面向忠诚计划和客户 App 的数据保护方案、同意管理、删除方案、查询流程和数据处理协议 |
| ISO 27001 | 建立信息安全管理体系，涵盖风险分析、措施清单、供应商管理以及定期的内部和外部审计 | 建立 ISMS 或将其扩展到门店和商店平台、风险登记册、措施计划，以及依据 ISO 27001 运维平台 |
| NIS2 | 针对食品零售和电商平台等重要实体的风险管理、重大事件上报、供应链安全以及管理层责任 | 适用性审查、差距分析、报告流程、对供应商的要求，以及向 BSI 注册所需的证明 |
常见问题
好问题。清晰的答案。
15 条解答，涵盖您的行业、项目以及后续运维。
行业与行动领域6 问题
OTOKO® 为商贸行业提供哪些 IT 解决方案？
服务范围包括基于 HSM 和 PCI DSS 点对点加密的支付安全、收银、商店与 ERP 的全渠道整合、符合 GDPR 的客户账户与忠诚计划、面向多门店的云端运维、结合 AI 的欺诈检测与预测，以及面向门店网络和电商的网络安全。每个行动领域都可以单独委托或作为整体套餐委托，均在德国数据中心运行。
如何缩小 PCI DSS 的审计范围？
审计范围取决于卡数据以明文形式出现的位置。从终端开始的点对点加密，以及收银系统、商店和进销存系统中的令牌化，能让这些系统脱离明文路径，网络分段则隔离其余部分。最终只剩下一个配备 HSM 的小型解密环境，其证明工作量也在合理范围内。
我们现有的收银系统和进销存系统能否保留？
通常可以。我们通过适配器将现有的收银系统、ERP 和商店平台接入集成层，只替换那些不提供接口或即将停止支持的组件。依据 KassenSichV 配备的技术安全装置在此过程中保持不变地接入。
GDPR 对忠诚计划有哪些要求？
每项处理都需要合法性基础，针对画像和个性化优惠需要有记录的同意，还需要删除期限、查询流程，在画像范围较大时还需要数据保护影响评估。我们将这些规则写入数据模型和同意管理系统，让查询和删除成为常规运营流程，而不是特例处理。
我们的企业是否适用 NIS2？
这取决于行业和企业规模。食品零售、电商平台和部分数字服务提供商可能被认定为重要实体，传统零售和餐饮业通常不适用。我们依据德国的转化法律审查适用性，并在需要时提供风险管理、报告流程以及向 BSI 的注册。我们与关键基础设施运营方和受监管行业合作，因此这些要求对我们而言是日常工作。
云端连接中断时，销售是否还能继续？
可以，前提是收银系统为此做好了准备。我们设置离线模式，让收银系统和终端在本地缓存销售数据，并按照支付服务商的规则继续受理刷卡支付。连接恢复后，收银系统会自动同步小票、库存和支付数据。
启动与实施5 问题
我们可以从单一行动领域开始吗？
可以。我们可以先界定一项具体任务，同时关注它与其余基础设施之间的接口，并在实施前明确哪些服务属于委托范围。
我们应该为初步沟通准备什么？
起步时，只需简要说明面临的挑战、涉及的系统以及您期望达成的结果即可。已知的时间节点和合适的联系人也会有所帮助。访问凭证或机密的系统文档不应包含在首次咨询中。
谁应该参与该项目？
安全架构师: 目标架构、网络分段、PCI 审计范围. 密码学专家: HSM、P2PE、令牌化、密钥仪式. 集成开发人员: 接口、事件平台、收银与 ERP 适配器. 云工程师: Landing Zone、迁移、门店连接. 数据工程师: 数据平台、欺诈模型、预测. 项目负责人: 里程碑、门店推广、验收.
时间计划和工作量是如何确定的？
我们会综合考察系统、接口、文档现状和运维方面的约束条件。经过协商确定的范围和里程碑，构成工作量评估的基础。缺少这些信息而给出的固定工期是不可靠的。
项目第一阶段会交付什么？
支付流程、收银与商店系统环境、客户数据和门店网络 优先级排序的措施清单、PCI 审计范围、针对 GDPR 和 NIS2 的差距分析
运维与持续完善4 问题
有哪些可能的合作方式？
项目: 边界清晰的项目，例如收银系统迁移、切换至 P2PE 或新建网上商店，具有明确的成果、里程碑和验收。 团队扩充: 集成开发人员、云工程师或安全专家加入您的团队，使用您的工具，融入您的发布周期。 托管服务: OTOKO® 负责运维支付平台、集成层、客户 App 或云环境，提供约定的服务水平和报告，以及支持 PCI 和数据保护审计的证明材料。
如何完成向运维的移交？
监控、审计、知识转移 监控、密钥轮换、审计陪同、分步移交
我们之后可以再补充其他站点或系统吗？
这一点可以在最初的方案中予以考虑。有文档记录的接口和可复用的规则，为后续扩展打下基础。不过，每新增一个站点或系统，仍会针对其特殊需求单独进行评估。
该方案如何保持长期可运维？
职责分工、周期性任务和变更流程，会与技术实施一并确定。文档记录和知识转移有助于您的团队开展日常工作。具体包含哪些工作内容和持续支持，会在服务范围中明确约定。
商贸行业
让我们一起探讨下一步。
让我们探讨如何在您的企业中安全地整合支付、客户数据与销售渠道。
预约初步沟通
