云布道师

2024 开年伊始，阿里云弹性计算团队全新推出新一季【ECS 安全季】，通过分享云上安全体系相关产品与最佳实践，让用户快速上手构建业务的安全防护能力。

首节课程《如何全方位构建 ECS 的安全体系》由阿里云弹性计算高级产品专家马小婷带来，课程涵盖了“云上安全的重要性、云安全责任模型、ECS 安全能力大图解读”等内容，本系列全部课程也将在阿里云官网、阿里云官方微信视频号、阿里云官方钉钉视频号、阿里云开发者微信视频号同步播出。

以下内容根据课程整理而成，供各位开发者阅读：

对于安全问题，很多用户的直接反应就是操作是否太难？没有安全背景和基础能否快速上手？又或是云上业务规模很小，是否需要知道并了解这些安全措施呢？结合以上的种种问题，今天的分享希望带给大家两个收获：第一点是让大家对 ECS 的安全责任边界和作为 ECS 的用户所肩负的安全责任有基本的认知，第二点是让大家能够掌握一些解决 ECS 常见问题的一些安全技巧，通过本节课程的学习，大家可以立马用起来，毕竟安全无小事。

本次的分享主要分为以上四个方面。

云上安全的重要性

首先我们来关注一下云上安全的重要性，一直以来安全问题都是用户上云最关心的问题，我们得到的调研报告显示 96% 的受访者其实非常关注云上安全问题，同时有70% 及以上的用户对云上的安全状态信心是不足的。

想要告诉大家的是，这种担心并不是可有可无。随着全球信息化浪潮的不断推进，我们发现针对数据安全的风险也在不断上升，甚至愈演愈烈，这一部分的风险也来源于攻击者不断进化的攻击手段和日趋增加的安全事件。根据 cyberattacks-2022 年的数据统计显示，2022 年全球网络攻击事件相比增加了 38%，而网络攻击带来的后果一般都非常严重，不仅会导致我们的业务中断不可用，而且会导致敏感数据泄露，以致带来严重的经济损失，比如病毒勒索等。根据 IBM 调查报告显示，2023 年因为数据泄露导致的平均损失高达 445 万美元，而数据泄露的平均周期是 277 天，这也意味着企业在遭遇了数据泄露以后，平均需要花费 277 天来识别并控制一个活跃的数据泄露，时间成本和经济成本非常高。那么除了日趋复杂和严峻的安全环境之外，我们来看看 ECS 的用户们经常遇到的威胁都有哪些。

其实很多用户上云购买的第一个云产品就是云服务器 ECS。我们发现很多用户在使用 ECS 的过程中存在着一个误解，那就是购买了 ECS 之后就可以“安全无患、高枕无忧”，其实不然。上图列举了目前 ECS 面临的一些典型的安全威胁，相信各位开发者可能也遭遇过。比如各位的实例遭遇 DDos 攻击，导致整个应用拒绝服务，或者ECS 中了勒索病毒，导致数据无法被找回，又或者实例登陆密钥被泄露，导致数据被删除无法找回等等。

其实大家遇到的问题只是 ECS 安全问题的冰山一角，在阿里云后台，我们每天默默处理掉的 ECS 的各种安全问题数量也非常惊人。阿里云每天发现并发出以上的漏洞病毒告警超过 10 万次，每天帮助用户清理的 DDos 攻击流量高达 2.08 Tdps，而我们每天扫描出来的操作系统这种安全漏斗高达 3 亿个，每天帮助客户清理的黑客工具高达 700 万个，这些问题每天依然在发生，那么导致以上问题的根因是什么呢？

当前云计算安全建设的主要驱动力其实是合规性要求，我们对安全攻击和防护的重视度是远远不够的，而安全的本质其实是对抗，要抵御各种威胁才是提高安全的最终目标。随着云计算得到了广泛的应用，聚焦于云计算的攻击者其实会搜集网络上各种云服务，进而去发现脆弱性并且加以利用。这些脆弱性主要来源于上图展示的五个方面。

根据 2023 年 cloud security Alliance的top cloud security challenges 我们可以看到，首当其冲的是用户配置不当导致；其次是因为客户在云计算的技能不足导致；第三是多云环境下的能见度不足导致的。根据 Gartner 预测，到 2025 年，由于用户配置不当导致的安全问题的比例可以高达 99%。由此我们可以看到很多安全问题最终的根因其实归结为两点，第一个其实就是安全意识的不足，第二个是我们安全实践技能相关的缺失。

