安全防御四部曲-防护实践方案(多产品结合)

炎火
  • 收获赞:56
  • 擅长领域:阿里云技术专家,兼职信息安全。擅长领域:云计算,信息安全

本篇内容为防护(Protection),检测(Detection),恢复(Recovery),响应(Response)实践方案四部曲之一,主要介绍如何结合多产品使用在阿里云国际站做好防护(Protection)部分的安全。

本篇内容为防护(Protection),检测(Detection),恢复(Recovery),响应(Response)实践方案四部曲之一,主要介绍如何结合多产品使用在阿里云国际站做好防护(Protection)部分的安全。

1

安全防御体系简介

我们知道现在企业对信息安全的保护和管理越来越重视,而在信息安全保护的过程中,不管是目前比较通用的PDRR模型 还是Community Gold Standard v2.0标准,都是大概从四个维度去衡量安全技术防御体系,包括防护(Protection),检测(Detection),恢复(Recovery),响应(Response)。本次的实践四部曲也按照这个逻辑线进行梳理,为大家介绍如何在阿里云国际站做好安全防御工作。

一 防护(Protection)---本篇重点

安全的第一道防线会是防护。要求我们在部署的时候尽量把好关,守好门。在满足业务战略的前提下,实现IT的高效可用。

  1. 客户需要关心的:

这里面跟客户应用系统强相关的会有几件事情,需要客户在系统开发和改善过程中做好,我们之后只能更多从查缺补漏的角度协助客户,根本做好这件事还是要靠客户自己。

(1)基础架构安全:从整体基础设施架构层面达到安全防护效果,涉及到网络,主机,应用等部分。

(2)应用安全:客户在应用开发的时候就需要遵循法律法规,参考行业/公司要求,减少应用系统可能受到的攻击面,完成相应的漏洞修复,实现安全开发流程生命周期SDLC的全覆盖。---云效

(3)数据安全:完善数据采集,传输,存储,处理,交换,销毁的全生命周期的安全管控,符合国内外相应的数据安全法,在数据管理,数据技术及对外隐私声明中进行明确的实现。

(4)业务安全:业务安全非常依赖于客户自身的业务逻辑,需要客户自身做好业务风控体系,进行业务逻辑的深度分析,如动态(实时感知)+静态{功能流程}分析结合,防止薅羊毛等业务风险发生,完成自身业务可用性的测试。

  1. 阿里云可以提供的防护:

在防护的阶段,我们主要是依托安全产品的产品能力达到细致化的防护水准,有效的帮助客户做好纵深防御,守好安全的大门。

权限管控:RAM ,云SSO

网络安全:云防火墙,网络ACL,安全组

应用防护:DDoS防护,Web应用防火墙,DCDN

主机安全: 云安全中心

数据安全:加密,密钥管理服务,公网入口

二检测(Detection)

现在越来越多的企业已经认可并且在实践着云作为整个企业未来IT基础架构的基础设施和基石。那么对于企业来说,因为没有像以前那种完全处于物理封闭的IDC机房,那么当遇到问题的时候可以及时检测到问题的发生和通知相关人员就变得至关重要。那我们阿里云不仅有高性能的IaaS服务,还有很多非常好的PaaS和SaaS服务可以帮助企业从各个不同的维度发现和存储相应的日志和痕迹。

  1. 客户需要关心的:

(1)有效的监控告警:我是否可以有效的监控到我应用系统的运行状态,当出现异常的时候,可以第一时间感知到这个问题,只有第一时间能够感知到问题,才可以去处理解决。

(2)完整的操作痕迹和日志:凡经过的必有痕迹,要求保存好所有的操作痕迹和日志对之后的溯源问题,排查解决都有着至关重要的作用,同时也可以对某些有心人恶意破坏的想法和行为进行威慑。

(3)预警性的检测和发现:其实公有云发展了这么多年,大家根据走过的弯路,逐渐总结出了相应的一些配置最佳实践,我可能不是全部非常了解,那是否可以有人或者服务高效地指出我不足需要改进的地方,这样我也完善自己的配置设计。(做一个小说明,我这里会把公有云的配置检测包含在检测的这块章节,但是系统的入侵检测,比如漏扫渗透测试这种偏向红蓝对抗的检测响应我会放在响应的部分,跟应用系统强相关也更多的需要开发人员的介入和响应处理)

  1. 阿里云提供的服务:

