POC 的目标是降低上线不确定性，不是证明“所有攻击都能发现”
不应使用单一告警数量、厂商演示样本或未受控的生产攻击来替代验收。任何测试都应经过资产负责人授权，并遵循变更、隐私、数据和业务连续性要求。
1. 先限定 POC 范围
把试点写成一页范围说明，并让业务、IT、安全、合规与采购共同确认。范围越明确，结果越能用于采购或上线决策。
资产与环境列出终端、服务器、VDI、远程设备及试点网段；标出不可安装代理、关键业务、离线设备和变更冻结资产。
要验证的安全场景从真实风险选择少量、可授权且可回滚的场景，例如可疑进程调查、端点隔离流程或多源告警关联；不把未知能力写进验收。
数据与集成指定允许接入的身份、邮件、网络、云或日志来源，并说明数据字段、脱敏、保留、跨境与访问控制要求。
不在范围内的项目明确生产全网覆盖、24×7 服务、复杂自动化、遗留系统迁移和正式 SLA 是否不属于本次验证，避免结果被过度外推。
2. 用可复核的指标验收
指标应结合基线和业务约束设定，并记录测试前提、时间、操作者、版本、策略与原始证据。以下是可用的指标类别，不是预设达标数值或性能承诺。
| 指标类别 | 可以记录的证据 | 验收讨论重点 |
|---|---|---|
| 部署与兼容性 | 安装成功情况、资源影响观察、冲突记录、卸载与恢复记录 | 试点资产是否覆盖真实系统组合；问题是否有明确处置或排除理由 |
| 可见性与调查 | 授权场景的遥测、告警上下文、调查记录与证据导出 | 信息是否足够支撑团队的分级与调查，而非只确认出现一个告警 |
| 响应工作流 | 人工审批、操作日志、回滚步骤、业务影响和责任人记录 | 响应动作是否符合权限与变更规则；未验证动作不能视为可用 |
| 运营可用性 | 告警分诊时间、交接质量、报表样例、培训反馈与待办清单 | 现有团队是否能持续使用；哪些工作仍需要流程、人员或服务补足 |
| 集成与数据治理 | 数据流图、字段清单、接口测试、留存与访问审计记录 | 是否满足安全、隐私、合规与网络边界要求；未获批准的数据源不接入 |
3. 将测试设计成安全、可重复的场景
选择代表性场景
优先基于本组织近期告警、资产风险和处置痛点。使用经过批准的良性模拟、测试文件或隔离实验环境；对生产系统避免破坏性载荷、未授权扫描和可能造成业务中断的操作。
定义“通过、待解决、失败”
每个场景写明触发条件、期望可见信息、允许的响应动作、观察窗口和验收人。若产品、策略、网络或数据源的前提未满足，应标为“未验证”，而不是默认通过或失败。
保留决策证据
把控制台截图、事件 ID、日志片段、工单、异常清单和责任人归档到受控位置。验收会应同时审阅有效场景和无法执行的场景，避免只展示成功案例。
4. 在开始前就写好退出方案
POC 结束不一定意味着采购。无论继续、暂停还是放弃，都应有可执行的收尾路径：
- 撤除与恢复：按变更计划卸载代理、撤销测试账户、删除临时策略和连接器，确认不会留下管理员权限或持久化任务；
- 数据处置：确认测试数据、日志、导出文件与凭据的保存、归还或删除方式，遵从适用的留存和审计要求；
- 配置与证据归档：保存版本、策略、已知问题、验收记录和接口配置，便于复盘或后续重新验证；
- 上线交接门槛：若决定推进，单独确认生产架构、许可、支持、监控、响应授权、培训、回滚和变更窗口，不将 POC 配置直接当成生产配置。
5. 兼容性和许可复核清单
不要从 POC 能否启动推断正式环境一定可部署。请在启动前、结束后分别复核：
- 厂商当前支持的产品版本、操作系统、服务器角色、虚拟化与网络要求；
- 每个功能、数据源、连接器、用户角色与容量是否需要不同的许可或订阅；
- 试点、评估或服务资格是否存在地区、渠道、期限、数量或合同前置条件；
- 遥测、日志、样本或其他数据的处理位置、保留时间、共享范围和审批要求；
- 与现有防病毒、EDR、SIEM、身份、代理、证书和网络控制的冲突及变更风险。
产品具体能力与适用范围应以 Kaspersky Next 官方产品资料、Kaspersky 官方支持文档、当期兼容性信息、正式报价和合同为准。
开始前的最小输入包
- 试点资产清单及业务负责人、变更窗口和回滚联系人；
- 希望验证的 3–5 个授权场景与现有处置流程；
- 当前安全工具、日志来源、网络/身份架构与数据处理限制；
- 验收角色、决策日期与上线或退出的审批条件。
本页为通用 POC 规划框架，并非特定厂商的官方实施方案。Linkmetax 不承诺具体可用功能、免费试用、固定期限、检测率、官方授权或服务范围；所有项目条件以可核验的官方当前资料、项目确认、正式报价和合同为准。