重新思考组织层级中的软件

本文部分内容曾刊载于 Dark Reading，现经更新后在此发布。

‍

每个人的职业生涯中，大概都见过那种定义组织内部汇报关系的运营报告或层级图。这种图表有时被称为组织架构图，它是一种很有用的工具，能让人们清楚谁是自己的下属，谁是自己的上司。例如，在典型的组织架构图中，编码组负责人可能向产品开发总监汇报，而总监则向创新副总裁汇报。这种职权线条贯穿整个公司结构。谁没看过这种图表，并试图在其中找到属于自己的那个小方块呢？

人类对层级和结构如此着迷并不奇怪。从历史上看，正是这种结构让我们作为一个物种得以长久生存，即使是在古代面对极其危险的世界时也是如此。我们从来都不是最强壮或最敏捷的生物，但我们擅长团队协作，每个人都清楚自己的位置和职责，从而让家庭、部落或群体团结一致，得以生存和繁荣。现代组织架构图实际上就是那个时代及其古老成功经验的延伸。

但几乎所有的组织架构图都有一个共同点，无论企业规模大小或其他因素如何。在大多数情况下，这些图表上的所有构建块代表的都是人类或人类群体。我们还没有达到机器能够监管人类的程度，所以目前，组织架构图纯粹是人类事务。但我们的软件是否也需要一种组织层级呢？

当然，我并不是建议把软件加入到公司的组织架构图中。没人想让一个应用程序当老板。你该怎么向它申请加薪呢？但如今我们的应用程序和程序所面临的威胁环境，与我们古代人类祖先很久以前面对的危险环境并无二致。通过在严密的层级中明确应用程序和软件的职责，并以最小权限原则执行相关策略，我们能够确保这些应用程序和软件在面对极其恶劣的威胁环境时，依然能够生存并蓬勃发展。

针对应用程序和软件的攻击达到历史最高水平

要理解为软件建立更好组织层级的必要性，首先必须了解威胁环境。如今的攻击者，以及为他们工作的机器人和自动化驱动软件，正在不断扫描防御中的任何疏漏以进行利用。虽然针对人类的网络钓鱼和其他攻击仍在发生，但最老练的黑客已将大部分精力转向攻击软件。

虽然所有软件都成为了目标，但最成功的攻击是针对应用程序接口（API）的。这些不起眼的 API 是开发人员使用的小型软件片段，用于为应用程序和程序执行各种细小但重要的任务。它们通常灵活且独特，有时甚至是在开发过程中根据需要即时创建的。

API 确实很灵活，但它们的功能往往权限过高。开发人员倾向于赋予它们大量权限，以便它们在所管理的程序不断开发和变更时仍能继续运行。但这意味着，如果攻击者攻破了它们，所获得的权限将远不止访问某个特定数据库的一小部分。他们甚至可能获得整个网络近乎管理员的权限。

难怪多家安全研究公司表示，当今绝大多数窃取凭据的攻击都是针对 API 等软件进行的。Akamai 称这一比例占总数的 75%，而 Gartner 也表示，涉及 API 的漏洞已成为最频繁的攻击向量。最新的 Salt Labs 报告显示，针对 API 的攻击与去年相比增长了近 700%。

为软件创建组织架构图

组织对抗凭据窃取威胁的方法之一，是在网络内强制执行最小权限原则甚至零信任。这限制了用户仅获得完成工作或任务所需的最低限度权限。这种访问权限通常还会受到时间、地点等因素的进一步限制。这样一来，即使凭据窃取攻击成功，攻击者也无法获得太多好处，因为他们只能在短时间内执行有限的功能。

最小权限是一种很好的防御手段，但通常只应用于人类用户。我们往往忘记 API 也拥有提升的权限，而且通常受到的监管远不如人类。这就是为什么根据追踪网络攻击模式的开放式 Web 应用程序安全项目（OWASP）的说法，失效的访问控制现在已成为头号公敌。

说解决这个关键问题的办法就是对软件应用最小权限原则很容易，但实施起来却难得多。首先，需要让开发人员意识到这些危险。其次，在未来，API 和其他软件应该被正式纳入或至少设想为计算机网络内组织架构图的一部分。例如，如果一个 API 的任务是作为预订应用程序的一部分获取实时航班数据，那么它就没有理由能够连接到工资或财务系统。在软件组织架构图上，不应有连接这些系统的直接或虚线。

让开发人员真正绘制出显示组织内成千上万甚至数百万个 API 运行情况的组织架构图可能不切实际。但意识到它们带来的危险，并将它们的权限限制在工作所需范围内，将对阻止当今每个人都面临的猖獗的凭据窃取攻击大有裨益。这始于意识，终于像对待人类用户一样对待 API 和软件。
‍

想要提升您的开发团队水平吗？通过我们的敏捷学习平台和开发人员优先的安全工具，驾驭 API 安全问题及更多挑战。