Exigir senha após a suspensão em máquinas Windows: Script do PowerShell

Principais conclusões

• Garantir a exigência de uma senha ao acordar é uma defesa de primeira linha contra o acesso não autorizado.
• O script do PowerShell fornecido automatiza o processo de ativação desse recurso de segurança.
• O script é especialmente útil para profissionais de TI e MSPs que gerenciam vários dispositivos.
• É necessário executar o script como administrador.
• Os métodos manuais tradicionais são menos eficientes para implantações maiores em comparação com o script.
• Testes em ambientes controlados e backups regulares do registro são práticas recomendadas.
• O NinjaOne pode complementar esses scripts, oferecendo uma solução centralizada de gerenciamento de TI.

No ambiente atual, que se preocupa com a segurança, a proteção dos dados do usuário tornou-se fundamental. Uma das vulnerabilidades mais comuns ocorre quando um computador é deixado sem supervisão depois de sair do modo de suspensão ou hibernação. Garantir que o Windows exija uma senha após o modo de suspensão não é apenas uma prática recomendada, mas também uma defesa de primeira linha contra o acesso não autorizado.

Histórico

Esse script foi desenvolvido para modificar configurações específicas do Windows relacionadas ao gerenciamento de energia, especialmente ao acordar do modo de suspensão ou hibernação. A capacidade de automatizar esse processo é inestimável para profissionais de TI e provedores de serviços gerenciados (MSPs) que gerenciam várias máquinas. Sem automação, a configuração desse recurso em vários dispositivos seria tediosa, propensa a erros e demorada.

O roteiro

#Requires -Version 2.0

<#
.SYNOPSIS
    Enables password on wake from sleep/hibernation.
.DESCRIPTION
    Enables password on wake from sleep/hibernation.
.EXAMPLE
    No parameters needed.
    Enables password on wake from sleep/hibernation.
.EXAMPLE
    PS C:> Set-RequirePasswordOnWake.ps1
    Enables password on wake from sleep/hibernation.
.OUTPUTS
    None
.NOTES
    Minimum OS Architecture Supported: Windows 7, Windows Server 2012
    Release Notes:
    Initial Release
By using this script, you indicate your acceptance of the following legal terms as well as our Terms of Use at https://www.ninjaone.com/terms-of-use.
    Ownership Rights: NinjaOne owns and will continue to own all right, title, and interest in and to the script (including the copyright). NinjaOne is giving you a limited license to use the script in accordance with these legal terms. 
    Use Limitation: You may only use the script for your legitimate personal or internal business purposes, and you may not share the script with another party. 
    Republication Prohibition: Under no circumstances are you permitted to re-publish the script in any script library or website belonging to or under the control of any other software provider. 
    Warranty Disclaimer: The script is provided “as is” and “as available”, without warranty of any kind. NinjaOne makes no promise or guarantee that the script will be free from defects or that it will meet your specific needs or expectations. 
    Assumption of Risk: Your use of the script is at your own risk. You acknowledge that there are certain inherent risks in using the script, and you understand and assume each of those risks. 
    Waiver and Release: You will not hold NinjaOne responsible for any adverse or unintended consequences resulting from your use of the script, and you waive any legal or equitable rights or remedies you may have against NinjaOne relating to your use of the script. 
    EULA: If you are a NinjaOne customer, your use of the script is subject to the End User License Agreement applicable to you (EULA).
.COMPONENT
    LocalUserAccountManagement
#>

[CmdletBinding()]
param ()

begin {
    function Test-IsElevated {
        $id = [System.Security.Principal.WindowsIdentity]::GetCurrent()
        $p = New-Object System.Security.Principal.WindowsPrincipal($id)
        if ($p.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator))
        { Write-Output $true }
        else
        { Write-Output $false }
    }
    function Set-ItemProp {
        param (
            $Path,
            $Name,
            $Value,
            [ValidateSet("DWord", "QWord", "String", "ExpandedString", "Binary", "MultiString", "Unknown")]
            $PropertyType = "DWord"
        )
        if ((Get-ItemProperty -Path $Path -Name $Name -ErrorAction SilentlyContinue)) {
            Set-ItemProperty -Path $Path -Name $Name -Value $Value -Force -Confirm:$false | Out-Null
        }
        else {
            New-Item -Path $Path -ItemType Directory -Force -Confirm:$false | Out-Null
            New-ItemProperty -Path $Path -Name $Name -Value $Value -PropertyType $PropertyType -Force -Confirm:$false | Out-Null
        }
    }
}
process {
    if (-not (Test-IsElevated)) {
        Write-Error -Message "Access Denied. Please run with Administrator privileges."
        exit 1
    }
    # Require a password when a computer wakes
    $Path = "HKLM:SoftwarePoliciesMicrosoftPowerPowerSettings�e796bdb-100d-47d6-a2d5-f7d2daa51f51"
    $ACName = "ACSettingIndex"
    $DCName = "DCSettingIndex"
    $Enable = "1"

    # Plugged In
    try {
        Set-ItemProp -Path $Path -Name $ACName -Value $Enable
    }
    catch {
        Write-Error $_
        exit 1
    }
    
    # On Battery
    try {
        Set-ItemProp -Path $Path -Name $DCName -Value $Enable
    }
    catch {
        Write-Error $_
        exit 1
    }
}
end {}

 

Detalhamento

O script fornecido é um script do PowerShell, destinado a ativar a exigência de senha na ativação:

• Configuração preliminar: O script começa fornecendo algumas meta-informações, como sinopse, descrição, resultados, notas e componente.
• Definições de funções:
• Test-IsElevated: Verifica se o script está sendo executado com direitos de administrador, o que é essencial para modificar chaves de registro.
• Set-ItemProp: Uma função utilitária para definir ou criar uma propriedade no registro do Windows.
• Bloco de processo: Se o script não for executado como administrador, ele gera um erro imediatamente. Em seguida, ele define o caminho para a chave de registro do Windows responsável pela configuração de senha ao acordar e a modifica para os cenários “Conectado” e “Com bateria”.

Casos de uso em potencial

Estudo de caso: Sarah, uma administradora de TI de uma empresa de médio porte, foi encarregada de garantir que todos os laptops da empresa precisassem de uma senha depois de dormir. Em vez de configurar manualmente cada dispositivo, ela usou esse script, economizando horas de trabalho e garantindo a consistência entre os dispositivos.

Comparações

O método tradicional de configuração desse recurso envolve navegar no Painel de Controle ou nas Configurações do Windows e alterar manualmente as opções de energia. Embora seja viável para máquinas individuais, isso se torna impraticável para implantações maiores. Esse script oferece um método dimensionável, eficiente e sem erros para obter o mesmo resultado.

Implicações

A exigência de uma senha após o sono acrescenta uma camada de segurança, reduzindo os riscos associados ao acesso não autorizado. Essa medida garante que as ausências temporárias, como uma pausa para o café, não se transformem em possíveis violações de dados.

Recomendações

• Sempre teste os scripts em um ambiente controlado antes de uma ampla implementação.
• Mantenha backups regulares do registro do Windows.
• Certifique-se de que os usuários sejam instruídos sobre a importância de senhas fortes.

Considerações finais

O NinjaOne, uma plataforma abrangente de monitoramento e gerenciamento de TI, pode complementar ainda mais esses scripts. Ele oferece uma abordagem centralizada para o gerenciamento de TI, garantindo que os sistemas sejam seguros, compatíveis e eficientes. A incorporação de scripts como o discutido pode reforçar a eficácia da plataforma, garantindo um ambiente de TI mais seguro.