在初创公司生命周期的某个时刻，他们决定需要在 18 个月内做好上市准备，一系列 IPO 准备活动就开始了。该策略的重点是一家致力于 IPO 准备的公司，该公司发现其在管理用户数据访问的内部控制方面存在缺陷。该公司希望切实改善用户数据访问的安全状况，但多年来该公司的安全举措多次失败。
这些举措大多数都失败了，因为它们显着降低了客户支持等团队的内部工作流程，导致最初的进展随着时间的推移而被逆转和颠覆，长期影响甚微。该战略代表了首席信息安全官 (CISO) 试图承认并克服这些历史挑战，同时履行其 IPO 准备义务，并且最重要的是为用户做正确的事。
这是一本关于工程策略的书的探索性草稿章节，我正在#eng-strategy-book中集思广益。因此，一些链接指向其他草稿章节，包括已发布的草稿和非常早期的未发布的草稿。
阅读本文档
要应用此策略，请从顶部的Policy开始。要了解此策略背后的想法，请按相反的顺序阅读各部分，从“探索”开始，然后是“诊断” ，依此类推。相对于默认的结构，本文档从两方面进行了重构，以提高可读性：首先， Operation被折叠到了Policy中；其次， Refine已经嵌入到Diagnose中。
有关此结构的更多详细信息，请参阅制作可读的工程策略文档。
政策与运营
我们的新政策及其实施机制是：
-
在我们首次公开募股之前，必须显着加强对访问用户数据的控制。高级领导层、法律、合规和安全部门已决定，作为一家上市公司，我们不愿意接受用户数据访问控制的现状，因此必须切实提高资源级访问控制的质量，作为我们 IPO 前准备工作的一部分。
我们的安全团队负责制定解决此风险的确切机制和方法。
-
我们将继续优先考虑资源访问控制的混合解决方案。这是迄今为止我们的方法，也是最快的可用选项。
-
直接将我们的资源级访问日志暴露给我们的用户。我们将建立一个用户可访问的日志，记录所有公司对用户数据的访问，并确保我们能够轻松地解释每一次访问。此外，这意味着从用户的角度来看，每个访问的理由都必须是可理解和合理的。
这很重要，因为它使我们的方法与用户的观点保持一致。他们将能够评估我们如何访问他们的数据，并根据他们是否同意我们的使用来决定继续使用我们的产品。
-
良好的安全讨论不会将决策制定为安全性和可用性之间的妥协。我们将追求多维度的权衡，同时提高安全性和效率。每当我们就安全性和实用性之间的权衡进行讨论时，就表明我们的讨论是错误的，我们应该重新考虑我们的方法。
我们将优先考虑能够自动授权并自动记录访问客户数据的理由的机制。最明显的例子是自动向已分配给客户支持代理的开放支持票证的用户授予对该代理的访问权限。 （并在重新分配或解决该票证时删除该访问权限。）
-
通过用户可理解的自动化原理来衡量客户数据访问请求百分比的进度。这将使我们的方法同时提高用户数据的安全性和同事内部工具的可用性。如果我们只扩展访问客户数据的要求，我们不会将其视为进步，因为它不是自动化的（因此当团队试图快速解决问题时可能会鼓励解决方法）。同样，如果我们只提高可用性，图表不会将其表示为进度，因为我们不会增加支持的请求数量。
作为这项工作的一部分，我们将创建一个私人渠道，安全和合规团队可以在其中了解用户数据访问的所有手动理由，并将直接向依赖手动理由访问用户数据的任何个人的经理发送消息。
-
使未使用的角色过期以实现最小特权原则。如今，我们在基于角色的访问控制 (RBAC) 系统中向不使用所授予权限的用户授予了许多角色。为了解决这个问题，我们将在 90 天不使用角色权限后自动删除同事的角色。
处于活跃待命轮换状态的工程师是这种自动权限修剪的例外。
-
每周回顾，直到看到进展；每月永久访问审核。从现在开始，安全工程团队、负责客户数据访问计划的团队和 CISO 之间将每周进行一次同步。本次会议将重点讨论快速迭代和问题解决。
这显然是一个正在进行的策略测试的论坛，CISO 担任会议的发起人，其首席安全工程师担任会议的指南。它将继续下去，直到我们明确了 100% 覆盖用户可理解的、自动化的客户数据访问理由的路径。
另外，我们还开始每月对客户数据的抽样访问进行审查，以确保我们构建的理由创建机制的正确使用和功能。这次会议的目标是审查访问理由的质量和适当性，既通过审查短期抽样理由，又确定更自动化的机制来识别未来要审查的高风险访问。
-
例外情况必须得到 CISO 的书面批准。虽然我们的总体工程战略规定我们遵循促进软件架构中描述的咨询架构流程，但客户数据访问策略是一个例外，必须由 CISO 明确批准并附有文档。在
#ciso频道中启动该流程。
诊断
-
我们拥有基于角色的访问控制 (RBAC) 和审核日志记录的强大基线。但是，我们确保分配的角色遵循最小权限原则的机制有限。当个人在公司任职期间更换团队或角色时尤其如此：有些人在公司五年多的时间里收集了许多未使用的角色。
同样，我们的审计日志是持久且普遍的，但我们用于识别异常使用的主动机制有限。相反，它们通常用于了解其他机制识别事件后发生的情况。
-
对于资源级访问控制，我们依靠用于传入用户请求的第三方平台和我们自己产品内的审批机制之间的混合方法。提供跨这两个系统访问的基本原理需要手动工作，并且随后以批量方式手动审查这些基本原理的适当性。
我们当前的资源级访问控制方法存在两个主要的持续问题。首先，提出请求的团队将其视为一项繁重的义务，对他们或代表用户来说没有太多好处。其次，由于理由审查步骤是手动的，因此没有可验证的证据来证明审查的质量。
-
我们没有发现滥用用户数据的证据。当同事确实访问用户数据时，我们一致且一致地发现该访问有明确且合理的理由。例如，用户支持系统中用户提出问题的票证。
然而，我们记录的基本原理的质量始终很低，因为它依赖于忙碌的人们每天多次手动复制重要信息。由于理由的质量较低，因此对这些理由的验证有些武断。从字面上的合规性角度来看，我们确实提供了理由和对这些理由的审计，但尚不清楚这些审计中的大多数是否提高了用户数据的安全性。
-
从历史上看，我们进行了大量的安全投资，导致我们的安全状况暂时飙升。然而，一年后审视这些举措，在许多情况下，我们看到了一种加强审查的模式，随后逐渐废除或避免新机制。
我们发现其中大多数都增加了其他内部团队执行的基本工作的摩擦。按照执行工作的自然顺序，这些团队会巧妙地破坏改进，因为它干扰了他们的直接目标（例如支持客户请求）。
-
因此，从我们的业绩记录来看，我们坚信我们的历史方法可以在内部创造光学胜利。我们对它可以在重大的、不太可能的内部变化之外创造长期改进的信心有限（例如，一年后同事们的忙碌程度明显低于今天）。我们似乎需要一种新的方法来有意义地改变我们对此类问题的立场。
探索
我们的经验是，有关管理用户数据内部访问的最佳实践可以通过我们的网络广泛获得，否则很难找到。其确切理由很难确定，但由于未来潜在的责任和合规问题，人们通常不愿意在公开场合讨论这个话题。
在我们的探索中，我们发现了两个标准化维度（基于角色的访问控制、审核日志）和一个高度不同的维度（特定于资源的访问控制）：
-
基于角色的访问控制（RBAC）目前是一种高度标准化的方法。核心前提是将用户映射到一个或多个角色，并且每个角色都被授予一组特定的权限。例如，代表客户支持代理的角色可能被授予停用帐户的权限，而代表销售工程师的角色可能能够配置新帐户。
-
审计日志也同样标准化。所有资源的访问和变更都应与执行该操作的人员绑定在持久日志中。这些日志应该累积在一个集中的、可查询的解决方案中。
核心挑战之一是确定如何主动利用这些日志来检测问题，而不是在问题已被标记时被动地利用这些日志。
-
资源级访问控制的标准化程度明显低于 RBAC 或审核日志。我们发现公司采用了三种不同的模式，而各公司所采用的模式几乎没有一致性。
资源级访问控制的这三种模式是：
-
第三方丰富，其中对资源的访问在 Zendesk 等第三方系统中进行管理。这需要使用这些对象所在产品的数据和元数据来丰富这些系统中的对象。它还需要在平台上实施操作，例如归档或配置，使它们完全存在于该平台的权限结构中。
这种方法的缺点是与平台供应商的紧密耦合、该平台固有的任何限制，以及维护工程团队熟悉内部技术堆栈和平台供应商的技术堆栈的开销。
-
第一方工具实施，其中所有活动（包括用户问题的创建和管理）都在核心产品本身内进行管理。这种模式在早期阶段的公司或客户支持领导力在组织内“成长”的公司中最常见，而没有太多接触同行公司所采取的方法。
这种方法的优点是有一个单一的、紧密集成的、可无限扩展的平台来管理交互。缺点是您必须在内部构建和维护所有这些工作，而不是将其推给应该能够在其工具上投入更多资金的供应商。
-
混合解决方案，其中第三方平台用于大多数操作，并进一步用于允许第一方系统内的资源级访问。例如，您可能只能在第三方平台中存在由该用户创建并分配给您的开放票证时才能访问该用户的数据。
这种方法的优点是它允许支持不符合平台限制的复杂工作流程，并允许您避免产品和供应商平台之间的复杂耦合。
一般来说，我们的经验是所有公司都实施RBAC、审计日志和资源级访问控制机制之一。大多数公司要么通过拥有平台实施的规模庞大的长期团队来追求第三方丰富，要么依赖混合解决方案，通过将工作集中到现有团队中，他们能够避免长期的专门团队。