系统架构设计高级技能 · 安全架构设计理论与实践_系统架构安全性设计

学习路线：

这个方向初期比较容易入门一些，掌握一些基本技术，拿起各种现成的工具就可以开黑了。不过，要想从脚本小子变成黑客大神，这个方向越往后，需要学习和掌握的东西就会越来越多以下是网络渗透需要学习的内容：

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以点击这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

• (14)GB/T18336-2015 信息系统信息技术安全评估准则。
• (15)GB/T 20438.1~7-2017 电气/电子/可编程电子安全相关系统的功能安全，由中国国家标准化管理委员会发布。

3.3 相关标准化组织

• (1)国际标准化组织 (ISO)
• (2)国际电工委员会 (IEC)
• (3)中国国家标准化管理委员会 (SAC)
• (4)全国信息技术标准化技术委员

四、安全模型

3.1 信息系统的安全目标

信息系统的安全目标是控制和管理主体(含用户和进程)对客体(含数据和程序)的访问 。
作为信息系统安全目标，就是要实现：

• 保护信息系统的可用性；
• 保护网络系统服务的连续性；
• 防范资源的非法访问及非授权访问；
• 防范入侵者的恶意攻击与破坏；
• 保护信息通过网上传输过程中的机密性、完整性；
• 防范病毒的侵害；
• 实现安全管理。

3.2 典型的安全模型

3.2.1 状态机模型

状态机模型， 一个安全状态模型系统，总是从一个安全状态启动，并且在所有迁移中保持安全状态，只允许主体以和安全策略相一致的安全访问资源。

3.2.2 BLP模型

BLP模型（Bell-LaPadula Model）。该模型为数据规划机密性，依据机密性划分安全级别，按安全级别强制访问控制。

3.2.2.1 BLP模型的基本原理：

（1）安全级别是“机密”的主体访问安全级别为“绝密”的客体时，主体对客体可写不可读。
（2）安全级别是“机密”的主体访问安全级别为“机密”的客体时，主体对客体可写可读。
（3）安全级别是“机密”的主体访问安全级别为“秘密”的客体时，主体对客体可读不可写。

3.2.2.2 BLP模型安全规则：

（1）简单安全规则 (Simple Security Rule): 安全级别低的主体不能读安全级别高的客体(No Read Up);
（2）星属性安全规则 (Star Security Property): 安全级别高的主体不能往低级别的客体写(No Write Down);
（3）强星属性安全规则 (Strong Star Security Property): 不允许对另一级别进行读写；
（4）自主安全规则 (Discretionary Security Property): 使用访问控制矩阵来定义说明自由存取控制。其存取控制体现在内容相关和上下文相关。

3.2.3 Biba模型

Biba 模型不关心信息机密性的安全级别，因此它的访问控制不是建立在安全级别上，而是建立在完整性级别上。

完整性的三个目标：
（1）保护数据不被未授权用户更改 ；
（2）保护数据不被授权用户越权修改(未授权更改) ;
（3）维持数据内部和外部的一致性 。

3.2.3.1 Biba模型基本原理

（1）当完整性级别为“中完整性”的主体访问完整性为“高完整性”的客体时，主体对客体可读不可写 (No Write Up), 也不能调用主体的任何程序和服务 ；

（2）当完整性级别为“中完整性”的主体访问完整性为“中完整性”的客体时，主体对客体可读读可写 ；

（3）当完整性级别为“中完整性”的主体访问完整性为“低完整性”的客体时，主体对客体可写不可读； (No Read Down) ;

3.2.3.2 Biba模型安全规则

Biba模型能够防止数据从低完整性级别流向高完整性级别 ，其安全规则如下：

（1）星完整性规则(*-integrity Axiom): 表示完整性级别低的主体不能对完整性级别高的客体写数据；

（2）简单完整性规则 (Simple Integrity Axiom): 表示完整性级别高的主体不能从完整性级别低的客体读取数据；

（3）调用属性规则 (Invocation Property): 表示一个完整性级别低的主体不能从级别高的客体调用程序或服务。

3.2.4 CWM模型

CWM模型（Clark-Wilson Model）。将完整性目标、策略、机制融为一体，提出职责分离目标，应用完整性验证过程，实现了成型的事务处理机制，常用于银行系统。

CWM模型具有以下特征：

