阿里云身份安全与密评合规实践分享

本文涉及的产品
密钥管理服务KMS,1000个密钥,100个凭据,1个月
日志服务 SLS,月写入数据量 50GB 1个月
简介: 本次分享由阿里云智能集团高级安全产品专家易鑫和九州云腾安全产品专家杨念念主讲,聚焦云上密码服务助力企业密评合规及阿里ADAS在企业上云过程中的身份安全管理。

阿里云身份安全与密评合规实践分享

 

内容介绍:

一、云上密码服务,助力企业云上密评合规

二、阿里ADAS如何在企业上云的过程中实现身份安全的管控

 

本次分享的主题是阿里云身份安全与密评合规实践分享,由阿里云智能集团高级安全产品专家易鑫和九州云腾安全产品专家杨念念分享。

 

一、云上密码服务,助力企业云上密评合规

密评最近几年一直在安全行业耕耘,明显感受到密评合规的需求已经越来越旺盛,或关键词听得越来越多。密评实际上已经成为继等保合规以后,下一个合规领域的重要事情。所以不管今天在座的各位朋友是否已经对密屏非常熟悉,也可能是第一次或工作中有过一些密评的接触。今天都来重新看一下,阿里云在这一部分做什么样的事情。其实今天也是阿里云第一次在云栖大会的正式场合发布密屏解决方案。

今天的内容分成三个部分,第一个是商用密码的政策法规的概要,主要是面向还不太熟悉的朋友。第二个是整个阿里云不管在专有云还是公有云领域,商用密码应用安全的方案介绍。第三个会介绍几个案例,直观的让大家感受到整个阿里在阿里云上是怎么样做密评的。

1. 法规概要

首先和大家介绍一下到底什么是密屏,密屏在相关的条例中,是有一些明确的解释的。它是按照相关的法律和法规的要求,对网络和信息系统使用商用密码的技术产品和服务的合规性、正确性和有效性进行检测和评估活动。所以本质上密屏这两个字其实是一个缩写,它实际上对应的是双密码的应用安全性评估。这里还有很多的法律法规的介绍,其中最重要的是中华人民共和国的密码法。

在2020年,从法律层面告诉大家,或者明确的要求IT系统,在满足相应的条件下,应该按照密评的相关要求进行建设。相应的还有不管是从国务院发布的商用密码管理条例,还是从密码管理局发布的商务密码应用安全性评估管理办法,还是从国务院办公厅发布的政务国家信息化项目的建设管理办法。都对相应的密评建设做出了明确的要求,当然配套的还有很多的标准,最基本的、最重要的是39786的基本要求。

可以注意到右下角对整个行业的密评的规范做了一些梳理。比如在政务云领域发布了两个,在今年4月份发布了两个。一个是关于政务云平台的安全性评估的实施指南,以及对政务云上的应用的实施指南。但其实在更早的时间,在2023年的12月,对医疗健康行业,从国家卫健委发布了两个同样的,也是针对云平台、全民健康信息系统以及卫生健康行业医疗机构的密评规范。

从健康行业,以及政务云行业,这两个行业是很明显的。不管在公共云还是在专有云,都有非常明确的密集需求或要求。当然更多在不管是从国务院的十四五规划,还是从公安部发布的指导意见中,明确了等保的三级系统,要按照密评的相关要求开展,并做相关的建设。同样还有政务、金融、交通、车联网、医疗和教育,都分别在不同的发布相关的行业指导性意见规划,对密评这件事做了明确。

2.阿里云商用密码应用方案

密评的标准是39786。它从两个层面对相关的内容做了阐述。

2.1.技术要求

技术要求和等保2.0的早期版本的框架是非常像的,分为四个层面,分别是物理和环境、网络和通信、设备和计算以及应用和数据,并做了相应的数据的机密性和完整性保护,以及身份鉴别的相关要求。2.2.管理

管理分为四个领域管理制度、人员的管理、建设运行和应急处置。当然它还有额外的一个章节叫密钥管理,对密钥管理的保护做了相应的、详细的约束。

3.总结

从四个不同的安全层面,物理和环境、网络通信、设备计算和应用数据四个层面对行为的真实性,或身份的真实性,以及数据的机密性和完整性和访问行为的不可否认性,进行了相应的规定。分为5个层面。第一个是安全合规,系统中用到的产品技术服务,应当符合国家的法律法规和标准中提到的相关要求。

第二个是身份鉴别,在国密密评领域,它是有非常明确的要求的。即身份鉴别的过程一定要用到国密的相关技术,验证这个设备以及人员的真实性。

第三个是数据保护,数据保护它主要对存储的应用的数据进行机密性和完整性的保护要求。第四个是安全通道,即网络通信信道,在通信的过程中要对传输的数据进行机密性和完整性的保护。最后一个是密钥管理,密钥的生命周期都要进行使用。密钥的存储分发使用,要保证它的安全性。

39786是核心的内容。那么阿里云到底是怎么样去满足这些要求的呢?将它分成两部分,第一个是专有云的方案,因为有很多政企类的客户,在云平台专有云场景下,密屏需求会分成两部分。一部分是关于云平台的,第二部分是关于云上应用的,以及对应的政务云的两个指导性指南。

4.云平台方案

云平台方案把专有云平台分成了六个区。

第一个叫用户接入区,用户接入区更多的是来自于互联网或他在终端的运维的区域。他们这里可能存在运维的管理员,或云的管理员在这个区域中用到的密码的技术手段,它主要是国密浏览器,包括VPN的客户端和智能密码钥匙,智能密码钥匙也叫UK,包括ODP的国密动态令牌。利用这样一些技术,为用户访问云平台资源,建立了一个国密的通信信道。并提供国密的身份鉴别能力。它可以起到加密信道的作用。