安全意识的不足这一点大家有目共睹，尤其是在我们 DoveOps 这种开发模式下，为了提升我们的开发效率，我们的开发运维团队会大量使用三方开源工具或者一些软件库，甚至是一些公开的容器镜像。这些开源软件或者是镜像中如果存在了一些安全漏洞，或者说遭遇了恶意污染，但我们的开发运维同学并不会去做严格的安全风控。最终如果用户使用了这些软件，那么接下来大家的业务则会面临着一些安全的风险，同时我们也注意到有很多人在无疑是的把业务中的一些敏感代码或者数据在互联网上进行托管，这种操作其实也会存在着一些数据泄露的安全风险。

另一个调查可以显示，23% 的企业承认自身的业务其实对网络攻击的准备是不足的，而 50% 的企业承认自身的网络安全水平其实是落后于起初规划的。其中一方面是因为大家自身技能的确实，另一方面也是大家不得不考量的成本问题，所以我希望今天的分享能够给大家做到安全方面的基础的科普，以及安全尝试，帮助大家尽量做到尽量避免因为配置不当或者意识不足导致的业务风险问题。

安全责任共担模型介绍

第二部分将为大家详细介绍 ECS 的安全责任共担模型。这个责任模型是我们进行云上安全实践的重要基础，也是主要依据之一。在介绍模型之前，先为介绍一下 ECS 的底层架构，因为这也是我们对 ECS 的安全性进行配置的一个基础。

在传统的云下应用架构下，搭建一个信息系统，需要自行负责信息系统所以来的所有底层软硬件的资源和服务搭建。如果把信息系统的搭建比作为一个房子，那在我们的传统服务模式下，我们则需要自行准备搭建一个房子所需要的全部资源。其实这里可以类比为我们在乡下宅基地自建房，需要选址打地基，设计房屋构造和布局，拉上水电煤等技术服务，最后做内部装潢，可能还需要判断房子外围是否需要加盖院子和围墙，来保障房子的安全。所以我们可以看到，在传统架构下，所有的任务和服务都需要我们自行设计、自行管理和自行维护。

而在 infrastructure as service 基础设施及服务这种的服务模式下，我们可以看到云服务提供商就像房地产开发商一样，每一个基础且重要的“建房步骤”都由云服务提供商来负责管理和维护，同时他们还需要保障不同的用户或者不同房子之间的资源隔离问题，需要做到互不影响。而我们作为用户，只需要根据业务需要以及当前的属性去做一些选择和配置即可。

那我们来看一下选购一个 ECS 和选购一个“房子”有哪些重要的参考参数呢？

首先就是选择地域和可用区，ECS 的地域和可用区类似于房子地段的情况，地段由城市和县市决定。在地域和可用区的选择上，主要交由用户选择。建议大家选择在更靠近业务服务的目标用户的区域，这样整个网络延迟相对更低。

其次选择对应的 VPC 和交换机。VPC 是用户自定义的一种私有网络，而不同的 VPC 之间在逻辑上是完全隔离的，但同一个 VPC 中子网又是默认互通的，交换机则是将一个 VPC 划分成一个或多个子网，所以从这个概念上来说我们可以把 VPC 理解为一个小区，同一个小区中的房子在不出小区的情况下就能够互通，如果我们在一个小区中有多套房子，就可以通过交换机操作类似单元楼的方式进行划分，方便管理。所以在某种程度上，我们选择 ECS 的 VPC 和交换机，其实就相当于我们在选择房子所在的一个小区和单元楼。

然后我们要选择 ECS 镜像。ECS 镜像我们也叫操作系统，其实我们在选择镜像的时候，可以分不同的类型和版本，比如我们选择 Windows server 2023 这个版本。这就相当于我们去选择这个房子的户型究竟是三室两厅还是两室两厅。

下一步选择对应的 ECS 安全组。安全组其实是一个虚拟的防火墙，主要用来控制安全组内的 ECS 实例的入出方向的流量，相当于我们设置的一个“规则”来允许什么人可以进出单元楼，所以我们可以把安全组类比做门禁卡，可以通过设置门禁卡的规则来限定什么样的人能够进入我们的小区，进入我们的房子。