(1)有效的监控告警:云监控,应用实时监控服务ARMS,日志服务,日志审计,配置审计,操作审计

(2)完整的操作痕迹和日志:操作审计,堡垒机,日志服务,日志审计

(3)预警性的检测和发现:配置审计

你可能会觉得有疑问,为什么有的东西出现了好几次,重复了,比如配置审计。具体的内容我们接下来的检测运维方案慢慢给大家一一道来。我先简单解释下,是因为产品的出发点的维度不一样,它的观测角度不同,看到的内容也是会有区别。下面举几个例子进行说明:

云监控主要关注点是运行时状态,服务是up还是down,

日志服务主要关注点是收集到的日志内容,有没有未授权账号登录。它就必须要有对应的日志输出,他才能进行检测,如果一个行为没有日志,比如系统CPU使用率突然升高一倍,但是系统还正常运行,没有异常日志,这种情况下日志服务观察不到,但云监控可以观察到。

配置审计主要关注点是云上配置变更,是否有不符合安全最佳实践的变更,对客户进行提示,你改了一个配置,系统状态可能还是正常的,所以这个云监控观察不到,但配置审计可以观察到。

所以我们也需要从整体多维度去完善我们的监控检测体系。

三 恢复 (Recovery)

这里的恢复主要还是侧重于数据备份,数据恢复,系统恢复。先恢复,想让系统变回正常状态。让业务可以继续处理下来。(业务价值永远第一位,工程师们可不要为了求真,为了某些问题方便复现和检查,而耽误业务恢复时间)

没有人可以保证自己的系统一直没有问题,那么怎么搭建好适合自己的高可用架构,保持业务连续性(BCP),在出问题的时候可以有相应的数据备份第一时间让系统恢复运行才是王者之道。简单说下我自己的理解,先说明一个概念,我会把高可用性和容灾分开,在我看来,高可用性是应用依靠自己的系统调度能力,比如多节点,负载调度等可以在部分组件遇到问题时仍然保持系统的运行稳定性。 容灾就是另一套完全不一样的环境,本身考虑的是地理冗余,或者一些突发的不可抗力,停电,海啸,地震等等,在传统的IDC机房时代,这也是我们常常听到的异地容灾,包括银监会和证监会要求的两地三中心都是针对这种地理容灾的场景。系统稳定性很高,但是同样成本也非常高。

  1. 客户需要关心的:

(1)应用自身的高可用性:这个是需要应用开发过程必须考量进去的问题,如果开发时候没有考虑到这点,再要改造,真的空间非常有限,也非常痛苦。

(2)数据备份的有效性:针对重要的,核心系统一定不要懒。勤做备份,保证至少一份异地存储,每个月最好对备份的有效性进行下验证,防止因为系统升级等原因,当真正出问题的时候,没办法恢复就尴尬了。

(3)容灾环境的冗余性:建议影响公司生命线的应用系统,一定要做容灾,做好容灾。在传统的IDC机房时代,异地容灾的成本代价是非常高昂的,但是云时代其实好多了,我们有不同的地域,有不同的可用性,有很多默认底层服务的打通。它的可得性变高啦。(番外:我人生中见过最认真最夸张的容灾是在日本,它的容灾演练是真的每隔半年主机房全部拉电闸断电,要求业务切换到备用机房,然后等个周末在恢复切回来,真的每次都很不容易,但是这样的系统稳定性也是特别棒的)

  1. 阿里云可以提供的帮助:

这里可能就不仅仅是纯产品化的东西,很多时候我们是提供给你底层的积木,需要你自己组合搭建最适合自己的小屋。但是确实比自己IDC机房要方便很多。希望大家可以好好利用阿里云提供的各个产品,达到自己期望的效果。

(1)应用高可用性: 多可用区 (AZ),负载均衡,多节点的数据库(比如PolarDB)等等

(2)数据有效性:快照服务,OSS存储,NAS存储,混合云存储等等

(3)容灾冗余性:多Region,云企业网CEN,数据迁移服务DTS等等

四 响应 (Response)