第二个区是身份认证区,即提供国民身份鉴别能力,这一块主要会用到包括SSVPN、OTP的server端,以及统一身份认证平台。密码能力为用户访问云平台资源建立了一个国民信道,也提供了国民身份鉴别能力。

第三个是云管理的应用区,对专有云了解的朋友可能会知道,它对应的是ASCMASO以及后台提供的API服务的PI网关等。在这些应用中,专门针对性的进行国内的一些整改。让这些产品满足,比如第一支持的国密SSL协议,支持客户端通过国密HTPHTTPS进行访问和通信。

第四个是运维管理区,主要用到的是堡垒机。堡垒机产品在过去没有国密要求之前,他是没有用到国密算法的。但是国密的密评要求出来以后,对堡垒机进行了国密改造。让它和云密码机,包括密钥管理服务做了一些联动和集成,来支持第一个支持的国密SL协议,包括他使用的动态令牌技术,提供了一个国内的身份鉴别,包括对堡垒及内部的一些敏感防管控控制信息进行完整性的保护。

第五个区域是核心的放置。包括云密码机、密钥管理服务区,它作为一个核心的云平台最核心的密码基础资源。云平台的云管控平台、API网关,包括云产品都提供了密码的运算,包括密钥生成的能力等。

最后一个是数据存储区。主要对应云平台的数据库,以及云产品的配置数据,包括日志服务、云产品的后台日志,它都是存储在这两个服务上面。并且对这两个产品,也是做了一些国内的改造。让他支持敏感的、重要的数据完整性和机密性保护。

这是整个专有云平台做的密屏方案、密码应用方案。这一部分已经基本完成了产品化。客户选用的专有云版本,它可以非常快速的启用国民能力。让云专有云平台在交付的时候能够快速的满足密屏的要求。

5.除了云平台以外的语音

语音是助上层的云平台上租户侧的应用。这些应用按照国家的要求,满足了一些密屏改造的要求。这时,我们用到了另外一种更加便捷于我们的应用,适配和改造产品和技术。整个方案其实是左边这样的一个框架图,最下层的最上面是我们的应用,这些应用本身要满足国内的要求,他需要对他的应用,比如身份鉴别的过程。包括身份鉴别的数据,即用户的敏感信息,还包括本身的应用系统存储的重要的敏感数据,类似于一些业务信息,或者是个人的敏感信息等。这时,这些数据同样也要做完整性,机密性和完整性的保护。

并且需要他可以调用到我们的示意里。比如数据的加密服务,包括用于身份鉴别的签名、验签的服务等。这些服务称之为密码服务或密码服务实例。这些实例,它本身它是一个软件,它后端要依赖从云密码机虚拟出来的虚拟密码机VSM。并通过VSM做密钥的产生,包括通过VSM和利用国密算法做数据的敏感性,机密性和完整性的保护,满足密屏的要求。

所以整个从上至下,其实最下面这一层,是通用云密码机的一个硬件。同时它虚拟给每个租户虚拟出不同的虚拟的密码机实力,做到一个密码机的有效的安全隔离。并往上支撑一层基础的密码服务的实力的软件层。通过这些软件层向应用提供数据加解密、签名验签或者sso网关卸载等服务。

在专有云场景下,有些人可能会问,这种架构和传统的密码厂商的价格有什么不同?不同点在于,如果是单独在云外或者是在云上利用ECS搭建的一套密码服务平台,他可能会跟整个云第一个存在的安全隔离性有一些区别。从这里可以看到,不管是从密码机还是密码服务,它都是进到了用户的VPC,即单属于这个VPC,它可以做到一个很好的密码资源隔离。

第二个,它和云的结合,在网络上天然利用了云的网络架构。即用户可以即开即用直接开通他自己的业务的应用VPC,不用考虑任何网络打通、并网等问题,这是一个关键的区别,所以我们这边也提供了非常多的、相应的和基础的密码服务。在右边列出了十种。这些密码服务都可能在整个租户的密码应用里面用到密码的基础服务。

6. 好处

第一个是它提供了一个更高的可靠性。整个密码服资源的密码服务,它其实是相互隔离的单租户服务的问题,它不会影响其他的租户。

第二个是集群,它可以利用整个专有云的企业级的容灾能力,实现高可用。

第三个点是应用性。密码服务和开通一个ECS或者是数据库一样,它可以一键开通并且扩容,如果是性能不够,还可以再扩一个实例,密码机也是一样的。

第四个是安全性,整个密码服务,它因为做到了租户间的隔离,或者VPC的隔离,它是不会被其他的VPC所访问到的。所以可以有效的为租户提供一个专属的密码服务器和密码资源。

第五个是智能的运维。因为整个产品,它和云平台已经做了完整的整合。所以这些云资源的,在运维侧的自动监控告警等,都可以和原来的云平台的一整套的运维管理、运维监控完全的实现一个集成。所以这是关于专有云租户侧,即租运用的密屏方案。

7.核心

它将介绍在公共云中,在座的很多客户可能公共云和专有都会用到。在公共云上,在2023年的时候,即去年的下半年,完成了整个云平台层面的合规。因为密评合规和合规一样,即你在云上的应用要是不满足密评合规,同样也会先要求这个平台先满足密评合规。