（1）包含主体、程序、客体三元素，主体只能通过程序访问客体。
（2）权限分离原则，功能可分为多主体，防止授权用户进行未授权修改。
（3）具有审计能力。

3.2.5 Chinese Wall模型

Chinese Wall模型，是一个混合策略模型，应用于多边安全系统，防止多安全域存在潜在的冲突。该模型为投资银行设计，常见于金融领域。

3.2.5.1 Chinese Wall模型工作原理

通过自主访问控制（DAC）选择安全域，通过强制访问控制（MAC）完成特定安全域内访问控制。

3.2.5.2 Chinese Wall模型的安全规则

（1）墙内客体可读取。
（2）不同利益冲突组客体可读取。
（3）访问其他公司客体和其他利益冲突组客体后，主体对客体写入受限。

四、信息安全整体架构设计 (WPDRRC 模型)

4.1 WPDRRC信息安全体系架构模型

WPDRRC(Waring/Protect/Detect/React/Restore/Counterattack) 信息安全模型是我国“八六三”信息安全专家组提出的适合中国国情的信息系统安全保障体系建设模型。 WPDRRC是在PDRR(Protect/Detect/React/React/Restore) 信息安全体系模型的基础上前后增加了预警和反击功能。针对网络安全防护问题，美国曾提出了多个网络安全体系模型和架构，其中比较经典的包括PDRR模型、P2DR模型。

而 WPDRRC模型由中国提出。在PDRR模型中，安全的概念已经从信息安全扩展到了信息保障，信息保障内涵已超出传统的信息安全保密，它是保护 (Protect)、 检测 (Detect)、 反应 (React)、 恢复 (Restore) 的有机结合，称为 PDRR模型。PDRR模型把信息的安全保护作为基础，将保护视为活动过程，要用检测手段来发现安全漏洞，及时更正；同时采用应急响应措施对付各种入侵；在系统被入侵后，要采取相应的措施将系统恢复到正常状态，这样才能使信息的安全得到全方位的保障。该模型强调的是自动故障恢复能力。

如下， WPDRRC模型示意：

WPDRRC模型有6个环节和3大要素 。

6个环节 包括：预警、保护、检测、响应、恢复和反击 ，它们具有较强的时序性和动态性，能够较好地反映出信息系统安全保障体系的预警能力、保护能力、检测能力、响应能力、恢复能力和反击能力。

3大要素 包括：人员、策略和技术 。人员是核心，策略是桥梁，技术是保证，落实在WPDRRC 的6个环节的各个方面，将安全策 预警略变为安全现实。

这里，6个环节说明如下： 生信息内容

● W : 预警主要是指利用远程安全评估系统提供的模拟攻击技术来检查系统存在的、可能被利用的薄弱环节，收集和测试网络与信息的安全风险所在，并以直观的方式进行报告，提供解决方案的建议，在经过分析后，分解网络的风险变化趋势和严重风险点，从而有效降低网络的总体风险，保护关键业务和数据。

● P : 防护通常是通过采用成熟的信息安全技术及方法来实现网络与信息的安全。主要内容有加密机制，数字签名机制，访问控制机制，认证机制，信息隐藏和防火墙技术等。

● D : 检测通过检测和监控网络以及系统，来发现新的威胁和弱点，强制执行安全策略。在这个过程中采用入侵检测、恶意代码过滤等技术，形成动态检测的制度，奖励报告协调机制，提高检测的实时性。主要内容有入侵检测，系统脆弱性检测，数据完整性检测和攻击性检测等。

● R : 响应是指在检测到安全漏洞和安全事件之后必须及时做出正确的响应，从而把系统调整到安全状态。为此需要相应的报警、跟踪、处理系统，其中处理包括了封堵、隔离、报告等能力。主要内容有应急策略、应急机制、应急手段、入侵过程分析和安全状态评估等。

● R : 恢复灾难恢复系统是当前网络、数据、服务受到黑客攻击并遭到破坏或影响后，通过必要技术手段，在尽可能短的时间内使系统恢复正常。主要内容有容错、冗余、备份、替换、修复和恢复等。

● C : 反击是指采用一切可能的高新技术手段，侦察、提取计算机犯罪分子的作案线索与犯罪证据，形成强有力的取证能力和依法打击手段。

4.2 信息安全体系架构设计

