在生产服务器上启用 PowerShell 的安全问题

在生产服务器上启用 PowerShell 的安全问题

我在 ISV 的软件开发部门工作。我们正考虑使用 PowerShell 来执行核心应用程序(本身是 ASP.NET)内部和周围的一些实用程序。

我的一位同事告诉我,大多数认真的客户会认为 PowerShell 在生产环境中是完全不行的,并且会断然拒绝它。他是对的吗?

答案1

PowerShell 在 Windows Server 的最后几个版本中已包含并默认启用。

如果“认真的客户”正在使用微软技术,那么他们几乎肯定已经在使用 PowerShell,即使它隐藏在其他管理 GUI 后面,或者即使他们没有刻意使用 PowerShell,它也存在。

2015年的微软服务器软件由PowerShell管理。

并扩展到第三方,包括VMware、NetApp、Equallogic

可以删除 PowerShell,我很想知道有谁这样做过,或者删除 PowerShell 后 Windows Server 2012 R2 的限制是什么。

答案2

考虑一下替代方案,您可以使用批处理命令、vb 脚本或您自己编译的二进制文件来管理您的产品。为什么潜在客户会比 PowerShell 更信任这些技术?

虽然 PowerShell 被认为非常有用,但powerful最终您可以使用这些技术中的任何一种来做任何事情。最终它们都调用 Windows API。

所以,PowerShell 并不比其他替代方案更不安全。实际上,要求所有脚本在运行前都经过签名是相当容易的(不过,你也可以对 vb 脚本执行同样的操作)。

此外,作为管理员,我更喜欢使用 PowerShell 脚本而不是 C# 二进制文件,因为我可以快速检查和查看脚本正在做什么。

像这样的事情足够的管理工具包可以限制某些管理员可以做什么以及何时做某些事情,从而进一步锁定系统。

因此,不允许在专业的 Windows 商店中使用 PowerShell 至少可以说是很奇怪的。

尝试在没有 PowerShell 的情况下管理 Windows Nano Server。

为什么不和你的一些潜在客户谈谈并询问他们这个问题呢?我很想听听任何反对使用 PowerShell 的论点。

答案3

听起来你的同事需要读点东西。PowerShell 是 Windows 2012 中一切的核心。PowerShell 的目标之一是消除 MS 团队创建自己的向导和 GUI 的需要……只需为所有内容创建 PowerShell cmdlet,然后在其上放置 GUI。并非所有内容都已实现,但 AD 升级向导就是一个完美的例子。点击几下,你就会得到一个你本来可以使用的 PowerShell 命令。

一路使用 PowerShell....通过 HTTPS 连接执行,您的安全性与 Linux 管理员可能使用的任何基于 SSH 的连接一样安全,甚至可能更加安全。

相关内容