所以在2023年的时候,公共云就通过了密评的三级。从20即从去年开始,逐步的针对一些在公共云上有密屏需求的客户,推出了我们自己的,在公共云上的云上系统的密码应用技术方案。左边是整个的公共云上密码应用方的架构,在公共云上看起来会相对简单一些。这也是依赖于公共云上的很多能力。

其实我们已经做了一些内置或者产品化。同样也有从客户端,包括证书、浏览器,它和这些是类似的。在服务端,提供了第一个是SF网关的密码模块。这个网关密码模块,它可以配合加密服务,对于密码机提供一个HTPS请求的绘画,提供一个S国密的sso卸载能力。并应对在网络和通信安全层面的身份鉴别和通信机密性的高风险问题,并解决这些问题。

8.加密服务

加密服务对应的是公共云上的,因为在公共云上,它在2015年就完成了云密码机的产品化,通过sas虚拟化和sas化后,变成了一个加密服务,给业务的应用提供云上的合规的数据加解密、签名验签和密钥管理等能力。并解决网络通信计算设备和应用数据层面的数据存储的机密性和完整性,以及密钥管理的高风险问题,同样也会用到堡垒机。

因为堡垒机,它在设备和计算层面是非常重要的组件。所以在今年7月份到8月份左右,专门完成了公共云上的堡垒机的国密版本研发。并对堡垒机有所要求,以及对国民要求中要求的堡垒机对它的防控制信息,包括身份鉴别等,统一做了一遍整改,从而满足相应的39786的要求。对此会发现在某些region是可以选到堡垒级国密版产品的。

9.对于移动端应用的整改

不管是APP,还是小程序等。都可以有类似于SDK的一种方式,它也叫移动端的密码模块,来解决移动端的APP问题,并集成一些端侧的加解密、签名、验签的能力,这是公共云上的一个方案。

从核心来说,不管是专有云还是公共云,它和等保不太一样的地方是它会有一个资源的应用的整改过程。即应用它不像等保,会有外挂式的一些产品做到旁路的防护或者串行的防护。他需要对应用做一些整改,从而满足数据的机密性和完整性的保护。即在数据存入库之前要进行加密,这可能会涉及到等保或整改的过程。

为了帮助用户或者客户快速的完成,一个是密屏整体的合规,第二个是整个应用的整改。在这个过程中,为了帮助客户解决对密码产品不太熟悉和对密评合规的要求不太了解的问题,专门去推出了专家咨询的密评咨询服务,帮助企业完成密评合规。第一个是做差距分析,类似于等保。

第二个是帮助用户编制一个在命名过程中非常重要的密码应用方案的材料以及整体方案。并且协助客户完成专家的评审,这个方案做好以后,完成了专家评审,意味着整体改造按照这样一个方案进行的话,会获得了专家的认可。那么后面的问题就会相对简单一些,或者不会有那么多障碍。

第三个是密码的管理制度编写。

第四个,可能有一些系统改造的过程,很多企业不太熟悉。那么我们会提供一些针对性的指导告诉,或者说给企业一些建议。哪些是应该进行机密性保护的重要数据,哪些身份界面的过程,它应该用到什么样的技术做国内的改造等来提高企业改造的效率。最后是在相应的提供测评过程中。因为有些测评机构会依据39786的要求,对整个系统的国内的合规性以及密屏的合规性做一个测评。

在这个过程中,帮助大家对接测评机构,完成从测评的过程,包括证据链的补充提供等。总结下来是在公共云上我们提供了全流程一站式的密评合规服务。

第一个是云平台的密评,在去年的十月份完成了密评合规平台上的密评合规。为云上的应用的密评合规提供了坚实的基础。在云上的应用开展密评的时候,可以复用云平台的物理和环境,包括网络和通信层面等结论。

第二个是云的密码产品,即云密码服务,为应用的整改提供了很大的便利。在2015年,国内首家上线了具有合规资质的云加密服务,客户不再需要单独的采购部署硬件设备满足密评要求。而是利用云上的sas化,用这种云化的服务就可以了。

第三个是为了解决客户在密评过程中遇到的整改问题,或者是对这个标准不了解的问题。我们整合了相关的资源,结合云上的密评实践,为客户提供了一站式的全流程的密评合规服务,帮助我们便捷的满足密屏的要求。

10. 两个案例

10.1专有云场景案例

它是某个省交通运行的监测调度指挥平台,这是他密屏系统对象,为客户提供了包括云平台和应用TOCC,如果对交通行业比较熟悉的朋友应该了解,TOCC是交通运行监测调度指挥平台应用云平台和应用的密码,以及应用的整体方案。

左下角是云平台的基础架构,可以看到在技术架构的右下角用到了在右边列出来的一些平台侧和租注册需要用到的一些密码的资源和能力。包括VPN、密钥的管理服务、统一身份证平台和动态令牌等产品,做了部署以后,最终就是这样的一个架构。

从平台侧的方案来说,前面讲了已经做的比较好的产品化。所以平台侧方案就是按照之前的展示图,并按照六个区域的分区架构满足命题要求。

在租户侧的密码应用设计中,我们花了非常多的精力支持他们的应用架构。可以看到,这个系统是一个很庞大的系统,TOCC上面有非常多的子模块,包括交通的运行监测预警,以及重点的运营车辆的智能监管等。这些应用系统,它都要接入密码的能力,对其中的一些平台的数据进行机密性和完整性的保护。所以这个架构就是按照密屏的要求来架构的。

第一个是物理和环境。物理和环境在机房层面,通过对视频监控门禁系统的改造,来满足视频监控和门禁其中的重要数据,并进行机密性保护,满足密闭的要求。这主要在机房这一侧和云平台的部署关系不是特别大。

