Airbnb 如何为我们庞大的员工、承包商和呼叫中心员工团队安全地管理权限？
Airbnb 是一家建立在信任之上的公司。这种信任的一个重要部分来自保护我们的客人和房东与我们共享的数据。我们这样做的方法之一是遵循最小特权原则。最低权限规定——在理想的世界中——员工在工作需要时拥有他们需要的确切权限。不多也不少。任何更多都会带来不必要的风险——无论是来自恶意员工、受损笔记本电脑，还是仅仅是一个诚实的错误。任何更少的东西都会抑制生产力。
执行最小特权不仅对于维持信任至关重要，而且正迅速成为法律上的必要条件。Airbnb 在世界上几乎每个国家和地区都有业务，因此我们必须遵守越来越多的数据隐私法规。
当一个人可以跟踪所有同事的工作时，管理员可以在小公司中用最少的工具有效地解决这些问题。但随着公司的发展，这种方法无法扩展。在这篇文章中，我们将解释 Airbnb 如何使用一种新颖的软件解决方案来维持最低特权，同时让我们庞大的员工、承包商和呼叫中心代理团队能够有效地完成我们的工作。
访问控制系统
在确定了对集中式访问控制的需求后，我们努力为我们将要实施的解决方案制定指导原则。最终，我们把对系统的要求归结为两个目标。
访问控制系统应该管理围绕权限生命周期的全部过程和逻辑。这包括。
- - 请求或撤销权限的自我服务方式。
- - 控制谁必须批准新权限的设置。
- - 用于管理权限组的工具。
- - 设置自动权限过期。
- - 记录，以满足操作和合规要求。
- - 关于相关权限更新的通知，如即将到期或需要批准的时候。
所有这些功能都应该为每个可用的权限进行声明性控制，系统应该使用这些声明来实现所有必要的逻辑和行动。
我们希望建立一个系统，可以轻松而稳健地与任何权限存储（如AWS IAM、LDAP、Apache Ranger、MySQL、Himeji等）集成，而不需要修改它。用网络来比喻，权限存储将是执行授权的数据平面，而我们的访问控制系统是协调一切的控制平面。这一要求使我们专注于提供必要的接口，以有效地将权限变化从中央访问控制系统同步到权限存储区。这将通过每个存储区的少量胶水代码来完成（允许我们保持中央系统的通用性）。
我们也澄清了该系统不会是什么：
- 不是一个超可靠的、超低延迟的方式来回答在线权限检查。权限存储本身将回答在线授权查询，而且，由于我们将与它们同步，如果中央访问控制系统发生故障，它们可以自动充当缓存。虽然可用性和性能总是很重要的，但我们主要关注的是权限管理逻辑。
- 这不是一个倾倒一次性授权代码的地方。之前的一些权限管理系统已经演变成了授权代码的倾销地，产生了大量的技术债务。
- 不是一个为我们的客人和主人存储权限的地方。公共产品的权限管理要求通常与我们授予员工访问我们内部工具和数据以完成其工作的权限有很大不同。规模一般也有很多数量级的差异。此外，内部权限通常要复杂得多。因此，单独处理每种情况是有意义的。
如果你只能从这篇文章中带走一样东西，请带走这些目标。明确我们的重点，并把这两个目标作为我们的北极星，是建立我们集中式访问控制平台的最关键的一步。
架构
我们设计了一个具有线性五阶段结构的系统。变化从左到右流动。该架构是线性的，即每个阶段可以查询前一个阶段，但不能查询其他阶段。例如，访问控制平台可以查询雇员数据系统，也可以被连接器查询，但从不与权限仓库直接通信。
一个阶段也可以通过松散耦合的渠道（如队列或回调）与紧接着的阶段进行有限的通信。例如，访问控制平台可以排队等待更新信息，该信息将被连接器消费以触发权限更新。
1、雇员数据系统
这些是人力资源系统（如LDAP），包含员工数据（如职称、地点、状态、管理链）。访问控制平台摄取这些数据，以实现基于职称的动态组和基于管理链的审批流程等功能。这些系统是由IT团队拥有的。
2、访问控制平台
这是一个核心系统。它包括所有管理权限的业务逻辑，以及员工用来进行和/或批准修改的用户界面。访问控制平台是高度可配置的，但不直接与任何与之集成的权限存储互动。安全团队拥有这个系统。
3、连接器
连接器是连接访问控制平台和权限仓库的胶合代码。它们有两个目的。首先，连接器告诉访问控制平台哪些权限可供请求。例如，数据仓库连接器可能使用户和预订Hive表的读取权限可供请求。其次，如果用户bob获得了读取预订的权限，数据仓库连接器将把这个权限同步到适当的权限存储中--在这种情况下是Apache Ranger。由于连接器只是通过适当的API调用来响应队列中的消息，它们可以在其所有者认为最好的任何环境中运行（例如，Kubernetes作业、AWS Lambda、Airflow DAG）。它们是由拥有相应权限存储的团队所拥有和运营的。例如，存储团队拥有MySQL连接器。
4、权限存储
权限存储是存储权限和回答权限查询的系统--例如，AWS IAM、LDAP、Apache Ranger、MySQL的内置权限系统、Himeji或其他内部系统。请注意，在某些情况下，权限存储可能内置于客户端，在这种情况下，第4和第5阶段将被合并，正如MySQL的情况。
5、客户端
客户端是终端用户需要的所有系统--例如，SSH、Apache Superset、MySQL、内部客户支持工具、Salesforce等。
效果
每当权限状态发生变化时，访问控制平台都会向队列发送消息。该队列由负责将更新权限的状态同步到权限存储的连接器进行处理。
信息的内容是设计的一个关键部分。消息包含了权限的内容和对象，但不包含权限是否被授予或撤销。为了获得当前状态（授予/撤销），连接器必须查询平台。你可以把消息看成是一个触发器，使系统为用户Y重新同步权限X。
这个设计有以下属性：
- 因为最新的状态总是被获取的（授予/撤销），消息处理是空闲的。
- 这使我们能够使用一次性传递语义，大大简化了确保每次权限变化时都发送适当消息的过程。如果一个权限发生了变化，但在我们记录平台触发了必要的更新消息之前，进程就被杀死了（也许是由于部署），我们只需在清理过程中再次触发消息。
- 重放攻击是失效的。因此，我们让连接器开发者自由地排队等候消息，以帮助调试。作为一个连接器的开发者，在试图确定权限同步失败的原因时，这一点相当有用。
- 如果更新失败的次数太多，消息就会进入死信队列，负责连接器的团队就会收到警报。开发人员会使用我们的工具从死信队列中读取消息，并调试失败的更新。一旦问题得到解决，所有失败的信息可以被重新排队，这将使所有的权限恢复同步。
- 我们定期运行离线作业来做大量的权限差异，并确定任何需要回填的权限变化。然后我们通过为这些权限排队更新消息来触发重新同步。这意味着连接器开发者只需要编写代码来支持增量同步，而不是同时支持回填和增量同步。回填是免费的
安全性
在安全方面最大的胜利之一是有一个单一的地方，我们可以实现新的最低权限功能，然后全面应用（而不是为AWS实现一次，为MySQL实现一次，为SSH实现一次，等等）。一个很好的案例是基于使用的过期。基于使用的过期是一种功能，在相当长的时间内没有使用的权限会被自动撤销。这种方法对安全是有好处的，因为不必要的权限会很快被清理掉。但它对用户体验也有好处，因为员工可以放心，被取消的权限并不是他们经常使用的。在撤销权限之前，访问控制平台会通知受影响的员工即将发生的变化，并提供指示，说明如果他们需要保留权限该怎么做。这些通知还提供了一些低难度的链接，如果他们后来意识到这些权限是需要的，可以在撤销后重新获得这些权限。