安全架构评审的关注点？

本文目录导读：

1. 身份与访问管理 —— 谁可以做什么？
2. 网络与边界安全 —— 哪里是出入口？
3. 数据安全与隐私 —— 数据如何被保护？
4. 应用安全设计 —— 代码和逻辑是否安全？
5. 日志与监控 —— 能否发现问题？
6. 基础设施与运维安全 —— 平台层是否可靠？
7. 合规与标准 —— 是否满足法规要求？
8. 评审检查清单示例（快速自检）：

安全架构评审是确保系统在设计阶段就具备足够安全性的关键环节，而非事后补救，其核心关注点可归纳为资产保护、威胁抵御、合规运营三大维度,以下是详细的评审关注点清单：

身份与访问管理 —— 谁可以做什么？

这是安全架构的第一道防线。

1. 认证机制：
   • 强度：是否采用了多因素认证（MFA）？密码策略（复杂度、长度、过期）是否符合行业最佳实践（如NIST 800-63）？
   • 会话管理：Token（如JWT）是否安全存储（HttpOnly, Secure, SameSite属性）？会话超时和刷新策略是否合理？是否存在会话固定漏洞？
   • 身份源：是否集成了统一身份认证（SSO，如OAuth 2.0 / OIDC / SAML）？LDAP/AD集成是否安全？
2. 授权模型：
   • 最小权限原则：用户、服务、API是否只拥有完成其任务所需的最小权限？
   • 权限颗粒度：是粗粒度的RBAC（角色权限控制）还是细粒度的ABAC（属性权限控制）？权限模型是否能灵活应对业务变化？
   • 特权账号管理：管理员、root、数据库DBA等高权限账号是否遵循审批、临时、回收机制（PAM）？
3. 认证与会话风险：
   • 暴力破解：是否有登录频率限制、验证码、账户锁定机制？
   • 会话固定/劫持：登录后是否生成新会话ID？HTTPS是否强制使用？

网络与边界安全 —— 哪里是出入口？

关注系统与外部、内部网络之间的隔离与通信。

1. 网络分段与隔离：
   • 微隔离：生产环境、开发环境、测试环境、办公网是否物理或逻辑隔离？关键服务（如数据库）是否位于独立的安全专区？
   • VPC/子网：云上是否使用VPC隔离？不同子网间是否有明确的ACL（访问控制列表）规则？
   • DMZ：面向公网的Web服务器、API网关是否部署在DMZ区？
2. 边界防护：
   • WAF：Web应用防火墙是否启用？规则集是否覆盖OWASP Top 10（如SQL注入、XSS）？
   • IDS/IPS：入侵检测/防御系统是否部署？是否能识别异常流量模式？
   • DDoS防护：是否部署了DDoS清洗或限流机制？
3. 通信安全：
   • 传输加密：所有外部接口（Web、API、移动端）是否强制使用TLS 1.2+？内部服务间是否使用mTLS（双向TLS）？
   • 端口暴露：是否仅暴露必要的端口？管理口（如SSH、数据库端口）是否对公网开放？

数据安全与隐私 —— 数据如何被保护？

数据是核心资产,需关注全生命周期的安全。

1. 数据分类与分级：
   • 标签与规则：是否有自动化的数据分类策略？个人敏感信息（PII）、金融数据、业务机密是否被正确标记？
   • 加密与脱敏：
     • 静态加密：数据库、文件系统、备份数据是否加密？密钥如何管理（KMS）？
     • 动态脱敏：应用层、数据库层是否对非必要用户（如客服、运维）脱敏展示敏感数据（如手机号、身份证）？
     • 传输加密：跨网络传输是否加密？
   • 密钥管理：密钥（加密密钥、API密钥、证书）是否存储在专用密钥管理服务中（如AWS KMS, HashiCorp Vault）？是否定期轮转？
2. 数据存储与保留：
   • 数据冗余：数据备份策略（RPO/RTO）是否符合业务需求？备份数据是否同样加密？
   • 数据保留与销毁：是否有明确的数据保留周期？过期数据是否安全销毁（如覆写、物理粉碎）？
3. 隐私合规：
   • 最小化收集：是否只收集业务必需的数据？
   • 用户同意：是否有明确的隐私政策？用户是否能行使数据访问、删除等权利？
   • 跨境传输：数据是否存储在本区域？如有跨境，是否符合GDPR、PIPL等法规？

