【系统架构设计师】二十四、安全架构设计理论与实践④

目录

六、数据库系统的安全设计

6.1 数据库的完整性设计

6.1.1 数据库完整性设计原则

6.1.2 数据库完整性的作用

6.1.3 数据库完整性设计示例

七、系统架构的脆弱性分析

7.1 软件脆弱性的特点和分类

7.2 软件脆弱性的生命周期

7.2.1 脆弱性的引入阶段

7.2.2 产生破坏效果阶段

7.2.3 修补阶段

7.3 软件脆弱性分析

7.4 典型软件架构的脆弱性分析

7.4.1 分层架构

7.4.2 C/S 架构

7.4.3 B/S架构

7.4.4 事件驱动架构

7.4.5 MVC 架构

7.4.6 微内核架构

7.4.7 微服务架构

相关推荐

六、数据库系统的安全设计

        从数据库管理系统的角度而言，要采取的安全策略一般为用户管理、存取控制、数据加密、审计跟踪和攻击检测，从而解决数据库系统的运行安全和信息安全。

        数据库完整性是指数据库中数据的正确性和相容性。数据库完整性由各种各样的完整性约束来保证，因此可以说数据库完整性设计就是数据库完整性约束的设计。数据库完整性约束可以通过DBMS 或应用程序来实现，基于DBMS 的完整性约束作为模式的一部分存入数据库中。

6.1 数据库完整性设计原则

        在实施数据库完整性设计时，需要把握以下基本原则：

        （1）根据数据库完整性约束的类型确定其实现的系统层次和方式，并提前考虑对系统性能的影响。一般情况下，静态约束应尽量包含在数据库模式中，而动态约束由应用程序实现。
        （2）实体完整性约束、引用完整性约束是关系数据库最重要的完整性约束，在不影响系统关键性能的前提下需尽量应用。用一定的时间和空间来换取系统的易用性是值得的。
        （3）要慎用目前主流DBMS 都支持的触发器功能，一方面由于触发器的性能开销较大；另一方面，触发器的多级触发难以控制，容易发生错误，非用不可时，最好使用 Before型语句级触发器。
        （4）在需求分析阶段就必须制定完整性约束的命名规范，尽量使用有意义的英文单词、缩写词、表名、列名及下画线等组合，使其易于识别和记忆，如PK_EMPLOYEE、CKT_EMPLOYEE。
        （5）要根据业务规则对数据库完整性进行细致的测试，以尽早排除隐含的完整性约束间的冲突和对性能的影响。
        （6）要有专职的数据库设计小组，自始至终负责数据库的分析、设计、测试、实施及早期维护。数据库设计人员不仅负责基于DBMS 的数据库完整性约束的设计实现，还要负责对应用软件实现的数据库完整性约束进行审核。
        （7）应采用合适的CASE 工具来降低数据库设计各阶段的工作量。

6.2 数据库完整性的作用

        数据库完整性对于数据库应用系统非常关键，其作用主要体现在以下几个方面。

        (1)数据库完整性约束能够防止合法用户使用数据库时向数据库中添加不合语义的数据。
        (2)利用基于DBMS 的完整性控制机制来实现业务规则，易于定义，容易理解，而且可以降低应用程序的复杂性，提高应用程序的运行效率。
        (3)合理的数据库完整性设计，能够同时兼顾数据库的完整性和系统的效能。
        (4)在应用软件的功能测试中，完善的数据库完整性有助于尽早发现应用软件的错误。
        (5)数据库完整性约束可分为6类：列级静态约束、元组级静态约束、关系级静态约束、
列级动态约束、元组级动态约束和关系级动态约束。

6.3 数据库完整性设计示例

        一个好的数据库完整性设计：

        首先需要在需求分析阶段确定要通过数据库完整性约束实现的业务规则。

        然后在充分了解特定DBMS 提供的完整性控制机制的基础上，依据整个系统的体系结构和性能要求，遵照数据库设计方法和应用软件设计方法，合理选择每个业务规则的实现方式。

        最后，认真测试，排除隐含的约束冲突和性能问题。基于 DBMS 的数据库完整性设计大
体分为以下几个阶段。

