安全始于设计：如何在编写任何代码之前将安全性融入架构
内容提要
安全应始于设计，而非事后添加。核心实践包括：威胁建模以明确攻击面；将安全要求作为领域业务规则强制执行；统一加密标准；数据库采用参数化查询、最小权限、TLS和密钥管理；严格配置CORS；日志字段级脱敏；CI/CD集成密钥扫描、静态分析、依赖漏洞扫描和配置校验；微服务间使用mTLS和签名事件认证；并将数据隐私合规落实为工程要求。
延伸解读
安全左移：从设计阶段构建安全
文章强调安全应始于设计，而非事后添加。通过威胁建模、将安全要求作为领域业务规则、统一加密标准等实践，团队能在架构决策前明确安全需求。这种主动方式将安全视为工程团队的责任，而非安全团队的附加任务，从而降低修复成本和违规风险。
威胁建模：系统化识别攻击面
威胁建模是正式工程活动，通过四个问题（构建什么、什么会出错、如何应对、是否足够）系统识别威胁。使用STRIDE方法分析欺骗、篡改、否认、信息泄露、拒绝服务和权限提升，帮助团队在编码前理解攻击面并做出设计决策，将安全要求文档化并验证。
加密与数据库安全：组织级标准与工程控制
组织需明确加密标准（如AES-256-GCM、bcrypt/Argon2、RSA-2048），并通过内部包集中交付，避免各团队自行实现。数据库安全需参数化查询、最小权限、TLS连接和密钥管理。这些措施防止SQL注入、限制泄露影响，并确保敏感数据在传输和存储中得到保护。
CI/CD安全门与微服务内部安全
CI/CD管道应集成密钥扫描、静态分析、依赖漏洞扫描和配置验证，作为自动化安全门。微服务间通信需使用mTLS和签名事件认证，默认不信任内部请求。同时，架构选择应基于团队运维能力，避免过度工程化带来的安全风险。
Q&A
什么是Secure by Design？它和传统安全方式有什么区别？
Secure by Design是一种在编写代码之前就将安全需求融入架构的思维方式。它把安全需求视为与功能需求同等重要，必须在系统完成前满足。传统方式是被动响应，出现问题后再修补，而Secure by Design是主动预防，在构建前就考虑威胁并做出设计决策。
威胁建模具体要回答哪四个问题？
威胁建模需要回答四个问题：1. 我们在构建什么？（映射系统组件、数据流和信任边界）；2. 什么可能出错？（使用STRIDE方法分析欺骗、篡改、否认、信息泄露、拒绝服务和权限提升）；3. 我们打算怎么处理？（决定缓解、转移、接受或消除威胁）；4. 我们做得够好吗？（验证措施是否实施，并随系统变化更新威胁模型）。
如何将安全要求作为业务规则在领域层强制执行？
将安全要求编码为领域层的业务规则，例如在领域实体或领域服务中强制执行业务规则，使其无法被绕过。通过值对象（如Money、AccountNumber）在构造时验证，确保无效数据无法进入系统。这样无论从API、客户端还是数据库访问，规则都在领域层被强制执行。
组织应该制定哪些加密标准？
组织应明确并强制执行以下加密标准：1. 对称加密算法和模式：推荐AES-256-GCM；2. 密码哈希算法：使用bcrypt、scrypt或Argon2，避免SHA-256和MD5；3. 非对称算法：RSA-2048起步，JWT签名用RS256或ES256；4. 加密交付：由内部包或云函数集中提供，避免各项目自行实现。
数据库安全有哪些关键措施？
数据库安全关键措施包括：使用参数化查询或ORM防止SQL注入；遵循最小权限原则，为应用分配所需的最小数据库权限；强制使用TLS加密所有数据库连接；数据库凭证从密钥管理服务运行时获取，不硬编码；合理配置连接池；可使用存储过程作为参数化策略。
CI/CD流水线中应集成哪些安全门禁？
CI/CD流水线应集成以下安全门禁：1. 密钥检测（如Gitleaks）扫描所有分支和完整Git历史；2. 静态分析（如Semgrep）检查SQL注入、不安全反序列化等；3. 依赖漏洞扫描（如OWASP Dependency-Check）检查已知CVE；4. 环境配置验证，确保生产配置无调试端点、通配符CORS、硬编码凭证等。
微服务间如何实现安全通信？
微服务间安全通信可采用两种模式：同步调用使用mTLS（双向TLS），双方交换证书验证身份；异步通信使用签名事件，发布者用私钥签名，消费者验证签名后再处理。所有内部服务默认不信任，必须认证。服务不应直接暴露于互联网，应通过API网关。
如何将数据隐私合规落实到工程实现中？
数据隐私合规需落实为工程要求：1. 数据最小化，只收集必要数据；2. 目的限制，数据不用于未授权目的；3. 数据驻留，特定数据存储在指定地理区域；4. 保留与删除，定义保留策略并自动删除；5. 审计日志，记录所有个人数据访问，确保可证明合规。