通过对网络应用的全面了解，按照安全风险、需求分析结果、安全策略以及网络的安全目标等方面开展安全体系架构的设计工作。具体在安全控制系统，我们可以从 物理安全、系统安全、网络安全、应用安全和管理安全 等5个方面开展分析和设计工作。

• 物理安全（前提）：包括环境安全、设备安全、媒体安全。
• 系统安全（基础）：包括网络结构安全、操作系统安全、应用系统安全。
• 网络安全（关键）：包括访问控制、通信保密、入侵检测、网络安全扫描、防病毒。
• 应用安全：包括资源共享、信息存储。
• 安全管理：包括健全的体制、管理平台、人员安全防范意识。

五、网络安全架构设计

5.1 OSI 安全架构

OSI 定义了7层协议，其中除第5层(会话层)外，每一层均能提供相应的安全服务。实际上，最适合配置安全服务的是在物理层、网络层、运输层及应用层上，其他层都不宜配置安全服务。

OSI开放系统互联安全体系的 5类安全服务 包括 鉴别、访问控制、数据机密性、数据完整性和抗抵赖性。

如下，信息安全体系结构示意图：

如下，安全服务和安全机制的对应关系：

OSI 定义分层多点安全技术体系架构 ，也称为 深度防御安全技术体系架构 ，它通过以下 三种方式将防御能力分布至整个信息系统中 。

• （1）多点技术防御
  在对手可以从内部或外部多点攻击一个目标的前提下，多点技术防御通过对以下多个防御核心区域的防御达到抵御所有方式的攻击目的。
  通过网络和基础设施，边界防御（流量过滤、控制、如前检测），计算环境等方式进行防御。
  (1)网络和基础设施。为了确保可用性，局域网和广域网需要进行保护以抵抗各种攻击，如拒绝服务攻击等。为了确保机密性和完整性，需要保护在这些网络上传送的信息以及流量的特征以防止非故意的泄露。
  (2)边界。为了抵御主动的网络攻击，边界需要提供更强的边界防御，例如流量过滤和控制以及入侵检测。
  (3)计算环境。为了抵御内部、近距离的分布攻击，主机和工作站需要提供足够的访问控制。
• （2）分层技术防御
  即使最好的可得到的信息保障产品也有弱点，其最终结果将使对手能找到一个可探查的脆弱性，一个有效的措施是在对手和目标间使用多个防御机制。为了减少这些攻击成功的可能性和对成功攻击的可承担性，每种机制应代表一种唯一的障碍并同时包括保护和检测方法。例如，在外部和内部边界同时使用嵌套的防火墙并配合以入侵检测就是分层技术防御的一个实例。
  外部和内部边界使用嵌套防火墙，配合入侵检测进行防御。
• （3）支撑性基础设施
  支撑性基础设施为网络、边界和计算环境中信息保障机制运行基础的支撑性基础设施，包括公钥基础设施以及检测和响应基础设施。
  使用公钥基础设施以及检测和响应基础设施进行防御。
  (1)公钥基础设施。提供一种通用的联合处理方式，以便安全地创建、分发和管理公钥证书和传统的对称密钥，使它们能够为网络、边界和计算环境提供安全服务。这些服务能够对发送者和接收者的完整性进行可靠验证，并可以避免在未获授权的情况下泄露和更改信息。公钥基础设施必须支持受控的互操作性，并与各用户团体所建立的安全策略保持一致。
  (2)检测和响应基础设施。检测和响应基础设施能够迅速检测并响应入侵行为。它也提供便于结合其他相关事件观察某个事件的“汇总”性能。另外，它也允许分析员识别潜在的行为模式或新的发展趋势。

5.2 认证框架

鉴权(Authentication) 的基本目的是防止其他实体占用和独立操作被鉴别实体的身份。鉴别提供了实体声称其身份的保证，只有在主体和验证者的关系背景下，鉴别才是有意义的。鉴别有两种重要的关系背景：一是实体由申请者来代表，申请者与验证者之间存在着特定的通信关系(如实体鉴别);二是实体为验证者提供数据项来源。

鉴别的方式主要基于以下5种：

（1）已知的，如一个秘密的口令。
（2）拥有的，如 I C卡、令牌等。
（3）不改变的特性，如生物特征。
（4）相信可靠的第三方建立的鉴别(递推)。
（5）环境(如主机地址等)。

