本次方案主要是针对阿里云国际站客户，企业在实际使用阿里云的过程中如何做好运维检测的一些多产品结合的方案介绍。 本篇文章的重点会放在检测（Detection）部分，会具体介绍涉及使用产品配置，FAQ等等，同时对整体的理论框架进行简单的介绍，帮助大家更好理解本部分在运维工作中的分属情况，更好的建立整体性的概念。
1. 方案介绍
我们知道现在企业对信息安全的保护和管理越来越重视，而在信息安全保护的过程中，不管是目前比较通用的PDRR模型还是 Community Gold Standard v2.0标准，都是大概从四个维度去衡量安全技术防御体系，包括防护（Protection），检测（Detection），恢复（Recovery），响应（Response)。我们今天重点会放在检测（Detection）部分。
先简单介绍下针对这几个不同维度内容我自己的理解，本次运维方案主要的重点在检测（Detection）这部分内容：相对来说，检测的通用性普适性更强，而其他不管是防护，恢复，还是响应都跟业务系统的特性有强相关性，需要更多的根据具体问题具体分析解决。话不多说，步入正题。下面会附上本次方案主要涉及的产品及内容的导图。
2. 架构简介---安全防御体系
2.1 防护（Protection）
安全的第一道防线会是防护。要求我们在部署的时候尽量把好关，守好门。在满足业务战略的前提下，实现IT的高效可用。
客户需要关心的：
这里面跟客户应用系统强相关的会有三件事情，需要客户在系统开发和改善过程中做好，我们之后只能更多从查缺补漏的角度协助客户，根本做好这件事还是要靠客户自己。
应用安全：客户在应用开发的时候就需要遵循法律法规，参考行业/公司要求，减少应用系统可能受到的攻击面，完成相应的漏洞修复，实现安全开发流程生命周期SDLC的全覆盖。
数据安全：完善数据采集，传输，存储，处理，交换，销毁的全生命周期的安全管控，符合国内外相应的数据安全法，在数据管理，数据技术及对外隐私声明中进行明确的实现。
业务安全：业务安全非常依赖于客户自身的业务逻辑，需要客户自身做好业务风控体系，进行业务逻辑的深度分析，如动态（实时感知）+静态（功能流程）分析结合，防止薅羊毛等业务风险发生，完成自身业务可用性的测试。
阿里云可以提供的防护
在防护的阶段，我们主要是依托安全产品的产品能力达到细致化的防护水准，有效的帮助客户做好纵深防御，守好安全的大门。
应用安全：云安全中心，云防火墙，Web应用防火墙，DDoS防护等。
数据安全：数据安全中心，数据库审计，加密服务，密钥管理服务等。
业务安全：内容安全，风险识别，游戏盾等等。
2.2 检测（Detection）---本次重点
现在越来越多的企业已经认可并且在实践着云作为整个企业未来IT基础架构的基础设施和基石。那么对于企业来说，因为没有像以前那种完全处于物理封闭的IDC机房，那么当遇到问题的时候可以及时检测到问题的发生和通知相关人员就变得至关重要。那我们阿里云不仅有高性能的IaaS服务，还有很多非常好的PaaS和SaaS服务可以帮助企业从各个不同的维度发现和存储相应的日志和痕迹。
客户需要关心的：
有效的监控告警：我是否可以有效的监控到我应用系统的运行状态，当出现异常的时候，可以第一时间感知到这个问题，只有第一时间能够感知到问题，才可以去处理解决。
完整的操作痕迹和日志：凡经过的必有痕迹，要求保存好所有的操作痕迹和日志对之后的溯源问题，排查解决都有着至关重要的作用，同时也可以对某些有心人恶意破坏的想法和行为进行威慑。
预警性的检测和发现：其实公有云发展了这么多年，大家根据走过的弯路，逐渐总结出了相应的一些配置最佳实践，我可能不是全部非常了解，那是否可以有人或者服务高效地指出我不足需要改进的地方，这样我也完善自己的配置设计。（做一个小说明，我这里会把公有云的配置检测包含在检测的这块章节，但是系统的入侵检测，比如漏扫渗透测试这种偏向红蓝对抗的检测响应我会放在响应的部分，跟应用系统强相关也更多的需要开发人员的介入和响应处理）。
阿里云提供的服务：
有效的监控告警：云监控，应用实时监控服务ARMS，日志服务，日志审计，配置审计，操作审计。
完整的操作痕迹和日志：操作审计，堡垒机，日志服务，日志审计。
预警性的检测和发现：配置审计。
你可能会觉得有疑问，为什么有的东西出现了好几次，重复了，比如配置审计。具体的内容我们接下来的检测运维方案慢慢给大家一一道来。我先简单解释下，是因为产品的出发点的维度不一样，它的观测角度不同，看到的内容也是会有区别。下面举几个例子进行说明：
云监控主要关注点是运行时状态，服务是up还是down的状态。
日志服务主要关注点是收集到的日志内容，有没有未授权账号登录。它就必须要有对应的日志输出，他才能进行检测，如果一个行为没有日志，比如系统CPU使用率突然升高一倍，但是系统还正常运行，没有异常日志，这种情况下日志服务观察不到，但云监控可以观察到。
配置审计主要关注点是云上配置变更，是否有不符合安全最佳实践的变更，对客户进行提示，你改了一个配置，系统状态可能还是正常的，所以这个云监控观察不到，但配置审计可以观察到。
所以我们也需要从整体多维度去完善我们的监控检测体系。
2.3 恢复 （Recovery）
这里的恢复主要还是侧重于数据备份，数据恢复，系统恢复。先恢复，想让系统变回正常状态。让业务可以继续处理下来。（业务价值永远第一位，工程师们可不要为了求真，为了某些问题方便复现和检查，而耽误业务恢复时间）
没有人可以保证自己的系统一直没有问题，那么怎么搭建好适合自己的高可用架构，保持业务连续性（BCP），在出问题的时候可以有相应的数据备份第一时间让系统恢复运行才是王者之道。简单说下我自己的理解，先说明一个概念，我会把高可用性和容灾分开，在我看来，高可用性是应用依靠自己的系统调度能力，比如多节点，负载调度等可以在部分组件遇到问题时仍然保持系统的运行稳定性。 容灾就是另一套完全不一样的环境，本身考虑的是地理冗余，或者一些突发的不可抗力，停电，海啸，地震等等，在传统的IDC机房时代，这也是我们常常听到的异地容灾，包括银监会和证监会要求的两地三中心都是针对这种地理容灾的场景。系统稳定性很高，但是同样成本也非常高。
客户需要关心的：
应用自身的高可用性：这个是需要应用开发过程必须考量进去的问题，如果开发时候没有考虑到这点，再要改造，真的空间非常有限，也非常痛苦。
数据备份的有效性：针对重要的，核心系统一定不要懒。勤做备份，保证至少一份异地存储，每个月最好对备份的有效性进行下验证，防止因为系统升级等原因，当真正出问题的时候，没办法恢复就尴尬了。
容灾环境的冗余性：建议影响公司生命线的应用系统，一定要做容灾，做好容灾。在传统的IDC机房时代，异地容灾的成本代价是非常高昂的，但是云时代其实好多了，我们有不同的地域，有不同的可用性，有很多默认底层服务的打通。它的可得性变高啦。（番外：我人生中见过最认真最夸张的容灾是在日本，它的容灾演练是真的每隔半年主机房全部拉电闸断电，要求业务切换到备用机房，然后等个周末在恢复切回来，真的每次都很不容易，但是这样的系统稳定性也是特别棒的）。
阿里云可以提供的帮助：
这里可能就不仅仅是纯产品化的东西，很多时候我们是提供给你底层的积木，需要你自己组合搭建最适合自己的小屋。但是确实比自己IDC机房要方便很多。希望大家可以好好利用阿里云提供的各个产品，达到自己期望的效果。
应用高可用性： 多可用区 （AZ），负载均衡，多节点的数据库（比如PolarDB）等等。
数据有效性：快照服务，OSS存储，NAS存储，混合云存储等等。
容灾冗余性：多Region，云企业网CEN，数据迁移服务DTS等等。
2.4 响应 (Response)
这里的响应主要是指的我们的入侵分析处理，安全状态评估，应急策略机制等等。遇到问题总要搞清楚它的根本原因，不管是软件的bug，还是真的有被人攻击，都要有一定的机制和手段防止这个问题再次出现。
客户需要关心的：
问题发现解决方案：没有一个系统可以说自己是完美无缺的，尤其在现代这个技术迭代飞速的时代，所以我相信绝大多数系统在上线前：都会进行专业的漏洞扫描和渗透测试等等专业性测试，发现容易相应的隐患和容易被攻击的故障点，然后在修复后才会正式上线。不管是针对本身Bug的：漏洞扫描，渗透测试，还是针对攻击对抗的：蜜罐，沙箱等等，都是为了及时发现定位问题，及时解决。
故障演练解决方案：我们一定都会告诉自己，出现问题，先别慌，按照应急流程进行处理和恢复。 我们会有专门的应急策略机制，有明确的行为和时间点依据，而不是自己当场手忙脚乱，所以这里应急预案和故障演练很重要。还是推荐大家至少每年进行2-3次真正的故障演练，熟能生巧，遇事不慌。
阿里云可以提供的帮助：
专业的企业支持计划：帮助客户在阿里云上获得无缝的流畅体验，有专属的技术支持经理，有专属的企业钉群，第一时间协助解决的您的各种问题，保障您的企业的业务稳定性。是不是听起来很棒，确实也很棒的，有专属的TAM会跟进每一个问题，所有的问题都会15分钟内进行初步响应，即使遇到严重故障，专属的TAM会第一时间跟客户您，产品研发同步，给出最有效的解决方案。你值得拥有。（我自己也是TAM的一员，我们一直在帮客户解决实际生产中遇到的各种问题，也积累了很多经验，算给我们团队打个硬广告）
定向的安全服务：漏洞扫描服务，安全托管服务等等。
3. 方案实施---运维检测实践
我们想从多维度的层面项大家展示阿里云的运维检测实践方案是如何运作的。下面分成几个维度逐一给大家介绍，希望可以从接入途径---实时监控---日志发现----配置运维等几个维度帮助大家完善云上的运维检测实践方案。
3.1 检测维度一---接入途径
那我们先来思考一个问题，假如你是一个客户，你会可以有哪几条途径接入使用阿里云？
如果可以把所有的途径都有效检测运维起来，那云上的安全水平也会大大提高。在我看来大概有三种主要途径：
控制台 Cloud Console ：一般主要是企业IT的架构团队/安全团队会通过RAM账号登录使用。可以有效利用和查看阿里云的集成好的SaaS服务，比如云监控，配置审计，操作审计的数据和结果，帮助客户进行运维检测的发现和分析，是云平台配置修改的两种主要途径的第一种方式。 （客户的应用外包团队如果确实有需要使用的情况，建议只给相应负责人配置一个对应权限的RAM账号，不建议这里过多配置账号）。控制台的操作只针对云平台的配置，但是对云服务器ECS等进行操作，不建议直接通过控制台进入，需要通过堡垒机连入。
OpenAPI Call：一般是企业自动化运维团队或者应用维护团队通过AK/SK的方式直接使用。我们阿里云的OpenAPI 已经支持绝大多数的产品新增，变更，修改，删除等操作。这也是一种非常方便的获取数据的方式。客户如果在线下有自己的检测平台也可以通过OpenAPI 抓取数据，在自己的检测平台去做定制化的分析。是云平台配置修改的两种主要途径的第二种方式。（以前针对这种方式的发现感知相对困难一些，也是很多客户主要的担心点）。
云服务器的接入使用（堡垒机）：我们推荐使用堡垒机（功能要比传统的跳转机强大的多），有完整的操作痕迹录像，日志，命令存储，可以添加相应的账户管理，访问控制，命令审计，操作时间限制等等。功能非常强大。那么对于云服务器ECS的最佳方式，就是关闭其他的连接端口，统一要求只能使用堡垒机进行登录使用。
针对这不同的途径，阿里云也有专门的产品去协助完成相应的运维检测实践：
操作审计：控制台 Cloud Console & OpenAPI Call--- 操作审计可以记录所有的控制台的操作和API操作，本身支持很多预定义的安全最佳实践的告警阈值，同时也支持导出到日志服务SLS进行自定义的告警监控设置。非常好的一个服务。
堡垒机：云服务器的接入使用---堡垒机是阿里云提供的系统运维和安全审计的管控平台，也是上市公司审计要求，国内外很多安全法规的必需品呀。
上面介绍的都是推荐给大家的最佳实践，基本可以覆盖到99%的使用场景。
3.2 检测产品1---操作审计
单账户操作审计配置
那么我们这里介绍下操作审计需要怎么配置：
开通操作审计服务
在控制台搜索操作审计，通过控制台入口进行，开通服务。
创建跟踪，默认的事件查询只是支持90天的操作记录，你必须创建跟踪才能支持多地域和更长时间的查询的。
创建跟踪，给出对应的名字，建议选择所有事件。多账号的跟踪必须有资源目录，这个我们会在多账号情况里进行说明，然后这里单账户先选否。
接下来就是投递选择：
我们可以不投递，也可以选择投递到日志服务SLS， 也可以选择投递到对象存储OSS。
简单说下投递到SLS和OSS的区别：
日志服务的SLS：比较推荐，进行可以即时查看各个数据的实时情况，同时日志服务也提供了比较强大的自定义模块，客户可以有很多告警监控的操作空间，缺点呢，嗯，比OSS贵一些啦。
对象存储OSS： 适合客户长期存储，比如1年以上的这种情况，不方便的点在于OSS的存储文件本身是压缩格式，需要下载下来解压缩才能看到实际内容，对实时查看的友好性没那么高。
这里我们都建好一个新的SLS和OSS
预览并创建过程就是我们核对下信息，没有问题我们就可以创建了
SLS日志服务的效果大概是这样的：
事件高级查询功能
同时也强烈推荐大家使用事件高级查询功能，非常清晰可见，也可以根据关键字搜索相应的信息，特别棒,GUI的操作也便捷了很多。
OSS对象存储的效果大概是如下：
因为新创建还没有文件，之后会在文件管理里可以查看。
多账号操作审计统一配置
多账号部署也分两种不同的情况。
第一种是你的多账号完全都在一个资源目录下面。那么这种最好处理的，只需要创建跟踪的时候选择应用到所有成员账号就可以了。跟踪会把所有成员账号的日志统一收集到一个日志集是不是很方便快捷。
说下怎么确定账号情况，首先我们可以查看资源目录，看看我们目前企业多账号是否都在同一个资源目录下。
在企业>资源管理>资源目录>概览下面可以看到你目前的多账号情况，哪些账号会自动统计。
然后在创建日志集的时候注意选择应用到所有成员账号的选项就可以啦。
重要
这里要注意多账号跟踪只能创建一个，千万不可贪多，也创建不出来。并且实践过，即使有新的账号加入资源目录，多账号采集会自动收集新的账号信息。
第二种情况，就是因为历史原因，比如企业主体不一致，或者其他原因导致部分账号无法加入资源目录，虽然我们没有办法把所有的日志都放在同一个日志集里集中分析，但是我们可以把非资源目录下的账号的操作审计日志投递到指定的审计账号的日志服务SLS里的某个指定日志集，这样审计人员可以在一个账号审计查看多账号的情况。
具体需要怎么配置呢，我现在帮助大家进行说明：
在事件投递的时候要选择投递到其他账号。这里面有几个比较重要的信息要填的：
需要你在原来的账号建立一个新的日志项目，然后把相关信息填上来。（地域保持一致）。
主要需要注意的是日志写入角色ARN，需要你在要投递的账号新建一个role，并且给出相应的权限。
新建role的方式和权限说明如下：
登录到要投递的账号里面RAM控制台，新建Role，选择角色>创建角色>阿里云服务。
角色类型>普通服务角色，角色名称>按照企业的规定起名，然后受信服务>选择操作审计。
为新增角色进行授权>选择精确授权>系统策略>填入
AliyunActionTrailDeliveryPolicy。
修改信任策略，添加操作审计创建的账号UID, 允许我们这个role访问到对应账号的操作审计服务，修改service部分，在actiontrail.aliyuncs.com前添加对应UID@xxx的信息这里假定账号UID是1234567890。
实际配置完的情况就是如下图：然后我们就可以用我们这个role的信息去完成之前的日志服务的投递工作啦。
其他部分的配置内容和单账号的没有太大区别，就不一一赘述。
3.3 检测产品2---堡垒机
堡垒机涉及的初始化配置内容比较多，具体的内容大家可以参考产品的文档说明。这里主要从账号管理，网络接入，运维审计三个方面帮大家理清楚思路。
账号管理
刚接触堡垒机的同学可能会发现有很多概念，用户（用户组），授权主机（授权主机组），主机（主机组），主机账号。
这个逻辑顺序 ：用户---授权主机 （需要先在主机内进行添加才可以进行授权）---主机用户
用户 （用户组）----授权主机（授权主机组）
用户的作用：使用用户连接堡垒机系统。针对用户，可以在堡垒机上进行管控，他可以访问的授权主机和主机组。非授权情况下，其他的主机，这个用户是根本看不到的。
一般是可以引入RAM 用户直接作为用户，或者也可以在堡垒机的控制台进行配置。
用户必须添加授权主机，否则啥也干不了。
然后在你登录访问的时候，你是使用用户和用户密码通过堡垒机的第一层认证，以Linux为例，我有个用户wensontest；
在登录时候，第一层密码就是要输入用户和用户密码（RAM 用户和对应密码）；
然后你可以看到下面关联的主机，这些主机都是你必须添加在这个用户对应的授权主机里才能看的到，如果没有添加，即使你的主机表里有100多台，那么也是一台也看不到的。
那么这是第一层关系。
2. 主机（主机组）--- 主机账号
主机就是代表着需要进行运维管理的所有服务器，当然以ECS为主，阿里云的服务器可以很方便通过控制台进入导入。
主机：你可以理解为云服务器 ECS
主机账号：就是ECS上的管理账号，比如windows的administrator，比如Linux的root 等等，我们可以自己设置很多服务器自身的账号来进行管理。
那么主机账号一般都在服务器上自己配置，那么这里要求添加主机账号的含义是为了帮助企业做好深度管控，对对应的主机访问，默认情况下只能通过已添加授权的主机账号进行。
你需要创建对应的主机账号并且进行验证。验证成功之后，才可以通过这个主机账号登录该服务器ECS。
主机账号可以添加多个，比如你可以添加 wenson，root等等，但是还比如你有一个admin的用户，你没有添加在主机账号上，那么即使你知道admin的用户密码，你也没办法使用admin去登录。
你的登录页面只会显示已经添加完成的主机账号对应信息，比如这里，root 和 wenson同一台主机，两个主机账号，并列选择。
然后这里你会发现上面还有一个empty，是这样，堡垒机有个功能是可以放在主机账号这块的管控，允许用户自行输入用户名和密码，主要用于外包项目比较多的场景，但是这个会削弱堡垒机的管控力度。
在系统设置中有相应的选项。
好的，那大家主要记住在账号管理方面的逻辑， 用户---授权主机---主机账号，三层逻辑关系，用户名和密码不要用串。
网络接入
很多同学在刚开始使用堡垒机的时候都会遇到一些网络问题，那么这里简单帮助大家梳理下堡垒机网络互联的机制。
堡垒机在初始化的时候是有指定的VPC，Vswitch和安全组，默认的只有这个安全组内的ECS是堡垒机互通访问的。其他的都需要进行打通，比如使用CEN。而不是你在阿里云上配置的所有云服务器都可以直接访问，这个是最大的区别，大家一定要注意。
不过安全组是可以添加多个的，大家可以后期添加编辑，但是超过vswitch层面的就需要通过CEN打通了。
然后只要是网络可达的，堡垒机是都可以连通的，进行相关的配置。对于多账号的场景，建议把堡垒机部署在共享资源账号进行统一使用，高效便捷。其他网络打通部分就不深入了。
运维审计
这部分直接用系统已经集成好的功能就行，有录像审计，实时监控，操作日志等等内容。
具体给大家放几个实际截图感觉下，都是直接控制台操作就好。
3.4 检测维度二---实时监控
那解决接入途径的问题，那接下来我们来看客户系统运维中最需要保证的就是系统要一直能够正常运行。对客户来说最重要的是能够实时观察到系统状态，并且在异常的时候可以及时通知到客户。
监控通知手段可以从不同维度，由云监控，日志服务和配置审计进行触发，但这里我们重点来说实时性能指标这块内容，比如CPU，内存使用率突然升高这种情况，那么本部分内容以云监控为主，日志服务和配置审计的内容在之后的部分进行具体介绍。
3.5 检测产品3---云监控
云监控可以支持的内容主要有以下几方面：
应用分组
这个可以根据标签和规则，建议选择标签智能同步，将对应标签下的所有实例自动同步加入分组。
对其相应指标进行监控，你再也不用担心新增实例的监控情况了。
主机监控
应该是大家最熟知开始的功能，主要针对CPU,内存，磁盘的使用率的监控。
云产品监控
阿里云其实提供非常多非常好的云产品，那么也可以通过云监控对相应云产品的性能进行自定义的监控。
这里面其实想跟大家重点说的就是希望大家一定利用好云产品监控的功能，这是一个非常有帮助的模块，在创建具体的监控规则的时候，我们云监控已经提供了很多维度的参数和指标，如下图，您只需要根据您的实际情况去设置对应的指标，是10%还是20%，可以有效帮助您监控自己应用的运行状态。
3.6 检测维度三---日志发现
接入和监控问题解决的差不多，那我们接下来看非常重要的一项内容，日志。日志自古就是兵家必争之地，包括很多监管要求都是对日志存储提出了明确的监管要求。
包括现在绝大多数的SOC的运作机制，也是主要通过抓取各个监控节点的日志，然后进行逻辑分析，发现异常现象，然后进行通知客户。
所以，日志很重要，很重要，很重要啦。日志主要就是两大部分，日志存储和日志分析。这里主要介绍日志服务产品，当然也可以通过其他的OSS,NAS进行存储。
3.7 检测产品4---日志服务
日志存储
你可以把相应的日志存储在日志服务的指定日志集，这是最简单也是大家用的最多的方式。
比如这里我新建的日志集application-wenson，使用它存储对应的应用日志。
日志分析
日志服务本身提供了很多组件，可以让客户进行自定义规则的编写，监控，抓取。同时也可以跟大数据分析联动，提供非常强大的分析功能。这里因为涉及内容比较多，就不一一介绍，大家有兴趣可以找日志服务的产品同学沟通，日志服务做的非常好，我接触过的产品同学都很细心负责。
自定义告警的设置方式
虽然日志服务里面已经集成了很多默认监控项，但是企业肯定还是会有自己的定向需求，这里给大家举个例子，介绍下如何在日志服务里定义自定义告警监控的方法。
比如目前我们没有堡垒机新建用户的默认告警，但是我们可以创建自定义告警去检测相应的日志并进行告警提示：
1. 我们在堡垒机新创建User，可以看到相应的actiontrail上的告警提示 。
2. 我们在相应的日志集过滤服务内容堡垒机和事件类型创建用户然后进行查询，确认只可以看到堡垒机创建用户的日志。event.eventName: CreateUser and event.eventSource: "yundun-bastionhost.aliyuncs.com"。
3. 根据这个过滤条件event.eventName: CreateUser and event.eventSource: "yundun-bastionhost.aliyuncs.com" 我们创建自定义告警规则，新建堡垒机创建用户告警，触发条件设置为>=1。
堡垒机配置告警生效后，进行实际验证，可以收到相应的告警提示：
3.8 检测产品5---日志审计
日志审计服务
是想重点给大家进行推荐的，非常好的一个服务。可以将您这边绝大多数使用的云产品日志进行汇总分析，审计。（日志审计服务会有单独自己的日志集）。
它可以支持大多数云产品的日志收集同时也支持多账号的汇总收集。可以解决客户绝大多数的问题。
不需要太复杂的配置，大家更多的就是打开直接使用就好。
给大家推荐日志审计服务，是因为它有很多已经集成好了可以查看的图表，数据。
多账号日志审计的配置
在日志审计服务的相关配置中，你可以在多账号配置的时候，选择资源目录，将资源目录的所有账号都进行关联输出到该日志集。也可以指定资源目录下某几个账号输出到该日志集。
如果你是多账号，但是还没有关联资源目录，也没有关系，可以通过自定义模式进行多账号的收集，通过添加AK/SK的方式对该账号下的审计日志进行收集。
3.9 检测维度四---配置运维
那最后客户在日常运维检测的过程中，很容易被困扰到的问题就是某个同事改了某项配置，但是其他人都不知道，也没有发现，当之后进行实际操作遇到报错的时候，大家就会有点手忙脚乱。毕竟很多配置修改只是被认为正常行为，是不会触发告警通知的，那么在这种情况下，是否有一些比较好的方式可以帮到客户解决这方面的困扰。
阿里云提供的配置审计服务是一项资源审计服务，可以为客户提供面向资源的配置历史追踪，配置合规审计等能力，面对大量资源，帮您可以轻松实现基础设施的自助监管。听起来是不是很不错，实际也很好。
3.10 检测产品6---配置审计
那接下来就具体给大家介绍下如何使用配置审计。
合规包创建
首先你要创建自定义的合规包，也就是规则组：
风险级别是可以自行定义，可以方便企业进行不同风险的组合，这个风险是整个合规包的风险程度，之后每一条规则会有自己的风险等级，大家不用紧张。不是一个合规包是高风险，里面所有的风险都是高风险。
那接下来是我们选择合规包的支持，其实产品侧已经提供了很多合规包的规则，这里你是不需要选择一个合规包就要选择所有的规则，你可以从合规包A选择自己想要的3条规则，然后从合规包B从选择自己想要的5条规则，是可以自由组合的，非常方便大家进行实践。
选择完成规则之后，会有一个review的页面，你可以进行具体的参数调整，比如密码长度，大小写要求，因为每个企业的要求可能会有区别，所以大家可以在创建规则的时候按照自己企业标准进行调整，之后也可以在规则里进行修改。同时可以定义的是每一条规则的优先级。有高中低三个分类，然后有默认的推荐值。
那么平时的问题发现和检测，推荐大家使用Rules这里过滤对应的合规包和风险，比较清晰。
多账号的配置审计
最后再说下，配置审计是支持多账号资源目录的设置。
在账号组里，可以创建和管理针对多个账号规则的账号组的，还是非常方便的。
4. 常见问题FAQ
每个模块大概列举了三个比较典型大家比较关心的问题，希望可以对大家有所帮助。
4.1 接入途径运维检测FAQ
除了这里提到的接入途径的检测方式，那还有没有可以影响到客户接入安全的关键产品？
有---它就是权限控制（RAM），也包括云SSO，集成Idp等等方式。接入检测毕竟是一个偏事中事后检测的机制，我们需要从根本上把权限管理好，才能避免问题的发生。如果是通过RAM账号登录，需要在RAM控制台进行相应的权限策略分配, 记得要细化呀,可不要马马虎虎所有人都给Administrator，权限如果泛滥，带来的负面影响非常大。 如果客户已经有比如 Azure AD，或者自己的权限管理系统，我们是可以支持作为IdP的方式集成接入。这里权限控制跟每个企业自身的组织架构息息相关，就不在这里深入展开，只作为一个提醒。
我可以选择自建一台Linux服务器作为跳转机，也可以实现跳转日志存储的功能，为什么还要推荐使用堡垒机呢？ 成本不是更高了？
堡垒机确实要更贵，但是用比较简单质朴的话说，东西确实不一样。你自己的跳板机如果被黑客入侵，或者假如内部员工有意去做恶意破坏的情况下，它是可以删除跳板机本身的日志，或者进行一些根本性的破坏行为，让你之后的溯源工作变得异常艰难。但堡垒机因为它独立的机制，不管从操作录像保存，命令执行情况，连接情况，文件上传下载情况，包括对危险命令的审批流，都可以有一个非常好的管控。这是SaaS产品所独有的功能。也是愿意推荐给大家使用的原因。如果您这边企业对安全要求比较重视，真的是可以帮您省心安心。
我按照你上面说的都做好了，我就可以高枕无忧了吗？
答案很可惜，不行的。很抱歉，没有给大家一颗信息十足的定心丸。 其实我们上面提到的是主要的通用的接入途径。但是真正大家使用多的时候会发现会有这样的场景，很多时候我们的服务器，数据库，存储必须要跟外网进行交互，比如ECS的弹性公网IP，可以通过这个IP直接访问ECS，那这里就需要注意网络ACL，和这台ECS交叉访问的权限设置，在说个场景。比如报销上传发票用的OSS，那可能会要求支持公网访问，要不然出差的员工就没办法及时报销。
当然不管是ECS的弹性公网IP，还是数据库对外网接口，包括OSS对公网链接这些都是应该严格按需配置，进行高级别管控，非必要不要开放公网权限。
建议大家对需要对公网开放的产品服务端口，链接等进行一个单独的文件录入管理，严格管控其权限。
4.2 实时监控运维检测FAQ
国际站多账号的监控是否可以集中在一个账号进行查看，如果分布在多个账号，对用户的查看和使用配置都会带来很大的困扰？
目前云监控服务只能针对单账号进行配置，无法跨账号，但是一个非常大的好消息是，非常感谢林平师兄的支持，企业云监控（支持多账号统一查看的功能）将在2022年3月底左右上线国际站，大家敬请期待。
国际站使用云监控有没有一些需要重点关注的地方？
有的，在告警通知的配置和传达上，目前国际站的监控告警通知可提供方式是邮件和钉群。没办法每个国家都进行短信和电话支持。所以建议大家还是可以考虑安装一个钉钉的app，随时查看监控的最新通知。
那我是不是使用了云监控上的所有服务，我就可以高枕无忧了？
不是这样的，云监控的维度更多的是从产品角度，基础设施的角度，监控阿里云提供服务的稳定性。那么如果应用自身的一些监控问题，根据应用的特性不一，还是需要客户自己重点关注，同时我们阿里云也有一款非常好的产品是ARMS解决云上应用监控的问题，可是实现主动拨测，应用性能监控，移动端性能监控等等方面的功能。
4.3 日志发现运维检测FAQ
我如果使用了日志服务，是否还有必要去接第三方的SOC 去进行运维监控的加强？
在我看来，绝大多数情况下，日志服务足以支撑您的需求，没必要在接入第三方的SOC。 日志服务的告警通知功能也可以有效把信息触发给您。SOC中心最值钱的是它的分析模型，但除非那种深度打磨过很久的特殊应用，然后监控规则客户本身又没办法全部掌握的情况下，那可能会需求性高一些。否则，您完全可以将这些规则都逐一在日志服务里面配置实现。
日志审计拥有单独的日志集，那费用问题是如何计算？
确实上，日志审计拥有单独的日志集，你可以理解是同时把产品的输出日志复制一份到日志审计所在的日志集进行分析。然后同一份log在您的日志服务里会在两个不同的日志集里进行存储，也达到了冗余备份的效果，那么费用是按照日志服务的通用计费逻辑进行收费的。
日志服务的日志可以实时查看和筛选，比较喜欢，但是跟OSS相比费用较高，是否有一些像OSS冷存储的方式，可以即有效查看数据，又可以避免过高的费用？
其实是可以做到的，日志服务本身是有冷热存储的。冷存储也只是存在10秒延迟，但是费用便宜很多，非常经济实惠，建议前30-60天使用热存储，之后使用冷存储。
4.4 配置审计运维检测FAQ
配置审计的检测机制是如何，多长时间会检测发现异常现象？
其实在配置审计具体检测项的规则里面会有进行说明，大概有几种。比如一些RAM权限的更改是可以及时同步过来。然后大部分资源可能是大概10-15分钟会进行一次同步，还有一些配置会进行周期性的同步检测。周期性目前看到最长的也只是24小时。
配置审计的是如何通知客户，告警监控如何触发？
目前配置审计主要还是通过控制台查看管理的方式，产品自己暂时没有配置外部触发的机制，但是支持将相应的内容导出到日志服务里，然后比如通过日志服务进行告警传达触发。
配置审计我看有一些默认的合规包，是否我开启了这些默认的合规包，如果没有发现问题，就代表着我针对这个标准达到了合规要求？
不能这么理解。这个问题需要从两方面进行回答：第一点合规标准规范一定是一个整体的多维度视角，配置审计只是重点关注配置方面的发现，还是需要和其他内容结合才能完成整体的框架，所以单独看配置审计无法说明合规性。第二点，产品基于自身的检测机制，去将目前可以做到的内容通过默认规则方便客户使用。但是无法保证一定覆盖到标准要求的每一项内容。有些内容是需要跟用户的具体信息结合判断，无法单独通过产品独立实现。所以还是需要一起努力的。
4.5 中国站和国际站的FAQ
为什么这里标题写的国际站的运维检测方案，那么中国站是不是也一样，有什么区别吗？
这里首先是因为我自己就是国际服务的同学，所以这里整理可能以目前国际站能支持的服务为主要对象，不过请放心，这里面所有的产品和功能中国站都已经完全支持，大家可以放心使用。中国站还有很多新的非常好的产品可能因为还没有上线国际站，所以这里可能还没提到，比如企业云监控（马上可以上线，开心）事件运维中心等等。也很感谢各位同学对国际站的大力支持，希望越来越多的新产品功能可以第一时间上线国际站。