可信设计

安全架构与设计原则

安全三要素与安全设计原则

• 完整性 Integrity
• 可用性 Availability
• 机密性 Confidentiality

开放设计原则

Open Design

• 设计不应该是秘密, 开放设计更安全.
• 安全不依赖保密.

失败-默认安全原则

Fail-safe defaults

• 访问决策基于"允许", 而不是"拒绝".
• 默认情况下不允许访问, 保护机制仅用来识别允许访问的情况.
• 失败安全: 任何一个复杂系统应该有功能失效后的应急安全机制, 另外对错误消息和日志要小心, 防止信息泄露.
• 默认安全: 系统在初始状态下, 默认配置是安全的, 通过使用最少的系统和服务来提供最大的安全性.

权限分离原则

Separation of Privilege

• 一种保护机制需要使用两把钥匙来解锁, 比使用一把钥匙要更健壮和更灵活.
• 权限分离的目的
• 防止利益冲突, 个别权力滥用
• 对某一重要权限分解为多个权限, 让需要保护的对象更难被非法获取, 从而也更安全.
• 分离不同进程的权责

系统可以默认设置 3 个角色, 角色间系统账号权限相互独立, 权责分离:

• 系统管理员: 负责系统的日常用户管理, 配置管理.
• 安全管理员: 负责对用户状态, 安全配置的激活, 去激活管理.
• 安全审计员: 负责对前面二者的操作做日志审计, 并拥有日志导出权限, 保证系统用户所有操作的可追溯性.

最小权限原则

Least Privilege

• 系统的每一个用户, 每一个程序, 都应该使用最小且必须的权限集来完成工作.
• 确保应用程序使用最低的权限运行.
• 对系统中各用户运行各类程序, 如数据库, WEB 服务器登, 要注意最小权限的账户运行或连接, 不能是系统最高权限的账号.
• 新建账号时, 默认赋给最小权限的角色.

经济使用原则

Economy of Mechanism

• 保持系统设计和代码尽可能简单, 紧凑.
• 软件设计越复杂, 代码中出现 bug 的几率越高, 如果设计尽可能精巧, 那么出现安全问题几率越小.
• 删除不需要的冗余代码和功能模块, 保留该代码只会增加系统的攻击面.
• 设计可以重复使用的组件减少冗余代码.
• 经济适用: 简单, 精巧, 组件化.
• 不要过设计

最小公共化原则

Least Common Mechanism

• 尽量避免提供多个对象共享同一资源的场景, 对资源访问的共享数量和使用应应尽可能最小化.
• 共享对象提供了信息流和无意的相互作用的潜在危险通道, 尽量避免提供多个对象共享同一资源的场景.
• 如果一个或者多个对象不满意共享机制提供的服务. 那他们可以选择根本不用共享机制, 以免被其它对象的 bug 间接攻击.
• 共享内存最小化
• 端口绑定最小化
• 减少连接, 防御 Dos 攻击

完全仲裁原则

Complete Mediation

• 完全仲裁原则要求, 对于每个对象的每次访问都必须经过安全检查审核.
• 当主体试图访问客体时, 系统每次都会校验主体是否拥有该权限.
• 尽可能的由资源所有者来做出访问控制决定, 例如如果是一个 URL, 那么由后台服务器来检查, 不要在前端进行判断.
• 特别注意缓存的使用和检查, 无法保证每次访问缓存的信息都没有被黑客篡改过. eg. DNS 缓存欺骗.

心理可承受原则

Psychological Acceptability

• 安全机制可能为用户增加额外的负担, 但这种负担必须是最小的而且是合理的.
• 安全机制应该尽可能对系统用户友好, 方便他们对系统的使用和理解.
• 如果配置方法过于复杂繁琐, 系统管理员可能无意配置了一个错误的选项, 反而让系统变得不安全.
• 该原则一般与人机交互, UCD(User Centered Design)界面相关.

纵深防御原则

Defense in Depth 纵深防御是一个综合性要求很高的防御原则, 一般要求系统架构师综合运用其他的各类安全设计原则, 采用多点, 多重的安全校验机制, 高屋建瓴地的从系统架构层面来关注整个系统级的安全防御机制, 而不能只依赖单一安全机制.