安全规则一： 你现在可能正在违反它

到现在为止，您已经对“安全零规则”有了足够的了解，可以将其牢记在心了。 您确实能背下来，对吧？

为了以防万一，让我刷新一下你的记忆：

你不应该相信用户输入。 曾经。

出色的。 现在我们已经建立并解决了基本规则，接下来让我们讨论安全规则一。 因为您可能已经猜到了，安全不止一条规则。 那么，我们继续讨论第一条规则，好吗？

安全规则一： 你不应该对凭证进行硬编码。 曾经。 

在通过标记化（API 中很流行）和联合身份进行访问控制的时代，面向公众的应用程序很少会违反这条规则。 在组织内部，这条规则经常被打破和忽视。 随着 NetOps 加大使用脚本和自动化来优化 IT 以支持其组织的数字化转型计划，这很快就成为一个问题。

让我用在互联网上找到的一个非常真实的例子来说明。 我说一个，因为我既没有时间也没有带宽来提供一份完整的清单。 这种做法非常普遍。

在您的右边，您将看到一个极其常见的安全失误：纯文本、硬编码、凭证。 甚至没有任何评论承认这种做法在工作环境中是不可接受的，也没有人点头表示需要使用更安全的身份验证方法。

从 NetOps 的角度来看，这让我深感困扰，因为当你干扰共享的企业网络时，爆炸半径会显著增大。

我们看到这种安全问题的原因之一是，尽管 NetOps 确实正在拥抱自动化，但它不一定在战略上采用它。 我们看到，相当大比例的 NetOps 专业人员正在选择 Python，并将其与传统的基于 CLI 的配置和管理方法相结合。

就像他们在命令行中输入凭据一样，他们也将相同的凭据放入脚本中，然后就完成了。

最终，这将是一个问题。 我们会看到有人利用这种做法，而且它会在我们的新闻中出现好几天。 因为这种事以前也发生过。 还记得OneLogin吗？ 虽然他们没有存储带有凭证的脚本，但他们存储了带有凭证的文件。 你可以想象这会造成多大的混乱。

问题是，NetOps 可能对将命令行凭据放入脚本中非常有信心，但该脚本最终会放到哪里呢？ 它是否得到了应有的管理？ 就像基础设施即代码？ 它是否有版本控制并保存在存储库中？

您可能还记得Network to Code 社区调查显示，NetOps 对 Github 的采用率很高（等等……）。

那么我们问一下自己，我们的存储库在哪里？ 是场外的吗？ 现场？ 它是如何受到保护的？如果有人拿到它，其爆炸半径有多大？

为了维持和服务业务，我们需要通过脚本和自动化来扩展运营。 NetOps 必须朝这个方向发展，但它不应该在没有认真考虑存储在任何地方的纯文本凭证的后果的情况下这样做。

至少，脚本应该在调用时要求输入凭证。 凭证绝不应该存储在文件或脚本中，当然也绝不应该以纯文本形式存储。 最佳情况下，您可以使用更高级的凭证管理解决方案来强制进行身份验证并在内部脚本中使用标记化。 但我知道，现在我们正处于 NetOps 大规模采用自动化的蓬勃发展时期，我们必须一步一步来。

考虑到这一点，至少在调用时需要凭证。 如果您当前的实施对于实现这一目标来说太困难，那么也许是时候退一步并看看您的 IT 整体自动化策略了。 第一个问题是：你有吗？ 或者您正在做的是对业务需求的战术性（和原始）回应？

因为长期解决方案不应该——也不能——是每个脚本中的纯文本凭证。 除了明显的安全风险之外，还要考虑您所承担的技术债务。 如果您必须更改凭证，则必须在所有地方更改它们。 追踪他们需要花费时间和精力。 您可能没有时间和精力，否则您一开始就不会如此急于通过采用自动化来腾出时间。

所以请不要违反安全规则一。 比那更安全和更聪明。 自动化不应该只是对规模和速度要求的战术反应。 它应该是——而且也是——战略性的，这意味着要更加关注如何实施它的长期影响。