第二个是网络和通信。这些子系统的所有业务访问是通过SSO网关来实现国密的SS卸载,卸载完成后,再传到TOC系统,来实现通讯数据的机密性保护。那么在设备和计算层面,它是用UK登录到国密的VPN,再基于国密VPN创建安全的通道接入。还有相应的堡垒机也会做到。

最后是应用和数据,它比较重要。

它用到了中间的统一的身份认证平台,它基于统一身份认证平台,对它的应用做统一的接入。并由这个平台对接我们的协同签名?验签等服务,包括移动端集成SDK,再协同完成应用系统的国民身份鉴别和身份认证平台。他去对接数据加密的服务,对一些重要数据防控制信息实现了完整性的保护。其他的子系统的重要的日志,同样也用到了数据加解密服务进行完整性的保护。最终这个平台在十几个子系统以及云平台都顺利通过了密屏。

10.2公共云的案例

客户是全站部署在阿里云上的招标采购的全链路电子化的专业服务商。他主要的业务是云化的采购平台,那么这个客户还是国资下属的企业。第一个是从他的上级单位对他的密评合规的要求,第二个,客户作为一家大型的招采平台,他的一些客户很多也是政务国企,他的招采数据也比较敏感,而本身上下游的这些客户对他有密评合规的要求,所以本质上这个客户在今年的3、4月份左右非常着急的找到我们说希望尽快的通过他的密评。最终客户也采纳了我们的一些建议,采用了云上的标准密评方案。

前面讲到的一个方案对他的招采平台进行了改造,并集成了密码能力。也对他的系统做了重要数据的机密性、完整性的保护,包括身份鉴别等。同时阿里云的专家也提供了密评咨询的服务,帮助客户快速的完成密码应用方案的编写和应用改造。

在五月份左右,我们通过一个月左右的时间,快速的、顺利的帮助这位客户完成了在公共云上的密评合规。这是密评合规的报告结论。

最后进行总结,今天讲的这些内容更多的是想告诉大家,不管是在阿里云的专有云还是在公共云,都已经推出了相对比较完整的密评合规的方案。如果大家的业务在未来有密评合规的需求,可以随时了解在阿里云上的方案,大家可以在公共云上搜索密评这两个关键字,就可以找到密屏方案的介绍。那么如果大家想要进行更多的沟通,可以在线下有更多进行交流。

 

二、阿里ADAS如何在企业上云的过程中实现身份安全的管控

接下来将和大家分享阿里ADAS如何不同的云产品做统一的协同,来实现云上身份安全的保障。

1.挑战

首先在企业上云用云的过程中,会面临新的挑战。因为随着上云用云的深入,企业在云上的资源产品会变得更多,从而也就有更多的人员需要访问云上的资源或者产品。在过去更多是企业内部的员工访问一部分的资源和产品。但是随着云资源的增多,会有更多的角色需要访问。比如外包供应商这就导致云上有不同的更多的访问链路。

比如可能有些员工他需要通过目录服务访问阿里云。那可能外包员工他的身份并没有在企业本地的目录服务。这时他可能需要用一些独立的账号密码或者其他身份体系访问其他的应用导致了有非常多的访问链路,在管理的层面上会有非常高的管理成本。而且环境也会变得更多样。

因为人更多了,需要访问的场景也更多了。你可能在办公网差旅的过程中或在一些外包的账号访问。那这时你网络边界更模糊可能在传统的系统中能够通过IP的限制做一系列的控制。但一旦没有网络的边界,身份本身有一些问题,那么在云上可能会逐渐暴露。

2. 存量身份问题

企业上云的过程中,企业本身已经在深度使用了一些身份体系比如outstep。这些体系它不一定能够云上的产品有非常好的协同。如果你的身份体系不能够完全统一,就会有多套的账号体系。有多套账号体系就会形成身份的孤岛。所以你需要单独维护每一套的身份,这样就会容易导致一些安全的隐患。比如一个员工他可能有多套的账号密码,会设置一个比较简单的密码来方便来记,这时就会有弱密码的问题,用密码会很容易被攻击。

如果员工在每套身份体系,都设置一个比较复杂的密码,对于员工来讲他是非常不方便的。在不同的账号体系之间,都要记住密码,非常不方便。如果它每个应用都设置同样的密码,那只要它一个密码被泄露,那么全部应用都会被泄露。所以这里有一个安全的隐患存在,特别对于一些MANC客户国际的客户,他们在华本土的团队,可能并没有一个身份体系的管理权限。他可能要依赖于global团队做统一的管理。这时其实就很难推动global团队实现在华本土身份的统一。为此会有一些使用上的卡点。

3.身份孤岛问题

从员工的视角来看,员工在入职的时候,转岗的时候,管理员可能需要手动的给他分配不同的账号,以及分配权限。对员工来讲,它效率上是有问题。对于管理人来讲,如果一个员工离职了,你的账号没有删除干净,那么你可能会存在员工离职了,依然保留了一个有权限的身份。然后他可以对你现有的资源进行访问。那这里会有比较大的安全风险。

基于这些身份的问题,希望能够为企业提供一个统一的解决方案。其实身份是数据的入口,数据是企业非常核心的资产。如果身份的问题没有解决好,那么在企业上云过程是会有一些挑战的。因此提供一体化的整体的身份安全解决方案,帮助企业在上云用云的过程中解决这些问题。

4.方案

方案分四部分,包括多元化、统一化、自动化合规化。

4.1多元化

