安全原则
在应用系统软件开发设计的过程中,对应用系统的总体设计应当满足如下安全原则
原则 | 说明 |
最小权限原则 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 | 安全功能的设计尽可能的要符合国家规范、行业规范以及业界的通用标准,如等级保护等规范。 |
转载请注明:清风亦平凡 » 安全架构设计基本原则