技术领导力雷达
通常的 engineering rubrics 专注于某个具体的领域,比如 IC (软件工程师、产品经理、设计师) 或者 manager,能否提出一个大一统的框架,以衡量技术工作者的商业影响力?有这样一些要求
- 全面
- 可执行
- 对组建团队有指导意义
我和朋友们的答案
-
Decisiveness 决策力:战略、战术、决断力。为自己或者别人的个人或组织做合适的/赢面最大的决定。搜集信息、诊断以得到 insight、提出有效的策略和执行方案。创新。在机会窗口内/限定时间内/没有所有信息/无法准确预测未来的时候,快速决策,在迭代中改进
-
Execution Engine 执行引擎:打造一个执行引擎而不是执行本身,以有效地影响自己和他人的产出、根据需求精准地调和速度/质量/范围, craftsmenship
-
Domain Expertise:special knowhow, been there/done that, uniqueness
-
People and Culture:Work with others: shaping the world together with people. Lead by example. 团队合作、人力管理、绩效与激励、文化、价值观、能干 + 温暖、心态、热情、自我驱动力、倾听与分享、hiring and coaching team、humility, low ego. best idea wins. growth mindset
-
Product-Sense:好的直觉、对市场和数据的理解、产品管理(包括运营)、项目管理、协同/synthesize、发明与简化、计划与变化、对客户的 obsession
-
Synergy & Resourcefulness: 资源整合力,全局上对客户、渠道、产品、人、技术、资本的网的优化,公司内部结交利益同盟并且有效协调不同组织的 alignment
微服务中的身份验证和授权
需求
- 设计一个从简单开始但可以随着业务扩展的身份验证解决方案
- 考虑安全性和用户体验
- 讨论该领域的未来趋势
大局观:身份验证(AuthN)、授权(AuthZ)和身份管理
首先,回归基础
- 身份验证:确定你是谁
- 授权:确定你可以做什么
在开始时……让我们有一个简单的服务……
- 分层架构
客户端存储一个cookie或token作为登录状态的证明。(代客钥匙模式)
- 服务器持久化相应的会话
token通常采用JWT格式,由从安全位置(环境变量、AWS KMS、HarshiCorp Vault等)获取的密钥签名
- 流行的Web框架通常提供开箱即用的身份验证解决方案
然后,随着业务的增长,我们用AKF 规模立方体来扩展系统:
- X轴:水平克隆
- Y轴:功能分解
- Z轴:分片
加上康威定律:组织设计的系统反映其沟通结构。我们通常将架构演变为微服务(参见为什么选择微服务?了解更多)
- 顺便说一句,“微服务与单体”和“多仓库与单仓库”是不同的概念。
- 对于企业,有员工身份验证和客户身份验证。我们更关注客户身份验证。
在微服务世界中,让我们抽取身份验证和授权服务的功能切片,并有一个身份和访问管理(IAM)团队在进行相关工作。
- 身份感知代理 是一个反向代理,允许公共端点或检查受保护端点的凭证。如果凭证未提供但被要求,则将用户重定向到身份提供者。例如:k8s ingress controller、nginx、envoy、Pomerium、ory.sh/oathkeeper等。
- 身份提供者和管理者 是一个或几个通过某些工作流(如登录、忘记密码等)管理用户身份的服务。例如:ory.sh/kratos、keycloak
- OAuth2和OpenID Connect提供者 使第三方开发者能够与您的服 务集成。
- 授权 服务控制谁可以做什么。
身份验证
身份提供者
- 最简单的解决方案是提交用户的身份证明并发放服务凭证。
- bcrypt、scrypt用于密码哈希
- 然而,现代应用程序通常处理复杂的工作流,如条件注册、多步骤登录、忘记密码等。 这些工作流本质上是状态机中的状态转换图。
工作流:用户设置和个人资料更新
Ory.sh/Kratos作为示例架构
2. 第三方OAuth2
OAuth2让用户或客户端经历四个主要工作流(不确定使用哪个?请查看这个),如
- Web的授权码授权
- 移动的隐式授权
- 传统应用的资源拥有者密码凭证授权
- 后端应用流的客户端凭证授权
然后最终获得访问令牌和刷新令牌
- 访问令牌是短期有效的,因此如果被泄露,攻击窗口很短
- 刷新令牌仅在与客户端ID和密钥结合使用时有效
假设在这个工作流中涉及许多实体 - 客户端、资源拥有者、授权服 务器、资源服务器、网络等。更多的实体会增加被攻击的暴露。一个全面的协议应该考虑所有边缘情况。例如,如果网络不是HTTPs /不能完全信任怎么办?
OpenID Connect是基于OAuth2的身份协议,它定义了可定制的RESTful API,供产品实现单点登录(SSO)。
在这些工作流和令牌处理过程中有很多棘手的细节。不要重新发明轮子。
3. 多因素身份验证
问题:凭证填充攻击
用户倾向于在多个网站上重复使用相同的用户名和密码。当其中一个网站遭遇数据泄露时,黑客会使用这些泄露的凭证对其他网站进行暴力攻击。
- 多因素身份验证:短信、电子邮件、电话语音一次性密码、身份验证器一次性密码
- 速率限制器、失败禁止和异常检测
挑战:电子邮件或短信的送达率差
- 不要将营销电子邮件渠道与事务性渠道共享。
- 语音一次性密码通常具有更好的送达率。
5. 无密码
- 生物识别:指纹、面部识别、声音识别
- 仍然存在权衡
- 二维码
- SQRL标准
- 另一种实现方式:
- 推送通知
客户端如何订阅服务器的状态?短轮询、长轮询、WebSocket或服务器推送事件。
4. 市场上的供应商
不要重新发明轮子。
- 托管解决方案。两年前,我比较了Auth0、Okta、Amazon Cognito、onelogin、Firebase Authentication。而最近,Okta收购了Auth0。总之,如果我正在运行一家新创业公司并且不想建立自己的身份验证系统,我会推荐Okta和Auth0。
- 本地/自托管解决方案。ory.sh。
6. 优化
挑战1:Web登录非常慢或根本无法提交登录表单。
- JS包对于移动Web来说太大
- 构建一个轻量级的PWA版本的SPA(单页面Web应用)。无论如何使包小 - 例如,preact或inferno
- 或者根本不使用SPA。简单的MPA(多页面Web应用)与原始HTML表单提交效果很好
- 浏览器兼容性
- 使用BrowserStack或其他工具在不同浏览器上进行测试
- 数据中心距离太远
- 将静态资源放到边缘/CDN,并通过Google骨干网中继API请求
- 建立一个本地数据中心 😄
挑战2:账户接管
挑战3:账户创建耗时过长
当后端系统变得过于庞大时,用户创建可能会分散到许多服务,并在不同数据源中创建许多条目。在注册结束时等待15秒感觉很糟糕,对吧?
- 收集并逐步注册
- 异步
授权
isAuthorized(subject, action, resource)
1. 基于角色的访问控制(RBAC)
2. 基于策略的访问控制(PBAC)
{
"subjects": ["alice"],
"resources": ["blog_posts:my-first-blog-post"],
"actions": ["delete"],
"effect": "allow"
}
挑战:单点故障和级联故障
- 预处理和缓存权限
- 利用请求上下文
- 假设:数据中心内部的请求是可信的,而外部请求则不可信
- 失败开放与失败关闭