可以看到,ADAS作为一个身份的枢纽身份的管理平台,或者叫IDP。对此两个事情,第一个是两个扩展。第一个是扩展上游人员以及上游的身份。第二个扩展是扩展下游的应用。对于左边来讲是上游人员身份。不同类型的员工,能够使用不同类型的身份访问到ADAS。在ADAS做中转,中转后,再由ADAS向下的应用做分发,来实现整个链路的打通。

例如正式的员工或运维的员工,可能他的身份是在域内的。那么他就可以通过AD或者open a dep的份访问到idas,从而在idas再访问到对应的系统。如果一些外包员工他不在域内,也提供其他的一系列身份体系帮助这些角色进行访问。比如国内的办公身份,支持钉钉,企业微信等。对于国际的身份,支持taHAD甚至有些企业可能自己建了一些简单的4A或者一些SS的系统。所以他可能没有办法很好的做完全的覆盖,但是他又希望继续可以用,这是没问题也支持你本地的4A做一个标准化对接。

除此之外,idas本身也会有种各样的认证方式来帮助员工角色做访问。比如账号密码短信验证码本地的人脸和指纹的验证来实现上游身份的连接。第二部分是对于下游的系统,发现有不同的几个链路。第一个链路是通过ADAS直接访问到云sso其实ADAS云sso以及RAM都是阿里云的身份管理产品。但是他们之间有一些区别首先ADAS的定位是在于企业的IDP,即不仅连接阿里云,还可以连接非阿里云,甚至连接一些线下云下的应用。

对于云sso来讲,它更多是对于阿里云本身的RAM的产品做统一的管控,即一个云sso产品能够统一管理多个阿里云的账号主账号,然后在USO通过一些逻辑,可以实现RAM的角色sso用户sso。那它定位更多是一个多账号。对于rim来讲,它的定位更多是阿里云本身的资源,所以它和身份的管理会有一定的区别。

可以看到在第一个链路通过ADASSO的集成,我们就能够实现多个阿里云账号的统一管控。比如直接通过AD就能够到ADAS,然后通过ADAS直接通过ESO就能办理阿里云的身份,访问到阿里云的资源和产品。第二条链路,ADAS也能够直接阿里云的RAM做连接。可能有一些产品,比如阿里云的资源或产品,或者有更多角色使用的产品,比如QBI。那ADAS能够RAM做一个集成和妥协,从而实现这些资源或者产品高效连接。

除此之外,阿里还有一些产品,它可能本身RAM的关联性没有那么大,产品可能本身没有身份体系,或者它本身需要一套独立的身份体系。比如sc、VPN、无影等产品,他可能自己有一套身份体系,或者他甚至没有。那ADAS能够产品做深度的集成,例如VPN产品它本身没有身份体系,它只是用证书做认证通过ADAS,能够利用idas的账号体系对证书做二次认证。这个例子接下来再做展开,由此可以实现阿里云产品的连接。

最后一个各类的云厂商,比如AWSH、腾讯云、华为云等。它们都能够通过ADAS做统一的多云的管控,以及通过一些sas的产品,或者开源产品,或者企业内部自研的系统,都能够从ADAS接进来。通过这些手段,ADAS作为枢纽,能够帮助企业扩展上游的身份以及效的应用。这第一部分身份多元化连接的能力。

4.2.统一化

当身份完成了连接之后,需要对它做一个统一的管控。可以发现身份可以归为两大类。第一类是人员的身份,我是一个人,可能会拥有一些身份去访问。第二类程序的身份,或者机器的身份。指的是这些应用,或者AKSK,它本身会有一些细分的分类。正常来讲,一些人员身份,他可能是一个普通的办公人员普通的职员。他可能需要做网络准入的事情,并访问一些云桌面,或者他需要访问内部的运营系统客服系统等系统。这里是一个普通的办公人员。

第二类,公司内部会有一些相对特权的身份。比如产业运维的身份他们可能需要做云资源云账号的管理和使用,还会涉及到公司的特权资源,这一类是需要重点保障的身份体系。对于机器来讲也是一样的,我们依然有特权的机器,它可能会涉及到一些非常敏感的,能够提前的系统。另外一部分是一些普通的系统,它只是做一些普通的服务之间的调用

通过ADAS的全链路的能力,能够将这一类不同类型的身份做统一的管控。可以看到中间ADAS链路会有这些能力。比如身份认证,需要先对人员或者机器来做一个认证,包括多样的认证方式,以及对于人员的二次认证。做完认证之后,第二个链路对他的权限的控制,他是否满足访问的条件,或这个条件可能有很多种。第二个是他是否有访问的权限如果他没有访问权限,那么在attest的入口级就能够将它访问拦截掉。

4.3.自动化

第三部分是我们云产品做集成。比如云产品的SSO,以及数据同步,来实现身份的统一化的管控。

4.4.合规化

最后一个针对机器的权限,即需要对机器做一个认证的授权。

5.三个场景覆盖

基于整个链路的管控之后,能够实现三个场景的覆盖。

5.1.办公的身份安全

办公的身份安全可能会涉及到一些云产品,比如scVPN无影等。正常来讲,在使用VPN的时候,可能只需要用一个证书就能够连接到公司的内网。如果证书或者设备丢失,其实是由访问者能够访问到公司内网数据的一个风险。所以我们VPN有这样一个联动当用户或者员工使用VPN进行连接的时候,ADAS能够做为一个二次认证的方式要求员工来进行第二次认证。比如他可以用本地的AD身份或者oppor身份来再次验证。认证无非三种类型。

