A configuração segura de Windows e Linux reduz as oportunidades de ataque criadas por serviços desnecessários, privilégios excessivos e parâmetros inadequados. O resultado deve ser uma configuração de referência aplicável a uma família de equipamentos, acompanhada por exceções justificadas e por uma forma de confirmar o estado realmente instalado. Uma lista de opções marcadas numa consola não demonstra, por si só, que o servidor continua operacional ou que um utilizador deixou de ter privilégios administrativos.
Este plano organiza o trabalho desde o inventário até à manutenção. Usa recomendações técnicas dos fabricantes como ponto de partida. Os exemplos de prazos e decisões são escolhas de uma organização fictícia; não constituem mínimos legais portugueses nem uma certificação de conformidade com o RGPD.
Escolher uma referência que corresponda ao sistema
Comece pela versão, edição, função e modo de gestão do equipamento. Um portátil de atendimento, um servidor de ficheiros e um controlador de domínio não devem receber uma política indiferenciada. Registe também a versão do documento utilizado: dizer apenas «seguimos as melhores práticas» impede comparar a configuração aprovada com a que está em produção.
A Microsoft disponibiliza configurações de referência de segurança para Windows. São conjuntos de recomendações técnicas cuja aplicabilidade depende do ambiente. O Security Compliance Toolkit permite comparar políticas e trabalhar com configurações de referência. A disponibilidade de uma opção deve ser confirmada na edição e na versão utilizadas; o nome comercial do sistema não basta.
Para Ubuntu, a documentação do Ubuntu Security Guide descreve auditoria, aplicação e personalização de perfis. Escolha um perfil suportado para a versão instalada e confirme os requisitos de acesso à ferramenta. Uma regra destinada a um servidor não é automaticamente adequada a uma estação de trabalho. Noutras distribuições, procure a documentação correspondente, em vez de copiar comandos de Ubuntu para sistemas com mecanismos diferentes.
As referências ajudam a executar a política de segurança da informação. Não substituem a análise de risco nem criam, por serem publicadas, uma obrigação portuguesa de instalar um produto específico.
Fazer o inventário antes de mudar parâmetros
Relacione os equipamentos com os serviços que suportam. A cartografia dos sistemas e fluxos permite identificar quem deixará de trabalhar se uma alteração bloquear uma integração. Inclua sistemas de autenticação, agentes de cópia de segurança, software de acesso remoto, certificados, incluindo os certificados TLS e contas de serviço. Uma aplicação aparentemente isolada pode depender de um mecanismo antigo de autenticação que só aparece no fecho mensal.
Uma empresa fictícia identifica 24 portáteis Windows, dois servidores Linux para aplicações internas e um servidor de ficheiros. Decide criar três perfis, com responsáveis distintos. Os portáteis usam um perfil comum; os servidores Linux partilham regras gerais, mas mantêm permissões de rede específicas. O servidor de ficheiros tem uma exceção temporária associada a um equipamento de digitalização antigo. A exceção identifica o serviço afetado, a limitação de acesso e a data prevista de substituição.
Este inventário deve ainda indicar equipamentos sem gestão central ou sem informação recente. Esses equipamentos ficam com estado «por verificar». Não os contabilize como conformes por não terem enviado alertas.
Construir a configuração Windows
Organize a referência por objetivos. Primeiro, delimite a administração: os utilizadores habituais não precisam de uma conta administrativa para ler correio ou trabalhar no sistema comercial. Separe as credenciais de administração e preveja uma forma controlada de instalar software. Se a empresa usar gestão de palavras-passe administrativas locais, confirme a unicidade das credenciais, quem as pode consultar e o que acontece após utilização.
Depois, reveja as entradas no equipamento. O acesso remoto deve ter uma finalidade, destinatários autorizados e um percurso de rede controlado. Uma regra de firewall deve identificar a aplicação ou o serviço e a origem necessária. Abrir um serviço para toda a rede porque uma instalação falhou torna a exceção muito mais ampla do que o problema original.
Por fim, trate a proteção dos dados e da execução de programas. Valide a cifragem e a recuperação de chaves, a proteção contra software malicioso, as restrições a conteúdo ativo e o comportamento perante ficheiros recebidos externamente. Os detalhes da cifragem e gestão de chaves devem estar ligados à referência, para que uma reinstalação não deixe o equipamento sem recuperação possível.
No perfil dos 24 portáteis, a empresa decide bloquear a administração corrente, manter a firewall ativa e limitar instalações a um processo de suporte. A equipa verifica dois percursos reais: um colaborador abre os documentos necessários sem elevação; um técnico instala uma atualização autorizada com credencial separada. Ambos têm de funcionar. Obrigar todos a usar a conta administrativa para contornar problemas seria um sinal de falha do perfil.
Tratar identidade e diretório como infraestrutura crítica
Quando existe um diretório central, uma conta privilegiada pode afetar muitos equipamentos. Distinga a administração do diretório da administração de aplicações e dos postos de trabalho. Evite que credenciais com alcance elevado sejam usadas em máquinas correntes e documente as contas de serviço, os proprietários e as dependências.
A revisão deve procurar direitos atribuídos por herança, grupos aninhados e contas antigas ainda utilizadas por tarefas automáticas. Remover uma conta sem identificar a tarefa pode interromper uma operação; mantê-la indefinidamente sem proprietário perpetua o risco. A solução é atribuir responsabilidade, reduzir permissões e observar o funcionamento numa janela controlada.
Associe esta parte à política de autenticação e palavras-passe. O comprimento de uma palavra-passe não corrige permissões excessivas, e uma política escrita não demonstra que uma aplicação utiliza efetivamente o mecanismo aprovado.
Construir a configuração Linux
Em Linux, parta dos pacotes e serviços necessários à função do servidor. Confirme os processos que escutam na rede e a razão para cada exposição. Um servidor de aplicação que não precisa de impressão, descoberta local ou acesso gráfico deve ter essa necessidade avaliada antes de manter os respetivos componentes ativos.
Para administração remota, defina contas nominativas, elevação controlada e meios de autenticação adequados. Antes de alterar a configuração de acesso, garanta uma sessão de recuperação ou uma consola independente. Bloquear o único acesso administrativo pode transformar uma melhoria de segurança numa indisponibilidade evitável.
Reveja permissões dos ficheiros de configuração, diretórios de exportação, segredos usados pela aplicação e tarefas agendadas. Os mecanismos de controlo de acesso do sistema devem ser configurados para o serviço concreto, com análise dos eventos de bloqueio. Desativar integralmente um mecanismo porque a aplicação não inicia elimina a proteção de outros processos; procure a regra específica e documente a alteração.
No exemplo, o servidor de relatórios aceita ligações apenas do serviço comercial e da rede de administração. O utilizador da aplicação não tem acesso ao diretório de cópias. A conta de manutenção pode reiniciar o serviço necessário, mas não recebe acesso indiscriminado aos dados de todos os departamentos. A verificação compara estes percursos com as regras efetivas, incluindo acesso indevido que deve ser recusado.
Aplicar atualizações segundo risco e dependências
A configuração segura inclui versões suportadas e um processo de correção de vulnerabilidades. Classifique a urgência considerando exploração conhecida, exposição, privilégios necessários e efeito sobre os dados. Uma pontuação técnica isolada não revela se o componente está acessível num serviço público ou desligado numa imagem antiga.
Defina quem recebe o aviso, quem decide a prioridade e qual a medida temporária quando a atualização não pode ser aplicada imediatamente. No exemplo, uma falha explorada num serviço exposto leva a restringir o acesso enquanto se prepara a correção. A empresa regista uma janela de execução e um responsável; não trata essa decisão como um prazo universal imposto pelo RGPD.
A reposição também importa. Confirme que as imagens usadas para reinstalar equipamentos incorporam as alterações aprovadas. Caso contrário, cada substituição física repõe uma configuração vulnerável que a equipa já tinha corrigido.
Pilotar e saber recuar
Escolha um piloto que represente os percursos mais difíceis, não apenas as máquinas mais simples. Inclua um utilizador com aplicações antigas, uma tarefa automática, impressão quando necessária e o acesso remoto autorizado. Registe o estado anterior, as alterações aplicadas e a forma de reversão.
| Verificação do piloto | Resultado exigido no exemplo | Ação se falhar |
|---|---|---|
| Sessão do utilizador | Trabalho corrente sem administração local | Corrigir permissões da aplicação |
| Tarefa noturna | Execução com a conta de serviço prevista | Rever dependência e direitos mínimos |
| Administração Linux | Acesso nominativo e elevação delimitada | Repor acesso pela consola de recuperação |
| Cópia e restauro | Ficheiro recuperado e legível por pessoa autorizada | Suspender expansão do perfil |
| Eventos de segurança | Eventos essenciais recebidos na plataforma prevista | Corrigir recolha antes da expansão |
A decisão de avançar deve indicar o que foi confirmado e o que permanece excecionado. Um piloto com uma falha grave de recuperação não fica aprovado porque os restantes controlos passaram. Ligue esta preparação ao plano de recuperação de TI.
Manter a referência e as exceções
Guarde a versão aprovada, a população abrangida e o resultado da verificação. Compare periodicamente a configuração efetiva com essa referência e investigue divergências. Uma alteração autorizada pode exigir nova versão; uma alteração inexplicada pode ser sinal de erro ou incidente.
A recolha de eventos de segurança deve permitir identificar mudanças importantes sem copiar dados pessoais desnecessários. Separe o relatório de conformidade técnica dos registos detalhados, limitando o acesso a cada um conforme a função.
Para a exceção do equipamento de digitalização, a empresa regista uma ligação restrita, um proprietário e uma data de revisão. Na revisão, confirma se o equipamento foi substituído e remove a regra quando deixa de ser necessária. Esse encerramento faz parte da configuração segura: uma exceção sem acompanhamento acaba por se tornar uma segunda configuração, menos protegida e mal documentada.
Uma referência utilizável combina, assim, parâmetros aplicáveis, percursos de trabalho verificados e decisões visíveis. A evidência mais útil é conseguir mostrar, num equipamento real, que a regra está instalada, que o serviço funciona e que o acesso que deveria ser recusado é efetivamente recusado.
Fontes técnicas verificadas em 8 de setembro de 2026.