控制台
authing blog banner
查看文章
案例分享 | Authing 助力零售电商 Ubras 构建身份安全运营体系
由于新一代消费者的崛起和社会基础建设的完善,为新一代品牌构建了快速成长的环境。数字化的变革和人货场的重构让 Ubras 等新锐品牌涌现在大众的视野里,弯道超车,定义鞋服时尚行业新风向。通过新需求红利创新品类,围绕着好用、好看、好玩三个核心,抓住当下的人群红利和内容红利,形成强大传播力的爆品,一蹴成为当下网红品牌。在今年的 618 等电商战役中,它们借势全域渠道下的布局,持续爆发。   找准细分增量赛道,打造差异化,是新品牌快速成长的第一招。     创立于 2016 年的女性内衣品牌 Ubras,隶属于彼悦(北京)科技有限公司旗下内衣品牌,总部设于北京。Ubras 主张不改变穿戴者的身体,轻松体现自然的体态美被消费者定义为“犹如人体第二层肌肤”般的穿着感受。Ubras 专注于满足女性对内衣 “舒适好穿” 的基本诉求,以平价方式向女性消费者提供优质面料和创新科技相结合的贴身衣物产品,带给女性消费者舒适感和消费体验。 平均每八秒卖出一件,成立仅四年销售额突破 10 亿大关,内衣销量排名名列全网第一,凭借着无尺码无钢圈的背心式内衣,逐渐占据了女性内衣市场。   需求挑战   随着 Ubras 企业的快速发展,以及数字化转型的不断推动,企业在产品、生产、采购、库存、财务、营销、市场、品牌等各个环节都需要信息化系统的支撑,人员的快速增长以及系统不断新建也催生出了诸如用户账号/权限管理效率低、系统分散登录、弱密码、离职后无法及时删除账号等一系列困扰。   为解决企业大量应用系统在身份管理与访问控制方面的问题,Ubras 彼悦携手 Authing,建设企业身份管理运营体系,以便支撑未来用户持续增长,实现应用系统统一登录、员工入转调离过程中上下游系统账号及权限自动化处理,从而提升用户使用体验,改善应用系统账号及权限管理效率,避免越权账号、僵尸账号等安全风险,使企业员工与信息化系统的连接做到安全、高效、与便捷。   在员工入离职、调岗全过程中,无法及时对应于系统中的员工账户进行同步变动,账号开通变更流程繁琐,容易造成信息安全隐患。 目前 Ubras 信息系统采用独立管理自身用户方式,多身份源,每个系统都有自己的用户管理模块,出现用户信息不一致和管理分散问题。 目前 Ubras 内部有十多个应用系统,包括阿里云、Jira、OA、自研系统等,内部员工多账号多密码访问,没有统一登录的门户,登录界面频繁切换,体验较差,同时也增加了 IT 管理成本。   解决方案 Authing 同步中心:基于 Ubras 在飞书上的身份源和组织架构实现身份供给和账号、组织架构、权限的打通,让企业员工一个飞书账号登录内部所有应用,统一身份管理平台提供账号及组织开通、启用、删除及停用功能,针对用户提供组织信息同步,大大减少 IT 运维人员的工作量,增强应用及账户的信息安全。 应用统一一体化:Authing 单点登录 SSO 为 Ubras 集成阿里云、Jira、自研系统等十多个应用,完成账号同步和访问授权,完善身份安全管理体系。 账号全生命周期管理:通过身份管理中心,统一管理应用系统账号及权限,实现用户入职后账号自动化开通及授权、岗位变动后权限自动清除或增加、以及离职后账号自动禁用或清权,实现员工数字身份全生命周期管理。       业务价值 Authing 为 Ubras 打造一套标准化、规范化、敏捷度高的身份管理平台成为经营发展的基本保障,极大提高了企业生产力。 基于安全的认证协议,将所有系统登录在一个平台上完成,并通过飞书统一登录方式,提升员工 IT 服务体验,帮助员工节省时间,增加员工生产力。 基于标准策略的制定,打通员工入转调离过程中的账号权限开通、变更、及清除自动化管理,在规范管理标准、提高管理效率的同时,有效避免众多应用系统中产生僵尸账号、违建账号、越权账号,从而减少非法账号所带来的信息安全风险。 基于身份管理与权限控制平台的建设,构建企业数字身份建设标准化指导,保障企业未来人员组织的扩张和应用系统的新建,有效支撑企业的快速成长及信息化转型。  
Authing Share|一文读懂测试金字塔
在软件产品上线前,都要进行大量的测试。在软件开发方法日益成熟的今天,软件测试的方法也在不断完善。软件测试的探索,从简单的手工测试发展到单元测试、集成测试、契约测试、UI 测试、端到端测试等多维度协同协作方式为软件质量提供保证,还衍生出 TDD、BDD、自动化测试、混沌测试等侧重点不同的测试方法论。   那面对如此纷繁复杂的测试内容我们该如何制定和构建,如何针对自己的团队选择做出最适合选择呢?   本文将探讨一个自动化的、具备高响应力的、可靠并且可维护的测试组合应该如何构建,该测试组合无关具体架构,无论我们的服务架构是一个 micro service、移动应用程序或者 IoT 系统。 测试自动化的重要性 早期企业通过软件应用提高员工工作效率,但现在软件应用已经成为我们日常生活中的一个重要组成部分。作为用户,我们每天使用的软件越来越多。软件创新也正在不断的推动着软件开发团队前行。在大浪淘沙的数字化浪潮中,如果想跟上时代的步伐,我们去寻找如何在不牺牲软件质量的情况下更快的向用户交付功能成为了重中之重。   随着软件数量增多和软件功能的复杂化,手动进行构建、测试和部署,很快就会变得难以进行,除非你想把所有的时间都投入到手动重复的测试工作中,而不是用来开发功能完备的可工作的软件。把测试自动化,从构建到测试,从部署到基础架构,也许是唯一的选择。   传统的软件测试依赖测试人员手工进行:首先将应用程序部署到测试环境,然后执行一些黑盒测试,通过点击用户界面来检查软件工作是否正常。通常这些测试将由测试文档约定,以确保测试人员每次测试的内容是一致的。   显然,手工测试所有功能非常耗时、繁琐且重复。重复很无趣,无趣就容易犯错,所以保证整个软件质量需要耗费大量人力物力。   但值得一提的是,当前针对重复性的手工测试已经有了较为完善的解决方案:自动化测试。   自动化将测试工作从繁琐重复过程中解放出来。构建自动化测试后,测试人员工作的侧重点就可以从保证程序功能完整性转移到安全性、健壮性、可用性等方面。   同时对于软件开发人员,自动化这些测试意味着你可以充满自信地修改你的代码,在你对代码做了大规模改动后惬意地喝一杯咖啡,喝完咖啡后就能马上得知你的改动有没有破坏原有功能。这样的开发体验是不是听起来就让人舒服多了。 测试金字塔 对于如何构建合适企业的自动化测试流程,我们必须要知道一个关键的测试方法论:测试金字塔。 麦克科恩 (Mike Cohn) 的著作《Succeeding with Agile》一书中提出了测试金字塔这个概念。通过使用金字塔形状形象的比喻测试是需要分层的。它还描绘了每一层的测试类型。 从 Mike Cohn 的测试金字塔模型来看,整个金字塔由三层组成: 单元测试 服务测试 UI 测试 整个金字塔模型代表着越上层的测试集成度越高,执行速度越慢,越下层的测试隔离性越好,执行越快越轻量。   图中分层粒度已经不能代表今天适用的测试结构了,有人认为 Mike Cohn 的测试金字塔里的命名或某些概念不是最理想的,从当今的角度来看,测试金字塔似乎过于简单了。   但是,我们仍能从测试金字塔中得到适合我们自己的经验法则: 构建不同粒度的测试 越高层次的测试应该越少,我们应该制定合理的测试策略   为了保持测试金字塔的形状,一个快速、可维护、覆盖范围合理的测试组合应该是这样的: 包含很多小而快的单元测试。 一部分粒度更粗的测试,如 API test,contract test。 较少的高层次的端到端测试。   同时,还有两点我们要注意的。一是千万不要让你的测试变成倒三角的形状,维护集成度更高的测试需要更多的上下文,同时执行起来也更慢,二是不用太拘泥于测试金字塔中各层次的名字,层次是根据测试粒度划分的,这一点也非常具有误导性,对于现代的前端单页应用,UI test 则可能不必位于最顶层,你完全有能力对 UI 进行单元测试,测试分层只需要和团队达成一致即可。 总结 对于现代软件测试架构来说,根据测试金字塔方法论制定一套合适的测试策略,将是快速迭代过程中质量保证的关键,同时分层结构的测试也更容易集成到 DevOps 体系中,将不同类型的测试分配在不同测试节点,以平衡研发效能、迭代周期、软件质量保障三者之间的关系。
Authing share | 一文带你读懂云原生、微服务与高可用
云原生 云原生是一个不断变化的概念,它的定义也在不断变化,其解释权不被个人或某些组织所有。但大体上,云原生(CloudNative) ,云指的是应用位于云中,而不是传统的数据中心;原生是指应用在设计之初就是以在云上运行为目标的,最大限度的利用云的分布式、高弹性等优势。   Pivotal 公司于 2013 年首次提出云原生(CloudNative)概念,现在 Pivotal 已成为了 Vmware tanzu 的一部分,他们最新的官网对于如何构建云原生应用描述了以下 4 点: DevOps:DevOps 是软件开发人员和 IT 运营之间的协作,旨在提供解决客户问题的高质量软件,使构建、测试和发布软件可以快速、频繁且更一致地进行。 微服务:微服务是一种将应用程序开发为小服务集合的架构方法; 每个服务都实现业务功能,在自己的进程中运行,并通过 HTTP API 或消息传递进行通信。 每个微服务都可以独立于同一应用程序中的其他服务进行部署、升级、扩展和重新启动,通常作为自动化系统的一部分,可以在不影响客户的情况下频繁更新实时应用程序。 容器化:与标准虚拟机 (VM) 相比,容器有更高的效率和速度。 使用操作系统级虚拟化,单个操作系统实例在一个或多个隔离容器之间动态划分,每个容器具有唯一的可写文件系统和资源配额。 创建和销毁容器的低开销以及单个 VM 中的高打包密度使容器成为部署单个微服务的理想计算工具。 安全性:云原生安全基于以下三个原则提供了一种降低企业风险的变革性方法:更新可用时立即修复易受攻击的软件; 经常从已知良好的状态重新修复服务器和应用程序; 经常轮换用户凭据。 总而言之,云原生架构的应用程序应该是:采用容器化方案,基于微服务架构提高灵活性和可维护性,借助敏捷方法、DevOps 支持持续迭代和运维自动化,利用云平台设施实现弹性伸缩、动态调度、优化资源利用率的应用程序。   云原生构建应用简便快捷,部署轻松自如、按需伸缩、架构灵活;相比 OpenStack 等虚拟化方案,减少了虚拟化的开销、部署成本低、性能更好;相比纯 Docker 集群,有更好的编排能力,维护性更好,可用性更高,可以减少故障率;而天生对微服务的支持也使得高内聚、低耦合可以轻松实现,使得运维、扩容、敏捷开发变得更加容易;云原生的优点不一而足,缺点却难以与其相提并论。 微服务 软件设计有两个关键目标:高内聚、低耦合,围绕这 2 个核心目标,又提出了单一职责、开闭原则、里氏替换、依赖导致、接口隔离、最少知识等设计原则,这也即是微服务的原则。   一个项目,开始搭建时总会有预料不到的后续问题,随着用户和业务的增长,性能就会出现瓶颈,或者项目的架构难以满足业务需要,这时候除了常规的代码优化外,就需要拆分服务了。   举个例子,一个项目刚刚创建,谁也不知道它未来要服务多少客户,5 个人的团队就能完成全部的开发任务,每个开发人员都对项目的代码心中有数,但随着业务的增长,复杂度的提升,团队从 5 个人变成了 50 个人,代码也从几千行到了几十万行,这时候单一的开发人员就很难对所有的代码都做到“心中有数”了,而当代码数量再度增加,业务也更上一个层级的时候,单纯的某一个子业务的代码就已经复杂到需要一个团队来开发维护了,此时老的架构已经不能支持业务的需求,对代码的维护也成了一个难题。   更好的做法是,在某个合适的时间点把代码按照核心功能拆分成一个个微服务,每个服务只关注自己的实现,每个服务都可以单独开发和部署,每个服务都可以交给一个团队,服务之间通过预先定义好的接口进行通讯。这样,每个团队只需关心自己负责部分的代码和功能,而个别服务出现故障也不会影响其他服务,而且采用这种架构我们可以快速进行迭代开发,提高交付效率。   Authing 就采用了微服务架构,这样可以带来最大的灵活性、可靠性和开发效率。 高可用 高可用是一种面向风险设计,使系统具备控制风险,提供更高的可用性的能力。   从概率学上讲,凡是可能出错的,随着次数的增加,出错将是不可避免的,这时我们就需要预先对各种风险作出评估,通过种种手段抑制避免这些风险,保障服务的可用性。   云原生和微服务虽然很好,具有灵活可拓展等一系列的优点,但想要做到高可用,还需要做很多努力,我们从控制风险、问题追踪、故障解决三个方面来讲: 控制风险 控制风险有四大因素:减少风险数量:从源头上减少风险,比如外面下雨你不出门,那你就没有被雨淋的风险;降低风险变成故障的概率:比如在任何可能阻塞业务的代码中加入错误冗余处理使其不阻塞其他业务;减少故障的影响范围:把整体业务拆成一个个微服务,某个服务挂掉了,不会影响其他服务的正常运行;缩短故障影响时长:事前做好预警工作、平时做好监控工作、有充分的预案和灾备、事后做好复盘,能自动化的操作尽量自动化,需要人工的操作尽量一键化,比如一键切换、一键回滚、一键扩容等等。   Authing 为了避免风险作出了诸多努力:在测试前会使用 Sonar 等工具检查代码质量、每次上线前都会进行多轮的冒烟测试、对于线上还会有定时的自动化测试脚本,一旦某个环节出了问题,就会自动预警以及时修复,等等。 问题追踪 平时要做好监控,发现问题才好追踪。对于云原生应用来讲,需要保证各个层面都有监控,日志集中管理,出现问题才好随时复盘,还应利用好各种工具来检测服务和集群的各项指标,出现问题前及时预警。   Authing 采用了 prometheus 、 grafana 等工具实时检测服务的各项指标,前端也做了相关埋点工作,并在各个层次和维度上记录了详细的日志统一管理,从开发、提测到上线,每一个节点都有记录了明细的相关文档可以追踪,这样可以保证及时预警避免事故发生,即便出了事故也可以快速定位修复问题。 故障解决 即便做了这样或那样的努力,有时候还是无法避免故障的发生,这时候就要尽快解决问题。在平时做了充分监控和记录的前提下,查阅日志和监控记录,复线问题,定位代码以找到错误并修复问题的速度就至关重要了。   Authing 采用了微服务架构,当问题出现时我们可以快速定位哪个模块出了问题,根据已有的日志和监控,快速定位、复现问题并解决问题,事后通过复盘避免类似事故的再次发生。   Authing 作为 SaaS 产品一直致力于提高自己的可用性,给客户更好的体验,我们会不断优化自己的架构,不断实践,不断进步。  
案例分享 | Authing 身份供应方案助力 PingCAP 实现 40 多个应用的单点登录和组织管理
随着企业数字化转型的高速进程,企业在发展进程中不断引入软件应用、IT 设备等搭建企业基础设施,来实现数字化管理,减少企业支出成本、提升管理运营效率。而在这一进程中,企业数字化系统建设体量越来越大,随之带来的应用软件账号管理、员工身份授权管理、老旧应用集成管理等问题,为企业 IT 部门和运维管理部门带来了极大的挑战。   在此环境下,Authing 身份供应/同步中心能基于第三方应用/ AD 中获取组织架构和账户信息,以及从 IDaaS 同步组织架构和账户信息到第三方应用/ AD 的配置、管理、审计中心,极大节省用户数据跨应用管理的成本,用户信息的维护成本和用户信息可流动性的管理。 01 Authing 身份供应/同步中心方案 Authing 与应用系统之间以 SCIM / LDAP 方式建立通信。   数据通过同步引擎、字段映射,基于 SCIM 与 LDAP 协议实现应用系统之间用户数据的同步。同步的成功和失败都会记录详细的网络日志,方便管理员随时查看任务信息,掌握同步进度和情况。   同步功能还提供定时任务机制,实现自动化数据同步的能力。想要构建同步机制,只需在同步中心选择身份源或者选择下游身份接收者(应用),配置映射同步的字段,设置好定时任务,点击开始,系统就会自动的进行用户信息增删改查的同步任务。     字段映射能力   Authing 的同步中心,采用极简的设置解决了复杂的员工身份同步管理问题,实现组织的同步和信息的同步。     02 案例分享 PingCAP 是一家企业级开源分布式数据库厂商,提供包括开源分布式数据库产品、解决方案与咨询、技术支持与培训认证服务。   由 PingCAP 创立的分布式关系型数据库 TiDB,为企业关键业务打造,具备「分布式强一致性事务、在线弹性水平扩展、故障自恢复的高可用、跨数据中心多活」等企业级核心特性,帮助企业最大化发挥数据价值,充分释放企业增长空间。   需求挑战:   • PingCAP 在长达 3 年的时间里一直存在多个员工身份源,在公司组织机构、跨平台的管理上存在难点,包括飞书,北森,Google 等接近 40 个应用之间的单点登录、协同办公和组织的管理需求。   • PingCAP 在国内、海外多个国家都有办公室,怎样做好各国员工身份管理,降低身份管理和运营成本是现阶段亟待解决的问题。   • PingCAP 希望可以通过北森 HR 系统作为企业统一身份源,进行海内外员工入职、单点登录、协同办公(项目组管理)、离职等自动化管理,能够搭建一个身份中台,管理和同步员工信息、组织机构,并可扩展到下游应用中,减少身份重复产研建设。   解决方案:   • 单点登录:基于 OIDC、SAML 协议,Authing 帮助 PingCAP 对接现有全部应用,Authing 的身份供应帮助 PingCAP 实现 单点登录 SSO 的功能,实现使用一个账号登录企业所有应用。   • 身份供给/同步中心:基于 SCIM、LDAP 协议实现组织机构供给能和 Authing 身份供给能力,实现 PingCAP 员工身份上下游同步供给的能力,可扩展高可用。   • 全球化部署:Authing 通过全球化部署方案,在中国区、美国区,分别部署两个业务中心。在中国区创建一个数据中心,通过外部读写一致的能力,保证了整体数据安全。   • Authing 对员工入离职管理和信息同步的产品能力,帮助 PingCAP 大大降低了运维时间和成本。   客户评价:   高科技创新的产品,灵活敏捷,响应速度快。没想到我们 40 多个应用的单点登录、协同办公和基于身份供应的上下游需求,用 Authing 产品很快就帮我们实现了需求。
Authing 与飞连达成全面合作,携手开创企业数据安全新格局
今年 7 月,字节跳动旗下智能科技品牌火山引擎宣布推出“飞连”正式版,这是集虚拟专用网络、办公网络管控、终端管控、网络准入、防病毒等功能为一体的数字化办公平台,能够帮助员工安全连接企业网络、设备和办公应用。   近期,Authing 与飞连达成全面合作。   01 飞连全面支持 Authing 登录 随着企业数字化转型的不断深化,远程办公 & 运维、移动办公逐渐成为新常态。受疫情影响,企业办公方式在也不断改变,边界不断扩大,复杂的办公环境也为企业带来了诸多挑战。   Authing 是国内首款以开发者为中心的全场景身份云产品,集成了所有主流身份认证协议,为企业和开发者提供完善的、安全的用户认证和访问管理服务。Authing 致力于以身份为中心,在所有 SaaS 软件和用户中建立身份共享的社会性基础设施,帮助企业构建安全的现代 IT 基础设施,不仅保护公司业务,更重新定义用户体验。   飞连在支持原有企业微信和钉钉身份基础之上,扩展使用 Authing 登录方式,同时还实现了和 Authing 组织部门数据打通。Authing 成为 ToB SaaS 的中立公共身份服务商又进一步。     基于飞连新一代融合办公安全解决方案与 Authing 独特的身份云基础设施实现融合,更加保障企业用户与客户的网络访问安全、灵活、易用、高效的数字化基座。飞连全面支持 Authing 登录,实现网络连接与身份云产品层面的打通,最终全方位保护客户数据安全。另外,通过多端融合及 Authing 产品的自适应多因素认证,Authing 实现一个账号登录所有应用,飞连实现终端安全集约化建设与轻管理,共同保障企业数字化办公动态安全防御体系的建设和落地。     02 生态合作 Authing 完善的统一身份认证体系,覆盖用户账号的全生命周期管理和权限控制结合飞连稳定的办公安全保障能力,发挥各自领域的优势,逐步实现全产品的合作、深度项目合作及品牌市场合作,为用户赋能增值,共建新生态,共拓新领域,实现双方市场共享及资源共享,推动行业企业数字安全转型落地。   Authing CTO 尚斯年表示,以 Authing 目前在数字身份领域已具备的明显优势,率先将 IDaaS 技术、方案和产品在国内推广和落地的企业,客户群和行业分布较广,产品创新力强,场景布局深,与飞连在产品和方案上形成融合,共建工作组,实现全生态的深度合作。   03 最佳实践 Authing -飞连 合作解决方案 远程办公场景 为了更好的支持企业远程办公和保护企业的网络安全,推出虚拟专用网络(VPN)结合统一身份管理方案。既可以避免企业暴露内部服务在互联网上从而被黑客攻击,同时提高企业员工远程办公的效率和访问控制。飞连结合 Authing 打通网络链路来实现统一身份认证体系。 Office 办公场景 可通过 WIFI 准入、终端安全、监控告警、统一身份认证、统一身份授权、用户行为分析、风险引擎管控等能力,来保障办公安全、合规、高可用、可扩展结合为一体的安全身份基础设施。   合作客户案例   PingCAP PingCAP 是一家企业级开源分布式数据库厂商,提供包括开源分布式数据库产品、解决方案与咨询、技术支持与培训认证服务。   结合 Authing 身份能力和飞连新一代融合办公安全解决方案,降低客户沟通成本,一站式解决 PingCAP 40 多个应用的单点登录、协同办公和基于身份供应的上下游需求,以及在用户登录过程中的安全防护问题。   仙工智能 上海仙工智能科技有限公司成立于 2020 年,是一家以智能化软件开发为核心的创新型公司。   Authing 完善的身份认证能力,和对应用的高可复用性,结合飞连的办公网络管控和终端管控机制,快速完成仙工智能对应用的身份集成及外部客户的安全登录管理,这一联合解决方案,创建了无缝的登录体验,提高了企业的安全策略,并大幅降低维护成本。
Authing 入选“卓信大数据计划”成员单位
9 月 10 日,中国信息通信研究院(以下简称“中国信通院”)公布了第三批“卓信大数据计划”成员单位名单,经审核认证,Authing(北京蒸汽记忆科技有限公司)顺利入选。   当前,数据成为国家基础性战略资源、重要生产要素,对于推动经济高质量发展,助力国家治理体系和治理能力现代化具有重要作用。中共中央关于“十四五”规划和二〇三五年远景目标建议明确提出建设网络强国、数字中国,发展数字经济,建立数据安全保护基础制度和标准规范,保障国家数据安全。   随着《数据安全法》以及《个人信息保护法》的正式通过,行业企业对数据安全领域的合规有着强烈的意愿,企业数据安全治理、数据安全保障、数据安全体系建设的重要性不断增强。然而,行业企业仍面临着不会做、不外化、不能用等诸多问题。因此,业内迫切希望行业内推出权威的数据安全治理全要素解决方案。   为促进各行各业更加安全的存储数据、使用数据、共享数据,中国信通院在广泛听取各方意见和建议后,于2021年初正式启动“卓信大数据计划”,旨在通过推出多层次指导措施和基础服务帮助企业提升数据安全能力,推动我国数字经济更加健康、可持续的发展。   Authing 作为国内领先的统一身份认证 IDaaS 服务商,致力于连接全球人与应用,让身份管理变得简单,保护企业数据资产。除了制定相应数据安全保障体系和机制,还积极参与到相关国家标准的应用试点中。此外,Authing 也在通过技术创新与产业合作,不断探索企业的用户认证和访问管理服务,实现企业的身份认证、访问控制、身份治理,响应“十四五”规划和二〇三五年远景目标,促进企业数据安全生态建设。   Authing 的对身份认证安全的重视根植于心,此次入选国家信通院“卓信大数据计划”,也将为 Authing 持续提升数据安全保障能力赋能。   “卓信大数据计划”第三批入选名单如下(排名不分先后):   名单来自“卓信大数据计划”  
还分不清摘要、加密?一文带你辨析密码学中的各种基本概念
你一定听到过这些词:加密、解密,也听过种种说法:   我要用 md5 把密码加密一下 将 base64 字符串进行解密 把 token 进行加密,验证时需要解密   很遗憾,以上的说法都是错误的。那么本文就带领大家一探密码学的究竟。当你说「加密」的时候你究竟想说的是?当你说「解密」的时候,你实际指的是? 编码 首先我们从编码开始。一生二,二生三,三生万物,编码就是「一」。试想一下如何用一个只能存储数字的设备来存储汉字呢?一个很自然的想法是将汉字转化成数字,然后再存起来:   例如:用 1 来表示「一」,用 2 来表示「二」,用 24 来表示「人」...... 将所有汉字映射成一个数字,然后将这些数字存储起来。   需要对编码方式进行事先约定,不然你一个编码,我一个编码,大家谁都听不懂谁说的是什么。 谁让电脑是美国人最先发明的,非常流行普及的编码方案也是人家提出的,让我们看看 ASCII 编码:     所以当你想要将「Good morning」存进电脑里,需要存「47 6f 6f 64 20 6d 6f 72 6e 69 6e 67」(16 进制,篇幅原因不再展开成为二进制)。   那么 base64 是什么?base64 也是一套编码规范,可以将二进制数据映射成可见字符(什么是不可见字符?像空格,换行符,制表符都是不可见的)。应用场景呢,比如你想把一张图片塞到 JSON 格式的数据里面,就要对图片二进制流进行 base64 编码。   所以,以后,作为一个密码学专家,你就要说,我会用 base64 算法编码一下图片文件。   最后一个问题,对信息编码会产生信息损失吗?请读者自己思考一下。 摘要 试想有一个搅拌机,放进去原料,输出果汁。在计算机的世界里,也有这样一个摘要机,输入数据,会输出数据的摘要。常见的摘要算法有 sha1、md5。     可以从摘要值反推输入的信息吗?可以从果汁还原水果吗?熟鸡蛋可以反生吗?摘要的计算是单向的,只能通过输入的信息计算摘要而不能从摘要反推信息。   MD5 算法总会输出一个 128 位二进制数,那么我计算一个电影文件的摘要,我可以通过这个 128 二进制数来还原整个电影吗?显然不能。   摘要算法的另一个特性是对于任意的输入变动,得出的结果是截然不同的。见上图,123456 和 1234567 只差了一个数字,计算出来的摘要值是完全不同的。即使你偷偷剪掉一个电影的一秒钟,计算出的电影摘要值也是完全不同的。   所以这有什么用呢?假设你是电影导演,在电影上映前需要先将剪辑后的作品发给不同的公司进行审核校对,那么你可以偷偷剪掉第一秒,计算一个摘要值,然后发给一个公司;偷偷剪掉第二秒,计算一个摘要值,然后发给第二个公司,以此类推。这样一旦有人将你的作品泄露到网上,你就能够通过摘要值立刻知道是哪家公司泄露出去的!还记得《权力的游戏》最后一季上映前先泄露了四集吗?如果他们使用这种方法,追查起来就可以很方便了。   总结一下摘要的特性:不可逆,失之毫厘,谬以千里。   所以,以后,作为一个密码学专家,你就要说,我要用 MD5 对明文密码做一个摘要然后再存储到数据库。 加密 试想在现实世界里,如果加密传递信息呢?把信息写在纸上,然后把纸装进盒子里,再把盒子锁上,最后把盒子邮寄给接受者。前提是接收者必须有这把锁的钥匙。你需要另寻办法将钥匙给到他。   在计算机的世界里,对称加密算法的原理也是类似。你有一段信息,有一个密钥,你用一段文字作为密钥,对你的信息做数学运算,得到一个结果,然后你把结果发给你的接收方,他用同样的文字作为密钥,对加密结果做数学运算,得到信息的原文。   常见的对称加密方法 AES、DES,本质上都是使用一段文字对原始信息做数学运算,然后将结果发送给接收方。   加密的意义在于,及时信息在传递过程中被黑客截获,他也不知道双方在说什么。       那么对称加密的密钥如何传递呢?另寻办法的方法是什么?非对称加密呼之欲出。非对称加密算法,用于加密和解密的密钥是不同的。也就是说,一段文字用于加密信息,另一段文字用于解密加密的结果。 公钥 在数学上,公钥就是两个数字(e,n)。e 一般取 65537,n = p * q(p 、q 为质数)。公钥用于加密。 私钥 在数学上,私钥就是两个数字(d,n)。d 是 e 对于 ø(n)(欧拉函数)的逆元。私钥用于解密。 公钥与私钥的关系 1. 在数学上没有区别,都是一对数字,取决于将哪一组数字公开。 2. 公钥加密的内容要使用私钥解密;私钥加密的内容要使用公钥解密。 3. 私钥要自己保护好,不得泄露;公钥可以公开在互联网上,任何人都可以用它来加密信息,当然加密内容只有私钥能够解出来。   下面是一次 RSA 加密信息的过程:       Q: 可不可以用私钥加密数据呢?   A: 可以!   Q: 那用公钥解密数据?   A: 是的!   Q: 公钥暴露在网络上,任何人都能解密数据,那加密还有什么意义?   A: 继续往下看! 拓展:上图中要计算每个字符编码的 e 次幂,需要算几次? 签名 先计算信息的摘要值,用私钥对摘要值进行加密,生成的结果叫签名值,签名算法有 RS256。顾名思义,是 RSA + HS256 的组合写法。签名需要分两步走:   计算信息的摘要值 用私钥加密摘要值,得到签名值   验签 利用公钥对签名信息进行验证。拿到一段信息和它的签名值,需要先本地计算信息摘要值,用公钥解密签名值,和计算的信息摘要值进行比对。     还记得公钥和私钥的区别吗?如果我们用私钥对数据加密,任何人都可以用公钥解密加密结果(公钥是公开的),如果解出来的内容是有意义的,那么数据的来源一定是私钥的持有者,如果解出来的内容是乱码,那么数据的来源就不是私钥的持有者。   那么之前对称加密算法的密钥传递问题也解决了,接收方将公钥给发送方,发送方用公钥加密一个密钥,接收方用私钥解密加密后的内容,得到密钥原文。如此一来,钥匙就安全地交给接收方了。   总结一下,如果你想对一段信息签名,先算它的摘要,然后用私钥加密摘要值,这样所有人都可以使用公钥验证它的正确性;如果你想加密传输一段信息,用公钥加密这段信息,这样信息接受者可以用私钥解密加密后的结果。   当你说加密的时候,你实际想说:编码、摘要、加密;当你说解密的时候,你实际想说:编码、解密、验签。
Authing 官方
·
2021-08-26
·
816 人阅读
Authing share | 身份访问管理关乎企业的发展
据报道,美国安全企业曾发现一起重大数据泄露事件,一个属于 One More Lead 的数据库将多达 6300 万的用户信息储存在一个没有保护的数据库中,至少有 6300 万人的身份信息可能被盗,或者被诈骗,甚至更糟。如何进行统一的身份和访问管理,来减少数据泄漏的风险呢。 01 身份信息安全关乎着企业的发展 首先,身份和访问管理,或者简称身份管理 IAM:Identity and Access Managetment,大多数人想到的都是针对企业内部员工、合作伙伴、临时人员等提供统一身份认证和权限管理能力的内部产品(Enterprise Identity & Access Management 或 EIAM)。 然而,随着软件的边界拓展到我们生活的方方面面,统一管理身份的需求也不断拓展边界,以企业为核心,由内而外,企业也开始容纳外部的海量顾客身份,由此诞生了针对互联网用户的顾客身份管理(Customer Identity & Access Management 或 CIAM)。 初始由 Accenture、AWS 等国外服务商率先将 CIAM 作为一个独立的、必须的产品来看待。完全不同于以内部效率为核心的 EIAM 产品,CIAM 的目标是协助企业完成全局的信息化转型,在所有对外服务中统一用户的身份,在以体验为核心的用户争夺战中,为终端用户提供完整的身份自助服务、为不同平台用户提供统一而流畅的使用、注册体验,以此来提高用户的留存、黏性,进一步创造价值,在行业竞争中取得先机。 今天领先的 IDaaS 服务商,都在致力于为企业提供上手即用、安全可拓展的用户管理和认证服务。使用 IDaaS,企业的 IT 研发、运维人员都可以快速管理任何应用、人员或设备的连接。无论是顾客、成员或是合作伙伴,无论是在云上、本地或是在移动设备上,IDaaS 服务商都可以帮助政企的 IT 服务变得更加安全,提高外部的核心业务的上线速度,也提高内部人员的生产力并保持合规性。 当然,企业在做好身份管理的过程中也⾯临着诸多挑战。 比如身份系统重复建设,导致多⽤户⻆⾊和分⽀机构并存,并需要投⼊⼤量运维资源,⽼旧应⽤的集成将⾯临极⼤的改造成本,使企业运营成本直线上升。此外,如果权限管理体系建设不完善,会导致⼤量应⽤系统外部暴露,业务系统技术标准不统⼀,因此安全管理制度和策略难落实,身份管理的难度也会增⼤。而基于边界的传统⽹络安全架构会使得企业数字化转型成为难题。另外,如果多应⽤重复开发身份登录模块,则⽆法复⽤和统⼀⼊⼝,因此导致开发周期长,成本⾼,身份管理难度大。 02 Authing 下⼀代身份云 致力于降低企业开发成本 Authing 基于身份源的用户管理体系,快速集成国内外多应用系统,加速企业研发团队核心系统的研发,减少研发周期。 同时,Authing 节约构建了身份管理系统的成本,并减轻未来维护升级的负担。Authing 的流水线 pipeline 能帮助开发者快速自定义认证流程中的功能改造,极大的降低企业开发成本,提高生产力。解放出的人力可让开发团队专注于核心业务,为企业的创新能力扩展出新空间,同时也可加快产品交付上市的时间。 Authing 可以帮助用户应对以上种种挑战,并摆脱系统结构复杂、耗时耗资、扩展性差等传统身份认证管理(IAM)解决方案的困境,快速实现任何 Web、App 和企业软件的身份认证和用户管理,为客户和员工提供最完善的登录解决方案。 Authing 已帮助上千家企业和开发者构建标准化的用户身份,可帮助企业降低 90% 运维成本,降低 50% 开发⼯时,提升管理和运营效率,统⼀数字身份,刻画更⾼精度的⽤户画像。 Authing 还拥有 700+ 开放接口,支持 RESTful 和 GraphQL,以及 Python、JavaScript、Node、PHP、Java、Swift、Rust 等编程语言和框架,满足 Web、 iOS、 Android 或其他后端各平台的使用需求。Authing 全面支持 Serverless 架构,有和 Serverless 安全兼容的 OIDC 框架,可以实现安全的单点登录和身份认证。多语言、跨平台、直观、友好、丰富的 SDK 支持。 想要进行统一的身份认证管理,快来试用吧!
搭建数据中台|实现用户原生打通
前言 大数据时代,数据成为企业的第一驱动力,数据具有普遍的代表性,能够给企业的机会提供有力的线索,在当前瞬息万变的商业战场上作出最正确,最科学的决策。 有人把数据比作石油,内部存在着无限的能量和财富,孕育而生了数据中台的概念。数据中台则像发电厂一样,将数据挖掘出最有价值的一面,得到源源不断的财富。 01 搭建数据中台的意义 建立数据标准 数据标准是指企业保障数据内外部使用和交换的一致性、准确性,进而制定的规范性约束。 在企业没有数据中台时,企业基本不会有数据标准,即便是有数据标准,也会由于没有数据中台这个实体形态,而无法进行落地执行,那么数据中台的建设就会帮助企业去建立数据标准与规范。 例如数据接入规范、数据存储规范、数据安全规范、数据分析规范等等。 在消费这些数据时又会存在权限、调用等等问题。 这些都是在建立数据中台时应运而生的,形成一套企业级别的内部规范,最终的目的是为业务降低成本,提高效率。 打破数据孤岛 本质上,数据中台就是将杂乱无章的数据,转化成为可以使用、决策的数据生产力。面对海量的数据,数据中台则是可以充分将外部数据融合,结合内部业务的分析,打破数据孤岛的现状,并打造可以持续增值扩张的数据资产,在数据整合后降低了使用数据的门槛,打造了企业内部完整健康的数据生态,实现了数据的价值闭环。 在全球大数据驱动的时代,企业必须通过最真实的数据,了解最真实的客户,在数据支持的条件下不断创新,打破数据孤岛,才能在企业竞争中保持优势。 在当下「生态」的概念愈发火热,但是很多业务的搭建,在最初并未考虑到跨应用分析的场景。 02 场景举例 比如多个应用之间,都有独立的账号体系,在各自的场景下可以很好的完成用户的数据采集,行为追踪,但是一旦希望跨应用追踪用户,做应用生态营销时,经常发现无法对应上是哪个用户,无法串联起用户行为,造成很多有价值的信息流失。 最终在生态建设上,失败于数据的应用隔离、业务隔离,本质上则是数据打通的不彻底,促使企业只能在海量的数据中清洗、Mapping,或者通过改造复杂的接入逻辑,但是成本过高,弥补为时已晚。 Authing 作为数据时代的一把利刃,通过用户身份的打通,从业务的入口打破数据孤岛,让用户在应用之间的行为,实现全链路、全流程的原生打通。   统一身份管理 接入进 Authing 的应用,天然实现用户统一,用户的行为在不同的应用内得以串联,打破同一用户多标识造成的数据孤岛,给予业务人员更准确的分析体验。   多种身份源能力 Authing 已支持 微信、Gitlab、飞书等多种社交与企业级第三方登录方式,降低客户改造成本,使用户轻松接入。   统一用户目录管理 Authing 提供的标准用户目录管理,将统一后的用户身份信息进行存储,可成为企业的用户身份仓库,供给上下游业务系统,实现高可用的数据共享。 …… Authing 拥有现代的 IDaaS 身份中台解决方案,助力企业便利地设置条件访问,通过统一身份提高用户安全无缝的访问体验。如果您正在为身份模块的开发而烦恼,不妨使用一下 Authing 的功能。
多因素认证 (MFA) 是防止数据泄露的最佳安全实践方法
据 IBM X-Force 的最新跟踪数据显示,2020 年数据盗窃相比 2019 年增加了 160%。随着云计算、IoT、5G 等技术的深入发展和普及,催生了大量数据泄露事件的发生,同时也给企业敲响了安全警钟。 01 多因素认证是防止数据泄露的最佳安全实践方法 对于企业而言,由于敏感数据泄露而造成的声誉受损威胁有可能对企业及其客户造成重大损害,还可能会导致诉讼和高额的监管罚款,而且还会影响企业的长期发展。 单纯使用用户名和密码来保护用户资料已不再安全,攻击者很容易劫持登录凭据和身份并访问敏感信息。因此,通过实施多因素认证(MFA)为帐户添加额外的安全层,成为企业防止数据泄露的最佳安全实践方法。 多因素认证(MFA)是一种非常简单的安全实践方法,它能够在用户名称和密码之外再额外增加一层保护。启用多因素认证后,用户进行操作时,除了需要提供用户名和密码外(第一次身份验证),还需要进行第二次身份验证,多因素身份认证结合起来将为你的帐号和资源提供更高的安全保护。 多因素身份验证(MFA)是为了验证一项交易的合理性而实行多种身份验证,其目的是建立一个多层次的防御,使没有被授权之人访问计算机系统或网络更难。多因素身份验证是由2个或3个独立的凭证进行验证,这些凭证主要有以下三个要素:   所知道的内容:用户当前已经记忆的内容,最常见的如用户名密码等; 所拥有的物品:用户拥有的身份认证证明,最常见的方式有 ID 卡、U盾、磁卡等; 所具备的特征:用户自身生物唯一特征,如用户的指纹、虹膜等。 02 功能强大的 Authing 多因素认证 通过对数据安全监管等技术的研究,Authing 提升了针对违法数据流动等安全隐患的监测发现与处理能力,采用全局多因素认证( MFA)提升整体的安全性。Authing 多因素认证可赋能 Authing 应用快速启用多因素认证(MFA),即刻提升应用认证与访问安全等级。 Authing 可提供多种认证方式,提高企业身份安全性,包括手机令牌、短信/邮箱验证码、兼容第三方身份验证器、生物识别、图形锁、小程序认证等。   Authing 多因素认证具有以下核心功能: 通过多种认证方式,保障业务安全; 认证流程自定义,一键开启,操作简单; 支持设备环境数据上报,多维度分析安全级别; 支持配置策略,实现环境风险自适应;   同时适用于应用内权限控制场景;   默认集成于通用登录组件(Guard); 用户数据管理、行为日志查询; 提供 SDK 与开放接口,助力开发者快速调用相关能力,并构建自定义的用户管理页面。   Authing 多因素认证具备多种优势:   开发者友好:提供开箱即用的端 SDK,方便端上开发者快速实现 MFA。 定制数据上报:定制数据上报,参与流程发起决策,覆盖更加复杂精细化场景。 基于策略:多因素认证的触发条件基于自定义策略,策略系统简单、高效、完备、灵活。 配置简单:基于友好的用户界面,快速配置具体应用的多因素认证。   03 更加灵活智能的自适应多因素认证 自适应多因素认证较于传统多因素认证,能够根据当前安全状况,选择应用不同的 MFA 方式,在保障安全的同时也兼顾用户体验。自适应多因素认证提供了更加灵活和智能的验证策略。 在用户进行认证流程时,自适应多因素认证对当前登录的用户生成的多种关键要素:   用户属性: 例如用户名、密码、用户身份等用户自身的属性和信息; 位置感知: 位置感知分为虚拟位置(IP 地址)和物理位置(国家、地区等); 请求来源: 对当前用户的请求来源进行判断,如:硬件设备信息、用户当前所在的系统等; 生物识别: 使用用户的生物信息进行识别,如:指纹信息、人脸识别等; 行为分析: 是否来自常用的登录地点、是否多次输入错误密码、用户之前的操作记录等一系列用户行为。   ……