这里的响应主要是指的我们的入侵分析处理,安全状态评估,应急策略机制等等。遇到问题总要搞清楚它的根本原因,不管是软件的bug,还是真的有被人攻击,都要有一定的机制和手段防止这个问题再次出现。

  1. 客户需要关心的:

(1)问题发现解决方案:没有一个系统可以说自己是完美无缺的,尤其在现代这个技术迭代飞速的时代,所以我相信绝大多数系统在上线前都会进行专业的漏洞扫描和渗透测试等等专业性测试,发现容易相应的隐患和容易被攻击的故障点,然后在修复后才会正式上线。不管是针对本身Bug的:漏洞扫描,渗透测试,还是针对攻击对抗的: 蜜罐,沙箱等等,都是为了及时发现定位问题,及时解决。

(2)故障演练解决方案:我们一定都会告诉自己,出现问题,先别慌,按照应急流程进行处理和恢复。 我们会有专门的应急策略机制,有明确的行为和时间点依据,而不是自己当场手忙脚乱,所以这里应急预案和故障演练很重要。还是推荐大家至少每年进行2-3次真正的故障演练,熟能生巧,遇事不慌。

  1. 阿里云可以提供的帮助:

(1)专业的企业支持计划:帮助客户在阿里云上获得无缝的流畅体验,有专属的技术支持经理,有专属的企业钉群,第一时间协助解决的您的各种问题,保障您的企业的业务稳定性。是不是听起来很棒,确实也很棒的,

有专属的TAM会跟进每一个问题,所有的问题都会15分钟内进行初步响应,即使遇到严重故障,专属的TAM会第一时间跟客户您,产品研发同步,给出最有效的解决方案。你值得拥有。(我自己也是TAM的一员,我们一直在帮客户解决实际生产中遇到的各种问题,也积累了很多经验,算给我们团队打个硬广告)

(2)定向的安全服务:漏洞扫描服务,安全托管服务等等。

方案实施---防护实践

首先想先说明的是,本篇的内容主要聚焦在云上防护实践,但是在整个企业的lifecycle的过程中会涵盖非常多的内容,我们这部分内容只能算一个子集,其他的内容,上到空间安全,物理安全,下到SDLC,DevSecOps ,甚至一些比较细分的领域,比如ERP,DLP,邮件网关等专业防护软件都暂时先不涉及。本次的防护内容可以参考下面的简图:

11

防护模块1---权限管控

权限永远是安全防护的第一道门,当你分配了恰当的权限之后,你可以避免很多隐性的风险发生, 这也是为什么现在越来也多的企业开始重视和加强权限的管控,细分每一个账号,每一个角色的具体权限,防患于未然。

权限这块涉及到的云产品主要是单账号的访问控制RAM和多账号的云SSO。 下面就分别介绍下主要的关注点。其实这两块内容,官网已经有比较详细的文档说明了,我就不过多介绍,我这次主要帮大家把用户-角色-策略-自定义,这种脉络梳理清楚,然后具体的比较模糊的地方说一下我自己的理解,希望可以有所帮助。

22

防护产品1---访问控制RAM

访问控制大家肯定已经很熟悉了,帮大家把使用的脉络和平时可能容易忽略的点梳理下,帮助大家可以更好地实现权限管控

RAM User:每个人可以拥有独立的一个用户账号,可以给内部或者外部的同事使用。 如果内部已经有了专门的身份管理的平台,如Azure AD,可以通过SSO集成的方式,与AD打通,完全使用AD进行管理。 最适合的场景:在项目制的情况下,给外部的合作伙伴使用,然后项目完成后,可以管理员在控制台取消权限或者删除相关用户。

ram user

RAM Role:Role和 User 很多同学容易弄混。这里说下主要的区别

  1. Role 和User 都可以添加不同的权限策略,但是User是可以通过控制台登录使用,Role不可以,Role更多是赋予某个主体的权限,这个主体可以是阿里云的某个账号,某个服务,或者是Idp (联合登录使用)。

ram role
  1. Role的权限策略还是比较清晰能看到的,在Permissions里面,但是要注意的它跟User不一样,本账号的User,权限策略生效的主体都是本账号的产品和服务,但是Role可以调用到别的账号的内容,所以当你查看你不太熟悉的role作用时,要以Trust Policy Management 里面涉及的账号UID为准。