鉴别服务分为以下阶段：安装阶段、修改鉴别信息阶段、分发阶段、获取阶段、传送阶段、验证阶段、停活阶段、重新激活阶段、取消安装阶段。

5.3 访问控制框架

当发起者请求对目标进行特殊访问时，访问控制管制设备（Access Control Enforcement Facilities，AEF）就通知访问控制决策设备（Access Control Decision Facilities，ADF），ADF可以根据上下文信息（包括发起者的位置、访问时间或使用中的特殊通信路径）以及可能还有以前判决中保留下来的访问控制决策信息（Access Control Descision Information，ADI）做出允许或禁止发起者试图对目标进行访问的判决。

5.4 机密性框架

完整性服务目的是 确保信息仅仅是对被授权者可用。

机密性机制包括： 通过禁止访问提供机密性、通过加密提供机密性。

5.5 完整性框架

完整性服务目的是 组织威胁或探测威胁，保护数据及其相关属性的完整性。

完整性服务分类有： 未授权的数据创建、数据创建、数据删除、数据重放。

完整性机制类型分为 阻止媒体访问与探测非授权修改两种。

5.6 抗抵赖框架

抗抵赖服务的目的是 提供特定事件或行为的证据。

抗抵赖服务阶段分为： 证据生成、证据传输、存储及回复、证据验证、解决纠纷这5个阶段。

六、数据库系统安全设计

6.1 数据库完整性设计原则

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

（1） 根据数据库 完整性约束的类型确定其实现的系统层次和方式 ，并提前 考虑对系统性能 的影响。一般情况下，静态约束应尽量包含在数据库模式中，而动态约束由应用程序实现。

**（2）**实体完整性约束、引用完整性约束是关系数据库最重要的完整性约束，在不影响系统关键性能的前提下需尽量应用。用一定的时间和空间来换取系统的易用性是值得的。

（3） 要慎用 目前主流DBMS都支持的 触发器 功能，一方面由于触发器的性能开销较大；另一方面，触发器的多级触发难以控制，容易发生错误，非用不可时，最好使用 Before型语句级触发器。

（4） 在需求分析阶段就 必须制定完整性约束的命名规范 ，尽量使用有意义的英文单词、缩写词、表名、列名及下画线等组合，使其易于识别和记忆，如CKC_EMP_REAL_INCOME_EMPLOYEE、PK_EMPLOYEE、CKT_EMPLOYEE。 如果使用CASE工具，一般有默认的规则，可在此基础上修改使用。

（5） 要根据业务规则对数据库完整性进行细致的测试，以尽早 排除隐含的完整性约束间的冲突和对性能的影响 。

（6） 要有专职的数据库设计小组 ， 自始至终负责 数据库的 分析、设计、测试、实施及早期维护 。数据库设计人员不仅负责基于DBMS 的数据库完整性约束的设计实现，还要负责对应用软件实现的数据库完整性约束进行审核。

（7） 应采用合适的 CASE工具来降低数据库设计各阶段的工作量 。好的CASE工具能够支持整个数据库的生命周期，这将使数据库设计人员的 工作效率得到很大提高，同时也容易与用户沟通 。

6.2 数据库完整性的作用

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

（1）数据库完整性约束能够 防止 合法用户使用数据库时向数据库中 添加不合语义的数据 。

（2）利用基于DBMS 的完整性控制机制来实现业务规则，易于定义，容易理解，而且可以 降低应用程序的复杂性，提高应用程序的运行效率 。同时，基于DBMS 的完整性控制机制是集中管理的，因此比应用程序更容易实现数据库的完整性。

（3）合理的数据库完整性设计，能够同时兼顾数据库的完整性和系统的效能。例如装载大量数据时，只要在装载之前临时使基于DBMS 的数据库完整性约束失效，此后再使其生效，就能保证既不影响数据装载的效率又能保证数据库的完整性。

（4）在应用软件的 功能测试 中，完善的数据库完整性有助于 尽早发现应用软件的错误。

（5）数据库完整性约束可分为6类：列级静态约束、元组级静态约束、关系级静态约束、列级动态约束、元组级动态约束和关系级动态约束。动态约束通常由应用软件来实现。不同DBMS支持的数据库完整性基本相同。