最后则是选择实例的用户名和密码，也就相当于“房子钥匙”，不同的人可以用钥匙打开我们的门，进入到房子中去，所以如果我们的用户名和密码没有得到很好的保障，则相当于我们的钥匙也没有得到很好的保管，那么我们整个 ECS 其实是可以任由大家访问的。

理解了整个 ECS 架构，我们就可以看到作为 ECS 用户，我们就相当于一个房子的租客一样，需要我们作为租客（用户），对房子中所有的基础设施的配置来负责，包括对应的 ECS 有没有设置对应的网络隔离，整个实例操作系统的安全性有没有得到保障等等，以及有没有设置对应的访问策略，以及在里面跑的这些应用是否安全。这意味着整个 ECS 内部的这一部分是由我们作为用户，需要自己管理并负责的。而云服务提供商其实就和房地产开发商一样，主要负责两部分的安全，第一部分其实负责对整个地域和可用区里面的基础设施进行和管理和维护，第二部分其实对于我们这个虚拟化服务和云产品的管理和服务进行负责。

在了解底层架构之后，我们再来讨论 ECS 的安全责任共担模型，其实就会发现，这个模型会更清晰。上图右侧列举了云服务提供商和我们的用户之间的责任边界，可以看到云服务提供商对云本身的安全性负责，而云本身的安全性分成了两个维度，第一个就是基础设施的安全性，第二个是云服务的安全性。基础设施的安全性主要包括底层硬件的主机安全，以及一些虚拟化的安全。要提供一个安全、合规、可靠的基础设施，这也类似于我们房子的地基，房子的地基是否安全，房体所使用的钢筋水泥土是否符合国家建筑安全的规定。云厂商的第二个安全责任就是需要对云服务的安全性负责，主要是云服务本身是否安全。

而在这个基础上，用户侧需要围绕云上安全性需要做哪些事情呢？上文介绍到了 ECS 一些重要的参数和组件，其实也是我们在提升 ECS 安全性方面所需要考虑的几个维度，目前我们可以分为四个维度。

最底层 GuestOs 安全其实是我们 ECS 所有安全的基础，相当于房子的门窗和钥匙是否安全。其次是访问安全，本质上来说，主要控制有哪些用户能够访问我们的实例。第三块是网络安全，主要通过网络隔离和网络控制手段提升整个网络的安全性。最后一部分是数据安全，也是云上安全的最终目标，当然其中也存在着不同的维度，比如我们可以用快照做数据备份，也可以对存储的数据进行加密，甚至可以通过机密计算的方式保证数据在计算过程中的安全性，这里预告一下，数据安全在后续章节也会有讲师为大家做深入的开展。

整体来说，ECS 的安全责任共担模型明确了云厂商和用户大家的责任边界，以及在每个维度上用户能够做的提升 ECS 安全性的一些事情。

前面介绍的安全责任共担模型其实是一个整体大原则，根据《中华人民共和国网络安全法》以及《互联网信息服务管理办法》等相关法律规定，他们对厂商和云平台其实提出了更多的法律监管的要求，也意味着云平台除了前面提到的需要对云本身的安全性负责意外，还需要根据国家的法律法规对以下的两类违法行为进行主动管控。

第一点要强调的就是 ECS 上的一些违法行为，第二个则是 ECS 上的一些违法信息。第一类是违法行为，包括我们在 ECS 上对其他云产品发起攻击，或者说我们对云产品进行一些扫描、渗透、测试等探测行为，或者我们使用云产品去搭建 DDos 的防御服务，还包括我们使用云产品从事一些虚拟货币相关的工作活动，比如挖矿等，均属于违规行为。第二类是违法信息，指的则是我们在 ECS 上搭建一些网站服务，提供色情低俗的内容，或者有欺骗、赌博等非法行为，以及出现危害国家安全，破坏政治社会稳定的信息。在这种情况下，云平台有权依照相关的法律采取相应的封禁措施。

对于存在一般违法行为的 ECS，阿里云会对 ECS 上的 url 和域名采取一些阻断动作。如果出现账号被封禁，用户可以申请免费解禁，或者申请主动解禁。但对于严重的违法行为，我们除了阻断 url 和域名访问意外，还会禁止用户解禁，除非用户把数据完全删除/完全释放，才会解禁。对于情节严重的违法违规行为，我们会对 ECS 采取关停甚至限制对应账号访问的行为。当然如果用户在使用 ECS 过程中，因为上述问题被阿里云采取了封禁措施，用户也会收到对应的 ECS 系统事件以及对应的短信、邮件、站内信的通知。大家可以根据对应的通知来采取相关的措施进行及时清理。如果没有及时清理，接下来 ECS 可能就没有办法正常使用。