policy

SSO 集成:如果客户已经有了比如AD的身份管理,那可能客户希望全生命周期的管控都通过AD来进行。可以通过SSO管理添加Idp身份去完成这块操作,官网有很详细的说明了,这里就不再重复了。最终的效果,就是所有的管理都在AD处进行,以常用的Role-base方式为例,我们需要做的 1. 建立Idp,2. 建立对应的Role 并分配相应合适的权限 3 在AD把它的用户user和我们的role关联关系绑定好,可以让相应的用户使用指定的role进行访问。

role-based

默认域名:我们阿里云账号的识别码其实是一串唯一独立的UID数字。你可以在RAM 的总控制台看到。那当其他的用户使用ram user的方式登录,你会发现登录方式会变成 xxx@xxxxx , 后面那一段就是UID的数字,很多客户其实不希望直接把UID透传出来,那么有一个比较好的方式,修改默认域名,可以改成对应的公司名字等等。

domain1domain2

自定义权限策略:目前系统默认的策略大部分产品只有Full Access和ReadOnly Access,部分产品如费用中心BSS还有支持一些别的权限,但是如果想实现非常细的精细化管控,就要进行自定义策略的定制。现在已经非常友善化了,在控制台有个专门的 visual editor页面,支持简易化完成自定义策略的定制

visual

当然如果有的产品控制台没有完全导入的,可以参考阿里云的OpenAPI说明,里面涵盖了所有支持的API操作,目前API放开的话,在policy基本是可以实现的,但是还是需要具体测试才能确定。

比如ECS, RAM virual editor 支持 276种操作,OpenAPI 支持336个相关API。

https://next.api.alibabacloud.com/home

openapi

防护产品2---云SSO

云SSO主要跟Landing Zone进行结合,支持多账号登录权限管控的解决方案。相当于只需要在云SSO的控制台配置一次账号的权限管控,就可以应用到多个账号环境使用,而不需要每个账号环境再单独配置。

具体的配置就不一一展开,说一下主要的配置流程和需要注意的主要关注点

  1. 创建用户和用户组

这个大家都是一样的。

group
  1. 访问配置管理

只需要注意一点,访问配置管理只需要配置权限,不需要进行任何用户,用户组,和之后要进行访问的账号之间的关联,只需要把对应的policy 组创建好

policy2policy
  1. 多账号权限管理

用户--访问策略---账号是在这里进行具体的关联的。可以配置多个账号

首先,选定多个账号:

account1

其次,指定要关联的用户组和用户:account2

最后选择相应的访问策略,完成配置

account3

配置成功之后,可以在具体的账号里面查看到具体的信息

account5

SSO集成

云SSO其实是支持两种管控模式,第一种是以云SSO为管控主体,可以只把AD的用户同步过来,之后的配置都在云SSO上进行,云SSO拥有完整的增删改查的权限。 第二种就是Idp的方式,用客户自有的权限管控平台为主体,以AD为例,在这种模式下,所有的用户信息都是跟AD进行同步,云SSO相应页面变灰,无法直接操作,当一个用户在AD侧进行了删除,同步在云SSO也会进行删除。大家可以按需选择

sso

防护模块2 ---网络安全

网络安全永远都是核心,重中之重。因为每个企业的网络架构各自不同,所以我们这次不讨论具体的网络设计方案,只从安全防护的角度来看,可以实现哪些网络安全防护能力。如果真的网络设计有很大缺陷,但一时又很难改动的话,就是另一个topic,比较需要具体问题具体分析。目前我们都主要聚焦常规场景。

33

防护产品 3 :云防火墙

如果在云上使用防火墙,还是比较推荐原生的云防火墙。它主要的核心功能分三部分:南北向流量防护---互联网边界防火墙, 东西向流量防护---VPC边界防火墙,IPS能力---攻击防护与访问控制。

南北向:互联网边界防火墙

南北向,就是从阿里云---外部互联网的管控,云防火墙作为原生的防火墙,已经整合了阿里云各类网络服务的公网出口,可以自动发现互联网出口IP ,比如EIP,SLB,NAT等等,实现了互联网出口的检测和防护的闭环。

north

它的一个很大的优势:开启互联网边界防火墙不会对现有流量产生任何影响。默认是使用观察模式,只经过不处理。

