Você já baixou um script do PowerShell, o executou e se deparou com a infame mensagem de erro abaixo? Se sim, você precisa do cmdlet Set-ExecutionPolicy e deste tutorial!

Neste post, você vai aprender sobre as políticas de execução do PowerShell e como gerenciá-las com o cmdlet Set-ExecutionPolicy
. Ao final deste post, você não apenas saberá como executar scripts, mas também como usar as políticas de execução!
Este tutorial foi escrito com o Windows PowerShell em mente, e todas as demonstrações foram realizadas com o Windows PowerShell. As políticas de execução não são exclusivas do Windows PowerShell e operam de maneira muito semelhante no PowerShell 6+. No entanto, se você estiver trabalhando com o PowerShell 6+, pode encontrar pequenas diferenças de comportamento.
What é uma Política de Execução?
Se você já se deparou com o erro descrito acima, encontrou uma política de execução. As políticas de execução do PowerShell são um mecanismo de segurança para proteger seu sistema contra a execução de scripts maliciosos. As políticas de execução não impedem que você execute código do PowerShell no console como uma shell, mas a execução de scripts.
A Microsoft diz que uma política de execução não é tecnicamente uma medida de “segurança”, mas mais como um portão que você pode abrir e fechar. Afinal, você pode facilmente ignorar uma política de execução definida, como você aprenderá mais tarde.
As políticas de execução são baseadas na confiança. Se você confia em um script, as chances são de que não seja malicioso. As políticas de execução geralmente não impedem a execução de todos os scripts. Seu principal propósito (especialmente quando configuradas de forma mais estrita) é garantir que você confie que o script que está executando está assinado criptograficamente com um certificado.
Escopos de Política de Execução
Como você aprendeu, as políticas de execução restringem a execução de scripts, mas o PowerShell pode executar scripts em muitos contextos diferentes. O PowerShell executa scripts no contexto do usuário conectado ou no contexto de máquina global, por meio de tarefas agendadas em execução como SYSTEM ou dentro do escopo de um único console do PowerShell aberto.
Para acomodar todos esses contextos, o PowerShell tem cinco contextos diferentes ou escopos nos quais você pode definir uma política de execução.
- MachinePolicy – Este escopo é limitado a um único computador. Afeta todos os usuários que fazem login nesse computador, e um objeto de política de grupo do Active Directory o define. Quando definido, tem precedência sobre todos os outros escopos.
- MáquinaLocal. Este é o escopo padrão que afeta todos os usuários do computador e é armazenado na subchave do registro HKEY_LOCAL_MACHINE. Quando você define uma política de execução usando
Set-ExecutionPolicy
, este escopo é o padrão.
A política de execução para MáquinaLocal é armazenada na chave do registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell.
- PolíticaDoUsuário – O escopo PolíticaDoUsuário afeta apenas um usuário em um computador, e um objeto de política de grupo do Active Directory o define. Você não pode alterar esta política com
Set-ExecutionPolicy
. - UsuárioAtual. O escopo de política UsuárioAtual define a política de execução apenas para o usuário atual e é armazenado sob a colmeia do registro HKEY_CURRENT_USER. Você não pode alterar esta política com
Set-ExecutionPolicy
.
A política de execução para UsuárioAtual é armazenada na chave do registro HKEY_CURRENT_USER\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell.
- Processo – Este escopo define a política de execução para uma única sessão do PowerShell para um único usuário. O escopo de execução Processo é a política de execução mais granular que você pode definir. Ao contrário de outras políticas de execução, esta política é salva em uma variável de ambiente chamada
PSExecutionPolicyPreference
em vez do registro.
Tipos de Políticas de Execução
As políticas de execução têm vários “níveis de segurança”. Esses níveis ditam o quão rigorosa é a política de execução. Por exemplo, você pode ter uma política de execução que, essencialmente, não faz nada; está desativada, mas, por outro lado, uma política de execução pode desativar completamente a execução de scripts.
Vamos abordar cada uma das maneiras de configurar o nível de segurança de uma política de execução, do menos restritivo para o mais restritivo.
Irrestrito
A política menos restritiva é aquela que não afeta nada; é Irrestrita. As políticas de execução Irrestritas estão essencialmente desativadas. Os usuários podem executar todos os scripts, independentemente da confiança, quando uma política de execução é Irrestrita.
Bypass
Assim como o tipo Irrestrito, uma política de execução definida como Bypass não bloqueia nada.
Embora Bypass e Irrestrito tenham um efeito semelhante, o tipo de política de execução Bypass não é tecnicamente um tipo. Ele pula completamente uma política de execução definida.
Indefinido
Embora não seja comumente usado, você pode essencialmente remover uma política de execução definindo-a como Indefinida. Quando você define uma política de execução como Indefinida, o PowerShell remove completamente quaisquer políticas de execução atribuídas do escopo atribuído.
Em computadores não-Windows, a política de execução é sempre definida como Irrestrita e não pode ser alterada.
Quando todos os escopos estão definidos como Indefinidos, o PowerShell trata essencialmente todos os escopos como Restritos.
RemotoAssinado
Conforme você leu anteriormente, as políticas de execução dizem respeito à confiança adquirida por meio de uma assinatura digital em scripts. O PowerShell também leva em consideração de onde esse script veio. Foi criado no seu computador local ou por alguma pessoa aleatória na Internet?
Scripts construídos em algum lugar que não seja o seu computador local não devem ser confiáveis por padrão. Por isso, o PowerShell fornece a política de execução RemoteSigned. A política de execução RemoteSigned obriga que todos os scripts escritos em algum lugar que não seja o seu computador local sejam assinados criptograficamente.
Você pode substituir essa política de execução em certa medida para arquivos baixados da Internet usando o
cmdlet
Unblock-File
. Obtenha mais informações sobre esse comportamento um pouco mais adiante na seção Como Funciona a Política RemoteSigned.
Para o Windows Server, RemoteSigned é atribuído como política padrão.
AllSigned
Se você deseja garantir que todos os scripts do PowerShell sejam assinados criptograficamente, defina a política de execução como AllSigned. Como RemoteSigned, essa política de execução leva o requisito de assinatura a um passo adiante e obriga todos os scripts a serem assinados antes da execução.
Mesmo que você tenha a política de execução AllSigned configurada, ainda é possível contornar essa política de execução, como você aprenderá posteriormente.
Restricted
A política de execução mais restritiva é Restrita. Quando uma política de execução é Restrita, absolutamente nenhum script pode ser executado; independentemente de serem confiáveis ou não. Essa política essencialmente desativa completamente a execução de scripts.
Também, ao contrário dos tipos menos restritivos, o tipo Restrita garante que arquivos de formatação e configuração do PowerShell (PS1XML), arquivos de script de módulo (PSM1) e perfis do PowerShell não possam ser executados.
Todos os clientes do Windows, por padrão, estão configurados com uma política de execução Restrita.
Tecnicamente, a Microsoft define uma sétima política de execução chamada Padrão, mas o tipo é essencialmente outro rótulo para RemotoAssinado (Servidores Windows) e Restrito (Clientes Windows).
Como a Política RemotoAssinado Funciona
Um cenário particular a ser observado é como a política de execução RemotoAssinado funciona. Esta política de execução (como você aprendeu) impede a execução de scripts que foram criados em outro lugar que não seja o seu computador local.
Mas como o PowerShell sabe que o script foi criado em outro lugar? Fluxos de dados.
Compreendendo e Consultando Fluxos de Dados do NTFS
Sempre que você cria um arquivo em um sistema de arquivos NTFS, o NTFS aplica um atributo de fluxo de dados alternativo (ADS) ao arquivo. Um ADS possui dois atributos de arquivo: $Dados e zone.Identifier. O PowerShell usa o atributo zone.Identifier para identificar se um arquivo de script do PowerShell foi criado em outro lugar.
Ao contrário de outros atributos como Compactado ou Somente Leitura, os atributos ADS estão ocultos no Explorador de Arquivos. No entanto, usando o PowerShell, você pode inspecionar esses fluxos de dados.
Execute o cmdlet Get-Item
usando o caminho para o script e o parâmetro Stream
conforme mostrado abaixo. Neste exemplo, Hello World.ps1 foi escrito no computador local. Observe que o único atributo atribuído à propriedade Stream
é $DATA
. Não há atributo ADS.