ECS 安全能力大图解读

第三部分我将为大家进行 ECS 安全能力的全貌解读。上文《安全责任共担模型》中提到，云厂商负责云本身的安全性，而用户需要对云上的安全性负责。那在云上安全性这个维度上，阿里云也提供了一系列的安全能力和云产品和功能，来帮助大家快速的完成对应的安全能力的构建。在这里我们将 ECS 的安全能力主要分成了以下五个维度。

第一个是 GuestOS 安全的安全，GuestOS 安全的安全前面提到其实就是 ECS 对应的实例操作系统贵的安全性。操作系统的安全性其实是 ECS 安全性的基础，主要也包含了两部分的安全，即操作系统本身的安全和登录安全。这两点类比的话，相当于房子的门窗是否紧锁，以及钥匙和门禁卡是否安全。

第二个是网络安全。网络安全是最容易忽略的。因为上云之后，所有的资源都在网络上，意味着人人都可以看到，如果设置不当，也可能会导致人人都能够访问。在这种情况下，如何能够进行安全保障呢？类比过来就相当于我们在地图上能够看到房子，但并不是所有人都能够进入到房内，因为单元楼和小区起到了物理的访问隔离的作用，加之门禁卡，就在访问隔离和访问安全控制下，更好的保障了房子的安全性。在网络上也是一样，可以通过设置对应的访问隔离，比如 VPC 的隔离策略来保证某些网络没有办法被其他网络访问，同时还可通过设置对应的安全组访问策略来限制“进去的人”和“出去的人”，进而提升 ECS 的网络访问安全性。

第三部分是身份与访问控制。这就不是从单个资源角度出发，而是从一个组织/公司中很多人在共同使用资源的角度出发。相当于一个公司有很多房子，分布在多个小区和单元楼，公司中什么样的人能够访问什么样的资源，对于核心资源的使用过程需要多次验证，临时来访用户需要临时授权等等，需要能进行精细化管理，同时还需要定时 review 过去一段时间内，有什么样的人通过什么样的方式访问了“房子”。所以某种程度上，身份与访问控制更多的是从一个组织的角度出发，对整个组织下面的多种角色以及访问行为进行全面的控制，同时还可以做审计，这样可以保证我们云上的资源访问能够可追溯且可授权。

第四部分是应用安全。顾名思义，应用主要指的是 Web 应用，或者说一些APP应用，主要作用其实是对外提供服务，并不是所有用户买了 ECS 都一定会对外提供服务，但一旦我们会外提供服务，最重要的就是保障服务的可用性。那么如何保障我们服务的可用性？阿里云提供了非常多的工具和产品，比如 Web 应用防火墙，它可以抵御各种常见的外部攻击。对于网站式 APP 的业务流量进行恶意特征识别，然后对流量进行清洗和过滤，能够把正常的流量返回给服务器，来避免网站服务器被恶意入侵，从而保证整个网络的业务安全。

最后一点数据安全。数据安全是所有安全防护的终极目标，数据安全也是一个端到端的安全保障机制。因为数据本身存在三种状态：静止态、传输态、使用态。静止态指数据存放在某种地方，可能存在被误删/被删除的风险，可以通过定期数据备份保障对应的数据安全。同时，还可以通过数据加密的方式保证静止态数据安全。数据加密可以防止数据泄露，保证数据在传输过程中的安全性。使用态的数据使用安全，一般指的是在内存中读写的数据安全性，而机密计算其实是通过一种基于硬件的可信执行环境来达成在计算中保障数据安全的目的。所以数据安全更多的是一种端到端的安全保障机制，如果大家的业务对数据安全有更高的要求，则可以选择性的采取必要的措施来保障数据安全。

为了进一步降低用户使用以上各种工具的门槛，我们提供了 ECS 使用成熟度评估与洞察这个产品，它基于云上的最佳实践和在其中提到的云上基础和安全保障能力，为用户做更多的风险识别，并且能够为大家提供对应的修复建议，最终提升整个 ECS 安全性。

