- 你需要使用人工智能来翻译这些文档，但所有的这类人工智能服务都被一种安全网络监控工具给屏蔽了。
- 你勉强赶在截止日期前完成了新软件版本的编码与质量测试工作，但由于安全团队尚未对其中包含的开源软件和库进行审查，导致该软件的发布被推迟了。
- 你的新数据库在开发/测试环境中运行得非常正常，但由于端口配置的问题，它在生产环境中无法正常使用，而且你也没有相应的操作权限。任何对生产环境权限的修改都需要经过安全审批流程。
瞧，影子IT来了……
“Shadow IT”这个术语听起来像是一部间谍电影中的情节，但实际上它描述的是一种现实中的现象。根据个人所处的职责不同，这种现象要么是一种令人无奈却又不得不面对的“必然存在”，要么就像是一场永无止境的“捉迷藏”游戏。如果你是一名致力于开发下一代优秀产品的工程师，那么“影子IT”技术就成为了必不可少的工具。
公司提供的信息技术更新速度远远跟不上市场的发展步伐，更无法帮助企业实现创新。尽管如此，公司的安全团队仍会严厉惩罚任何试图使用非官方供应商或非官方产品的人。数据存储必须被严格限制在经过加密且受到保护的环境中，用户要想获取这些数据几乎需要费尽周折。而且，用户在使用工具方面也毫无灵活性可言——即使其他工具能够让他们更高效、更出色地完成工作，他们也不被允许使用这些工具。
于是，你就不再遵守那些规则了，而是去寻找那些真正有效的工具和技术。
也就是说，直到有人对云托管费用提出异议、发现了无线网络接入点，或者注意到了那些非官方的软件仓库为止。一旦安全团队采取行动，他们就会没收你的工具或切断你的访问权限。这样一来，你就会感到非常沮丧，你的团队也会觉得受到了攻击，而安全团队自然也会勃然大怒。
如果你属于安全团队，那么应对“影子IT”现象就如同在玩“打地鼠”游戏一样——公司提供的信息技术系统总是在未经审查的情况下被频繁更改。你明白公司这么做是为了推动创新，但这些变更却破坏了所有那些能够让你销售服务和产品的IT合规性认证。为了阻止员工将客户机密信息存储在个人云存储设备中，你不得不进行调查、收集证据，并就相关政策和法规与相关人员进行争论。
无论你是安全运营中心的新员工，还是那位不得不向首席技术官汇报工作的倒霉首席信息安全官，这句话你肯定都听过不少次了。
然而，没有人希望出现这种情况。你不愿意，你的老板也不愿意，保安们自然更不愿意了。
如果无法修复，那就把它拆掉吧。
是时候改变安全领域的基本准则了——我们应该将重点从严格的安全措施转向如何有效防止安全漏洞的发生。大多数安全团队都希望调整自己的工作方式，专注于他们所接受过专业培训的领域：威胁情报分析、风险管理、取证分析以及安全工程。我从未遇到过哪个安全专家愿意把时间浪费在争论端口配置细节上。这种无谓的争论不仅令人疲惫不堪，还会在双方之间引发长期的矛盾与对立。
想象一下，在这样一个环境中工作：你可以使用各种创新的新工具，无需担心安全问题就能发布产品，还可以随时调整系统配置，以确保系统的顺利运行。
我们可以接受这个方案。
但要实现这个“安全与信息技术的理想世界”，就必须发生一个微妙的变化：非安全团队必须理解并落实安全部门所提出的所有要求。所有参与这一变革的人都需要清楚自己行为的后果，并对最终的安全结果承担全部责任。
让安全措施放松一下吧
当我向那些非 IT 职业的同事解释安全部门在产品发布前需要承担的工作内容时，他们都感到非常震惊。- 自定义代码及第三方代码中的漏洞与攻击点
- 供应商安全措施的范围与有效性
- 数据的加密、传输与存储，尤其是在跨境传输的情况下。
- 遵守相关法规与数据保护法律
安全要求其实并不是什么秘密。拥有集成代码扫描工具的开发者可以避免出现 OWASP 列出的十大常见安全漏洞，同时也能识别并移除那些存在安全风险的库以及那些被硬编码在代码中的账户信息。而那些拥有网络安全工具管理权限的基础设施管理员，则能够通过精确的配置来维护网络、服务器和容器的正常运行。
结果是什么呢？安全团队可以不再严格遵守那些僵化的部署规则了。
如果开发人员使用代码安全工具并遵循最佳实践，那么获得安全团队的审批应该只需要几个小时，而不是几天或几周的时间。安全团队还可以对整个架构中的标准容器配置进行审批，而无需逐一审查每个单独的容器。他们可以明确相关要求，提供工具帮助你检查自己的代码，同时协助你将这些最佳实践融入到日常的工作流程中。
“信任但验证”应该成为一种日常行为，而不仅仅是一种口头上强调的良好部门间协作方式。在产品发布后，安全团队仍会持续监控系统环境和应用程序的安全状况。他们会密切关注供应商提供的声明和审计结果，并通过威胁情报系统来获取任何可能表明存在安全风险的警报信息。这样一来，安全团队就有足够的时间去完成他们本职该做的工作——而这显然比监督其他部门的工作要有趣得多。
这一变革还要求，必须允许安全团队放手去履行他们的职责。当信任被破坏时——比如如果供应商没有经过适当的评估，或者新软件被引入却未及时上报相关情况——责任不应归咎于安全团队。如果安全漏洞是由代码编写不当造成的，那么开发团队必须为此负责；如果数据泄露是由于网络配置不完善导致的，那么网络管理和运维团队也必须承担相应的责任。如果相关要求本来就已经制定好了，但却没有得到执行，那么责任方就应该是那些同意这些要求却未能将其落实的人。
自由选择背后隐藏着隐忧
这种新的自由让“影子IT”变得不再必要了。团队无需再隐瞒自己所做的决策。然而，这种选择的自由也伴随着一个代价：必须为自己的选择承担全部责任。以公司的收费卡为例：财务部门会制定关于如何使用这些收费卡的政策，并提供相应的报销流程。他们并不会实时审核每一笔交易，但会定期审查用户的消费记录和支付情况。
如果使用者滥用该工具，或者无视事先约定的使用规范，那么使用者将承担相应的责任。任何由于缺乏相关知识而导致的违规行为，都不会让你免于承担后果。对于轻微的违规行为，使用者可能会收到书面警告；而对于严重的违规行为，使用者很可能会被直接解雇。
财务要求、相关协议、定期审查以及明确的处罚措施有助于从内部防范欺诈行为。更重要的是，这些措施能够保护公司免受疏忽责任的指控。
安全责任方面的运作方式也可以类似如此。安全团队可以制定相关要求，IT人员需要逐一同意这些要求。之后，IT团队就可以根据自身工作需要自由地进行部署和调整了。IT部门会在资产投入生产之前确保其安全性，而在资产投入使用后，也会继续遵循最佳实践，持续对这些资产进行安全审查。这样一来，获取所需工具的延迟时间就会大大缩短，而且你对自身工作的部署过程也能拥有更高的掌控力。选择“影子IT”方案的动力会大大减弱，而选择这种方案所带来的个人风险则会相应增加。
不过，最后这一点才是关键所在——当你掌控了系统的控制权时，你就必须为系统的运行结果负责。在这种情况下，你无法简单地承诺会修复某个漏洞，而必须保留那些存在安全风险的代码，等到漏洞被真正修复后再重新部署系统。如果你的部门与一个不可靠的供应商签订了合同，那么因合同违约而遭受损失的就是你经理的预算。而当网络遭到攻击时，被解雇的会是首席信息官，而不是首席信息安全官。
目前，这一责任由安全团队承担，相应的风险也由他们来承担。然而，这样的结果却是：整个企业被这种风险规避心理所束缚，对企业最终会面临什么后果既缺乏了解，也无力加以控制。
到目前为止，我主要讨论的是信息技术领域的问题，但我也想把这个观点应用到更实际的层面：安全领域的专业人士们，我们不要再试图控制别人的工作了。当我们提出一些与技术现实完全不符的苛刻要求时，我们的信息技术团队反而会更加善于隐藏自己的行为痕迹。只有当我们致力于实现共同的目标，并奖励那些能够超出我们预期的人时，我们才能取得更大的进展。
当安全与信息技术实现和谐共处时，所谓的“影子IT”就变得不再必要了。
我曾经与一个开发团队合作过，他们希望将公司的专有代码存储在一个托管的代码仓库中。这个代码仓库确实满足了他们的需求：具备自动版本控制功能、精细的访问管理机制、便捷的分支管理功能、可以从任何地方访问代码，同时还提供了集中式的代码存储服务。为了不必等待供应商完成长达六个月的安全审查流程，开发团队主动收集了供应商提供的审计证书、数据管理承诺书，以及关于安全性和数据保护方面的标准合同条款。他们还深入研究了该第三方服务提供商的安全扫描政策，并要求对方提供相应的事件响应和通知机制。如果开发人员直接选择了使用这个代码仓库，我们的安全团队恐怕会很难找到它的存在。然而，他们却以一种非常巧妙的方式规避了我们的安全审查流程——他们主动提供了我们所有需要了解的关于该代码仓库的信息。
作为回报，我——这位负责安全工作的负责人——立刻就同意了，根本不需要等待我那已经忙得不可开交的团队去安排另一次供应商评估会议了。
我的回报是什么呢？没有了那些“影子IT”系统，而且我们的IT团队也变得非常开心了。
安全措施不应仅仅局限于防止这类妥协行为的发生；我们反而应该主动去寻找这些潜在的妥协点。要说服首席信息安全官，让你们的IT团队既拥有相应的控制权，也要承担相应的责任；与那些真正重视安全的团队达成共识；而对于那些不重视安全的团队，则应将精力用于与他们进行沟通和协调。
对于管理员和开发人员来说：请提供您打算使用的供应商所出具的ISO审计报告。成为第一个掌握该组织代码扫描工具的开发团队吧。阅读来自您的云环境的最新风险评估报告，避免再次使用那些存在安全漏洞的配置方案。这些小小的改进不仅能让您的工作变得更加高效、简单，还能节省成本——因为相比自行寻找解决方案，这种方式显然更加经济实惠。