Agora, execute o mesmo comando em um script baixado da Internet. Observe que agora Get-Item
retorna outro objeto completamente com um Stream
de Zone.Identifier
.

Uma vez que você sabe que um arquivo tem um ADS, você pode então usar o comando Get-Content
para descobrir a zona. A zona define de onde o arquivo veio.
Get-Content
irá retornar um valor ZoneId
que representa a zona de onde o arquivo veio.

Os possíveis valores de zona são:
Precedência da Política de Execução
Como mencionado anteriormente, muitas políticas de execução diferentes existem simultaneamente. Todas essas políticas de execução, quando combinadas, ditam as configurações da sua sessão atual. Quando você tem múltiplas políticas de execução em vigor, você deve ter precedência.
A precedência da política é a ordem em que o PowerShell aplica diferentes políticas definidas em diferentes escopos. Algumas políticas de execução têm prioridade mais alta do que outras.
Quando você executar Get-ExecutionPolicy -List
, você encontrará todas as políticas de execução atualmente em vigor, ordenadas da menor para a maior prioridade. Por exemplo, como MachinePolicy tem uma prioridade mais baixa, as políticas LocalMachine e CurrentUser irão sobrepor a ela.

Trabalhando com Políticas de Execução
Compreendendo o suficiente sobre o histórico das políticas de execução, vamos agora aprender como trabalhar com elas! Para trabalhar com as políticas de execução do PowerShell, você tem dois comandos à sua disposição: Get-ExecutionPolicy
para descobrir políticas atualmente definidas e Set-ExecutionPolicy
para definir novas políticas.
Obtendo Políticas Atualmente Atribuídas
Antes de começar a alterar as políticas de execução, você precisa saber com o que está trabalhando. Para isso, você tem o comando Get-ExecutionPolicy
. Esse comando enumera todas as políticas atualmente atribuídas em um computador.
Quando você executa diretamente o comando Get-ExecutionPolicy
em um console do PowerShell sem parâmetros, ele mostrará a política de execução definida para sua sessão atual do PowerShell.

