本次课程将围绕四个方面展开。首先是合规对于企业的重要性和必要性，其次讲解推荐在云上的合规框架、合规的做法，然后介绍阿里云提供了哪些工具和能力，帮助实施落地云上资源的合规，最后是新能力的发布。
一、企业面临的合规挑战
谈到合规，可能很多人想到等保、网安法，如果出海可能是GDPR等一些监管的审查，这些都是的法务人员或者专业的合规人员才需要关注的，那么作为一个开发人员认为这些东西其实离得挺远，不太需要关注，其实并非是这样。在每天的日常工作中，都会面临一些合规风险及挑战。比如经常去做一些运维管理的操作，做一些资源配置的变更，一个无意配置的错误，都可能会导致云上的资源面临一个非常严重的合规风险。比如这个案例，这是一家海外科技巨头，他的员工因为一个无意的配置错误，把一个私有的存储桶配成了公开访问，这个存储桶里恰好又有公司的一些敏感数据，所以导致公司敏感信息的泄露，这里引用了事件调查员说的一句话：“这不是第一次，也不会是最后一次，因为配置错误而导致的敏感信息外泄。”同时，2024年数据泄露调查报告中也显示，近70%的数据泄露事件并非是因为漏洞攻击所产生的，而云上很多的安全风险都是因为一些配置错误所导致的，所以它是云上安全风险的一个非常主要的诱因。
这些配置错误其实并不少见，比如很多云上的用户因为缺少安全方面的最佳实践技能，缺少这方面的经验，可能会错误的把OSS Bucket配成公共访问，让数据库开了公网，或给云上的用户都分配了超级大的管理权限，这些配置错误其实都很熟悉，日常的工作可能都面临着这些资源的配置，所以他离我们并不远，谈合规并非只是法言法语，它存在我们的工作日常中，一个有意的或无意的配置错误，可能使企业面临舆情的风险、面临监管的审查、处罚，甚至面临巨额的成本支出，所以值得每一个云上的用户去关注。
二、云上合规框架
谈到合规，一定有规才去合，规主要来自三个方面。首先，不同的国家会发布一些法律法规，比如我们国家有大家耳熟能详的《网安法》《等保条例》等，比如等保，等保它是一个普适性的要求，所谓等保就是网络安全等级保护基本要求，基本要求即做到了，它未必能够一定安全，但如果没做到，那一定是不合规的。同时，看到一些行业，比如金融、医疗，这些行业都有一些行业的通用的标准，金融行业普遍都比较认可的PCI-DSS标准等等。
除了国家的法律法规、行业的标准，企业积累的一些安全的经验以及沉淀的一些攻防的经验，会沉淀成企业内部的安全基线，这些都是合规中“规”的来源。面对这些合规的要求，推荐主动自查，而不是被动的合规，所谓被动合规即监管什么时候来查，就什么时候做，监管不查就不做，监管指哪打哪。这种被动合规的做法是一种运动式的，这种运动式的做法是很难能够系统的全面的发现公司的风险，所以这个风险其实处在一个不断累积不断扩大的过程中，一旦有一天风险爆发，或者是监管来审查的时候，这个时候整改难度很大，而且整改时会面临一些风险，可能对业务的正常开展产生影响，推荐大家变被动的要我合规转换成主动的我要合规。
一般企业会有安全或者法务的人员，合规法务的人员先对法律法规做解读，国家的法律法规，如果出海，那海外的、当地的一些条例等，对这些法律法规做解读之后，就是把外规转化成企业的内规，转换成企业内规之后，依然是一些法言法语，需要合规人员去做翻译，把它翻译成安全部门或研发人员能够听得懂的策略，这些策略再结合安全沉淀下来的一些最佳实践的经验，结合从成本控制角度所沉淀下来的推荐的一些做法，共同形成了企业内部的一些治理的基线和策略，有了基线跟策略之后，后面就借助于云平台或者自研的一些工具去落地实施合规的一些机制和流程，借助于这样一套合规的框架，把企业的合规变成了一种主动的、常态化的运营机制。首先很重要的一点是先有一些企业内部的合规基线，可能大家会认为公司现在没有专业的法务人员去做解读，也没有合规人员做翻译，其实阿里云自己也是深度用云，也沉淀了非常多的规则，把这些用云的经验、安全的实践、攻防的经验陈列成一条条规则，让大家可以直接使用。有了企业内部的安全的、合规的一些最佳实践的建议之后，后面要借助于工具把这些能力落下去。
三、如何实施云资源端到端的合规
阿里云为开发人员、合规审计人员提供了从可见到可控到可持续的一个端到端的云上资源合规的能力，帮助企业客户提升大家在云上资源合规的水位。首先，因为可见是可控的前提，只有可见才能够继续往下做事情，请大家带入一个场景，比如今天是一个公司负责安全合规相关的同事，今天早上来到公司，有一个同事给报了一个风险，即公司内部系统里发现了一个公开访问的OSS Bucket，里面有公司的一些敏感的数据，非常紧急需要处理，这时第一件事情要先找到这个资源，这个资源是哪一个业务部门在用以及在哪一个应用里面，要及时的止取，把这个资源从公开访问变成私有，找到这个资源要由点及面，公司内部除了这个资源之外，它还有非常多其他潜在的风险资源，把他们都找出来去做治理，治理之后要复盘一下，这些资源是怎么来的，是哪些员工创建的，它是有意的还是无意的，做到哪些事情，然后决定下一步的策略。
所以介绍的这些东西都会用到云平台提供的一些基础的能力。首先第一步要先找到有问题的资源，很多客户在云上都是多账号的，资源分散在不同的账号下，每个业务部门可能都有一个或多个账号，即使是同一个账号下，资源可能是多地域的，要想找到一个资源在以前还是蛮困难的，这里给大家推荐一个非常好用的产品即资源中心，资源中心它提供了阿里云上跨产品跨地域跨账号的全局资源的视图和资源的查找能力，在这里大家可以看到在云上一共保有哪些资源，以及提供了非常强大的搜索能力，大家可以自定义SQL去做一些灵活的查询。
除此之外，如果是自研一些需求或自己做管控的一些需求，还可以通过资源中心提供的统一的获取资源的API，或通过资源投递的方式，把云上的资源进实时的同步到的云下，这是资源中心这款产品。下面列了几个DEMO让大家来感受一下，比如刚才的case，要找到OSS Bucket，不需要到对应的云产品控制台知道这个账号在哪里，只需要到达资源中心的跨账号资源搜索页面，在这里输入资源的ID或资源的名称信息，就可以在企业全局范围内唯一的定位到这个资源。知道这个资源它是哪一个业务账号下以及这个资源相关的资源组信息、标签信息，用于去做一些判断，这个资源属于哪一块业务。如果说见的有一个IP地址异常，要找到这个IP背后的资源，在以前阿里云上有这么多款产品，如何知道IP背后的资源是哪一个。
利用资源中心，同样把搜索条件切换到IP地址，输入相关的IP地址，就可以找到这个IP背后的资源，非常的便利。找到了有问题的资源，通过资源中心提供的能力，跳转到对应的产品控制台，把这个配置给修正掉，接着需要知道企业内部还有哪些有问题的资源，这里可以利用高级搜索的能力，高级搜索提供了非常灵活的资源查找能力。右边列了一个类似SQL一段查询语句，大家可以通过VR语句指定要查的资源类型是OSS Bucket，通过一个条件指定，因为OSS Bucket有个属性，它的ACL是公开读或公开读写，select是资源的ID/资源的地域信息，或者其他的一些业务属性，都可以在select语句里写出来，通过这样一段查询的语句运行，如果是跨账号的范围，选择的范围是跨账号，可以在整个企业范围内全局的找到今天除了那一个有问题的资源之外，还有哪些资源是有问题的。
还经常面临一个场景客户，要盘点资源都在哪些地域，特别是金融的客户，因为金融的一些要求是资源必须做本地化部署，要查看今天的资源有没有在其他一些不应该开展地域的资源存在，这个时候也可以利用资源中心的高级搜索能力，对云上的资源去做分析，比如这段语句，就可以按照地域去对资源去做分组，去做count查询，就看到在全局的账号下的资源主要分布在这几个地域，有没有一些地域是不符合的预期的，然后进一步的去做一些处置和分析。因为之前也有客户反馈说很灵活很好用，能否不需要写SQL，能否实现想要什么，只要说意图就可以自动帮助做查询。今年还发布了一个基于自然语言辅助生成SQL的能力，大家只需要告诉高级搜索说需要什么，比如这个例子中，只需要输入有哪些未开启服务端加密的OSS，这个时候它会自动的生成对应的查询语句，只要去运行就可以查看到对应的资源，能够帮助降低使用门槛，这块的能力也在不断的完善和不断的优化中，大家可以去体验。
刚才已经找到了这个资源，也对云上企业内部所有账号下的资产统一做了盘点和修复，紧接着要去复盘。这些资源是如何来的，谁创建的，要用到另外一款非常实用的工具即操作审计这个产品。操作审计让所有的用户，不管是云上的用户，不管是通过控制台还是直接调用API等各种方式对云资源管控的操作，都可以在操作审计中可见可审计。比如刚才那个例子，拿到有问题的OSS Bucket，在这里面输入bucket的名称，就可以看到最近一段时间有哪些用户对这个资源做了什么操作，这里面就找到在某一个时间点用户创建了这个资源，点查看事件详情能够看到详细的，比如发生的时间、IP地址、请求时的一些参数、请求成功还是失败的结果，所以操作审计能够帮助定位谁在什么时间对什么资源做了什么操作，以及操作结果是什么。
操作审计是平时在去做问题的排查、故障的追溯时非常实用的工具，除了这个之外操作审计还支持一些其他的能力，比如可以对一些敏感的高风险的操作做告警，云上比如像释放资源，尤其像释放数据库，删除ECS这种非常高风险的一些操作，这些操作有可能也设了一些防护的手段，比如开启了释放保护或者通过管控策略去拦截，不允许做这些操作，但其实操作本身代表的是一种意图，如果有一个请求不断请求尝试去删除这个资源，虽然因为有一些策略导致删除失败，但操作本身代表需要关注的一种意图，可以通过这种事件告警的能力，提前感知到今天有一些可能是恶意的调用尝试做这些事情，然后提前去做干预。
需要注意操作审计默认为所有的云上账号提供默认90天的日志留存，所以大家基于不管是等保要求180天以上，还是基于平时要做日志的排查，都需要把日志留存，可以通过创建跟踪把云上的日志，通过转存到OSS或者转存到SLS里去做备份留存，如果企业是多账号的，操作审计也支持组织级的多账号跟踪，在一个账号下可以把企业内部所有的账号的日志统一做归集。另外操作审计还提供了一个AK审计的能力，尤其是如果发现AK可能泄露，需要定位到AK有没有被恶意使用，可以用AK审计这个功能查看这把AK最近访问过哪些云服务，最后一次调用的时间是什么，能够帮助去辅助做一些决策。
操作审计因为日志量是很大的，在得到用户的授权之后，操作审计还提供了一个安全分析的能力，帮助大家从大量的操作日志中识别一些潜在风险的调用，比如可以识别一些异常的IP请求，或者识别一些不正常的API调用，或者一些API调用频繁的出错，都能够帮助去做识别。刚才都是围绕能力里面的可见，资源中心实现云上资源的全局可见，操作审计实现云上资源操作记录、操作日志的可见，这些能力都是需要人工发现风险之后去做事后的补救、事后的查询。是否有工具能够让风险在发生之前规避掉，或者能否帮助自动的去发现这些有问题的资源，甚至可以帮助自动修正。
阿里云提供了两种资源的控制类型，一种是事前的预防性的控制，可以通过资源目录的管控策略，通过事后的持续的检测，用到配置审计的能力。首先第一行，当一个日常的运维请求到达云平台之后，到达云平台的请求会先经过RAM的健全体系，RAM的健全体系里面包含了对于管控策略的判断，如果请求不符合公司的某一个策略的要求，这个请求直接在源头上被拦截，使得有问题的请求、高风险的请求不会到达云平台执行下来。云环境是比较多变的，不会在事前把一些权限或把一些东西卡的太死太严，因为研发人员也需要一定的自由度，不能说今天做一个事情没权限，然后去把权限放松一下，然后改天又做一个事情被管控住，还需要再放松，所以不会把事情都管控卡那么严，同时有一些事情也没办法事前做，比如对资源的闲置做检查，也没有办法事先做管控，当请求没有被那基线拦截的时候，当资源完成执行之后，可以利用配置审计对云上已经有的资源进行自动的发现。可以帮助持续的扫描云上资源的合规状态，当发现有问题时还可以告警，可以做到自动修正。
下面查看如何利用管控策略守住企业组织的合规底线，管控策略是一种预防性的策略，可以把风险在发生之前规避掉，左边是云上企业常见的资源的架构。常见的企业在云上可能都是多个业务的，不同的业务可能因为一些隐私或者不同的业务之间有隔离的诉求，不同的业务比如有一些业务是出海的，有一些业务可能在国内，满足这些合规的基线要求也是不一样的，或今天不同的业务有强诉求必须独立结算，成本要能看的非常清楚，基于这些诉求，很多企业会给每一个业务创建独立的账号，企业会在云上有多个账号，多个账号业务的隔离性满足了，但作为企业的安全户或者企业的合规人员，负责的是整个企业所有账号的安全合规，现在有这么多的业务账号，给工作带来一些挑战。这里可以利用到资源目录的能力，资源目录可以帮助把云上所有的账号组织起来集中做管理。可以通过创建资源夹，把相关的账号做分组，比如同一个业务部门的账号，可以把它放到同一个资源夹下，资源夹还支持多层的嵌套结构，在部门之上可以是子公司，子公司之上可以是总公司，形成多级嵌套的云上的资源结构，来反映在云上的一种管理的情况。
利用资源目录把账号已经有序的管理起来，作为安全的一个同事，可以给公司内部不同的部门授予应该去管控的一些策略，比如今天某一个部门没有对公网开放服务的场景，可以创建一条管控策略，禁止创建有公网访问能力的资源，然后把这个策略附加到公司根节点上，或者需要管控的某一个节点上，这个策略它有一个非常好的特性，它有自上而下的继承性，就像流水一样沿着资源夹的结构向下继承，资源夹下每一个节点都会受到策略的约束，保证了策略不会被比如二级子公司或子部门的管理员他修改了这个策略，导致策略没有有效的实施。
管控策略跟RAM的授权策略它是一个什么关系？首先需要清楚一个点，管控策略它不是授权，管控策略它是权限的边界，管控策略约定企业组织中能做什么、不能做什么，他就像画了一个圈，只能在这个圈圈的范围内去做事情。通常管控策略对应的是企业的一些红线、基线、底线，不能被突破的一些规则，可以通过管控策略去落地，管控策略它一般是比较稳定的，不像公司内部的一些底线、红线是经常变动的，它一般是比较稳定的。授权策略是在公司允许的范围内，给员工授予他日常工作所需要的权限，要结合员工的工作职职能，结合他工作的诉求，灵活的给他调整他所需要的权限，然后达到最小授权的目的，所以一般是比较动态的，生效的逻辑看右边这两个圈。这里也举一个例子，比如有一个员工，权限管理员给他授予了他能够访问ECS和OSS，但是这个组织他有一个全局的管控策略，约定了企业内所有账号下的员工只能访问ECS和RDS，那最后这个员工他能干什么？他能做的是这两者的交点，即他能做的首先公司允许做，并且权限管理员还显性的授权的事情，所以在这个例子中他只能对ECS去做管理。
刚才那个例子是管控策略常见的事例。比如禁止生产环境的所有账号去创建公开访问OSS Bucket，左边策略设立，这个语句其实跟RAM的授权语句语法是一样的，可以通过effect，这里面是deny，即黑名单的策略，然后deny拒绝什么，在action里去指定不允许执行的操作是哪些，通过condition约定这个策略生效的条件是什么，第一段语句是禁止创建ACL，非公开的、非私有的bucket，通过这样一个策略，把它附加到组织的生产环境所属的资源夹下，这个资源夹下所有的账号都会受到这个管控策略的约束，这个账号下比如今天有一个超级大管理权限的RAM的用户，他尝试去创建公开访问的bucket时，其实他就会被策略所拦截，那报错弹框、策略类型里面也会告诉用户，是因为管控策略拦截的，需要联系资源目录的全局管理员查看是策略配置有问题，还是操作是公司所不允许的。
这里也列了一些云上的用户常用的一些管控策略的事例，常见的是比如说禁止去创建公网访问的ECS实例，像ECS服务是提供了一个自定义的condition，能够帮助实现管控，同样像RDS或OSS都提供相关的condition，所谓condition其实是一些控制点，能够帮助实现相关的控制目的，比如对地域的一些限制，对于一些必须要开启的服务，防止业务部门随便的关闭等等这些策略的事例，只要按照相应的语法，都能够灵活的去实现控制的目的。事前的管控把一些企业不允许被突破的安全的底线、安全的红线，通过管控策略去做拦截。
对于云上已经存在的资源，不可能把事前的管控卡的那么死、那么严，而且有些事情不是在事前能够做到的，就可以利用配置审计相关的能力。分享传统的一些审计的做法，因为很多企业其实都会人工的定期评估，每半年或者每一年企业发起一次，要去做全面的审查，查看是否有问题，然后让业务部门配合做整改，这种每半年一次、每一年一次的做法，也是一种运动式的做法，像大家都玩过打地鼠的游戏，今天这一下子下去了，其实后面的风险一直还在不断的冒出来。这种做法浪费人力和投入精力，但其实很难能达到合规的目的，相应的可以利用配置审计，配置审计能够帮助系统自动的发现，持续的扫描云上资源合规的状态。
当他不合规的时候，可以去告警，可以发一些通知，通过程序做集成，自动的做修正，或者让业务部门做修正，这样就是一种持续的合规的状态，它能够让在云上的资源的合规性一直保持在相对比较高的水位上。接下来介绍一下配置审计的一些能力，从配置审计它的四阶段来做介绍，首先第一个阶段依然是可见，资源能够识别，能够发现，在识别和发现阶段，配置审计跟前面介绍的资源中心这款产品去做了一个集成，当资源发生变化的时候，配置审计可以第一时间感知到这种变化，比如在云上今天新创建了一个资源，或者今天业务部门的研发对一个资源去做的配置的变更。这种变化都能够让配置的审计第一时间感知到，感知到之后就会触发一个检测任务，所以除了支持定时的检测，也支持因为变更事件所触发的定时的检测，在检测阶段，配置审计有自研的规则引擎，同时也集成了函数计算，检测的依据是这一些规则，这些规则有一些是系统提供的内置的规则，同时也支持让大家配置一些自定义的规则，来满足一些比较灵活的、个性化的管控的诉求。
检测之后下一个阶段是对检测的结果做响应，响应可以通过云监控接收到不合规的通知，然后了解今天合规的态势，同时不合规的事件也会投递到SS日志服务中，大家可以通过程序去消费。下一个阶段是对不合规的资源做修正处理，对一些规则支持自动的修正，也可以下载合规报告，或者把这些不合规的事件通过程序的对接，让业务部门的具体开发人员通过工单下发下去，让他们去做整改，那这是配置审计的四个阶段所提供的能力。
举一个持续落地的案例，这边是一个常见的企业的组织的云上资源的结构，它是多账号的，可能有十几二十个账号，作为一个安全合规的负责同学，会给企业内部不同的节点实施一些相应的规则，这些规则实施下去之后，当资源发生变更的时候，就会触发规则的检测，检测出结果之后，就有两种情况，一种是今天没有自动集成的能力，可以去下载合规报告，这个合规报告里面就列出来哪些资源是不合规的，一共有哪些不合规的资源。可以把这个报告下载下来，发给对应的业务团队同学，这些资源是有问题的，大家回去自查一下，把这些东西修复掉，这个合规报告可以用于合规安全的同事去跟业务部门的同事协作，如果今天有自动集成能力的客户，可以把这些不合规的事件去订阅这些事件，然后集成到自己企业的it服务管理系统中，然后通过分发工单的方式，把这些不合规的资源的事件发给对应的资源功能，然后通知他们去做自查，阿里云内部也是这样一套机制。
在分发下去之后，对于资源的修正有两种情况，有一种是不需要开发人员介入，作为合规人员可以设置一些自动修正的策略，能够把这个资源自动修正掉，常见的比如打标签场景，有些资源要求某个地域的资源可能都是某一个业务部门的，大家都要打上一个标签用于后面做分账，如果发现这个资源没有达标，可以通过一定的规则实现对于没有达标的资源自动扫出来，自动做修正。对于不能做自动修正的，一定需要开发人员去介入的，需要把报告发下去，让研发人员去做修正，一种是通过内部的系统做打通，通过发工单的方式发到对应的业务部门的开发同学那里，开发人员今天收到了安全合规同事所下的整改通知之后，可以利用资源中心这款产品，通过资源中心找到有问题的资源，然后确定一下配置是否有问题，把它修正掉，修正完之后又会触发配置审计的重新检测，重新检测之后如果是合规的，这件事情就了结了，如果不合规，后面的扫描又会出现不合规的事件，持续的通知开发人员去做治理，这就是一个闭环的端到端的，能够保证开发人员、合规人员通过这个机制完成一种协作，而不是这种人工的对抗、抵触的情绪。回顾一下，首先是可见，可见、可控和可持续，通过资源中心，操作审计，让云上的资源可见，让操作记录可见，通过管控策略的能力，把风险规避在事前，通过配置审计的能力，让云上已经有的资源持续去扫描、持续的去发现，然后去做修正，这一切的工具都是为了让基线能够落地。
四、新能力发布
如果今天企业内部没有相关的法务人员做解读，没有相关的合规人员做翻译怎么办。阿里云包括阿里巴巴在自己深度用云的过程中，沉淀了非常多的安全经验，跟攻防沉淀下来的一些实践，把这些经验、实践沉淀成了一条条规则，然后对规则按场景做了聚合，比如大家可能关心的稳定性、多可用区域架，从成本的角度关注有哪些资源是闲置的，并且大家可以在配置审计的合规库里找到大家有用的，对企业有帮助的规则，做开启，建议大家都去试用一下，对云上所有资源的合规状况做一个全面检查。
