答案。

问题的背景：

信息安全要求是大型IT项目中最重要的组成部分，自从出现第一批安全审计标准（如ISO 27001或俄罗斯的法律152-FZ要求）以来。没有清晰的分析和规范化要求，系统的安全性可能会是宣言性的且不适用在实践中。

问题：

安全要求通常以抽象的方式表述（“一切都必须得到保护”），没有考虑实际的业务流程和架构，没有分层解读：组织、技术、用户层面。此外，客户和开发人员可能会不同地解释同一条要求——导致可实现性和规范性的不匹配。

解决方案：

系统分析师首先研究公司、政府和行业标准（如：国家标准，GDPR，PCI DSS，ISO 27001）。然后，他与架构师和安全人员共同识别关键业务流程、数据存储和传输点、可能的威胁，并确定相关风险的清单。在此基础上，分析师准备详细的访问、存储、日志记录、加密要求矩阵，以及事件场景。经过协商后，他将这些规范化为文档——以便每个要求都可以通过测试或审计进行验证。

关键特征:

• 安全要求根据架构、业务流程和RegTech规范进行规范化。
• 必须区分组织、技术和用户的安全政策。
• 必须与安全人员、架构师、法律顾问及QA工程师紧密合作。

伪问题。

为什么不能仅仅依靠技术手段（防病毒软件，防火墙，SIEM）来确保信息安全？

因为信息安全是一个过程，而不仅仅是一组系统。组织程序、人为因素、定期检查和用户培训发挥着至关重要的作用。

如果系统仅通过内部测试，可以认为要求已完成吗？

不能——通常要符合规范要求，需要外部审计、认证，有时甚至需要在监管机构的监督下进行压力测试。

仅仅在技术规格中传递“系统必须根据152-FZ保护”这个要求就足够了吗？

不够——需要指明具体措施（访问控制、事件日志存储、数据加密）、实施地点、验证标准。

常见错误和反模式

• 模糊或宣言性要求的表述（“应该是安全的”）
• 将安全过程与架构和业务分析分开（平行工作，不互动）
• 过高估计技术手段的作用而忽视人为和过程因素
• 没有定期检查信息安全要求的相关性

生活中的例子

负面案例: 在一个网上银行项目中，分析师在技术规格中只传达了一句般的‘必须遵守152-FZ的要求’。承包商实施了标准授权和SSL证书，而在外部审计阶段发现数据存储缺乏控制，认证日志未加保护。

优点：

• 快速开发

缺点：

• 不满足监管要求
• 启动风险被阻止

正面案例：

在项目启动阶段，系统分析师与安全人员和客户协商确定威胁清单，为每个场景开发了加密和审计的详细要求，并确定责任人。最终系统顺利通过审计，没有错误。

优点：

• 符合规范
• 保护声誉

缺点：

• 更长的设计阶段