Para ver a política de execução definida para um escopo, especifique o parâmetro Scope
usando o nome do escopo para o qual você deseja ver os resultados.

Para visualizar todos os escopos e suas políticas de execução, use o parâmetro List
como mostrado abaixo.

Alterando Políticas de Execução
Uma vez que você sabe quais políticas de execução estão atualmente atribuídas, você também pode alterá-las. Para alterar a política em um único computador, você tem o comando Set-ExecutionPolicy
à sua disposição. Mas, se você estiver em uma organização, desejará alterar as políticas em massa. Se esse for o caso, você sempre tem a Política de Grupo se estiver em um domínio do Active Directory.
Usando Set-ExecutionPolicy
Vamos primeiro cobrir como alterar políticas com o comando Set-ExecutionPolicy
. Para fazer isso, abra o PowerShell como administrador.
Agora execute o comando Set-ExecutionPolicy
com um único parâmetro (ExecutionPolicy
) fornecendo o nome da política de execução.
O PowerShell então perguntará se você gostaria de alterar a política de execução. Se sim, digite Y ou A e pressione Enter.

Alguns comandos do PowerShell precisam executar várias outras tarefas para operar. Se no exemplo acima você digitar Y
, o PowerShell poderá solicitar que você continue para cada etapa. Se você pressionar A
, ele continuará para todas as etapas subsequentes.
Executando Set-ExecutionPolicy
Sem Solicitações
Por padrão, ao executar Set-ExecutionPolicy
, será solicitado se deseja ou não alterar a política de execução. Você pode pular esta solicitação adicionando o parâmetro Force
ao seu comando. Usar o parâmetro Force
suprimirá todas as solicitações de confirmação.

Definindo a Política de Execução do PowerShell via Registro
Já que a maioria das políticas de execução são armazenadas no registro (excluindo Processo), você também pode alterar as políticas diretamente através do registro.
Para alterar as políticas de execução via registro:
- Abra o Editor de Registro do Windows (regedit) ou sua ferramenta de edição de registro preferida.
2. Navegue até a chave de registro do escopo da política de execução que deseja alterar.
MáquinaLocal – HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell
UsuárioAtual – HKEY_CURRENT_USER\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell
3. Clique com o botão direito na chave de registro e crie um novo valor de string chamado ExecutionPolicy.
4. Dê um duplo clique no valor de string ExecutionPolicy recém-criado e insira o nome da política de execução desejada (Restrita, RemoteSigned, AllSigned, NãoRestrita ou Indefinida).
5. Crie outro valor de string na mesma chave chamado Path. O valor de string Path representa o caminho para o mecanismo PowerShell. Certifique-se de que o valor Path seja C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe, que aponta para o mecanismo Windows PowerShell.

O modo de execução CurrentUser sobrepõe uma política LocalMachine. Se você tiver uma política CurrentUser definida no registro e tentar alterar a política de execução via Set-ExecutionPolicy
, que, por padrão, define a política no escopo LocalMachine, o PowerShell retornará um erro mostrado abaixo.