一个是用户知道你的密码密保问题,这是他所知的第二个是他拥有什么东西。比如拥有的手机sim卡设备。第三个是琐事,用户的指纹人脸,是它所具有的生物特征。VPN的场景,用户首先用了一个证书,他拥有的东西进行了第一次认证。验证完后,ADAS能够提供比如AD的账号密码,这是用户所知道的东西,用它来进行第二次认证。通过MFA的方式,就能够解决绝大部分的身份攻击的问题。

5.2.运维的身份安全

运维身份安全会涉及到很多特权的账号以及敏感的资源。堡垒机为例子,堡垒机本身有一套账号体系。Idas堡垒机是先做完协同和融合之后,我们可以做到用户只需要做一些授权,就能够将用户上游的数据同步到ADAS,在ADAS能够直接将这个数据同步到堡垒机。当idas的数据有变动的时候,堡垒机的数据也会自然的有变动。同时当用户在访问堡垒机的时候,能够复用ADAS本身的访问策略或者安全能力,来实现安全水位的提高。

5.3.应用的身份安全

当程序向程序之间做调用的时候,本质上也是有权限的健全流程。可能以往更多是在权限,在下游的资源和下游应用里面做。通过idas能够联合API网关做整个统一的授权。比如在idas先做完上游应用的授权之后,当应用调用受保护的资源的时候,由ADAS来签发一个token,那token包含了一些权限的信息。

之后API网关就能够做自动化的拦截,以及做健全,这是应用安全方面能够做到的事情。那么在完成了身份的连接,以及身份的统一管控之后,关心只有上游的身份下游的ADAS,以及下游这些业务系统是如何做协同的是否还需要在不同的地方反复的管理身份体系。通过自动化流转的能力就能够解决这个问题。

6.例子

企业的数据在ID的时候,可能需要将这个数同步到RAM,然后实现AD数据到RAM的访问。可以看到上面IA作为中间的位置,能够AD做连接。首先走的是加密的协议。当AD的员工入职的时候或者创建的时候,我们会监听AD,并和AD之间会有一些集成。

我们会监听他的事件,或者做一个增量同步的能力。他的员工在AD增加完之后,在ada这边大概在十分钟以内就能够直接自动的实现ADAS账号的创建。Idas本身RAM也可以做好预先的配置。这样就可以实时的将数据推送到RAM,来实现RAM的身份体系,并对账号数据进行创建。这是访问的链路。

如果员工离职了怎么办?如果员工在AD这边他离职了,删除了这个账号,那么也会自动的挨打,这边会将账号给删除掉。这里有两个逻辑,第一个逻辑是ADAS的账号删除掉之后,AD的账号就没有办法再访问到idas也就没有办法访问到RAM,即使RAM的数据没有被,你的权限没有被撤销,这个用户员工他依然没有办法访问到RAM。

第二层是ADAS在数据层面依然能够RAM做这协同当ADAS的用户被删除之后,也可以同步的将RAM对应的账号做删除通过我们就能够实现整个数据流程以及认证流程的自动化管理。

除此之外,会有一些更加灵活的能力来帮助企业做一些筛选。比在我的域内,可能只一小部分的用户需要用到RAM。那ADAS能够指定哪些用户需要访问到RAM。比如你是某一个组织下的或者某一个组下的,甚至你是某一个用户名开头的是CN中国区开头的,这样的用户需要访问到人,那ADAS能够做这样一个过滤。

第二个是对于每个用户,他会有非常多的属性。包括用户名手机号邮箱敏感的信息。如企业对这种安全或者合规有要求的话,也可以通过ADAS的标准能力将这些字段排除掉只需要将比如将我的标识同步到ADAS,然后ADAS也可以只将这个标识同步到RAM。在这两个上游和下游都能够做灵活的配置。这样就能够实现即使AD的账号ADAS的账号或者RAM账号是完全不一样的依然能够做转换,实现不同身份之间的连接和映射。

7.合规化治理的能力

我们服务了非常多的国际客户。国际客户对安全性的要求,合规性的要求是非常高的。我们需要客户一起global团队做汇报,并且还要做评审。我们总结出来一些问题是他们非常关心的。基于这些问题所构建的能力,能够比较好的满足global团队对于安身份安全合规的要求。首先是ADAS依赖于阿里云的基础设施,所以天然的拥有一些安全性、合规性、稳定性的能力。在这个基础之上,提供四大类型的能力。

第一个是网络,能够私网连接到客户本地,例如客户本身的服务,或者他的目录在本地。那么ADAS能够利用客户阿里云的所属他自己的网卡,通过私网连接到客户本身的VPC,如果有专线的话,也能够直接连接到客户的本地。这样就能够做到两个事情。第一个是客户本地的服务不需要开放公网端口,也不需要部署单独的agent,就能够云上的iclas做集成。第二个是网卡它是属于客户自己的。客户需要配一些管控策略做一些监控。所以ADAS在整个过程中,对于数据的使用流量使用,客户都是可见的我们可以自证清白,证明没有做额外过多的事情。这样就能够对客户安全合规的评审能够有一定的满足。

第二个是能够支持VPS的接入。客户可以通过私网接入到ADAS,调用idas的接口。第二部分是数据维度,我们能够支持不同层次的数据过滤。如果你的公司可能有10万个人,你可以将其中的一部分,比如1万个人同步到adas。那么数据范围下面就是字段范围。每个用户可能有非常多的字段或者属性,并且依然可以筛选一部分的字段和属性同步到adas,比如手机号不用同步过来。

第三部分是不同的字段,可能你的逻辑是不一样的。在上游可能叫CK--jack,下游它可能只是jack。通过ADAS的表达式引擎,能够实现字段的灵活转换。