七、系统架构脆弱性分析

7.1 系统架构的脆弱性组成

系统架构脆弱性 包括 物理装备脆弱性、软件脆弱性、人员管理脆弱性、规章制度脆弱性、安全策略脆弱性 等。

如下， IBM 的软件缺陷分类法：

7.2 典型架构的脆弱性表现

软件架构脆弱性通常与软件架构的风格和模式有关，不同风格和模式的软件架构，其脆弱性体现和特点有很大不同，且解决脆弱性问题需要考虑的因素和采取的措施也有很大不同。

7.2.1 分层架构

分层架构被广泛应用于企业应用软件架构设计，大多数分层架构模式通常包括4个层次：即表示层、业务层、持久化层和数据库层。分层架构将应用系统正交地划分为若干层，每一层只解决问题的一部分，通过各层的协作提供整体解决方案。分层架构的脆

弱性主要表现在两个方面：

（1） 层间的脆弱性 。一旦某个底层发生错误，那么整个程序将会无法正常运行，如产生一些数据溢出，空指针、空对象的安全性问题，也有可能会得出错误的结果。

（2） 层间通信的脆弱性 。将系统隔离为多个相对独立的层，这就要求在层与层之间引入通信机制，在使用面向对象方法设计的系统中，通常会存在大量细粒度的对象，以及它们只见大量的消息交互——对象成员方法的调用。本来“直来直去”的操作现在要层层传递，势必造成性能下降。

7.2.2 C/S 架构

C/S 架构是客户机和服务器结构。 C/S分为两部分：服务器部分和客户机部分。服务器部分是多个用户共享的信息与功能，执行后台服务，如控制共享数据库的操作等；客户机部分为用户所专有，负责执行前台功能，在出错提示、在线帮助等方面都有强大的功能，并且可以在子程序间自由切换。

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

（1） 客户端软件的脆弱性 。只要安装了特定客户端软件的用户才可以使用 C/S 架构系统，正因为在用户计算机上安装了客户端软件，所以这个系统就面临着程序被分析、数据被截取的安全隐患。

（2） 网络开放性的脆弱性 。目前很多传统的C/S 系统还是采用二层结构，也就是说所有客户端直接读取服务器端中的数据，在客户端包括了数据的用户名，密码等致命的信息，这样会给系统带来安全隐患。如果这样的系统放在Internet上，那么这个服务器端对于 Internet上的任何用户都是开放的。

（3） 网络协议的脆弱性 。 C/S 可以使用多种网络协议，也可以自定义协议，从这个角度来看，C/S 架构的安全性是有保障的。但是， C/S架构不便于随时与用户交流(主要是不便于数据包共享),并且 C/S 架构软件在保护数据的安全性方面有着先天的弊端。由于 C/S 架构软件的数据分布特性，客户端所发生的火灾、盗抢、地震、病毒等都将成为可怕的数据杀手。

7.2.3 B/S架构

B/S 架构是浏览器/服务器结构模式，是一种以Web技术为基础的新型管理信息系统平台模式，它是利用通用浏览器实现了原来要用复杂专用软件才能实现的强大功能。 B/S架构的优点在于可以在任何地方进行操作而不用安装任何专门的软件，只要有一台能上网的计算机即刻，客户端零维护；系统的扩展非常容易，并且数据都集中存放在数据库服务器，所以不存在数据不一致现象。

B/S架构的脆弱性主要表现在：

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

7.2.4 事件驱动架构

事件驱动架构是一种流行的分布式异步架构，是一种适合高扩展工程的、较流行的分布式异构架构模式，有较高柔性，它由高度解耦、单一目的异步接收的事件处理组件和处理事件组成。事件驱动架构通常有两种拓扑结构： Mediator结构和Broker结构， Mediator结构通常适用于事件的多个步骤需要通过中间角色来指挥和协调的情形，而 Broker结构适用于事件是链式关系而不需要中间角色的情形。

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

（1） 组件的脆弱性 。组件削弱了自身对系统的控制能力，一个组件触发事件，并不能确定响应该事件的其他组件及各组建的执行顺序。

（2） 组件间交换数据的脆弱性 。组件不能很好地解决数据交换问题，事件触发时，一个组件有可能需要将参数传递给另一个组件，而数据量很大的时候，如何有效传递是一个脆弱性问题。