Configurando a Política de Execução do PowerShell via Política de Grupo
Se você estiver em uma organização com o Active Directory, não vai querer percorrer todas as suas máquinas com Windows e executar o cmdlet Set-ExecutionPolicy
. Em vez disso, você pode gerenciar políticas em massa com a Política de Grupo.
Para gerenciar políticas de execução via GPO:
Crie o Objeto de Política de Grupo
- Abra a aplicação de Gerenciamento de Política de Grupo em um controlador de domínio ou em sua estação de trabalho associada ao domínio.

2. Expanda Domínios —> <seu floresta do Active Directory> —> Objetos de Política de Grupo.

3. Clique com o botão direito em Objetos de Política de Grupo e clique em Novo.
4. Dê um nome ao seu GPO. Neste tutorial, o GPO é chamado de Política de Execução do PowerShell.

5. Clique com o botão direito no GPO recém-criado e clique em Editar.
6. Navegue até Configuração do Computador\Modelos Administrativos\Componentes do Windows\Windows PowerShell.

7. Abra a configuração no painel de janela direito, abra a configuração Habilitar Execução de Script.

8. Na caixa Habilitar Execução de Script, selecione a opção Habilitado. Agora você pode selecionar qualquer uma das opções mostradas abaixo:
9. Agora altere a Política de Execução para a política desejada.
- Permitir apenas scripts assinados – Permite a execução de todos os scripts quando um editor confiável os assina.
- Permitir scripts locais e scripts assinados remotamente – Permite a execução de scripts locais, mas os scripts baixados da internet devem ser assinados por um editor confiável.
- Permitir todos os scripts – Permite a execução de todos os scripts.

Atribua o Objeto de Política de Grupo
Depois de criar o GPO, é hora de atribuí-lo aos seus computadores de destino. Para fazer isso, você deve atribuir o GPO a uma Unidade Organizacional (OU) do Active Directory.
Se, em vez de criar um novo GPO, você editou um GPO existente, esse GPO provavelmente já foi atribuído a uma OU.
- Em Gerenciamento de Diretiva de Grupo, navegue até a sua OU de escolha indo para Domínios —> <seu floresta de diretório ativo> —> <Sua OU>.
2. Clique com o botão direito na OU e selecione Vincular uma GPO existente…

3. Selecione a GPO acabada de criar (Política de Execução do PowerShell) e clique em OK.

Agora você deve ver a GPO atribuída à OU conforme mostrado abaixo.

Neste ponto, você pode esperar pelo intervalo de atualização da Diretiva de Grupo definido ou executar o comando gpupdate em um computador alvo para forçar uma atualização.
Restringindo Alterações na Política Local
Uma vez que uma GPO está em vigor e altera a política de execução, os usuários locais não podem mais alterar a política via console do PowerShell local. Se tentarem, receberão um erro, como mostrado abaixo.

Burlando Completamente a Política de Execução
Como mencionado anteriormente, uma política de execução não é necessariamente destinada a ser uma medida de segurança. Por quê? Porque você pode completamente burlá-la se quiser de algumas maneiras diferentes.
Usando o Parâmetro -ExecutionPolicy Bypass
Ao contrário das outras políticas de execução, a política Bypass geralmente é definida não no console do PowerShell, mas é passada para o mecanismo powershell.exe executado como administrador.
Por exemplo, para executar um script chamado Hello World.ps1 ignorando completamente qualquer política de execução, invoque powershell.exe, use o parâmetro Bypass
e forneça o caminho do arquivo conforme mostrado abaixo.

Lendo Scripts e Executando Códigos Raw
Você também pode contornar qualquer política de execução lendo primeiro o conteúdo de um script e passando esse conteúdo diretamente para o mecanismo do PowerShell. Ao fazer isso, cada comando é executado individualmente e não como um script inteiro de uma vez.
Como pode ser visto abaixo, a política de execução está configurada como Restrita, mas ao ler o script e passá-lo para powershell.exe, ainda funciona.
Esta abordagem é semelhante a abrir um script em um editor PowerShell como o PowerShell ISE ou Visual Studio Code, selecionar uma linha e pressionar F8.

Conclusão
Agora você deve saber tudo o que há para saber sobre as políticas de execução do PowerShell. Mesmo que não sejam tecnicamente uma medida de segurança, você ainda deve gerenciá-las em sua organização de acordo com as políticas organizacionais.