七、系统架构的脆弱性分析

        脆弱性分析主要是分析信息系统中产生脆弱性的根源、脆弱性可能造成的影响、如何利用脆弱性进行攻击、如何修补脆弱性、如何防止脆弱性被利用、如何探测目标系统的脆弱性、如何预测新的脆弱性的存在等一系列问题。

        从技术角度而言，漏洞的来源主要有以下几个方面：软件设计时的瑕疵、软件实现中的弱点、软件本身的瑕疵、系统和网络的错误配置。

7.1 软件脆弱性的特点和分类

        软件脆弱性有其自身的特点，主要包括4个方面：

        （1）脆弱性是软件系统中隐藏的一个弱点，本身不会引起危害，但被利用后会产生严重的
安全后果；
        （2）在软件开发过程中，自觉或不自觉引入的逻辑错误是大多数脆弱性的根本来源；
        （3）与具体的系统环境密切相关，系统环境的任何差异都有可能导致不同的脆弱性问题；
        （4）旧的脆弱性得到修补或纠正的同时可能引入新的脆弱性，因此脆弱性问题会长期存在。

        软件脆弱性可以从不同视角进行分类，比较典型的分类法有：ISOS 分类法、 P A 分类法、
Landwehr分类法、 Aslam 分类法、 Bishop分类法和 IBM 分类法。IBM 分类法的详细缺陷分类如下图：

7.2 软件脆弱性的生命周期

7.2.1 脆弱性的引入阶段

        （1）输入验证错误；
        （2）权限检查错误；
        （3）操作序列化错误；
        （4）边界检出错误；
        （5）软件设计时的缺陷；
        （6）其他错误。

7.2.2 产生破坏效果阶段

        （1）非法执行代码；
        （2）非法修改目标对象；
        （3）访问数据对象；
        （4）拒绝服务攻击。

7.2.3 修补阶段

        （1）删除伪造实体(如IP伪造、名字伪造等);
        （2）增加新的实体；
        （3）写该实体不正确的位置；
        （4）其他情况。

7.3 软件脆弱性分析

        软件脆弱性分析可从三个方面考虑：

        （1）分析软件故障现象，分析故障的技术本质、总结脆弱性模式；
        （2）分析软件开发，发现安全管理和技术的薄弱环节，提高软件安全性；
        （3）分析软件使用，发现其脆弱性，采取相应措施，避免脆弱性转化为安全故障。

        软件脆弱性分析首先要明确分析对象，脆弱性分析对象可以分为两类：脆弱性数据和软件系统。

        由于软件本身具有自身的性质和特点，针对软件的脆弱性分析，我们也需要考虑软件本身的各种特点。主要考虑软件结构和实现技术两个方面。
        软件结构具有多方面的含义，包括数据结构、体系结构、安全体系结构、系统结构等。
        在实现技术方面，不论功能、性能如何设计，最终总会落实到软件实现。

7.4 典型软件架构的脆弱性分析

7.4.1 分层架构

        分层架构的脆弱性主要表现在两个方面：

        （1）层间的脆弱性。一旦某个底层发生错误，那么整个程序将会无法正常运行。
        （2）层间通信的脆弱性。将系统隔离为多个相对独立的层，这就要求在层与层之间引入通信机制。本来“直来直去”的操作现在要层层传递，势必造成性能下降。

7.4.2 C/S 架构

        C/S 架构的脆弱性主要表现在以下几个方面：

        （1）客户端软件的脆弱性。因为在用户计算机上安装了客户端软件，所以这个系统就面临着程序被分析、数据被截取的安全隐患。
        （2）网络开放性的脆弱性。目前很多传统的C/S 系统还是采用二层结构，也就是说所有客户端直接读取服务器端中的数据，在客户端包括了数据的用户名，密码等致命的信息，这样会给系统带来安全隐患。
        （3）网络协议的脆弱性。C/S 架构不便于随时与用户交流(主要是不便于数据包共享),并且C/S 架构软件在保护数据的安全性方面有着先天的弊端。由于 C/S 架构软件的数据分布特性，客户端所发生的火灾、盗抢、地震、病毒等都将成为可怕的数据杀手。

