管理层希望我创建一个脚本/应用程序/古老的魔法神器，让现场技术人员在我们的配置管理器服务器上执行一项任务（更新集合成员身份 - 通过 WMI 调用即可轻松完成），而无需实际授予技术人员执行该任务的权限。首先想到的解决方案是创建一个具有必要权限的服务帐户，然后找到一种方法，让技术人员在此帐户下运行命令，而无需实际向他们透露服务帐户的凭据。我想我可以通过非对称加密来加密凭据，但我对加密一无所知，所以我会遇到很大困难。
我正在考虑的另一个选择是创建一个自定义 WMI 方法提供程序，它将进行适当的 WMI 调用，以在一组约束内完成我需要的任务，我希望使用管理层需要的工具强制技术人员执行这些约束。然后，我只需在 ConfigManager 服务器上注册此提供程序，并向现场技术人员授予“执行方法”权限。
在我陷入使用疯狂的自定义 WMI 垃圾（我的继任者可能很难修改或重新创建）破坏我组织的 SCCM 服务器的困境之前，我是否忽略了什么明显的因素，导致这种做法愚蠢或不可行？否则，是否还有其他我未注意到的常见做法，允许我们的技术人员通过代理执行他们没有明确权限执行的任务？
答案1
你说的是通过隐蔽性实现安全。你希望一组技术人员有权执行某些操作，但你不想让他们访问一个巨大而可怕的控制台，上面有很多按钮，如果使用不当，可能会给他们带来麻烦。我明白。但这是错误的想法，因为它只是一条温暖的毯子，感觉很舒服，但实际上并没有提高安全性。
我经常在公司看到这种情况；他们希望让低级帮助台技术人员能够重置 AD 密码，但又不想让他们访问 Active Directory 用户和计算机 RSAT 工具。因此，他们最终创建了一个网页或某个使用服务帐户来完成工作的密码重置应用程序。您可能会说这降低了恶意软件的攻击面（因为您只需保护 1 个帐户，而不是 20 个或更多），但实际上您所做的只是隐藏信息，而恶意用户如果真的想要，无论如何都可以通过其他方式获取这些信息。
最重要的是，您可以在技术人员的工作站上安装 SCCM 控制台，而无需授予他们访问服务器本身的权限，并且该控制台是完全安全的。您可以完全控制谁可以看到什么。要做到这一点需要一些工作，但肯定比您谈论的无法维护的 Rube Goldberg 式 WMI 脚本少得多。
教你的技术人员如何正确使用控制台，明确他们的职责范围，并给予他们足够的权限来完成他们的工作。如果他们无意中做了你不打算让他们做的事情，那是你的错。如果他们故意地做一些你不想做的事情，他们应该被解雇（或者，如果他们做了一些聪明而有用的事情而没有破坏任何东西，他们应该被提升）。
极力游说管理层不要使用技术来解决人员问题。最终，这只会增加您的工作量，并鼓励他们认为网络比实际更安全。