信息安全从业者一定遇到过这样的客户，当你试图和疑似客户讨论具体场景风险和防控措施的时候，对方会告诉你他需要的是数据全生命周期的管理方案，而不是单点的能力。
如果你发现自己正处于以上的局面，那么你心想之事将变得艰难，你遇到的人大概率并不想解决你提出的问题。在权力不对等的关系里，站在高处的一方“讲道理，上价值，炫理论”的行为，都只是一种典型且朴素的不认同和拒绝你的方式而已。
01/7 以数据为中心，以应用为中心
数据安全的方法论和技术演变，大致沿循这样的路径：以文档为中心（DLP，透明加解密）、以数据为中心（全生命周期理论）、以人为中心（UEBA）、以环境为中心（沙箱）、以应用为中心（数影安全）。
每一轮的理念变化都伴随着新技术的采用（数据中心论除外），对过往的颠覆从没有发生，新的方法更多也是对旧方法的新场景补充和调优。
如 UEBA 想解决的是 DLP 误报率太高而无法日常运营的缺点，以及补充除了终端文件外泄之外的其它数据安全风险覆盖；沙箱想要解决的是 UEBA 模型无法通用泛化落地，且甲方企业数据维度和质量远远无法用于识别风险的问题，倒不如把公司数据资产都框在一个沙箱环境里，体验和成本又优于传统云桌面的解决思路；而我们数影的应用中心论，想解决的又是沙箱应用适配成本高，安全粒度太粗和用户体验不够好的缺陷，在构造安全办公环境的基础之上，把用户体验和整体成本进一步优化。
以数据为中心的思路可以从数据的产生、传输、使用和销毁的生命周期里，架构起严格的逻辑框架，用作对安全建设的评价和思考体系颇为贴切，但是不足之处在于其逻辑的基础是理想化的因果论，无法为这个复杂的数据世界留下夯实的基础设施遗产。数据分类分级就是这样的产物，只有思想而难以有结果。
02/7 以应用为中心，把安全左移为基础设施
应用是数据的载体。一切皆应用，任何信息化的工作都是依托特定应用或特定应用的组合来完成和沉淀的，应用大如某个设备的操作系统、小如一张浏览器页面，以各式各样的形态存在。应用的存在服务于人的需要，或者用于支撑另一个应用的存在。应用之间存在着错综复杂的依赖关系，人对应用又有无休止的要求。每个应用都需要考虑和平衡自身的功能体验、构造成本、信息安全以及复杂运行环境的适配，但并非每个应用的构建者都有这个能力或者意愿去把应用构建得面面俱到，甚至于若是每个应用都如此理想地发展，那么应用使用者将不得不面对无法统一的、各式各样的应用体验和管控方式，那将是更大的灾难。
03/7 应用的第一道关卡，是应用账号
以应用为中心的数据安全实操体系之应用账号篇，我们今天就讲讲因为应用账号管理不当而造成的数据安全风险实例，而且是那些让各大公司 CSO 也好，CIO 也罢集体无奈的第三方公有云应用账号，我们看看几个经常遇到的客户案例。
04/7 面向研发的，第三方开发者平台账号控制权转移
案例一：研发人员离职，带走第三方应用商店平台账号拒不归还，导致公司 APP 无法上架更新。 "
（阿里云开发者登录）
对于开发者来讲，最常见的就是第三方开发者账号比如苹果开发者账号、钉钉、企微开放平台账号，云平台账号如阿里云、腾讯云、AWS、Azure等等，还有很多第三方数据平台账号如巨量引擎、友盟等等。对于一个科技型的企业来讲，这些平台的重要性不言而喻。但是我们却常常看到企业因为这些平台的账号失陷，而被动完分。
（小米应用商店登录）
在各种类型的第三方开发者平台中，唯独云平台（阿里云、腾讯云、华为云等）在账号权限建设层面花了极大力气，有最基本主子账号、RAM 账号架构，也有完善的 MFA 多因子认证和 ACL 权限控制，可以非常安全地保障账号的合理使用。除此之外其余的平台就显得简陋异常，往往一个账号密码的组合就可以毫无障碍地走天下，导致平台的账号控制权实质掌握在员工个人手中，也就导致了上面例子的层出不穷。而这样的平台也众多，比如一个科技公司开发了一款 APP，那么市面上有多少个应用商店，就得有多少个这样的平台账号，如苹果开发者账号、小米、华为、Vivo、Oppo 等等。
05/7 电商类企业第三方客服系统账号
案例二：电商客服小二通过客服系统导出消费者订单，转卖数据获利。
如果说国内电商商家的客服系统账号是最复杂的账号难题，我是必投赞成票。因为这里面有太多的因素缠绕在一起，多电商平台、多客服应用、客服人员三班倒、客服账号共用、客服人员工时计算、大促期间临时客服、客服人员离职...，所有这些问题汇总在一起，都依赖小小的一个客服系统账号来解决。
（淘宝天猫，商家客服系统千牛登录）
如何安全、灵活地管理第三方公有云客服应用账号，是商家们的痛点。
06/7 物联网企业管理员通宵修改运营商平台账号密码
案例三：因为业务的特殊性，大量物联网类的企业拥有大量的运营商平台账号，由于缺乏账号管理的能力，只能通过 Excel 共享的方式在员工之间共享所有账号。一个员工离职，管理员通宵修改所有账号密码。
通常情况下，办公系统的账号并不允许在不同人之间共享，但是例外总是存在，比如上面提到的开发者账号往往都是在研发之间共享；比如公司采购了论文检索平台的账号，从成本节约角度来讲也势必将有限个平台账号在需要的人之间共享；比如三班倒的客服也一直在共享客服系统账号。大家面临的矛盾就都出奇的一致了，第三方平台只要有账号就能登，且在哪都能登并不局限于公司环境内，那么一旦共享范围内有人离职，所有共享的账号都得进行密码修改才行。
07/7 无密码使用应用的解题思路
当所有矛盾汇聚到一起，我们提炼本质，在所有的应用都具备类似阿里云这样的完善账号权限管理能力之前（当然这是不可能发生的事情），我们构想解决方案的本质一定是围绕企业如何夺回应用账号控制权而展开，我们以应用为中心的解决思路是，员工如何在不掌握账号密码的前提下也能使用应用本身。
7.1 密码管理器 Lastpass、1Password
密码管理工具相比于现在企业内部依靠人工进行账号管理有很大优势：
- 都有企业版本，可以方便管理员去共享账号给员工，不用再拉群或者私聊给每个员工发账号了。
- 有一定账号使用情况的管理和视图。
- 可以设置很复杂的密码，不用担心简单密码被泄露。
- 员工不需要记忆账号密码，选择登录就行。
有这么多优势，员工和管理员都受益，但是却有个致命的问题，那就是“每个人都知道密码”，可以通过账号管理软件内部，或者插件，或者浏览器开发者模式，轻易拿到密码。
（1Password 密码对员工直接可见）
7.2上 IAM、IDaaS 第三方账号管理服务
应用不支持第三方 IAM 对接，卒！
7.3上专属浏览器，实现账号自动登录，屏蔽应用密码还原
我们回到应用的载体浏览器本身。当我们改变不了应用，我们改变其环境。
- 将密码管理器自动登录应用的能力移植到浏览器。
- 通过浏览器屏蔽回显密码的所有方式（查看源码、开发者模式、远程调试模式等等）。
- 将账号分配的能力收回给管理员，回收员工查看账号的能力。
这样我们就达到了我们想要的一切效果，员工在不知道应用账号密码的前提下，依然能使用第三方公有云应用。员工离职，无法带走应用账号。且第三方应用无需做任何配合改造和开放接口。