到现在，您应该已经听过很多遍“安全第零法则”，足以熟知它，并且牢记于心。您确实已经牢记于心了，对吧？
以防万一，先来回顾一下：
绝不可相信用户输入。任何时候都不行。
很好。既然这条基本原则已经明确，接下来我们来谈谈安全规则一。您可能已经猜到，安全规则不止一条。那么，我们开始讲第一条吧。
安全规则一：绝对不得硬编码凭据。
在通过令牌化（常用于API）和联合身份进行访问控制的时代，面向公众的应用很少违反这条规则。真正经常违反和忽视这条规则的地方，是组织内部。随着网络运维团队加大脚本和自动化的应用力度，以优化IT并支持组织的数字化转型计划，这正迅速成为一个问题。
下面以我在网上发现的一个真实案例来说明。之所以只举一个例子，是因为我既没有时间，也没有精力列出完整清单。这种做法就是如此普遍。
右侧展示了一个极其常见的安全错误：以明文形式硬编码凭据。代码中甚至没有注释指出这种做法在工作环境中不可接受，也没有提及需要采用更安全的身份验证方法。
在网络运维场景中，这让我深感担忧，因为一旦对企业共享网络进行不当操作，影响范围会大得多。
出现此类安全问题的原因之一是，尽管NetOps确实在采用自动化，但未必是从战略层面加以实施。我们发现，相当一部分NetOps专业人员开始使用Python，并将其与传统的基于CLI的配置和管理方法结合起来。
他们就像在命令行中输入凭据一样，直接把相同的凭据写进脚本，便认为大功告成。
这种做法最终会引发问题。有人会利用这一点，相关新闻也会连续多日出现在我们的信息流中。因为类似的事情以前就发生过。还记得OneLogin吗？虽然他们存储的不是包含凭据的脚本，而是包含凭据的文件，但不难想象这造成了多大的混乱。
问题在于，网络运维团队可能很放心地将命令行凭据写入脚本，但这个脚本最终会存放在哪里？是否按应有的方式进行管理，例如采用基础设施即代码的方式？是否进行版本控制并保存在代码仓库中？
您可能还记得一项Network to Code社区调查。该调查显示，NetOps对Github的采用率很高（没想到吧……）。
不妨问问自己：我们的代码仓库在哪里？是在异地还是本地？它受到怎样的保护？如果有人获取了代码仓库，影响范围会有多大？
为了跟上业务发展并为业务提供支持，我们需要通过脚本和自动化来扩展运营规模。NetOps必须朝这个方向发展，但在此过程中，应认真考虑将明文凭据存储在任何位置可能造成的后果。
至少，脚本应要求在调用时输入凭据。凭据绝不能存储在文件或脚本中，更不能以明文形式存储。理想情况下，应使用更先进的凭据管理解决方案，在内部脚本中强制执行身份验证并采用令牌化。但我知道，目前NetOps才刚刚开始大规模采用自动化，我们需要循序渐进。
基于这一点，至少应要求在调用脚本时输入凭据。如果当前实现难以做到这一点，或许应该退一步，重新审视整体IT自动化策略。首先要问的是：是否已经制定了这样的策略？还是说，目前的做法只是为应对业务需求而采取的临时（且原始）措施？
因为长期解决方案不应该，也不能，是在每个脚本中使用明文凭据。除了显而易见的安全风险，还要考虑由此产生的技术债务。如果必须更改凭据，就必须在所有位置进行更改。查找这些凭据需要投入时间和精力，而您可能恰恰没有这些时间和精力，否则一开始也不会如此迫切地采用自动化来节省时间。
所以，请不要违反安全第一原则。应采取更安全、更明智的做法。自动化不应只是满足规模和速度要求的权宜之计，而应作为一项战略来实施。为此，需要更加关注实施方式可能带来的长期影响。
关于作者
Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。
Lori Mac Vittie 的更多博客文章相关博客文章
Thingbot正转变为攻击平台
Lori MacVittie重点介绍了F5 Labs对2018年1月至6月全球物联网设备攻击的研究，并指出了其中令人警醒的影响。物联网设备不仅持续遭到利用，还被转变为攻击平台，这意味着攻击者可以更充分地利用这个必然增长的市场。
借助F5全新Quick Start，在AWS上快速开展业务
在AWS re:Invent开幕前，我们很高兴与大家分享F5与AWS之间全新的Quick Start集成。F5的Tom Atkins将介绍该服务如何启动、配置和运行在AWS上部署工作负载所需的计算、网络、存储及其他AWS服务。