默认是观察模式,客户已经根据自己的实际需求,去更改为不同的拦截模式,这里一定要配置,如果不选择拦截模式,其实就相当于云防火墙没有真正进行拦截。

firewall2

再具体的防御规则里面,其实我们提供的不仅仅只是系统集成好的开关,用户可以选择开或者关,也可以进行自定义修改,真正某些客户希望进行单独精细化管理的策略进行修订。你可以选择不同的操作行为,观察,拦截和禁用。

firewall4firewall5

东西向:VPC边界防火墙

VPC边界防火墙应该算是云防火墙跟传统防火墙会有部分引流的优势,传统的网络防御体系,即使手动路由所有的流量到防火墙,但也会有路由遗漏的风险,可能会在不同的区域部署多个云墙。 云防火墙作为原生的防火墙,可以有效确保所有流量都引流至云防火墙进行防护。如果客户有部分流量不希望经过云防火墙,也可以通过自定义路由表的方式进行实现。

VPC默认是没有进行防护,需要手动配置开启的:

vpc11firewall2firewall3

那下面简单介绍下云防火墙的VPC边界防护的原理:

云防火墙会单独有一个FW-VPC。 所有的流量,比如原来 VPC1---VPC2. 就会通过TR路由变成 VPC1---FW-VPC--VPC2.

对于所有需要防护的流量,就是你出VPC的路由选择都指向云防护墙FW-VPC,然后真正的目的地路由IP段的指向,在FW-VPC清洗之后的路由里进行配置。

然后如果有部分流量不希望经过云墙清洗,可以直接送到对应的VPC。

如果使用了CEN-TR,因为可以自定义路由选择,会复杂一些,客户可以自由选择部分VPC防护,部分不防护,比如下面的这个例子:

下面三张路由表

CEN子网路由表(不可信路由表,关联开墙VPC): 出VPC---入云墙。流量不可信,需要进行清洗。

CEN子网路由表(可信路由表):出云墙---入VPC,流量经过清洗后,变成可信,转发到相应的VPC。

CEN系统路由表(关联未开墙VPC):不经过云墙 出VPC---入VPC,流量未进行清洗,直接送达。

vpc

在CEN-TR里可以自定义多个路由表,具体的查看位置要在CEN-TR查看

cen-tr

具体细节我就不展开了,大家可以参考官网的介绍

https://help.aliyun.com/document_detail/410537.html

IPS能力---攻击防护与访问控制

入侵防御:是可以比较清晰看到最近的攻击态势。

1212

在配置里面可以针对单独的IP进行加白:1213

1214

访问控制:里面包括互联网边界防火墙,VPC边界防火墙和主机边界防火墙。

互联网边界和VPC边界需要单独配置访问控制策略(五元组控制),比较好的可以支持按照地域去做一定程度的控制。

12181217

主机边界防火墙会同步主机安全组的策略内容,可以在云防火墙进行统一的增删改查操作。1216

防护产品 4:网络ACL

在VPC的控制台,有一部分网络ACL的内容,可以对出入规则分别进行访问控制。

唯一需要注意的是: 网络ACL生效的对象是Vswitch也就是虚拟交换机。 对该交换机下面的所有网段都生效。1219

防护产品5:安全组

安全组相信很多人都已经非常熟悉了,那对于安全组来说,首先要注意的,安全组生效的范围是ECS,一台ECS可以关联到多个安全组。

那这里想强调第一点,安全组生效对象是ECS,这个不要记错了,不是VPC,生效范围是同一VPC下的ECS,所以创建安全组的时候要选择指定的VPC。

group1

然后第二点,我们有两种安全组类型:普通策略组和企业策略组。最大的区别是同一安全组内是否内网互通。

默认同一VPC是内网互通,同一普通策略组内网互通。但是同一企业策略组内网隔离。

security1222

防护模块3---应用防护

应用的owner主要还是在客户自己手上,但是我们是可以通过 DDoS,WAF,DCDN帮助客户抵御一定程度的风险。

44

防护产品6:DDoS防护

DDoS攻击相信大家都不陌生,就是通过消耗目标服务器性能或网络带宽,从而造成服务器无法正常地提供服务。

