尊敬的 NetOps 人员： 安全零规则也适用于你

好的，NetOps。 当您开始全面自动化并全心全意编写脚本时，是时候温馨提醒一下您的安全问题了。 我说的不是您可能负责部署和管理的防火墙、WAF 或其他安全服务。 我说的是您在踏上数字化转型之旅时将要编写的脚本和代码。

今天我想提醒大家关于零安全规则。 唤醒你的记忆：

安全规则零： 你不应该相信用户输入。 曾经。 

非常简单的规则，对吧？

理应如此，但事实并非如此。 违反 之后 违反 在商业世界中，可以追溯到安全零规则被违反。 当开发人员研究和学习新语言和框架时，他们所看到的示例代码中违反此规则的情况比比皆是，不幸的是，它也蔓延到了令人兴奋的新领域 NetOps。

我可以出示附件 A：

现在，公平地说，至少这个脚本可以体贴地警告您数据未经验证。 这很好，因为该脚本可以根据输入对路由器配置进行各种远程操作。

我对此的不满在于，该代码旨在帮助指导 NetOps 如何开始使用脚本来自动化生产网络设备，并且仅仅点头进行数据验证，而没有提供任何有关如何执行此操作的有用信息。

有关使用 Python 验证 IP 地址的一些好建议，请查看此 Stack Overflow 讨论。

但是 Lori，这是脚本，我们正在做 CLI 工作，拜托，这有多危险？

坏习惯很难改掉。

忽略零安全规则会导致两个问题。

首先，我的朋友，CLI 的日子已经屈指可数了。 API 是新的 CLI，大多数自动化框架都采用 RESTful API 来配置和管理网络设备和服务。 这意味着应用程序堆栈和解析器。 这意味着设备可能容易受到攻击，因为它们的配置可以通过可能包含漏洞的 API 进行更改。

我提供的证据是，我对思科针对广泛讨论的 Apache Struts 漏洞发出的警告并非夸大其词。 共识是将未经清理的输入传递给 Struts 框架会引发各种各样的不良后果。  

但是，以防万一潜在的利用机会不会让您担心执行零安全规则，请允许我指出，未能清理输入的影响半径可能比单个设备大得多。 考虑一下我们对 2017 年初 Amazon S3 中断的了解：  

太平洋标准时间上午 9:37，一名授权的 S3 团队成员使用已建立的剧本执行了一条命令，该命令旨在删除 S3 计费流程所使用的 S3 子系统之一的少量服务器。 不幸的是，命令中的一个输入有误，删除的服务器数量比预期的多。

-- 北弗吉尼亚 (US-EAST-1) 区域 Amazon S3 服务中断摘要

他输入到脚本中的数字比他预期的要大得多。 但是盲目接受操作员提供的任何内容（忽略安全规则零）的脚本最终必然会导致这种错误。 通过脚本进行简单的（尽管有些烦人）验证可能会阻止该问题成为 Twitter 上超过一周的讨论话题。

在网络、在生产中，我们常常通过授权的视角来看待安全。 Bob 有权限执行这个操作吗？ Alice 可以执行这个脚本吗？ 我们需要它，它仍然至关重要。

但是，随着我们（内部）数字化转型进程的加快，采用更多的框架并使用 API 和脚本来实现配置和管理的自动化，我们也必须从开发的角度考虑安全性。

这些规则中的第一条就是安全零规则： 你不应该相信用户输入。 曾经。 

始终验证输入。 它不仅提供额外的安全性，而且还可以防止良好的自动化变得糟糕。