部分是访问层面,能够控制不同条件下的访问。比如支持自身二次认证的能力,并且能够支持用户的访问权限以及应用的访问权限。

8.支持多维度的审计能力

包括管理员的操作用户的操作都会有详细的日志进行记录。这些日志也能够导出到阿里云SOS来做进一步的分析基于这些能力就能够多维度的满足客户的合规要求。这部分是在最近新发布能力,叫条件访问。结合我们已有的能力,能够实现企业的人员访问整体的安全加固。

首先看左边,在事前中和事后链路,adas有哪些能力能够做这个事情。首先在事前有账户和凭证管理相关的能力,比如私网的连接、数据的过滤密码复杂度密码的更改周期以及历史的密码等一系列的密码策略。企业可以按需的设置需要的密码有哪些的强度或者哪些要求。

同时还会有一些员工会涉及到用到已经泄露的一些密码。这密码是不安全的我们自己会有维护数据级别的密入泄露密码库。在用户更改密码的时候,或者管理员更改密码的时候,会对密码进行加密和比对之后,提醒用户这个密码泄露了多少次不太建议使用密码。这就能够将检测的结果响应给用户或者管理员。

对于中来讲会支持一系列身份认证。包括扫码登录、委托认证、联邦认证、二次认证身份认证能力。以及单点登录条件访问权限,它是用访问的控制来做全盘的管控。最后是各样的日志记录全链路不同用户类型的行为。

基于这些能力,从用户访问的视角来看,怎么样兼顾用户访问的安全性用户访问的效率首先用户在访问的时候,要认证他本身是一个什么样的人,以及否是是他本人。那他可以有不同的方式。比如他可以用密码进行认证。如果用密码的时候,结合密码的能力,这样就能对它本身的密码做一个加固,来提高密码的安全性。

如果客户、用户不需要用密码他希望用更加便捷的方式。比如用钉钉扫码登录企业微信扫码登录等。那我们就提供无密码的登录方式,包括支持外包商或者fidel让用户用设备本地的人脸和指纹来进行认证。认证完后,通过条件访问的能力,可以做第一层的决策。我们会基于不同的条件来综合判断,给出一个决策。比如基于用户的网络范围,你是不是一个办公网,或者说是不是一个被拦截的IP以及未来加灰产黑产的IP威胁加入进来。

第二部分是访问对象的风险,你要访问哪些应用,这是一个高风险的应用还是一个低风险的应用,可以将它作为一个条件。

第三个是根据绘画的判断,用户上一次访问是不是安全的访问。在一定有效期以内,他的访问是否是安全的。这里不需要再对它进行进一步的认证,可以对他进行一个放行。这些时间的规则以及绘画的规则,是能够做一个设置的。最后一个是访问者的归属,用户员工是归属于哪些组织或者哪些组的可以给他设置不同的策略。比如不同的组或者不同的组织的用户,对他的访问的要求是不一样的。基于这些条件,ADAS给出一个决策。

决策有三种类型。第一种是我们判断它是一个高风险,那么会直接拒绝掉他访问,比如他不在办公网IP内,就会直接拒绝掉。第二类是如果它是一个低风险,我们认为没有问题,都满足这些条件,那么可以对它做一个放行的操作,让它进入到下一步判断程序。第三类是很多企业比较头疼比较关注的问题。有些应用的敏感程度是不一样的,比如特权的应用以及财务的应用,他们需要高安全的强管控的策略保证它的安全性。但对于一些低风险的应用也不需要经常做二层证。

但很多时候没有办法做到不同的应用做区别的对待,或者对于不同的人做区别的对待。基于这个条件访问的能力就能够做到这个事情。比如针对财务应用或者堡垒机的应用,这些人永远都需要进行二次认证。而且需要用更加安全的二次认证来进行认证。比如需要指纹人脸来认证,那么这里可以设置一个规则。

一些应用

这些应用可能只需要在很长时间没有使用过后,才需要进行二次验证。而且可以随意选择任何的二次方式。比如可以用TOTP邮件的验证码,或短信验证码。另外也可以设置这样的一个规则。这个规则能够指定不同应用它所需要的认证方式是不一样的。这样就能避免每一次用户在访问的时候都需要进行二次认证打扰。二次认证能够提高整体的安全性。

但是如果过度的打扰也会影响客户用员工的效率。

当条件访问决策完了之后,会有个访问权限的决策,即已经认证完了整体的条件,本身是可以的,那么是否有权限去访问这个应用,还需要再看一下,所以这时会判断它的访问权限。如果他对这个应用没有访问权限,在ada这边就直接把这个访问给拒绝掉。如果他有这个权限,就进行放行。可以注意到在整个过程中是不需要企业的应用做任何改造的。

因为整个拦截的逻辑都在ADAS,就不需要做任何的改造。当idas放行过后,比如进入到了阿里的RAM,或者到了企业的SaaS应用资源应用,才会到下一步细粒度的权限控制。所以整体对于企业的业务是无侵入性的。

案例

这是外企在华非常典型的场景。可以看到上面很多正常的外企,这是他在中国本土经营的时候的逻辑。分两部分,第一部分是数据的流程,数据同步的流程。第二部分是用户访问的流程。

在数据同步的流程时候,很多在华的企业并没有身份的管理群。他可能需要使用海外的身份系统做身份的管理。当入职一个员工的时候,可能需要提交个工单到global团队,请global的团队为本土的团队创一个账号。这会有时差的问题,也有邮件反复确认的问题,对整个管理员的消耗是非常大的。当账号添加完之后,可能还需要请global团队将数据配置到国内的应用,来实现国内应用国际身份数据的打通。这对于管理员的消耗非常大

