控制台
authing blog banner
查看文章
Authing 两周年庆丨积累点点星光,汇聚成斑斓星河
Authing 成立两周年,我们经历了从成立到快速发展壮大,这离不开 Authing 所有同学的努力,以及全球开发者和客户的支持。 我们也成功获得了华创资本和陆奇博士领导的「奇绩创坛」近千万元天使轮融资到 「GGV 纪源资本」 500 万美元 Pre-A 轮融资。 并成功闯过了疫情的黑天鹅与种种未曾设想的坎坷,最终收获了信念与勇气。   2019 年回顾 产品和架构上我们做了如下更新: 新增众多协议支持:OIDC、SAML(IdP 和 SP)、OAuth2.0、AD/LDAP(IdP 和 SP)、CAS,全面支持单点登录; 新增认证协议在控制台的配置化功能和 SDK 化; 新增 GraphQL 调试器,在 SDK 跟不上接口开发速度时允许开发者通过直接调用 API 完成业务处理; 建立了服务高可用集群,容器集群支持滚动升级; 加速了 Gitbook 在国内的访问速度,从 30s 优化到 2s(仍有优化空间); 使用 Nest.js 重构了全部代码,系统更稳定,代码结构更加合理; 等......(点我了解完整更新内容)   Authing 在 2019 年取得了长足进步,这些进步让 Authing 可以进一步赋能企业和开发者更安全、更稳定的实现自己的业务, 2019 年我们向着 Authing 的使命「让身份管理像水和电一样即需即用」迈了一大步。   2020 年回顾 2020 年 Authing 帮助超 1000 万企业员工和客户安全登录,支持企业自建应用 10000+,累计认证次数多达 5 亿次。 这一年 Authing 走出国门,破浪前行,海外客户分布在美国、英国、日本、加拿大和法国等 10 个国家和地区,为日本丰田、大众汽车、招商银行、安永会计师事务所、意大利裕信银行等世界百强企业提供高质量服务,各行各业都有了 Authing 的身影,这一年 Authing 经历了 2 次重大升级,架构重新设计,视觉重磅升级,近百次的功能迭代,20 倍的性能提升,实现「内外互连」。   Authing 到底是什么样子的?
Authing Share丨如何对用户进行权限管理
当你已经构建起用户系统,在某个时刻你的 API 就需要判断当前访问的用户是否能够访问当前资源了。这时候你就需要构建自己的权限系统。权限系统中一个很重要的概念是授权,授权指的是判断用户具备哪些权限的过程,与认证是两个完全不同的含义。 目前被大家广泛采用的两种权限模型为:基于角色的访问控制(RBAC)和基于属性的访问控制(ABAC),二者各有优劣:RBAC 模型构建起来更加简单,缺点在于无法做到对资源细粒度地授权(都是授权某一类资源而不是授权某一个具体的资源);ABAC 模型构建相对比较复杂,学习成本比较高,优点在于细粒度和根据上下文动态执行。 在 Authing 的权限系统中,我们通过用户、角色这两种对象实现了 RBAC 模型的角色权限继承,在此之上,我们还能围绕属性进行动态地、细粒度地授权,从而实现了 ABAC 权限模型。同时,我们为了满足大型系统中复杂组织架构的设计需求,将资源、角色、权限授权统一组合到一个权限分组中: 你可以基于 Authing 强大而又灵活的权限系统快速构建出适合你业务场景的权限模型。下面我们以现实中一个简单的场景为例。   权限模型介绍 什么是基于角色的访问控制(RBAC) 基于角色的访问控制(Role-based access control,简称 RBAC),指的是通过用户的角色(Role)授权其相关权限,简单来说,这相比直接授予用户权限,要更加灵活、高效、可扩展。 当使用 RBAC 时,通过分析系统用户的实际情况,基于共同的职责和需求,授予他们不同角色。你可以授予给用户一个或多个角色,每个角色具有一个或多个权限,这种 用户-角色、角色-权限 间的关系,让我们可以不用再单独管理单个用户,用户从授予的角色里面继承所需的权限。 以一个简单的场景(Gitlab 的权限系统)为例,用户系统中有 Admin、Maintainer、Operator 三种角色,这三种角色分别具备不同的权限,比如只有 Admin 具备创建代码仓库、删除代码仓库的权限,其他的角色都不具备。 我们授予某个用户「Admin」这个角色,他就具备了「创建代码仓库」和「删除代码仓库」这两个权限。 不直接给用户授权策略,是为了之后的扩展性考虑。比如存在多个用户拥有相同的权限,在分配的时候就要分别为这几个用户指定相同的权限,修改时也要为这几个用户的权限进行一一修改。有了角色后,我们只需要为该角色制定好权限后,给不同的用户分配不同的角色,后续只需要修改角色的权限,就能自动修改角色内所有用户的权限。 什么是基于属性的访问控制(ABAC) 基于属性的访问控制(Attribute-Based Access Control,简称 ABAC)是一种灵活的授权模型,通过一个或一组属性来控制是否有对操作对象的权限。ABAC 属性通常来说分为四类:用户属性(如用户年龄),环境属性(如当前时间),操作属性(如读取)和对象属性(如一篇文章,又称资源属性),所以理论上能够实现非常灵活的权限控制: 在 ABAC 权限模型下,你可以轻松地实现以下权限控制逻辑: 授权编辑 A 具体某本书的编辑权限; 当一个文档的所属部门跟用户的部门相同时,用户可以访问这个文档; 当用户是一个文档的额拥有者并且文档的状态是草稿,用户可以编辑这个文档; 早上九点前禁止 A 部门的人访问 B 系统; 在除了上海以外的地方禁止以管理员身份访问 A 系统; 上述的逻辑中有几个共同点: 具体到某一个而不是某一类资源; 具体到某一个操作; 能通过请求的上下文(如时间、地理位置、资源 Tag)动态执行策略; 如果浓缩到一句话,你可以细粒度地授权在何种情况下对某个资源具备某个特定的权限。   授权模式介绍 Authing 支持两种授权模式: 通过基于 OAuth 2.0 流程中的授权码模式。① 通过权限 API 对用户进行授权管理。   借助 Authing 实现权限模型 下面我们以调用权限 API 的模式为例。 创建角色 你可以使用 Authing 控制台创建角色:在权限管理 - 角色管理中,点击添加角色按钮: 角色 code: 该角色的唯一标志符,只允许包含英文字母、数字、下划线 _、横线 -,这里我们填 admin。 角色描述:该角色的描述信息,这里我们填管理员。 创建好三个角色: 你也可以使用 API & SDK 创建角色,详情请见角色 Management SDK。② 授权用户角色 在角色详情页面,你可以将此角色授权给用户。你可以通过用户名、手机号、邮箱、昵称搜索用户: 选择用户之后点击确认,你可以查看被授权此角色的用户列表。 你也可以使用 API & SDK 给用户授予角色,详情请见角色 Management SDK。② 在后端通过用户角色控制权限 当用户成功认证、获取到 Token 之后,你可以解析到当前用户的 ID,接下来你可以使用我们提供的 API & SDK 在后端获取该用户被授予的角色,这里以 Node.js 为例: 首先获取用户的被授予的所有角色列表: 得到用户的所有角色之后,我们可以判断该用户是否具备 devops 这个角色: 创建资源 上一步我们通过用户是否具备某个角色来控制权限,这种权限控制还是比较粗粒度的,因为只判断了用户是否具备某个角色,而没有判断其是否具备某个特定的权限。Authing 在基于角色的访问控制模型(RBAC)的基础上,还能够围绕资源进行更细粒度的授权。 你可以把系统的一些对象抽象为资源,在这些资源上可以定义了一些操作。比如在本文的场景中,Repository、Tag、PR、Release Notes 都是资源,且这些资源都有对应的操作: Repository:创建、删除等。 PR:开启、评论、合并等。 Tag:创建、删除等。 Release Notes:创建、阅读、编辑、删除等。 我们在 Authing 中创建这些资源: 授权角色操作资源的权限 而且 Authing 还同时支持给用户、角色授权,如果用户在某个角色中,他也将继承这个角色被授权的权限。所以 Authing 既能够实现标准的 RBAC 权限模型,也能在这基础上进行更细粒度、更动态的权限控制。比如下面这个例子中,我们给 admin 这个角色授权了 repository 资源的 Create 和 Delete 权限: 在后端判断用户是否具备权限 在上一步我们通过资源授权,做到了授权给某个用户(角色)对某个特定资源的特定操作权限,我们在后端进行接口鉴权的时候,就可以做更细粒度的判断了: 首先初始化 Management SDK: 这里已 Node SDK 为例,我们同时还支持 Python、Java、C#、PHP 等语言的 SDK,详情请点击此。③ 调用 managementClient.acl.isAllowed 方法,参数分别为: userId: 用户 ID,用户可以被直接授权特定资源的操作,也可以继承角色被授权的权限。 resource: 资源标志符,如 repository:123 表示 ID 为 123 的代码仓库,r repository:* 表示代码仓库这一类资源。 action: 特定操作,如 repository:Delete 表示删除代码仓库这个操作。 options: 其他选项,可选 options.namespace,资源所属权限分组 code Authing 策略引擎会根据你配置的权限策略,动态执行策略,最后返回 true 或者 false ,你只需要根据返回值就能判断用户是否具备操作权限。 总结 本文从最简单的 RBAC 权限模型开始,再在此之上实现了如何进行更细粒度、动态的 ABAC 权限模型,且整个过程是渐进地,你可以随着业务的复杂性不断变大,逐步地迁移到 ABAC 权限模型。 跳转链接: 1.docs.authing.cn/v2/concepts… 2.docs.authing.cn/v2/referenc… 3.docs.authing.cn/v2/referenc…
QCon 演讲实录丨带你了解 Authing 背后的计算哲学
5 月 30 日上午,在 QCon 北京全球软件开发者大会上,Authing 创始人 & CEO 谢扬受邀在「研发平台选型方案专场」分享「 Authing 背后的计算哲学」,现场反响非常热烈,多位技术专家提出问题、参与讨论。 互联网应用越来越多,带来很多便捷性的同时,也带来了很多数据孤岛。这些数据孤岛产生了大量的资源浪费,有无数企业和供应商在解决数据孤岛问题。而现阶段大多数企业解决数据孤岛问题都是采用的数据融合方案,Authing 身份云是从根本上解决计算孤岛问题的解决方案,核心理念之一就是:即使是微小的数据块可以很容易地共享。以下为演讲实录: 背景介绍 Authing 是一款身份云产品,身份云的英文全称是 Identity as a Service (IDaaS),也就是身份即服务,总的来说,我们主要提供两种服务,一种是内部员工身份管理(EIAM),另一种是外部用户身份管理(CIAM)。 内部员工身份管理可以这样理解,一家公司有 1000 个员工,如果这家公司使用了 10 个软件,HR 和运维负责人就需要管理 1 万个身份,而我们可以把管理 1 万个身份的成本降低回管理 1000 个身份的成本。 用户身份服务可以用腾讯这家公司举例,腾讯几乎旗下的所有软件都可以使用 QQ 帐号或微信帐号进行登录,这样就造成账号体系内存在非常大的流量并发。有很多公司也面临和腾讯一样的问题,但却没有技术能力解决此问题,Authing 可以帮助这些企业走出大流量并发的困境。 现在,Authing 在全球拥有 100 多家客户,平台上积累了 1 万多名开发者,这些开发者正在使用 Authing 身份云连接 2 万多个应用。 这将激发起整个软件行业的变革,在没有 AWS 和阿里云之前,人们只能自建服务器,有了它们后,大家选择把服务器托管到云上,从前人们自建身份,现在越来越多的企业选择把身份放在 Authing 上进行托管。 在员工身份方面,以前如 AWS 和 IBM 等都有自己的员工身份系统,这些身份系统往往会受到复杂性的限制,它们处于一种定制化、软件化的形态,被统称为 IAM。身份基础设施 Authing 的出现改变了这个局面,将来 Authing 会变成一种身份标准,连接所有人和应用。 这张图揭示了整个云计算的概览,基础设施层也就是 IaaS 层面是 AWS 和阿里云做的事情,往上一层是应用程序栈堆也就是 PaaS 层,是类似于 MongoDB 上云所做的事,再往上就是应用层和用户层,这就是 Authing 所做的事,我们将用户层和应用层通过云化方式托管,来做整个身份的解耦。 Authing 的优势是非常注重开发者友好,我们提供十几种语言的 SDK 和 700+ API,帮助开发者将 Authing 嵌入到任何应用和设备中,例如我们支持开发者一键打通微信八种登录场景和 QQ 身份等所有身份都可以做统一识别。 计算哲学 什么是计算哲学?讲计算哲学之前,我先谈一下什么是计算,简单来说计算分为三种: 第一种是数学计算,如「15 = 12 + 3」和「X + X = 2X」; 第二种是思维和认知的计算,如「狗 = Dog」和「我爱你 = I love you」; 第三种是视觉计算,如「我 ❤ 你」在中文语境下大脑会自动翻译成我爱你,或者我喜欢你。 观察 Facebook 到谷歌的路线图,我们也能得到很多信息,比如我们可以大致推算出路程所用时间多少、距离的长短,甚至可以推算出需要将车开到什么速度才能准时到达,这就是图形辅助人们进行决策,也就是上文所说的视觉计算。 由于纽威尔、西蒙、福多和明斯基等,一大批学者的努力,物理符号系统假说、心灵的表达计算理论,心脑层次假说等相继提出,让思维就是计算、认识就是计算的结论得到验证。 马尔在视觉计算理论和视觉拓扑计算理论上的研究,与通过规则、程序、逻辑进行加工得出的结果,更加完善了整个计算哲学的全貌。 因为今天是软件开发大会,我们来深入讲解下软件领域的计算哲学,在软件领域我们听到最多的一个词就是 I/O,I/O 简单来说就是输入参数得到结论,比如想要做一个认证请求,得到这个请求是否正确。 宏观来看,整个计算机领域几乎都在围绕着 Input 和 Output 进行编程和数据结构设计。这也是我们 Authing 所秉持的计算领域的世界观、核心价值观和核心目标——Make Data Linked Again。 什么叫 Data Link ?我们可以用「在什么情况下把数据库表的字段参数进行拆分」的问题来解答,正确的答案是信息可以被复用的情况下会进行拆表,比如一个人的身份信息,一个人的 ID 可以关联到所有数据,因为这个人的 ID 要被复用,一个人的文章信息,可能既要用于自己的读者界面,也要用于整个网站页面,所以整个软件领域里面所有关于复用的信息都可以抽出来,作为基础设施进行连接。 现在的普遍做法是通过数据库级别的 ID 字段来进行连接,我们所秉持的连接还不太一样,是更大范围的链接,接下来我通过一个例子,讲下数据互联的好处。 现在 Auhing 在全球有 100 多家付费客户,而且这个数字还在快速增长,结果就是我们遇到很多数据问题,导致我站在公司 CEO 的角度无法做出更高效的决策。 这些影响高效决策的数据包括,招聘人数、营销花费、ROI 、销售转化率、客单价、成单周期和怎么最大化利用渠道。这些数据涉及到各个环节和决策链,它们将最终通过一个关键的决策点在公司层面进行决策,这个决策点就是我们还有多少现金流。 拆分来说现金流包含两部分,第一部分是现金,第二部分是应收账款,现金流计算起来比较容易,要减去一些成本,其中包括人力成本、营销成本,还有公司各方面成本。 应收账款计算非常复杂,它包含的因素更多,比如我们签了多少合同,还有多少合同待签,以及已签合同里面对应的有效线索转化率是多少,计算转化率的原因是转化率影响着预算,预算影响着我们在哪些渠道进行营销、广告投放,以及要投入多少钱,最终能够帮我们进行决策。 在没有完整信息化和工业化系统之前,上图中所有箭头都需要人工录入,而 Authing 成功做到了数据联动,现在 Authing 负责增长的同学只需要输入自己的线索,线索确定有效之后会自动转单给销售,销售填写好更新记录,整体现金流、成本、利润以及我们需要增长多少倍,都会自动出现数据结果,实现了一个非常自动化的流程。 在此之前,我需要找财务同事对齐信息,她再去各个部门之间进行流转,最后用 Excel 来做计算,整个过程繁琐、低效和费时。 现在,整体协作变成了网状结构,每个人只需要各司其职,公司整体层面就可以看到全部数据的流传,并及时给到我们进行决策,这就是 Make Data Linked Again,也是我们秉持的计算哲学。 或许有人会问这跟 Authing 有什么关系?我前面提到 Authing 是解耦了身份应用,我们做业务层面,Authing 就从这个层面做到低耦合高内聚,从身份入口,所有企业都在构建软件或者采购软件,所有软件最离不开的就是身份,Authing 作为最大「轮子」,去嵌入或集成到各种各样的应用中,业务效果从各自为战到高效互联,最后让我可以进行秒级决策。 目标签单额和实际签单额、平均客单价和获取的线索量,每个数据不需要经过财务或者增长运营同学进行繁琐的计算,全部自动化处理,基于所有这些数据,就可以预测未来一年的增长,这就是数据互联带来的好处。 我们所有依靠的数据,通过内容营销渠道,每篇内容访问量都可以实现自动化的监测。包括整个商机增长趋势,我们前期做了非常多工作,保证各渠道线上线下所有数据打通,我们还给每名电话销售人员创建一个专属大屏,以上数据最终会汇总到公司增长中心和财务中心的中台里。 值得一提的是实现上述成果,我们没有动用任何一名研发人员,全部工作都是由我们财务人员和我的 COO 来合作完成的。为什么我们能做到这一点?因为我们用了国外一个非常棒的工具 Coda,这个工具特别符合我们对计算哲学的设想,我的 COO 并不需要使用编程技能,就可以在 Coda 里面通过数学公式实现所有数据的连接,而且里面所有图表和表格都可以自由设计与编写。 Coda 以文档为核心,为什么要以文档为核心,后面会讲一下,这是计算哲学的方法论。Coda 可以嵌入到任何应用当中去,同时编程组件也可以支持编程,这就是我们秉持的计算哲学。 我们的业务人员和开发者,只需要在各个数据块之间做关联,比如我整理出来了公司能够帮助我决策的全部流程,业务人员根据流程在各个数据之间做 Link,我作为一个管理者,可以在所有关联数据里面通过图表或其他方式来做探索和决策。 另外,公司所有人都可以在整个关联关系里面寻找所有相关联的数据,所有数据在公司内部都是关联的,我们想打造的是在全社会层面的数据关联状态,就像是在一个现实世界里面,你可以开车去任何一个城市,但在网络世界里面没有办法开车到另外一个应用里面去。我们就要在应用之间,数据层面、身份层面互联。 另外一个领域是即使再微小的数据块也可以很容易地共享,后面我会讲方法论如何做到这一点。 我们整个计算领域的世界观,就是让数据连接互联,让数据可以被再次编程。 因为我们现在遇到很多数据孤岛问题,其实这些成本在早期的时候可以避免,我们就是要从 Day 1 开始让企业远离这些数据无法互联的困扰。因为企业数据对企业来说是非常重要的,价值非常大,价值挖掘在于数据关联程度不高,降低数据关联成本。   计算方法论 计算方法论就是让计算世界观落地的一系列方法。 中国很少有人讲计算哲学,但我觉得计算哲学对中国整个计算机行业和信息行业的重要性不亚于马克思主义对于中国的重要性,计算哲学从思想层面、理论层面重新构建了一套基础架构,让所有计算更加有序,更加普适。 在交互层面,我们认为未来所有计算都应该是文档,甚至可以形容为「万物皆文档,文档生万物」,如 Coda 之类的工具最大的特性是可编辑性,我们用 Coda 做了一个公司完整的数据中台,图片里面有图表、文字和表格,这就是文档能够给予的价值。 在语义网领域有一个词是语义控制面板,所有数据都是可以互联的,你的粉丝数据、通讯录数据和聊天数据,它会在各个层面被剥离出来,再汇集到文档里面,表格和功能去完整的定义符合自己标准的数据中台,这就是我们认为在交互层面应该做到像 Coda 一样自由灵活。 同时,我们要提供给终端用户和客户非常简单的操作界面,Coda 还有一个理念叫文档即应用,我可以在手机上查看公司所有的数据,这也是我们认为的下一代计算基础设施应该有的状态。 语义组件就是让人和机器都可以读懂。我举个例子,我们在前端做应用的时候,组件的所有名称标签都是非常语义化的,我可以输入<LoggedIn> 标签,帮我快速判断这个用户有没有登录,所有这些字段在整个语义组件层面都是通用的,这是我们想打造的下一个计算未来时代。 我们认为在语义组件层面有三个很重要的点: 1、数据同步 Data Sync 2、实时展现 Realtime 3、可嵌入性 Embeddability 这三点可以组成非常语义化的组件,举个例子,我们在给外国客户发邮件时,因为距离导致的沟通不顺畅等问题,会出现一些类似于地址填写错误的问题,结果就是要反复的调整转发邮件。 在实现数据同步之后,我可以直接把要调整的内容复制到邮件里,对方的显示界面也会实时变动,这个时候所做的编程就不再是 Dom 编程,而是语义组件的编程,我们将各个语义组件像乐高一样重复进行拼接。 业内也有一些公司在做相关的场景落地,比如微软的 Fluid Framework,另外如 Coda 这种软件是 Fluid Framework 的展示层,还有像 Authing 与声网这些公司将一些业务组件化,这就是我们做的事情,这也是我们认为的计算方法论。 语义组件即编程语言,现在大家还在用「 if else 」 这些逻辑和循环语句来写编程,在将来所有编程都会变成语义组件级别的编程,我们也非常认可这个理想,Authing 就让想让所有组件变得可编程,可嵌入到任何一个应用当中去。 现在有很多 SaaS 服务把整个身份体系和权限体系切换成 Authing,我们发现这里面有大量重复的研发工作,组织架构可以嵌入到客户的应用当中去,我们用这样一套思想和理论,帮助开发者减少公式开发与一些不必要的劳动。 下面我总结一下我刚才讲的计算哲学,落地方法通过文档和语义控制面板、语义组件,来做可嵌入性的标准,我们让整个生态变得像城市一样。 我们可以回想一下,没有共和国之前的城市是什么样子,那时城市与城市之间有城墙相隔,相互沟通只能通过飞鸽传输或使馆来信方式,工业时代之后出现了高速公路,现在马斯克提出了地下隧道 Hyperloop,实现点对点的传输,Hyperloop 就很符合计算哲学的世界观。 将来所有数据之间也可以点对点的进行互联,就像我们前面展示的这张图片一样,没有数据互联之前会有单点瓶颈,有了数据互联之后,每个数据、模块和组织都可以进行非常便捷的互联与连接,这就是我们计算哲学所存在的价值,这也是我们希望能给到中国软件行业和信息产业的一些启发。   总结 Authing 计算哲学旨在人、应用和数据之间建立一个互操作性生态。虽然计算哲学的内容在国内非常少,但我认为计算哲学相对于中国整个软件行业的重要性非常大,所以我非常希望大家能够关注计算哲学。 现在企业用户的所有数据在不同应用中被分裂,最看重这些数据的人与数据断开了链接,Authing 的潜力就在于解耦用户身份、数据与应用,从而开启信任和创新的新时代。 大家可以想像在一个网状的数据结构里,每个人都可以无限制的做各种创新,对于公司治理来说,全部有权限的人都可以看到公司的整体状态,让同学们有更多的价值观,更多的控制权和参与感,我们认为在将来所有计算都是以人为中心,都是面向业务,以身份为中心,谁抓住了身份,谁抓住了身份互联,谁抓住了数据互联,谁抓住了计算哲学,谁就抓住了未来。 我们 Authing 的使命和愿景是连接全球人与应用!   Q&A 环节 Q1:我听说 Authing 公司在海外有很多客户,如果从 CIAM 场景来看,Authing 在海外最大的竞争对手是谁? A1:是 Auth0 和 Okta 这两家公司,但 Okta 是一家美国公司,在中国没有提供本地服务,因此在国内访问 Okta 的速度非常慢且不稳定。国外企业如果想在中国开设分公司,Authing 肯定是更好的选择。 而且把 Authing 与 Okta 从身份中台、工作流、目录、应用集成、用户分析、开发组件六个维度与 Okta 进行对比可以看出,目前 Authing 是唯一能够全面替代 Okta 的身份服务提供商。   Q2:很多传统企业在做数字化转型或云转型,他们会把很多应用系统上云,不过虽然云的供应商本身有一些解决方案,但没有像专业的 SaaS 服务这么完善,像我们这种小企业可能会倾向于用轻量级的方式替代专业的方法,Authing 公司最优的发展战略是什么? A2:我们的发展战略是以开发者为中心,永远做面向开发者友好的东西,通过开发者口碑传播和便捷性传播,来获得公司决策层的认可。包括我们整体产品做得很简洁、轻量,我还非常强调整体平台的可嵌入性、可代码性和可编程性,所以任何组件都可以作为一个单独模块给企业和开发者使用,这就是我们的战略。   Q3:我是个程序员,我有些财务数据,怎样去做数据和 ID 的关联,让数据联通起来。 A3:以本体为例,本体是描述数据的数据,本体定义了头像的名称只能叫 Photo 而不能叫 Pricture ,通过这样的语义组件来完成数据连接,需要结合 Fluid Framework 特性,在上层定义很多语义化的标签来做数据互联。 假如说不需要程序员的情况下,上图有我们有整个商机获取的表格,下面有线索阶段,对接人姓名,公司规格。大家可以想想程序员怎么做数据关联,表格与表格之间的数据关联,我们有界面来帮助业务人员做快速的数据管理表格创建和 ID 关联。   Q4:身份认证流程是什么?是否是嵌入到各个应用厂商的产品里,我的产品是否也要上云,还是仅作为一个入口。安全性又怎么保证呢?100 多个厂商上云之后,如果有泄露或者被攻击的风险怎么防护。 A4:我先回答第一个问题,首先整个流程是符合国际标准协议的,认证过程中可以是云上应用,也可以是云下应用,只要系统网络可以联网就行。第二个有关安全性的问题,把身份拓展到云上反而是更安全的,因为我们有更专业的安全工程师,另外,我再说一下技术上的解决方案,第一是有 PKCE,包括所有收据将通过 AWS 和阿里云的 KMS 加密,最后数据只有客户自己能访问到,主要是通过这三种方式。   Q5:我做的业务是偏金融行业的帐户业务,原来我们有想过做 SaaS 化方面的实践,但我们帐户和交易柜台耦合在一起,如果我们做交易结算的时候去查帐户的权限,希望您能够给我一些建议。还有基于帐户上面会有很多「重」的业务,像一些适当性、合规、留痕、校验和人证比对,其实帐户是很忙的,我们虽然可以通过租户的方式来做 SaaS,但我们考虑上面这一层服务是很「重」的。 A5:我们落地了几家银行,银行卡把帐户分成三种类型,客户帐号、内部员工帐号、用户帐号和企业帐户帐号,这三种在银行体系都是分开的,从而可以做到对每个应用的连接。 我建议需要将身份中台单独抽出来,让所有业务都走中台,一种情况下是他们有云计算基础设施,搭建了一个身份云服务,所有应用都切入那个服务,这个服务一般和行内的 AD 或 CAS 进行连接,这个场景会比较复杂 (我们可以私下聊)。
Authing Share|系统安全与防范
概述 随着信息产业的迅猛发展,网络的安全机制与技术也在不断地变化,现在,网络安全技术不再是一种统一的技术和策略,它已经成为了一个十分复杂的系统工程,拆分来说系统安全可细分为用户安全、密码安全、网络应用安全和数据安全。 越来越多的企业开始重视系统安全,为了适应市场的需求,Authing 在系统安全与防范上推出了一套完整的制度与标准流程。 一、用户安全 对于使用 Authing 的用户,我们采用了密码加验证(短信和邮箱)的方式登录,即在密码输入完成后,会给使用者发送短信或邮件提示验证码,当验证码输入正确后才可登录。并且只要此账号登录就会通知到管理员,管理员可以对用户密码进行加密处理或非明文存储等操作。 二、网络安全 网络管理包括网络设备及网络监控等管理,要保障网络设备(例如防毒墙、防火墙等软硬件)安全、可靠和稳定的运行。 合理管理网络设备的 IP 地址,账号密码等不被泄漏,合理设置防毒墙、防火墙等软硬件的过滤规则和防护等级,合理划分管理区域层次,例如安全管理区域、办公区域、网络接入区、核心交换区、中心服务区和数据管理区等。 三、服务器安全 服务器会每天进行监控,定时对服务器进行备份和更换密码,增加密码复杂度,关闭不需要的服务和端口等,禁止 root 远程登录,以及子用户权限合理分配。 四、数据安全 对用户进行权限划分,不同权限的人看到的数据是不同的,只有有权限的人看到的是没有被处理过的数据。 数据备份,灾备保证数据安全性、一致性和隔离性。   制度流程安全 一、用户管理 用户管理分为对使用用户、系统用户、应用用户和数据用户等的管理,按照各种用户的不同身份、不同等级清晰划分用户的各种使用权限及访问范围,通过各个用户的不同需求,使用不同的权限来限制用户的访问范围。 使用用户是指对应用、系统、数据等的使用者,或者对硬件如服务器和交换机等的使用者,这类用户需要根据其对这类事物的应用范围或者用量等合理安排其权利并作详细的使用记录或者留有操作日志等。 系统用户指操作系统的各个管理用户,在操作系统中,一般 Linux 以 root 用户权限最大来管理其他全部用户及文件数据等。root 用户只有运维管理人员或者系统管理员才可以使用,其他人员的使用可以根据需求来创建适合需求的用户来管理数据信息等。 应用用户指应用程序的使用者,这里需要开发人员做好相应的程序控制,不同用户在应用程序中所接触的数据不一样。 数据用户这里主要针对于数据库的操作用户。数据库的各个用户根据不同的数据需求赋予其相应的角色或者用户权限,以达到对不同系统数据的保护和保密作用。 所有用户按照其特点统一管理,根据不同用户的属性划分使用者范围及用户管理人员。其他人员需要使用有权限的账户需要跟相关的管理人员作出申请,申请审核过后并经过登记方,可使用其申请的用户权限,其他人员在未经授权的情况下不得随意使用,或者在有可使用权限以后不能直接告诉其他未经授权使用的人员。 二、密码管理 用户密码和用户名,都需要进行统一的管理。用户及密码的获取均需要提出相应申请,并经过审核,由管理人员登记给出用户及密码。对于密码的安保性,管理人员更需要时刻注意防止密码的外泄。 三、应用管理 应用管理需要加强应用开发、应用代码和应用服务等的安全管理。 应用开发过程中需要有相应的代码描述和注释,统一的代码书写规范及命名规范等。 对于应用代码需要保证代码的安全性,例如防止代码丢失、代码外泄和代码混淆,一般可以通过 svn 等工具,一定程度上提高安全性,但也需要从制度上和习惯上的严格要求。 应用服务需要控制好安全数据的私密性,个人隐私数据及保密数据需要做加密及解密措施,以防止隐私数据的透漏。 四、数据安全 数据安全主要针对数据库内存储的数据管理,包括数据库用户、密码、数据表空间及表的管理。 根据应用系统及存储数据的性质来分配应用使用的用户及密码,划分相应的数据库表结构及表空间。做到数据同一规划,数据存储形式一致,这样既可以保证存储数据的安全性,也可以使我们数据的存储有条理性。   网络安全 一、传输安全 根据应用部署要求和新一代数据中心建设的原则,以及考虑到网络安全的实施,数据中心可划分为以下几个区域 : 数据管理区:集中存储和管理所有应用系统的数据。 业务应用区:部署总局端的业务应用系统。 支撑平台应用区:部署平台支撑应用系统(Session 集中系统、分布式缓存系统和分布式任务调度系统 )。 公共服务区:部署公共服务、WEB 服务和安全管理所需要的各种设置与应用系统。 安全接入区:用于实现与互联网的安全连接和逻辑隔离,包括各种安全设施 ,以及直接向互联网用户提供服务的应用系统。 IT 管控区:用于实现对 ECIQ 主干系统的网络管理、安全管理和运维管理,包括各种安全保障设施和管控平台。 安全接入区域、数据管理区域、应用服务区域、IT 管控区域,采用身份鉴别 : 主机身份鉴别和应用身份鉴别; 访问控制; 系统安全审计; 入侵防范; 主机恶意代码防范; 软件容错; 数据完整性与保密性、备份与恢复等安全保护措施。 二、网络可靠性 网络高可靠性方面,需要采用构建具备高可靠性的网络结构,建设的网络要可以对业务流量实现分流,也可以互为灾备,因此需要构建可靠的硬件冗余以及网络协议冗余,在网络出现单点故障时能够自动侦测到网络的可达性,并对全网络进行宣告,通过硬件切换或软件切换实现网络的可达性,保证网络正常运行。 三、网络负载均衡 负载均衡运行在网络层面,需要将日常的业务流量均衡至整个数据中心,数据中心内采用负载均衡设备对网络数据流量进行负载分担。 对于业务流量,采用全局负载均衡设备对用户访问数据中心分流,根据策略或负载情况不同用户访问不同的数据中心,分散网络流量,减少网络拥塞,提高访问和服务质量。 对于数据中心内部服务器数据流量,采用本地负载均衡把数据流量合理分配给服务器群内的服务器共同负担。 四、网络结构安全 网络结构的安全是网络安全的前提和基础,系统核心路由和网络设备需要进行冗余部署,避免单点故障,并考虑业务处理能力的高峰数据流量,因此需要冗余空间满足业务高峰期需要,网络各个部分的带宽要保证接入网络和核心网络满足业务高峰期需要。 按照业务系统服务的重要次序定义带宽分配的优先级,在网络拥堵时优先保障重要业务服务器,合理规划路由,业务服务器之间建立安全路径绘制与当前运行情况相符的网络拓扑结构图,根据所涉及信息的重要程度等因素,划分不同的网段或 VLAN。 重要业务系统及数据的重要网段不能直接与外部系统连接,需要和其他网段隔离,单独划分安全区域。 五、网络安全审计 网络安全审计系统主要用于监视并记录网络中的各类操作,侦察系统中存在的现有和潜在的威胁,实时地综合分析出网络中发生的安全事件,包括各种外部事件和内部事件,通过网络监控功能及启用网络设备日志审计,并纳入安全管理平台统一监控管理实现。 六、网络设备防护 为提高网络设备的自身安全性,保障各种网络应用的正常运行,对网络设备需要进行一系列的安全加固措施,包括: 1、对登录网络设备的用户进行身份鉴别,用户名必须唯一; 2、对网络设备的管理员登录地址进行限制; 3、身份鉴别信息具有不易被冒用的特点,口令设置需 3 种以上字符、长度不少于 8 位,并定期更换; 4、具有登录失败处理功能,失败后采取结束会话、限制非法登录次数和当网络登录连接超时自动退出等措施; 5、启用 SSH 等管理方式,加密管理数据,防止被网络窃听; 同时需要部署内控运维管理系统对设备管理用户登录认证和审计,确保经过授权的管理员通过可靠路径才能登录设备进行管理操作,并对所有操作过程进行审计、控制和记录,避免授权用户非法操作或误操作,保证对网络设备进行管理维护的合法性。 七、通信保密性 应用层的通信保密性主要由应用系统完成。在通信双方建立连接之前,应用系统应利用密码技术进行会话初始化验证,并对通信过程中的敏感信息字段进行加密。对于信息传输的通信保密性由应用系统和数据库系统传输加密系统完成 。 服务器安全 一、服务器系统安全 服务器安全一:从基本做起,及时安装系统补丁包括 Windows 和 Linux 在内的任何操作系统都有漏洞,及时的打上补丁避免漏洞被蓄意攻击利用,是服务器安全最重要的保证之一。 服务器安全二:安装和设置防火墙现在有许多基于硬件或软件的防火墙,很多安全厂商也都推出了相关的产品。对服务器安全而言,安装防火墙非常必要。防火墙对于非法访问具有很好的预防作用,但是安装了防火墙并不等于服务器安全了。在安装防火墙之后,需要根据自身的网络环境,对防火墙进行适当的配置以达到最好的防护效果。 服务器安全三:安装网络杀毒软件现在网络上的病毒非常猖獗,这就需要在网络服务器上安装网络版的杀毒软件来控制病毒传播,同时在网络杀毒软件的使用中,必须要定期或及时升级杀毒软件,并且每天自动更新病毒库。 服务器安全四:关闭不需要的服务和端口服务器操作系统在安装时,会启动一些不需要的服务,这样会占用系统的资源,而且也会增加系统的安全隐患。对于一段时间内完全不会用到的服务器可以完全关闭,对于期间要使用的服务器也应该关闭不需要的服务,另外还要关掉没有必要开的 TCP 端口。 服务器安全五 :定期对服务器进行备份为防止不能预料的系统故障或用户不小心的非法操作,必须对系统进行安全备份。除了对全系统进行每月一次的备份外,还应对修改过的数据进行每周一次的备份。同时,应该将修改过的重要系统文件存放在不同服务器上,以便出现系统崩溃时可以及时地将系统恢复到正常状态。 服务器安全六:账号和密码保护账号和密码保护可以说是服务器系统的第一道防线,目前网上大部分对服务器系统的攻击都是从截获或猜测密码开始。一旦黑客进入了系统,那么前面的防卫措施几乎就失去了作用。所以对服务器系统管理员的账号和密码进行管理是保证系统安全非常重要的措施。 服务器安全七:监测系统日志通过运行系统日志程序,系统会记录下所有用户使用系统的情形,包括最近登录时间、使用的账号、进行的活动等。日志程序会定期生成报表,通过对报表进行分析,可以知道是否有异常现象。 二、服务器软件安全 服务器软件主要针对我们使用的软件介质,严格防止携带病毒插件的软件的安装实施,所有软件或者应用的安装部署,均要经过领导审核验证安全后才能放到服务器上进行实施。坚决不允许直接通过服务器上网直接下载任何软件。软件或者文件的上传均需要通过前置机或者堡垒机上传至服务器上运行。 三、服务器安全管理 1. 不得在服务器上使用带有病毒和木马的软件、光盘和可移动存储设备,使用上述设备前一定要先做好病毒检测,不得利用服务器从事工作以外的事情,无工作需要不得擅自拆卸服务器零部件,严禁更换服务器配套设备。不得擅自删除、移动、更改服务器数据。不得故意破坏服务器系统,不得擅自修改服务器系统时间。 2. 服务器系统必须及时升级安装安全补丁,弥补系统漏洞。必须为服务器系统做好病毒及木马的实时监测,及时升级病毒库。 3. 管理员对管理员账户与口令应严格保密、定期修改,以保证系统安全,防止对系统的非法入侵。 4. 任何无关人员不得擅自进入主机房,需要进入主机房须征得服务器管理人员同意,爱护主机房内的设备和物品,未经允许非管理人员不得擅自操作机房内设备。 5. 严禁易燃易爆和强磁物品及其它与机房工作无关的物品进入机房,严禁吸咽。 6. 服务器主机房内必须配备一定数量的防火(灭火)器材,并有专人负责管理,注意妥善保管,定期检查,使其处于随时可用的良好状态。 7. 做好机房的防火、防潮、防尘、防虫等工作,坚持“预防为主,防治结合 ”的原则。 8. 双休日、节假日,要有专人检查网络运行情况,如发现问题及时解决,并做好记录处理,解决不了的及时报告。 9. 管理人员每次节假日前必须将数据库以及网站所有程序及资料备份交下载到本地进行保存。 数据安全 一、数据库系统安全 数据库系统的安全性问题包括两个方面:1. 数据库数据的安全:应能确保当数据库数据存储媒体被破坏时,或因数据库用户误操作以及其他原因造成数据库系统 DownTime 时,数据库数据信息不至于丢失。2. 数据库系统防止非法用户侵入:应尽最大限度的发现并堵住潜在的各种漏洞,防止非法用户利用漏洞侵入数据库系统,获取信息资源。 二、数据安全 1. 定时进行数据库数据备份,全量备份,增量备份。 2. 正确分配备份人员的权限。 3. 安装防火墙和入侵检测系统。 4. 数据加密采用 DES、密码反馈等先进的加密技术来提高安全性。在对数据库文件密码、数据库字段说明部分加密时要把它们作为一个整体加密。 三、数据库系统防止非法用户侵入 1. 安全管理 绝大多数数据库管理系统采用的是由数据库管理员 DBA 负责系统的全部管理工作 (包括安全管理)。显然,这种管理机制使得 DBA 的权力过于集中,存在安全隐患。 解决办法是在安全管理方面采用三权分立的安全管理体制,将系统管理员进行拆分: DBA 负责自主存取控制及系统维护与管理方面的工作 SSO 负责强制存取控制 Auditor 负责系统的审计 这种管理体制真正做到三权分立,各行其责,相互制约,可靠地保证了数据库的安全性。 2. 用户管理 用户需要访问管理系统、数据库系统、操作系统、文件系统以及网络系统等,应当申请取得相对应的权限账号,审核通过后才能进行访问数据库系统,为了防止误操作需要及时备份数据用于及时回滚。普通用户是没有对数据库系统操作权限。 身份认证是安全系统中最重要且最困难的工作,因为标识过程和鉴别过程容易混淆。具体而言,标识过程是将用户的用户名与程序或进程联系起来,而用户的鉴别过程目的在于将用户名和真正的合法授权的用户相关联。
Authing 应用市场内测版上线,让单点登录更快更简单
诞生 我们找到一种方法,可以帮助企业管理员和开发者更简单、高效的完成应用单点登录授权。———应用市场 关于应用市场: 应用市场是我们最新上线的功能,在这里,你仅需两步便可轻松地集成第三方应用: 1. 在 Authing 应用市场找到你想要集成的应用。 2. 点击「获取应用」填入该应用的相关配置即可完成。 应用市场的价值: 1. 用户将可以极速、极简的集成第三方应用。(比如,配置阿里云 SAML 应用时,用户预填阿里云 SAML 配置项并上传密钥即可完成配置。) 2. 未来 Authing 将提供 2000+ 的应用集成,通过丰富的应用量和开放的系统架构,所有入驻的企业客户和开发者都能在应用市场生态中受益受惠,Authing 致力于打造中国 SaaS 应用生态体系,为客户和开发者带来极致体验。(Authing 将中国应用市场搬到了“开发者的授权平台”上。) 应用市场的亮点: 可信赖:我们在应用市场中提供了多种安全有效的授权方式,并且所有上架的应用都是经过 Authing 严格的安全认证。 轻松找到你所想:你不仅可以轻松找到所需的集成应用,你还可以在应用市场中浏览到你不了解的可集成应用,我们提供值得信赖的合作伙伴和第三方集成应用目录,仅需点击几下鼠标,即可添加第三方应用到你的 Authing 控制台中。 开放:Authing 应用市场的特点是开放自助,方便开发者在这里资源交换的同时,更欢迎开发者在我们的社区论坛里发起集成应用申请,不过为了保障所有用户的安全,只有通过 Authing 测试和审核的应用才能最终在应用市场上架。 在应用市场中,集成单点登录的详细步骤 我们来通过集成「腾讯云」让用户快速通过腾讯云账户登录应用程序的例子,说明应用市场的使用方法: 1. 注册一个免费的 Authing 账户。 2. 进入 Authing 控制台,再转到应用市场,在这你可以根据需求选择应用集成。 3. 搜索「腾讯」,并点击选项腾讯云选项 之后你将进入到腾讯云集成页面,其中包含以下信息: 第三方集成应用的说明 第三方集成应用地址和隐私政策 可以带你进入应用安装集成配置页的「获取应用」按钮 4. 单击「接入教程」按钮,你将看到集成应用配置的详细分步说明。 5. 按照帮助文档完成「腾讯云」的配置后,点击「保存」。你将被定向到 Authing 应用列表页为用户分配权限。如果想要测试它是否有效,请选择「体验登录」。 6. 链接正常运行,你将看到「腾讯云控制台」包含用户个人信息的页面。 就这么简单!总结一下,Authing 应用市场可以帮你: 搜索目标应用,一步直达目标 自助式教程,帮助你快速上手 开放式模式,无边界体验   已集的应用 你可以通过访问每个集成应用的页面,轻松地将其中任何一个添加到你的应用程序中。 华为云 华为云为用户提供云服务器,云数据库,云存储,CDN,大数据,云安全等公有云产品和电商,金融,游戏等多种解决方案,7x24 小时客服支持,帮助企业轻松上云 。 AWS 中国 AWS 是亚马逊公司旗下云计算服务平台,为全球客户提供整套基础设施和云解决方案。以弹性云服务器、云存储、数据库、机器学习为主的安全、可靠的云计算服务,帮助企业轻松上云。 阿里云 阿里云是阿里巴巴集团旗下公司,是全球领先的云计算及人工智能科技公司。提供免费试用、云服务器、云数据库、云安全、云企业应用等云计算服务,以及大数据、人工智能服务、精准定制基于场景的行业解决方案。免费备案,7x24 小时售后支持,助企业无忧上云。 腾讯云 腾讯云为数百万的企业和开发者提供安全稳定的云计算服务,涵盖云服务器、云数据库、云存储、视频与 CDN、域名注册等全方位云服务和各行业解决方案。 ServiceDesk Plus ServiceDesk Plus 是一个革命性产品,它将 IT 团队从日常救火转变为提供卓越的客户服务。它在处理 IT 问题时提供了良好的可见性和中央控制,以确保业务不会出现停机。经过 10 年的运行,它已经向数以百万计的 IT 人员、最终用户和涉众提供了良好的服务。 腾讯企业邮箱 腾讯企业邮箱是腾讯基于多年海量用户邮件系统研发和运营经验,为企业量身订造的一套办公用邮箱系统。我们为开发者提供了五大开放接口:通讯录管理、新邮件提醒、单点登录、系统日志、功能设置。希望帮助企业提升开发效率、降低开发成本和难度,从而提升生产和管理之间的协作效率。   下一步计划 这仅仅是 Authing 应用市场的开始,我们接下来会集成 2000+ SaaS 应用,如果你想要合作,请联系喻女士,我们非常期待合作! Tel:13717565192 Email:yuying@authing.cn 同时,我们希望应用市场内测版为开发者带来最优质的用户体验,因此,你的反馈对我们十分重要,请在问卷中写出你最真实的想法,谢谢!   扫描下方二维码 参与应用市场内测版调查问卷   请在我们的社区论坛里提出你的看法或问题,并让我们知道你期待的新功能体验。Authing 论坛地址:https://forum.authing.cn
拜登下令强制推行零信任架构
内容来源:安全牛 近日,美国总统拜登签发了业界期待已久的行政命令(EO),旨在采用“大胆的举措”提升美国政府网络安全现代化、软件供应链安全、事件检测和响应以及对威胁的整体抵御能力。总统令提出六大举措: 政策支持。拜登指出,渐进式的改进不会给我们提供所需的安全性;相反,联邦政府需要做出大胆的改变并进行大量投资,以捍卫支撑美国生活方式的重要机构。 消除威胁信息共享的障碍 联邦政府网络安全现代化 增强软件供应链安全 成立网络安全审查委员会 联邦政府网络安全事件预案标准化 拜登总统令强调了联邦政府网络安全现代化的关键举措和最佳安全实践: 迈向零信任架构。(政府部门)向云技术的迁移应在可行的情况下采用零信任架构。CISA 应对其当前的网络安全计划,服务和功能进行现代化升级,使其能够在具有零信任架构的云计算环境中完全发挥作用; 云服务中静态和传输中的多因素身份验证和数据加密; 加快向安全云服务的转移,这些云服务包括软件即服务(SaaS)、基础架构即服务(IaaS)和平台即服务(PaaS); 集中和简化对网络安全数据的访问,以加强分析、识别和管理网络安全风险的能力; 在技术和人员进行投资以实现上述现代化目标。 尽管近年来每位美国总统都下达了加强国家网络安全的命令,但专家们认为,与以往的形式化总统命令相比,拜登的总统令更为详尽,而且成功的机会也更大。拜登的总统令选择了一个“绝佳”的时间点,数天前美国关键基础设施遭遇了前所未有的网络攻击,导致 Colonial Pipeline 输油管道中断,而余波未平的 SolarWinds、Exchange Server 网络攻击也都被看作是美国政府遭遇的最严重的网络攻击。 拜登总统行政命令的一大关键措施是强化供应链安全,要求所有联邦政府软件供应商都遵守有关网络安全的严格规则,否则有被列入黑名单的风险。最终,该总统命令计划创建一个“能源之星”标签,以便政府和公共购买者都可以快速轻松地查看软件是否遵循了安全开发规范。 其他措施还包括成立“空难调查式”网络安全安全审查委员会,该委员会将在重大事件发生后提出改进建议,以及针对政府事件响应的标准化手册。 总统令还给出以下方面的规定:政府范围内的端点检测和响应(EDR),改进的政府内部以及公共部门和私营部门之间的信息共享,以及联邦政府部门进行事件记录的要求,以加强调查和补救。 该行政命令受到了安全专家的欢迎。 Sonatype 的首席技术官兼创始人 Brian Fox 认为,这将要求供应商和软件公司对他们的代码安全性承担更大的责任。 他补充说:“虽然不应该采取政府干预措施来使企业采取适当的软件安全措施,但拜登充分利用联邦政府的购买力来提高软件安全性,这是所有国家都可以借鉴并从中受益的。” Illumio 首席执行官 Andrew Rubin 也赞扬了拜登对分布式计算环境安全最佳实践零信任模型的支持。 他说:“拜登政府发布了一份全面的行政命令,最终承认了过时的联邦网络安全模型的失败,并揭开了新安全设计的第一个迭代——建立在零信任中的全新政府网络安全架构。” “安全(过度)自信并不只是美国的问题,联邦的问题或政策问题,而是全球性问题。因此,我强烈支持这项行政命令。这是对全球政府采取行动的呼吁,我们需要改变保护自己的方式。有了这个新的行政命令、这个新的零信任蓝图,我们将朝着更安全的未来迈进。”