那在DDoS防护这块,阿里云其实有几种不同的产品可以支持客户进行DDoS防护。

海外区域有一个基础DDoS防护阈值,默认是500M,超过会暂时进入黑洞进行屏蔽(解除时间 :75分钟)。

https://www.alibabacloud.com/help/zh/ddos-protection/latest/view-black-hole-triggering-thresholds-in-anit-ddos-origin-basic#concept-40033-zh

DDoS原生防护

DDoS原生防护是直接为阿里云公网IP资源提升防御能力。 主要针对三层和四层流量型攻击。虽然它不像DDoS高防可以针对七层应用去进行一些精准防护,但是绝大多数DDoS攻击都是三层和四层的攻击,这才是基石性的能力。同时,一个原生防护包可以支持多达100个IP的防护,非常有效的为企业用户解决了只能单IP或域名进行清洗的防护困境。

最后一句总结把,这是DDoS防护的首选推荐,好的东西唯一的缺点可能就是贵。

YUANSHENG

DDoS高防(国际)

DDoS高防是通过DNS解析和IP直接指向两种引流方式,实现网站域名和业务端口的接入防护。

场景范围: 业务服务器部署在中国内地以外的场景,可以进行七层精准防护。

121222aa

DDoS高防(新BGP)

DDoS高防(新BGP)和DDoS(国际)的原理是完全一样的,只是使用场景不同。

场景范围: 业务服务器部署在中国内地的场景,在简单点:服务器在内地---新BGP,服务器非内地---国际。

121333

MCA IP

MCA的全称是Mainland China Acceleration,其实主要给中国内地访问海外比如香港源站的场景使用。本身它是兼备加速功能和DDoS防护能力。那使用MCA的好处就在于它走的不是全中国都在用的公网出境出口,那样的访问速度很难得到保障,繁忙时就可能会出现访问不通的情况。

1288

12889https://www.alibabacloud.com/help/zh/ddos-protection/latest/configure-anti-ddos-premium-mca

防护产品7:WAF防护

WAF做的事情就是有效识别Web业务流量的恶意特征,在对流量清洗和过滤后,将正常,安全的流量返回给服务器,避免网站被恶意入侵导致性能异常等问题。

那最主要能体现业务平稳性的指标就是QPS和带宽

QPS:Query Per Second,即每秒钟的请求量

每100 Mbps业务带宽对应约4,000 QPS的并发请求,如果这两个指标都比较平稳,说明客户业务平稳,无太大风险存在。

WAF的原理很简单,就是在DNS解析上把源站的解析地址改成WAF提供的CNAME,然后在WAF配置指向真正的源站,请求路线就变成了请求----CNAME(WAF 清洗)----源站。

如果你需要DDoS高防和WAF进行同时部署,那么同时部署一般的顺序是这样的:

DDoS高防(入口层,防御DDoS攻击)->WAF(中间层,防御Web应用攻击)->源站服务器(ECS、SLB、VPC、IDC等)

12900

WAF在国际站其实是有两个版本,中国内地版本和海外版本的,接下来想跟大家讨论下在实际使用中要如何进行选的。

跨境防护

WAF本身就是一堆防护规则的组合,那这里不同版本的区别本质还是涉及到了跨境的问题。

现在假设一个场景, 客户的源站在香港,但是它需要服务中国内地及海外的用户。

  1. 如果客户的DNS解析支持按地域解析,可以考虑分别CNAME解析到两个地域的WAF。中国内地的WAF解析之后可以接GA来到香港,保证网络质量。

  2. 如果不支持分地域解析,那可能需要考虑下用户分布和业务类型,但一般来说,选择同源站区域的WAF情况比较多,就是海外版本的WAF,中国内地的流量先跨境过来,再进行清洗。

  3. 你可以看出来前两个方案有个很大的区别,是先过WAF,还是先跨境。 这个就是说的要结合实际情况来看的。先过WAF,WAF的成本高一些,但实际到源站的流量肯定比未清洗要小一些,那如果选择GA这种加速线路,带宽也可以买小一些。

防护产品8:S-DCDN

S-DCDN ,S代表的就是security的意思,你可以理解为跟安全能力结合的更好的CDN服务。你可以在它的控制台看到有内置的DDoS模块和WAF模块。S-DCDN