7.4.3 B/S架构

        B/S 架构是浏览器/服务器结构模式，是一种以Web 技术为基础的新型管理信息系统平台模式，它是利用通用浏览器实现了原来要用复杂专用软件才能实现的强大功能。 

        B/S 架构的脆弱性主要表现在：系统如果使用 HTTP 协议， B/S 架构相对C/S 架构而言更容易被病毒入侵，虽然最新的HTTP 协议在安全性方面有所提升，但还是弱于 C/S。

7.4.4 事件驱动架构

        事件驱动架构的脆弱性主要表现在：

        （1）组件的脆弱性。组件削弱了自身对系统的控制能力，一个组件触发事件，并不能确定响应该事件的其他组件及各组建的执行顺序。
        （2）组件间交换数据的脆弱性。组件不能很好地解决数据交换问题，事件触发时，一个组件有可能需要将参数传递给另一个组件，而数据量很大的时候，如何有效传递是一个脆弱性问题。
        （3）组件间逻辑关系的脆弱性。事件架构使系统中各组件的逻辑关系变得更加复杂。
        （4）事件驱动容易进入死循环，这是由编程逻辑决定的。
        （5）高并发的脆弱性。虽然事件驱动可实现有效利用CPU 资源，但是存在高并发事件处理造成的系统响应问题，而且，高并发容易导致系统数据不正确、丢失数据等现象。
        （6）固定流程的脆弱性。因为事件驱动的可响应流程基本都是固定的，如果操作不当，容易引发安全问题。

7.4.5 MVC 架构

        MVC 架构的脆弱性主要表现在：

        （1）MVC 架构的复杂性带来脆弱性。 MVC 架构增加了系统结构和实现的复杂性。
        （2）视图与控制器间紧密连接的脆弱性。视图与控制器是相互分离但确是联系紧密的部件，没有控制器的存在，视图应用是很有限的。反之亦然，这样就妨碍了它们的独立重用。
        （3）视图对模型数据的低效率访问的脆弱性。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问也将损害操作性能。

7.4.6 微内核架构

        微内核架构的脆弱性主要表现在：

        （1）微内核架构难以进行良好的整体化优化。由于微内核系统的核心态只实现了最基本的系统操作，这样内核以外的外部程序之间的独立运行使得系统难以进行良好的整体优化。
        （2）微内核系统的进程间通信开销也较单一内核系统要大得多。从整体上看，在当前硬件条件下，微内核在效率上的损失小于其在结构上获得的收益。
        （3）通信损失率高。微内核把系统分为各个小的功能块，从而降低了设计难度，系统的维护与修改也容易，但通信带来的效率损失是一个问题。

7.4.7 微服务架构

        微服务架构的脆弱性主要表现在：

        （1）开发人员要处理分布式系统的复杂结构。
        （2）开发人员要设计服务之间的通信机制，通过写代码来处理消息传递中速度过慢或者不可用等局部实效问题。
        （3）服务管理的复杂性，在生产环境中要管理多个不同的服务实例，这意味着开发团队需要全局统筹。

相关推荐

【系统架构设计师】二十三、通信系统架构设计理论与实践①-CSDN博客文章浏览阅读1.2k次，点赞34次，收藏21次。通信网络主要形式：局域网、广域网、移动通信网。局域网网络架构有 4 种类型：单核心架构、双核心架构、环型架构、层次型架构。广域网属于多级网络，通常由骨干网、分布网、接入网组成。在网络规模较小时，可仅由骨干网和接入网组成。通常，在大型网络构建中，通过广域网将分布在各地域的局域网互连起来，形成一个大的网络。移动通信网为移动互联网提供了强有力的支持，尤其是5G 网络为个人用户、垂直行业等提供了多样化的服务。https://shuaici.blog.csdn.net/article/details/140826449【系统架构设计师】十九、层次式架构设计理论与实践①-CSDN博客文章浏览阅读922次，点赞32次，收藏10次。层次式体系结构设计是一种常见的架构设计方法，也称为 N 层架构设计，它将系统组成为一个层次结构，每一层为上层服务，并作为下层客户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层接口只对相邻的层可见。层次式体系结构的每一层最多只影响两层，同时只要给相邻层提供相同的接口，也允许每层用不同的方法实现，这种方式也为软件重用提供了强大的支持。大部分的应用会分成表现层（或称为展示层）、中间层（或称为业务层）、访问层（或称为持久层）和数据层。https://shuaici.blog.csdn.net/article/details/140684710