应用安全设计 —— 代码和逻辑是否安全？

关注业务逻辑和代码实现中的漏洞。

1. 输入验证与输出编码：
   • SQL/NoSQL注入：是否使用参数化查询或ORM？存储过程是否安全？
   • 跨站脚本（XSS）：所有用户输入和输出是否进行合适编码（HTML实体、URL编码等）？
   • 文件上传：是否限制文件类型、大小、执行权限？上传目录是否不允许脚本执行？
2. 认证与会话管理（同上，但侧重应用层实现）：
   • OAuth流程：授权码模式是否正确实现？Token是否不泄露在URL中？
   • CSRF防御：是否使用Anti-CSRF Token或SameSite Cookie？
3. 业务逻辑安全：
   • 限额与防刷：API调用是否有限流？关键操作（如转账、下单）是否有幂等性设计？
   • 竞争条件：是否存在并发操作导致的数据不一致或越权（如抢购漏洞）？
   • 敏感操作：删除、修改关键数据是否需要二次确认或审计日志？
4. 组件安全：
   • 依赖扫描：是否定期对第三方库、开源组件进行已知漏洞（CVE）扫描？
   • 安全配置：中间件（Tomcat, Nginx）、容器（Docker）、云服务默认配置是否已加固？

日志与监控 —— 能否发现问题？

安全事件发生后，能否快速发现、溯源和响应。

1. 审计日志：
   • 完整性：是否记录了所有关键操作（登录、权限变更、数据访问、管理员操作）？时间戳是否同步（NTP）？
   • 不可篡改性：日志是否只追加（append-only）？是否存储在独立的、受保护的系统上？
   • 敏感数据过滤：日志中是否避免记录明文密码、信用卡号、Token等敏感信息？
2. 监控与告警：
   • SIEM/SOC：是否对接了安全事件管理系统？告警规则是否覆盖了异常登录、异常流量、暴力破解、恶意软件行为？
   • 异常检测：是否有基于基线的异常行为分析（如非工作时间大量数据导出）？
3. 应急响应：
   • 开关与熔断：系统是否有“紧急阻断”或“降级”开关？
   • 备份与恢复：数据备份是否可快速恢复？恢复流程是否经过演练？

基础设施与运维安全 —— 平台层是否可靠？

1. 云资源/物理安全：
   • 安全组：云环境安全组规则是否仅允许必要流量？是否存在过度开放的规则（如 0.0.0/0 暴露管理端口）？
   • 镜像安全：容器镜像、虚拟机镜像是否经过安全检查？
2. 配置与部署：
   • CI/CD安全：代码仓库、构建流程是否安全？是否有安全检查（静态代码扫描SAST、依赖检查）嵌入流水线？
   • 基础设施即代码（IaC）：Terraform、CloudFormation文件是否经过安全扫描（如Checkov）？密钥是否硬编码？
3. 灾难恢复与业务连续性：
   • 冗余：是否有跨可用区/多区域部署？单点故障风险是否已识别？
   • 备份与恢复：是否定期测试灾难恢复计划？

合规与标准 —— 是否满足法规要求？

1. 法律与行业法规：是否符合GDPR、CCPA、HIPAA、PCI-DSS、SOX等与业务相关的法规？
2. 企业内部标准：是否遵循企业内部的《安全基线》、《数据安全管理办法》？
3. 信任框架：是否参考了NIST CSF、ISO 27001、CSA STAR等框架？

评审检查清单示例（快速自检）：

• [ ] 所有对外接口使用HTTPS？
• [ ] 关键操作需要MFA？
• [ ] 管理员账号使用SSO或PAM？
• [ ] 数据库、缓存（Redis等）未暴露公网？
• [ ] 代码库中没有硬编码的密钥/密码？
• [ ] 存在输入验证（防注入、防XSS）？
• [ ] 日志记录了谁、在何时、做了什么、结果如何？
• [ ] 有定期备份并测试恢复？
• [ ] 第三方依赖版本已知无高危漏洞？
• [ ] 有DDoS和WAF防护？

安全架构评审不是通过问答清单来“完成”，而是通过威胁建模（如STRIDE）来主动思考“攻击者会如何利用这个设计”，从而确保安全不是事后打补丁,而是原生嵌入系统基因。