（3） 组件间逻辑关系的脆弱性 。事件架构使系统中各组件的逻辑关系变得更加复杂。

（4） 事件驱动容易进入死循环 ，这是由编程逻辑决定的。

（5） 高并发的脆弱性 。虽然事件驱动可实现有效利用 CPU 资源，但是存在高并发事件处理造成的系统响应问题，而且，高并发容易导致系统数据不正确、丢失数据等现象。

（6） 固定流程的脆弱性 。因为事件驱动的可响应流程基本都是固定的，如果操作不当，容易引发安全问题。

7.2.5 MVC架构

MVC 架构是Model、View、Controller 的缩写，它是把一个应用的输入、处理、输出流程按照 Model、View、Controller的方式进行分离，即应用可被分成三层：模型层、视图层和控制层。

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

（1） MVC架构的复杂性带来脆弱性 。 MVC架构增加了系统结构和实现的复杂性。比如说一个简单的界面，如果严格遵循MVC方式，使得模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。

（2） 视图与控制器间紧密连接的脆弱性 。视图与控制器是相互分离但确是联系紧密的部件，没有控制器的存在，视图应用是很有限的。反之亦然，这样就妨碍了它们的独立重用。

（3） 视图对模型数据的低效率访问的脆弱性 。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问也将损害操作性能。可以说， MVC架构的脆弱性主要表现在缺少对调用者进行安全验证的方式和数据传输不够安全等两个方面，这些不足也是导致MVC存在比较大的脆弱性、容易招致攻击的主要原因。

7.2.6 微内核结构

微内核架构是指内核的一种精简形式，将通常与内核集成在一起的系统服务层被分离出来，变成可以根据需求加入选，达到系统的可扩展性、更好地适应环境要求。微内核架构也被称为插件架构模式 (Plug-in Architecture Pattern), 通常由内核系统和插件组成。

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

（1） 微内核架构难以进行良好的整体化优化 。由于微内核系统的核心态只实现了最基本的系统操作，这样内核以外的外部程序之间的独立运行使得系统难以进行良好的整体优化。

（2） 微内核系统的进程间通信开销也较单一内核系统要大得多 。从整体上看，在当前硬件条件下，微内核在效率上的损失小于其在结构上获得的收益。

（3） 通信损失率高。微内核把系统分为各个小的功能块 ，从而降低了设计难度，系统的维护与修改也容易，但通信带来的效率损失是一个问题。

7.2.6 微服务架构

微服务架构是一种架构模式，它提倡将单块架构的应用划分成一组小的服务，服务之间相互协调、相互配合、为用户提供最终价值。微服务架构中的每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制相互沟通。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等中。

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

本人从事网路安全工作12年，曾在2个大厂工作过，安全服务、售后服务、售前、攻防比赛、安全讲师、销售经理等职位都做过，对这个行业了解比较全面。

最近遍览了各种网络安全类的文章，内容参差不齐，其中不伐有大佬倾力教学，也有各种不良机构浑水摸鱼，在收到几条私信，发现大家对一套完整的系统的网络安全从学习路线到学习资料，甚至是工具有着不小的需求。

最后，我将这部分内容融会贯通成了一套282G的网络安全资料包，所有类目条理清晰，知识点层层递进，需要的小伙伴可以点击下方小卡片领取哦！下面就开始进入正题，如何从一个萌新一步一步进入网络安全行业。

学习路线图

其中最为瞩目也是最为基础的就是网络安全学习路线图，这里我给大家分享一份打磨了3个月，已经更新到4.0版本的网络安全学习路线图。

相比起繁琐的文字，还是生动的视频教程更加适合零基础的同学们学习，这里也是整理了一份与上述学习路线一一对应的网络安全视频教程。

网络安全工具箱

当然，当你入门之后，仅仅是视频教程已经不能满足你的需求了，你肯定需要学习各种工具的使用以及大量的实战项目，这里也分享一份我自己整理的网络安全入门工具以及使用教程和实战。

项目实战

最后就是项目实战，这里带来的是SRC资料&HW资料，毕竟实战是检验真理的唯一标准嘛~

面试题

归根结底，我们的最终目的都是为了就业，所以这份结合了多位朋友的亲身经验打磨的面试题合集你绝对不能错过！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以点击这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！