现状
团队权限授权现状
作为架构师这几年一直做一些权限管理相关的工作，团队内使用的工具颇多，如ibm cloud，kubernetes, github, vault, jenkins, linux servers, Jfrog Artifact, DB, LDAP, Email Account等等。不同工具的权限管理方式千差万别，但总结来说，常用的管理方式无外乎如下几种。有好有坏，梳理一下，做一个完整的一次性解决权限管理的方案。
- 团队内只有一个账号也只有一个角色就是admin,团队内部共用此账号。之前有几台测试服务器(linux server)，大家公用root账号。
- 好处: 简单粗暴
- 坏处：1. 有security问题。2. 环境出错，难于排查原因
- 账号admin和其他，lead/architect持有admin账号，其他人持有普通账号。
- 好处：简单粗暴
- 坏处：Role设计单一，所有的配置类操作只能由admin账号持有人操作。
- 申请就给赋权。前期没有做好权限规划，使用的时候发现缺少权限，就给加一个，完全是针对个人的，没有角色的概念。比如最开始使用Jenkins
- 好处：简单粗暴
- 坏处：很难统计某个人有哪些权限，随着时间的推移，权限管理成本会剧增。
- 最小权限。把每个人权限都限制在最小，甚至不授权，由专职人员进行维护。团队最开始的kubernetes是使用这种方式，但问题是在一个实践DevOps的团队中，开发需要通过pipeline进行部署服务，需要在失败之后去调查失败原因，很多时候需要登录到kubernetes上进行。如果将Dev和Ops分开，会使流程冗杂，工作效率低下。
- 好处：安全
- 坏处：流程冗杂
- SOD(Separation of Duty)，将团队内的人分为不同的分工(Responsibility)。工具中的角色按照团队内的分工进行安排。
- 好处：安全
- 坏处：设计复杂，施工成本高昂，
团队权限管理复杂度曲线
团队中成员针对权限的反应
- 有多少权限用多少权限
- 没有全局观，只顾着做完自己的工作，并不知道有时候自己权限内可以操作的事情会对团队其他成员的工作成果有伤害。比较典型的例子就是git的单repository管理，有的人代码写完之后在Merge的时候根本不考虑他人有没有更新过代码，直接 git push -f操作，就将别人的成果全部覆盖掉了，需要别人进行merge操作。
- 没有权限，创造权限。在企业里，大多数领导都是只要结果，不关注过程，每个人都削尖了脑袋要表现自己(就是内卷)。如果按照流程办事，会耽误一些时间，并且很多时候管理权限的人并不是自己直接汇报的对象，所以有的人就会剑走偏锋，找到权限管理漏洞并将其用到极致。之前团队中发生过一次，当时系统的
同意按钮是通过前端控制的，不同的角色可以看到不同的按钮，被某位同学发现之后，每次都是直接浏览器端修改代码直接同意，没有经过任何权限审批流程。
-
杞人忧天型，不敢使用自己的权限。这种人怕犯错，怕翻车。会跟谨慎的操作任何跟权限相关的东西。所有权限都先去确认一下再使用。正所谓做多错多，不做不错。
-
相对合理使用权限。通常是权限的设计参与人员和经过完整权限相关内容培训的成员。这个事情提醒我们，虽然敏捷中重沟通轻文档，但是必要的文档(如权限设计)等还是需要有的。
- 不知道自己有什么权限的
权限设计
权限管理原则
- 减少Godden Role Design
- 操作有记录可查
- VPN + 跳板机，减少外网直接暴露，同事也减少由于部分团队人员离职而权限未及时删除带来的风险。
- 所有工具争取集成公司统一SSO
- 二次验证(账号 + 短信/verify app)
- 使用企业级解决方案，减少团队的二次开发
- SOD文档规范权限使用范围
零信任模型
核心思想: 从不信任，始终验证
从本质上讲，零信任安全不仅承认网络内部和外部都存在威胁，而且还假定攻击是不可避免的(或可能已经发生)。因此，它会持续监控恶意活动，并限制用户只能访问完成工作所需的内容。这有效地防止了用户(包括潜在的攻击者)在网络中横向移动并访问任何不受限制的数据。
- 零信任模型的原则
- 持续的验证 持续验证是零信任的一个关键方面——它意味着不存在隐式可信任设备、凭据或区域。有几个要素对于各种资产的持续验证来说是必不可少的，包括基于风险的有条件访问（维护用户体验）和易于应用的动态安全策略（考虑到合规性需求）。
- 最小特权访问 最小特权原则是零信任的关键，它向每个用户或实体授予最小必要的访问权限，防止暴露于敏感的网络区域中。最小权限原则要求谨慎管理用户权限。
- 假定攻击已经发生 最大限度地减少影响范围和实现权限隔离。验证端到端加密，并使用分析来获得可见性，推动威胁检测和改进防御。
- 零信任模型
- 身份安全
- Endpoint安全
- 应用程序安全
- 数据安全
- 可见性和分析
- 自动化
- 基础设施安全
- 网络安全