第二部分是当员工拿到了这个账号,他去访问的时候。因为海外的身份大多数是部署在海外的,所以员工在访问会遇到一些非常效率低的问题。比如整体的访问非常的缓慢,或者整体的访问是不稳定的。他可能有时连的上,有时连不上,或者有一些海外的身份在中国本土,它本身有一部分能力的缺失这时整体员工的使用,它都是非常糟糕的员工可能要先跳到海外,再从海外跳回到中国,整体的效率是不高的通过ADAS能够解决这个问题,首先在数据的流程能够做两个事情。

第一个是能够国际的身份体系做一个同步。这时它是一个前置的操作,它不需要管理员做预先的更多的实时的事情。

第二部分是当数据同步到阿里云idas之后,用户或者管理员也能够选择性的在阿里ADAS自己去建一些账号。比如维护你的外包账号,或者维护你的供应商账号。在ADAS这边就能够有一个自主管理的权限做管理。然后通过ADAS国内的应用做对接,这样就能够实现国内的链路国际的链路,它本身没有强的依赖这个是数据的链路。

用户访问的时候,可以直接通过本土的ADAS就能够访问到本土的应用不需要海外绕一圈再回来。基于这些能力的建设,就能够实现本土的访问海外访问的隔离,这样避免了对管理的损耗,然后用户体验的问题或者效率的问题。

ADAS会有四个场景,它是适合企业考虑的。首先是上云的场景,当你在上阿里云的时候,你需要用本地的身份连接到阿里云的时候,ADAS能够帮助你用不同的身份进行扩展。用原有的或现有身份,甚至不用改变现有身份的架构的情况下连接到阿里云,这是第一个场景。在深入使用阿里云的时候是第二个场景,你可能深入使用非常多阿里云的资源,以及阿里云的产品。我们能够做到和不同的云产品做统一的协同,来实现ada作为唯一的入口管控不同的产品。

第三个是多云的场景,如果您不仅使用阿里云,还使用其他的云或其他的开源产品以及SaaS产品。也能够通过它做统一的管控,来实现阿里云非阿里云资源或者应用的统一管控。最后一个是外企在华的身份管理场景。

如果企业在中国本土缺乏IA产品,或者依赖于国际的这种身海外的身份产品。其实会存在一些稳定性的问题,合规的问题,或者效率的问题的困扰也可以考虑使用ADAS来进行替代。

最后,ADAS在云上或者云下都有非常丰富的客户的案例或实践。所以我们也是中国第一家,也是唯一一家入选garden SS management的魔力象限报告的中国厂商,是唯一一家连续三年报告。所以我们整体的能力也受到国际机构的认可

今天的分享到这里就结束了,如果大家对产品或商业场景有更多的兴趣,希望进一步交流的话,那我们可以私下做更多的交流

相关文章
|
5天前
|
人工智能 监控 安全
什么是身份治理和管理(IGA)
身份治理和管理(IGA)是身份和访问管理(IAM)的关键组件,部署于云、本地或混合环境。它通过自动化和策略确保用户根据角色获得适当权限,涵盖身份治理(分析、报告、权限管理等)和身份管理(生命周期管理、工作流编排等)。IGA减少人为错误、防止权限滥用,并简化合规性,提升组织安全性和运营效率。
|
29天前
|
运维 监控 安全
身份是安全的基石:深入理解阿里云身份体系
企业云上身份管理面临诸多挑战,如账号泄露、权限未及时回收等,导致数据泄露和内部系统被篡改。阿里云提供了一套完善的身份管理体系,包括单账号和多账号场景下的解决方案。对于单账号,通过主账号保护、RAM用户和角色实现分权与审计;对于多账号,使用云SSO统一管理和配置跨账号权限,确保安全合规。该体系支持浏览器、API访问,并集成企业IDP,实现无密钥登录和自动化管理,有效降低风险并提高管理效率。
|
8月前
合规培训体系
【6月更文挑战第25天】合规培训体系
147 54
|
6月前
|
存储 监控 安全
IDaaS(身份即服务)的潜在风险
【8月更文挑战第31天】
115 0
|
9月前
|
运维 监控 安全
构建多账号云环境的解决方案|多账号配置统一合规审计
配置审计(Cloud Config)是提供了面向资源配置的审计服务,可以持续监控资源的配置变更,并在变更时自动触发合规评估,确保持续性合规。为了解决企业运维和安全人员业检查资源合规配置的效率难题,配置审计为客户提供了多账号的统一审计能力。用户可以在管理账号或者委派账号中统一设置合规基线并应用,从而可以实时查看企业下经过汇总的不合规资源。
64041 36
|
存储 安全 数据管理
【应用安全】什么是联合身份管理?
【应用安全】什么是联合身份管理?
|
机器学习/深度学习 人工智能 安全
【应用安全】什么是身份和访问管理 (IAM)?
【应用安全】什么是身份和访问管理 (IAM)?
|
存储 安全 数据库
【企业安全】企业安全系列第 2 部分 — 身份和访问管理
【企业安全】企业安全系列第 2 部分 — 身份和访问管理
|
运维 安全 数据安全/隐私保护
账号体系问题可能会造成哪些数据安全风险
账号体系问题可能会造成哪些数据安全风险
384 0
|
存储 安全 程序员
【应用安全】细粒度授权和其他IAM关键条款
身份和访问管理(IAM)的世界有自己的语言,随着新技术的出现和安全威胁的变化,它也在不断发展。