安全原则
在应用系统软件开发设计的过程中，对应用系统的总体设计应当满足如下安全原则
| 原则 | 说明 |
| 最小权限原则 Least Privilege | 应用软件的每个模块如进程、用户只能访问当下所必需的信息或者资源。赋予每一个合法动作最小的权限，以保护数据以及功能避免受到错误或者恶意行为的破坏。 |
| 权限分离原则 Separation of Duties | 对业务的操作、管理和审计权限应该由软件中的不同角色的用户分别承担；普通用户和管理员用户信息应该存放在不同的数据表中。 |
| 深度防御原则 Defense in Depth | 在应用程序对业务数据进行处理的每个阶段都要考虑安全性问题，不能仅在某个阶段做安全防御，这样单点防御一旦被突破将造成安全风险。 |
| 容错保护原则 Fail Secure | 当程序出现故障时或系统异常当系统失败时，可以进入到一个失败保护的状态。如果用户请求失败，系统仍可保障安全 |
| 单点异常终止原则 Single Point of Failure | 当用户提交数据超出预期时，应立即终止程序的执行，不要试图加以修正并继续执行下去。 |
| 外来代码安全原则 Least Third Party Components | 严格控制第三方函数与插件的使用，对外来代码必须进行详细的安全测试。 |
| 代码重用原则 Leveraging Existing Components | 尽可能的重用软件已有的模块，这样可以降低引入新的漏洞和攻击界面的可能性。 |
| 数据保护原则 Data Protection | 对用户数据的保护功能应涵盖用户数据存储的完整性、用户数据传输保密性、数据传输的访问控制、剩余信息的保护、数据反转操作等内容；应对系统中关键数据（如用户密码等）的存储和网络传输时应采用加密保护，实用加密加密算法应该符合国际标准、国家标准和业界标准。 |
| 可审计原则 Auditing | 在应用系统中设计审计日志记录的功能，并对应用系统产生的日志增加完备的审计功能。 |
| 开放设计原则 Open Design | 开放设计与“不开放即安全”的原则相对而言，认为设计本身不应具有神秘感。这一原则的具体表现可以参见应用于加密设计的Kerchoff定律，“系统不应单纯依赖私密性，若落入敌人手中则毫无优势可言”；开放设计以提高系统兼容性和可扩展性。 |
| 抗抵赖原则 Anti Repudiation | 对于涉及支付交易等重要的业务场景，系统设计应有效地防止通信双方抵赖，如采用电子证书签名等方式。 |
| 规范性 Standardization | 系统设计所采用的安全技术和安全产品应符合国际标准、国家标准和业界标准，为系统的扩展升级、与其他系统的互联提供良好的基础。 |
| 可扩展性 Scalability | 以当前业务安全需求为基础，充分考虑发展的需要，安全功能模块子系统以插件或接口方式以方便未来的扩展。 |
| 实用性 Practicable | 安全功能设计需要尽可能的考虑投入产出比，同时尽量控制对用户体验的影响。 |
| 符合性 Regulatory Compliance | 安全功能的设计尽可能的要符合国家规范、行业规范以及业界的通用标准，如等级保护等规范。 |
转载请注明：清风亦平凡 » 安全架构设计基本原则
支付宝扫码打赏
微信打赏