下面将为大家介绍两个最佳实践，让大家有更直接的体感。

第一个是最佳实践是围绕 Guest OS 安全性提升的。前面提到了，Guest OS 的安全性是整个云上安全的基础。它分为两个维度的安全，首先是登陆安全，第二个是操作系统的安全。那如何从这两个维度上去提升我们 Guest OS 的安全性呢？围绕着登陆安全这个维度我们有几个简单的 tips。

首先当然是使用非 root 账号登录。我们常见的比如阿里云侧我们会推荐大家使用ECS uesr 账号登录，而不是默认的 root 账号。如果大家的能力更高阶，我们会推荐用户使用 Linux 系统，使用 ssh 密钥对进行登录，无需密码，安全性更高。但不管我们使用非 root 账号的登录，还是使用 ssh 密钥对登录，都需要定期更新登陆凭证，避免密码泄露带来的风险。如果我们对 ECS 的登陆安全有更高的要求，则可以使用我们提供的云助手提供的会话管理功能。它类似于堡垒机的功能，在不需要密码的情况下能够安全的登录到 ECS 的实例上，同时也可以通过会话管理或是workbench 对所有的登陆操作进行追溯。

关于操作系统安全，上文我们也提到操作系统的安全相当于整个房子的门窗是否安全，所以在这部分，我们首先推荐用户开启镜像加固，使用免费版的云安全中心对操作系统中存在的安全漏洞进行扫描并定期修复。同时，云安全中心的收费版不仅可以对系统漏洞进行修复，同时还能够对操作系统中存在的木马和病毒进行扫描和修复。当然如果我们有足够的能力且没有付费意愿，还可以通过系统运维管理的补丁管理去自动设置对应的补丁扫描，并且设置对应的修复策略。系统补丁管理程序则会根据设置自动扫描对应的操作系统中的补丁情况，并根据指定的修复策略自动完成对应的补丁修复，并且帮助我们去重启实例，保证补丁得到最新的修复。此外，如果我们对安全等保这个地方有要求，也可以使用阿里云提供的原生操作系统——Alibaba Cloud Linux 等保 2.0 的镜像来提升整个操作系统的安全合规要求。

上图中展示的灰色部分是基础能力，也意味着我们推荐所有用户都采用这样的策略，黄色部分是高阶能力，推荐大家按需使用。

第二个最佳实践实际为一个综合性解决方案。我们发现很多用户在安全维度面临的问题是，用户无法判断当前自身业务是否存在安全隐患，所以也无法进行优化/改进。同时，有些用户想要做一些安全性的改造，却不知道从哪里可以入手且快速看到效果。正如我们前面介绍的，绝大多数安全性问题其实是由于用户配置不当或者意识不足导致的，所以对绝大多数用户而言，我们提升安全性的第一步是要识别我们当前的安全风险。那如何能够快速识别我们业务中常见的通用安全风险，进而防患于未然呢？

在这里，ECS Insight 是我们推荐的一款一站式解决方案，它能够帮助用户快速发现问题，并且识别问题的严重程度，同时推荐对应的解决方案。对于没有太多安全基础，但想要提升安全性的用户来说，不清楚第一步如何“落脚”，那么 ECS Insight 是一个快速上手的好选择。ECS Insight 是一款免费的风险识别类产品，当我们开通服务以后，会自动对我们 ECS 和关联资源的分布、使用、配置等信息做分析，并结合机器学习算法进行建模，最终结合云上的最佳实践和最佳方案，给用户最终提供两个输出。

第一个输出是使用成熟度整体评估，它会从 ECS 的基础能力、成本、自动化、可靠性、弹性、安全性六大维度对当前业务进行一个整体评估，每个维度 100 分。如果该维度存在风险，则会进行扣分。第二个输出是对应的风险应对优化推荐方案。对于每个维度的失分项，ECS Insight 都会根据该问题的严重程度来进行区分。对于高危项，我们推荐用户立刻采取行动进行修复，对于告警，我们推荐用户选择合适的时间及时进行修复。对于提示项、不适用项和健康项，我们只是作为参考。所以在以上的几种情况下，我们借助 ECS 能够快速、一键式的识别当前业务存在的安全风险，并及时修复，防范于未然。