前面都已经比较详细了介绍了DDoS和WAF的防护,这里就不再做赘述。这里想跟大家解释的是把这部分安全能力内置的好处是什么,也可以帮助大家更好的理解和选择。

内置联动

传统模式下:你的CDN,DDoS,WAF可能都是分别购买,那么它们每一个都是独立的产品。基本是需要流量在一个产品内部流转完,再到下一个产品。

CDN部分是有边缘节点的,它的调度逻辑是靠流量调度器去调节加速,如果不联合内置的话,一旦这个流量切走,比如切到了高防服务上,那么加速效果就会受到影响。这个是最关键的产品内置整合的原因啦。

防护模块4---主机防护

主机防护的内容主要是依靠云安全中心实现的。

55

防护产品9: 云安全中心

云安全中心其实包含了非常多的内容,说三块大家需要可能会忽略的内容,帮助大家进行一下查缺补漏。云安全中心的所有检测机制都是基于实例要首先安装云安全中心的agent。

安全Agent

可能有的人会说我好像没有单独安装过安全agent,但是一直也可以使用云安全中心。这个是因为其实在你创建ECS的时候,默认勾选是已经安装了安全agent,你就不用单独在进行安装了。

SE1

当然,在云安全中心里面,也有统一查看目前agent的安全情况,如下图:

se2

防勒索

防勒索的功能是需要你去手动配置的。其实防勒索的原理就是对你指定目录进行防护,即使被勒索病毒攻击,也可以有途径对你的文件内容进行修复。因为防勒索的容量需要单独购买,所以要自己建防护策略指定防护的服务器和路径才可以生效的。

se3se4

容器安全

云安全中心最大的亮点之一就是可以做到容器安全。 虽然目前只有旗舰版才支持容器安全防护的功能,但是已经是一个很大的进步。最核心的三个功能就是容器镜像扫描,容器防火墙,和容器主动防御,但目前还不是全自动化,需要配合手动操作才可以起到良好的防护效果。

容器镜像扫描

se5容器防火墙要手动开启:

se6

容器主动防御也要主动去配置激活:

se7se9

防护模块5---数据防护

数据防护其实是一个非常大的话题,也可以讨论的非常非常深入,这个权衡选择也是需要根据企业的实际情况去决定,因为在数据防护这部分最现实的问题的,比如加密,如果做了加密,一定会对性能和存储容量会轻微影响, 也根据加密形式不同,透明加密影响最少,BYOK相对影响更大。还是那句话,选择最适合自己的,不要选择最贵的。

66

防护产品 10 :KMS 密钥管理服务

密钥

KMS可以提供密钥的全托管和生命周期的保护能力。如果需要有定期自动rotate需求的话,KMS可以说是非常必备的能力。

kms1

凭据

简单来说,凭据就是进行二次加密后,帮助你规避在代码中硬编码凭据带来的敏感信息泄露风险。

使你在全生命周期中都不会有机会去泄漏真正的用户名和密码,达到良好的保护效果。

kms2

防护产品11:加密

对很多客户来说,加密的能力也很重要,很多客户有了对镜像,云盘,OSS等进行加密的要求。那这个我们都是可以实现的。 那简单介绍下加密最主要分几大类, 1. 直接用产品的透明TDE进行加密,好处是在整个使用过程中用户是无感知的,非常的方便快捷。2. 对于自管理要求比较高的用户,可能需要指定密钥BYOK的方式,拥有更强大的管理能力。

RDS

创建时候就需要选择是否针对云盘进行加密RDS

OSS

OSS也最好在对应的bucket设置好加密配置

oss

防护产品12:公网出口

最后的,除了网络侧的常见的EIP,SLB的公网出口之外,其实某些产品也会出于功能需求,可以开放对公网访问出口,这时候就要尤为注意对这种出口的管控了。

OSS

OSS如果开放公共读写或者公共读,导致数据泄漏,造成的影响可能是非常大。所以对这里选择公共读写和公共读一定要慎重。

OSS11

Database

对于云上的数据库,例如RDS,PolarDB,Oceanbase这些,可能有要开放外部直接接入访问的数据入口,这时候就需要进行严格管控。如果因为应用没有在同一个云上环境,那也一定要记得设置白名单去进行精细化的IP限制。

88