写入云到后端访问契约的六个决定

设想一个云账户中的报表服务，它需要来自客户内部系统的经批准的汇总。VPN 或经过认证的应用连接保护路径，但不决定其他任何事。它不决定报表工作负载是否可以读取无关记录、更改后端，或保留它取回的内容。在选择连接器之前，先用操作和数据的语言写下访问协议，因为连接器是以后最便宜的改动部分，也是最容易在一开始就出错的部分。

先决定操作，再决定连接器

第一个决定是工作负载被允许做什么，用操作而不是网络范围来命名。就报表这个例子而言，一个狭窄的报表 API 也许就能满足需要，而不必把数据库管理权交给云工作负载。

把报表需要的数据与仅仅恰好可达的数据分开。把允许的操作以端点和动词的形式，写进与身份决定相同的那份文档里。这一区分，正是能挺过审计的集成与每年都要重新解释一遍的集成之间的差别，也能在日后省掉一次会议就解决争论。

决定工作负载的身份，并为它指定所有者

无人值守的任务无法回答提示，所以团队往往抓来某个人的宽权限账户，然后就把它忘了。使用后端真正接受的服务账户或机器凭据，并记录谁拥有它、存放在哪里、如何轮换。

三个条件应当把决定推向专用身份：任务在无人到场时运行，凭据的生命周期超过一次部署，并且不止一个人需要知道它存在。如果三者都成立，共享的人类账户就不是捷径，而是一个没人能干净撤销的永久例外。

优先选择平台能够为工作负载签发和轮换的凭据，例如后端会验证的工作负载身份令牌，而不是粘贴在配置里的静态密钥。应用设置里的静态密钥，正是轮换变成故障的原因。

决定网络范围，并知道它不是权限

明确由哪一侧发起连接、支持的传输方式以及涉及的端点。保持对等身份校验开启，并让无关的后端目的地不可达，而不是仅仅不对外宣告。

狭窄的隧道路由是有用的范围，但它不能取代操作级别的授权。后端必须通过自身的控制来执行契约，因为网络会乐于承载任何到达可达端口的请求。要检查后端自己的角色与授权，而不是路由表。能到达服务器的路由仍然把决定留给服务器，而契约究竟被执行还是被忽视，就发生在那里。

反过来也成立：有效的服务凭据并不构成向每个来源发布监听器的理由。两种控制都需要，而且谁也不能取代谁。

决定数据处理与责任划分

记录什么离开了客户环境、应用在哪里处理它，以及真实的存储、备份、访问与保留安排。保留往往是较晚才被发现的部分，通常是在有人问起上季度的副本是否还存在于某个没人记录过的存储桶里的时候。

把各方区分开。应用运营方、软件供应方和基础设施托管方可能承担不同的责任，而服务模式决定了谁是哪一方。请阅读实际的协议，而不是假定三方拥有完全相同的访问权限，或者根本没有。

决定故障、移除，以及你将如何验收

在故障发生之前就分配好责任。当连接器损坏或某个身份被怀疑遭到泄露时，反应不应是一条临时拼凑、毫无限制、并且比事件本身活得更久的网络例外。

移除值得和搭建一样的精确度。定义授权如何被撤销、活跃访问如何在产品支持的行为范围内结束，以及关系结束时被保留的副本会怎样。

用有代表性的允许操作和契约所要求的拒绝来验收这项集成，全部在预期的工作负载身份下进行。确认请求路径和实际交付的数据，然后真正演练凭据替换与移除。一条连通的隧道只能证明路径存在；契约才是给这条路径划出边界的东西。