【问题标题】:Securing passwords in PowerShell scripts保护 PowerShell 脚本中的密码
【发布时间】:2019-09-18 01:04:58
【问题描述】:

我正在编写一个 PowerShell 脚本,每隔几个月,第三方应用就会自动调用它来执行以下操作:

  1. 使用[System.Web.Security.Membership]::GeneratePassword() 随机生成密码,然后将该密码与Export-PfxCertificate 和OpenSSL 的passin 一起使用。
  2. 使用静态密码通过 COM API 向不支持 API 密钥或任何东西的第三方系统进行身份验证。

安全地执行此操作的最佳方法是什么?

据我所知,#1 没有任何问题,但我在网上阅读的关于 #2 的所有内容都建议:

  • 要求用户在执行脚本时提供凭据,但这违背了自动化流程的意义。
  • 使用 PSCredential,但这在此处是不可能的。
  • 使用加密的密钥/密码文件,但据我所知,这没有任何意义,因为您实际上仍在将密码存储在脚本文件旁边 - 如果服务器受到威胁,那么他们可以从脚本中读取密码或解密密钥文件中的密码。除非您使用未存储在服务器上的自定义加密密钥,但同样会破坏自动化。

【问题讨论】:

  • 可以对文件的密码进行加密,使其只能由同一用户在同一服务器上恢复,因此该文件对其他人实际上是无用的。不是 100% 安全,但可能足以满足您的情况。查看我之前对类似问题的回答:What is the best way to store account credentials ...

标签: powershell security passwords


【解决方案1】:

对于#2,有很多资源/文章介绍了使用 PowerShell 时如何保护凭据。

从 Windows 凭据管理器开始...

Install-Module -Name "CredentialManager"

Get-Command -Module "CredentialManager"

$Target = "YourServerName"
$UserName = "Administrator"
$Secure = Read-host -AsSecureString
New-StoredCredential -Target $Target -UserName $UserName -SecurePassword $Secure -Persist LocalMachine -Type Generic

Get-StoredCredential -Target "servername" –AsCredentialObject

Remove-StoredCredential -Target "servername"

...然后看看其他方法。有关其他方法,请参阅此问答。 Passwords in powershell logging

至于……

如果服务器被入侵

...如果一个邪恶的人进入你的系统这么远,为了能够做到这一点,那么这会起作用:Ten Immutable Laws Of Security (Version 2.0)

【讨论】:

  • 这让我去了mcpmag.com/articles/2017/07/20/… | “凭据”使用 Get-Credential | Export-CliXml、$Credential = Import-CliXml 和 $Credential.GetNetworkCredential().Password,这就是我所使用的。
  • 后续问题:在用户执行设置以输入配置(包括凭据)但系统执行脚本的理想场景中,最好的方法是什么——当然系统不会能够解密凭据,因为它是不同的安全上下文,因此 *-CliXml 使用不同的密钥?
  • 我改用了这个方法:getsysadminblog.com/2017/03/16/…
【解决方案2】:

您查看过Azure Key Vault 或类似的东西吗?

如果您走这条路,请查看 Az 模块(Windows PowerShell 5.1 或 PowerShell Core)。 Az.KeyVault 子模块有很多函数可以用于保管库。

编辑:为了解决安全问题,我们对系统知之甚少。但是,这些是我会研究的事情:

  1. 最低权限:确保该服务帐号只能做它应该做的事情。
  2. 使用时间限制:如果知道应该执行的计划,请将系统配置为仅允许帐户在该时间段内成功进行身份验证,甚至允许 JIT 权限(如果可能)。
  3. 基于位置的限制:仅允许帐户从该位置进行身份验证。最好的结果,能够限制到应该执行它的特定服务器(可能需要一个专用的出口 IP)。
  4. 审核:监控这些设置的变化并发出警报。

如果这些都到位,您的暴露就是实际系统受到损害,并且攻击者可能在允许的窗口期间在允许的范围内进行意外更改。在这一点上,这是一个相当低的风险,这比不实施此类控制要好得多。

这些可以在应用程序中实现,或者通过第三方可信身份验证源(如果它可以与应用程序集成)实现。

【讨论】:

    猜你喜欢
    • 2011-05-18
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-02-21
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多