下面为大家介绍一下 ECS Insight 的简单的 demo。大家登录 ECS 的控制台，在导览页里面就会有一个 ECS Insight 使用成熟度评估与洞察这样的一个入口，用户则需要先申请开通这个服务，开通之后需要花费 t+1 的时间对当前账号下所有资源的分布、使用、配置等信息去做一些数据的采集，建模分析，最终就会为大家产出一个分析报告。

其实我们可以看到它主要分为了六个维度，也是从这六个维度的角度上做了评分。每个维度的分值以及对应的总分，这些都可以看到。对于没有得分的项，ECS insight会根据对应问题的严重程度归类。对于高危项和警告项，是需要用户立即采取行动的。而对于不适用项和提示项，其实是 nice to have 的能力，用户可以适当做一些参考。在安全能力维度上，我们可以看到 ECS Insight 目前提供的是通用的安全评估能力，主要包含网络安全能力、实例访问安全能力和实例数据安全能力三个维度，每个维度都提供了详细的安全风险评估标准。对于未得分项，都可以点开具体看到评分规则，以及对应的受影响的资源是什么，以及对应的修复建议和对应的最佳实践。

最后我们可以参考最佳实践和对应的修复建议来完成相关的配置修改，就能够完成相关的风险修复，也欢迎大家到 ECS Insight 页面上体验我们的产品，从而达到 ECS 安全性的提升。

云上安全的展望

最后为大家分享我们对云上安全的展望。

第一个是机密计算。上文提到的，网络安全很大一部分其实是为了保障数据安全，而数据根据其情况我们可以分为静止、传输和使用中三个状态。而存储的数据属于静止态数据，在网络中属于传输态，而正在处理的数据则属于使用中的状态。前面提到的加密技术主要用于提高数据的机密性，进而防止一些未授权的访问和保障数据完整性，也就是防止未经授权的修改，它主要用户保护传输中和静止状态的数据。那么数据在内存中使用时如何保证其安全性呢？这其实就是机密计算的目标场景了。

机密计算通过在基于硬件的可信执行环境中执行计算的方式来保证使用中的数据的安全性。而可信执行环境则通常被定义成能够提供一定程度的数据的完整性、机密性和代码完整性来保护环境。而基于硬件这样一个可信执行环境，主要使用我们芯片中的一些硬件支持的技术，为代码的执行和环境中的数据提供保护，从而提供一个更强的安全性的保证，进而有效预防基于内存的攻击手段，比如 target 的安全事件和 CPU的侧通道攻击，它能够防御一些恶意软件入侵的攻击手法，比如乌克兰的电网攻击。对于机密计算感兴趣的同学可以听我们后续的其他讲师的一个专题的分享，在这里面我可能就不做详述了。

第二个是零信任安全。零信任安全其实是一种安全理念，它的基本原则其实是不信任任何设备和用户，除非验证其可信。同时，用户和设备在经过验证之后还会持续监控设备的安全状态和用户行为，一旦发现信用等级下降，则需要动态的调整访问级别，并在需要的时候去切断对应的访问会话。所以，零信任本质上来说是一种更安全的云上设备和身份的验证。

在传统的网络安全保障机制中，主要通过子网划分、安全域划分、网络控制等手段去实现网络管控。随着网络设备和云计算被广泛使用，也让企业员工在任何时间、任何地点、都能够使用任何设备来访问企业资源这是一种常态的趋势，在这种趋势下，我们认为零信任的安全则是一种更安全、更有效的安全防护机制。

最后想和大家分享的一点是“当安全性遇到 AI”。其实 Gartner 早在 2016 年就提出了 AIOps 的概念，并在 2017 年把它明确定义为需要借助人工智能的算法提供具有一些动态性、预测性的一个洞察能力，最终实现 IT 运维自动化的能力。在AIOps中，我们可以看到 Gartner 主要强调了三个关键点。第一要使用 AI 算法，第二要能够发现并识别一些异常信息，第三是要能够完成一些自动化的运维执行。所以，虽然 AIOps 很多时候强调的是智能化运维，但是我认为在安全领域下，这三个关键点依然是有效的。所以当安全性与 AI 相碰之后，我们认为 AIOps 在安全这个领域维度上也应该能够实现，能够借助我们 AI 算法去识别一些危险的洞察，并且能够去归纳其攻击行为和攻击意图，并且能够自动化的给出执行建议，同时自动化的辅助/帮助用户完成对应的安全措施。

以上就是本次课程的全部内容。