Proteger o acesso à API XML do Sophos Firewall

A API XML do Sophos Firewall é útil para automação, monitorização, backups, análises e integrações. Por isso, também faz parte da superfície de ataque de gestão. Permitir acesso à API dá a um sistema a capacidade de ler dados de configuração ou, dependendo das permissões, fazer alterações.

O acesso à API não deve ser amplamente permitido a partir de redes internas ou de fontes aleatórias. É melhor ter um conjunto pequeno e documentado de redes de gestão, hosts de automação ou acessos de parceiros fixos.

Desde o SFOS 22, a Sophos expandiu o controle de acesso à API. As configurações de acesso à API estão na seção Administration > API access, e as fontes permitidas podem ser definidas como IP Hosts. Isso permite modelar não apenas endereços IP individuais, mas também intervalos de IP e redes de forma eficaz.

Quando o acesso à API XML é útil

A API XML não é um acesso padrão para o trabalho administrativo normal. É útil quando há um processo técnico específico por trás.

Casos de uso típicos:

• Monitorização ou inventário.
• Verificações de configuração automatizadas.
• Processos de backup ou documentação.
• Plataformas MSP ou de integração.
• Scripts para tarefas administrativas recorrentes.
• Alterações preparadas a partir de ferramentas como o Sophos Firewall Config Studio.

Se um processo pode funcionar sem a API, o acesso à API não deve permanecer ativado por precaução. Cada interface adicional precisa de um responsável, uma fonte, um conceito de acesso e um controle.

O que mudou com o SFOS 22

Com o SFOS 22, o controle de acesso à API XML tornou-se significativamente mais gerenciável:

• As configurações de acesso à API foram movidas para o menu Administration > API access.
• O acesso à API está desativado por predefinição e deve ser ativado conscientemente.
• O acesso à API pode ser restrito a IP Hosts.
• Como fontes, são possíveis endereços IP, intervalos de IP e redes.
• Até 64 IP Hosts podem ser permitidos.
• Durante a atualização, os endereços IP permitidos anteriormente são automaticamente convertidos em objetos IP Host.
• Objetos migrados recebem o prefixo apiconfig.

Isso é útil para a operação, pois as fontes da API não precisam mais ser mantidas como endereços individuais soltos. Pode-se nomear de forma clara uma rede de gestão, um host de automação ou um grupo de hosts dedicado e reconhecê-los em revisões posteriores.

Regra básica: permitir API apenas de fontes definidas

API access deve ser tratado como WebAdmin ou SSH: tão restrito quanto possível e tão amplo quanto necessário.

Fontes adequadas são, por exemplo:

• um servidor de automação dedicado,
• um sistema de monitorização,
• um host de gestão de configuração,
• uma rede interna de gestão,
• uma rede VPN ou de administração,
• um endereço de origem de parceiro ou MSP claramente definido.

Não são adequados:

• redes de clientes completas,
• redes guest ou IoT,
• Any,
• permissões vagas como “rede de servidores completa”,
• endereços IP temporários de teste que depois ficam esquecidos.

Se prestadores externos precisarem de acesso API, a fonte deve ser definida da forma mais específica possível. Também deve ficar documentado para que serve o acesso e quando será removido.

Procedimento recomendado

O caminho exato na interface pode variar ligeiramente conforme a versão do SFOS. No SFOS 22, a configuração da API fica em Administration > API access.

Procedimento prático:

1. Verificar que sistema precisa de acesso API.
2. Em Hosts and services > IP host, criar um objeto IP Host claro para esse sistema.
3. Se forem necessárias várias fontes, nomear corretamente IP Hosts, IP ranges ou redes.
4. Em Administration > API access, ativar API access.
5. Em Allowed IP hosts, permitir apenas estes objetos.
6. Clicar em Apply.
7. Não inserir redes amplas de clientes ou servidores.
8. Testar o acesso a partir do verdadeiro host de automação ou monitorização, não do portátil do administrador.
9. Remover fontes que já não sejam necessárias.
10. Documentar a alteração no processo de change.

Em instalações existentes após uma atualização para SFOS 22, também se deve procurar objetos com o prefixo apiconfig. Estes objetos foram criados a partir de entradas API allow antigas e devem ser verificados, renomeados ou limpos.

Testar o acesso de forma direcionada

O endpoint da API normalmente encontra-se em:

https://<IP-ou-hostname-da-firewall>:<Port>/webconsole/APIController

A porta é a porta HTTPS da WebAdmin Console. Se a porta de administração foi alterada em Administration > Admin settings, a ferramenta API deve usar a mesma porta. A API trabalha com payloads XML via HTTP POST, não como uma API REST clássica com endpoints GET, POST, PUT e DELETE separados.

Um teste útil não responde apenas se o login é possível. Deve mostrar se a fonte correta é permitida, se a conta pode executar a operação necessária e se o resultado permanece rastreável no processo de auditoria ou change.

Para aceitação, verificar estes pontos separadamente:

• Fonte: O teste corre a partir do verdadeiro host de automação, monitorização ou integração, não do portátil do administrador.
• Acesso: A firewall aceita o IP de origem apenas se o objeto IP Host correspondente estiver permitido em API access.
• Conta: A conta API ou de serviço utilizada tem apenas os direitos necessários.
• Segredo: Nome de utilizador, palavra-passe ou token não acabam no histórico da shell, tickets, chats ou screenshots.
• Auditoria: O acesso ou a alteração é rastreável no processo de auditoria ou change.
• Rollback: Antes de operações de escrita existem backup, ponto de rollback e um teste de leitura inofensivo.

Exemplos curl com nome de utilizador e palavra-passe no URL são rapidamente copiados e depois difíceis de remover dos logs. É melhor fazer um teste curto com uma conta de serviço dedicada, segredo temporário de teste, armazenamento seguro e rotação posterior se um segredo foi usado num contexto inseguro.

Para testes estruturados, uma coleção Postman é muitas vezes mais limpa do que um comando shell copiado à pressa. Também aí, endereço da firewall, porta, nome de utilizador, palavra-passe e valores de objetos devem ser mantidos como variáveis ou segredos, não fixos em requests, screenshots ou tickets. A coleção não é um conceito de segurança, mas ajuda a testar operações de leitura e escrita de forma mais reprodutível.

Uma API acessível ainda não prova que a alteração planeada é tecnicamente segura. Antes de operações de escrita em produção, deve funcionar primeiro uma consulta de leitura inofensiva e depois uma pequena alteração controlada.

Acesso à API e permissões de usuário

Um IP de origem sozinho não é um conceito de segurança completo. A restrição limita apenas de onde a API é acessível. Além disso, deve estar claro com qual conta o acesso à API é feito e quais permissões essa conta possui.

Para ambientes produtivos, deve-se verificar:

• Está a ser utilizada uma conta de API ou de serviço própria?
• A conta tem apenas as permissões necessárias?
• Está claramente documentado qual pessoa ou equipe é responsável pela conta?
• A senha ou segredo está armazenado de forma segura?
• O acesso é removido quando a integração não é mais usada?
• As alterações são rastreáveis através de logs de auditoria?

Contas de administrador compartilhadas são problemáticas para processos de API. Se vários sistemas ou pessoas usarem a mesma conta, a rastreabilidade é enfraquecida. Para análises de mudanças, é relevante verificar os logs de trilha de auditoria do Sophos Firewall.

Para uma conta API dedicada, um processo restrito é melhor do que copiar rapidamente um administrador completo. Na documentação Sophos, este bloco aparece como Allow API access to administrators: não é apenas a origem que é autorizada, o administrador ou o perfil também tem de ter o acesso adequado.

1. Criar um perfil de administrador com as permissões necessárias em Profiles > Device access.
2. Criar um utilizador administrador para o processo API em Authentication > Users.
3. Atribuir o perfil de administrador adequado.
4. Se o acesso for apenas temporário, limitar Access time.
5. Se possível, limitar Login restriction for device access às origens previstas.
6. Depois permitir API access e Device Access para a origem adequada.

A Sophos suporta as APIs oficiais e scripts de exemplo não modificados. Integrações, wrappers e automações próprias continuam a precisar de um responsável interno, testes e um conceito de rollback. “Funciona no lab” não é suficiente para operações de escrita em produção.

MFA e utilizadores API após SFOS 22

A MFA é importante para acessos administrativos interativos. Para processos API e de automação, porém, é necessário planear conscientemente como a autenticação deve funcionar. Um script, ferramenta de monitorização ou sistema de integração não consegue simplesmente introduzir um código OTP se o utilizador usado exigir MFA.

A lista Known Issues documenta um caso especial do SFOS 22: após uma atualização, alterações de configuração por API podem falhar para utilizadores migrados se MFA estiver ativa e nenhum one-time token for enviado. Utilizadores não migrados podem comportar-se de forma diferente em alguns casos. Para a operação, o importante não é desativar MFA em todo o lado, mas separar corretamente as contas API.

Abordagem recomendada:

1. Usar uma conta de serviço própria para processos API.
2. Atribuir à conta apenas os direitos necessários.
3. Limitar adicionalmente API access a IP Hosts fixos ou redes de gestão.
4. Verificar se MFA é tecnicamente e operacionalmente adequada para esta conta.
5. Se MFA não for prática para a conta API, controlar a conta de forma especialmente rígida através de fonte, direitos, armazenamento de segredos e audit trail.
6. Após uma atualização para SFOS 22, testar todos os processos API com operações de leitura e escrita.

⚠️ Utilizadores API sem MFA não são uma autorização para direitos amplos. Se uma conta API tiver de funcionar sem MFA por motivos técnicos, IP de origem, direitos, armazenamento da palavra-passe, responsabilidade e auditabilidade devem ser controlados com mais rigor.

Este ponto é especialmente importante em automações que não apenas leem, mas também alteram configuração.

Antes de alterações API em produção, verificar pelo menos três coisas:

• Existe um backup da Sophos Firewall atual.
• A conta API planeada consegue executar com sucesso uma consulta de leitura inofensiva.
• Em alterações em massa preparadas com Sophos Firewall Config Studio, as chamadas API ou curl geradas funcionam com a conta planeada.

Distinção de Device Access

O controle de acesso à API não é o mesmo que Device Access, mas ambos os controles interagem. O Device Access controla serviços locais da firewall como WebAdmin, SSH, User Portal, VPN Portal, DNS ou Ping. As configurações de acesso à API controlam adicionalmente quais IP Hosts podem usar a API XML. Importante: as permissões de Device Access para a WebAdmin Console também se aplicam aos acessos API.

Na prática, isto significa que o API access deve estar permitido, a fonte deve estar autorizada nas configurações de acesso à API e o acesso local de gestão à firewall não pode estar bloqueado pelo Device Access. Cada camada limita uma parte diferente da superfície de ataque:

• Configurar corretamente o Device Access: serviços locais da firewall como WebAdmin, SSH, User Portal, VPN Portal, DNS ou Ping
• Controle de acesso à API: IP Hosts que também podem usar a API XML
• Ativar MFA para WebAdmin, VPN Portal e Acesso Remoto do Sophos Firewall: Logins interativos para WebAdmin, VPN Portal e Acesso Remoto
• Admins nomeados e papéis claros: Rastreabilidade e raio de dano de contas de admin e serviço

Se uma rede de administração pode usar WebAdmin, SSH e API, essa rede deve ser especialmente bem protegida. Um cliente comprometido na rede de gestão é, caso contrário, uma entrada direta na gestão da firewall.

Operação e revisão

O acesso à API deve ser revisado regularmente. Especialmente após migrações, mudanças de prestadores de serviços, projetos de automação ou atualizações de firewall, muitas vezes permanecem fontes antigas.

Perguntas de revisão sensatas:

• Quais IP Hosts podem atualmente usar o acesso à API?
• Existem objetos com o prefixo apiconfig?
• Esses objetos ainda são necessários?
• Os nomes e descrições correspondem ao propósito real?
• Existem responsáveis documentados?
• Os acessos à API são considerados em um processo de mudança ou auditoria?
• Existe um backup atual antes de grandes alterações baseadas em API?

Antes de alterações baseadas em API, deve sempre haver um backup. O artigo Criar ou restaurar backup do Sophos Firewall descreve o que deve ser considerado em relação a backup, restauração e compatibilidade.

Erros típicos

• API access permitido para uma rede de clientes completa: Qualquer cliente comprometido nessa rede pode chegar à API.
• Objetos apiconfig antigos não verificados: Exceções antigas migradas permanecem ativas sem serem notadas.
• Conta de serviço usa direitos de administrador completos: Um segredo comprometido tem um raio de impacto desnecessariamente grande.
• Automação API usa um administrador com MFA obrigatória: Script ou ferramenta pode falhar em operações de escrita após uma atualização SFOS.
• Porta errada na ferramenta: A porta HTTPS de administração foi alterada, mas a ferramenta continua a usar a porta antiga.
• Esperada lógica REST: A ferramenta envia métodos REST em vez de payload XML via HTTP POST para APIController.
• IP temporário do prestador continua ativo: O acesso externo permanece possível durante mais tempo do que o previsto.
• Sem documentação sobre o objetivo: Administradores posteriores não sabem se uma autorização ainda é necessária.
• Alterações API sem backup: Automação incorreta é mais difícil de reverter.

Resolução de problemas

Se uma ferramenta não conseguir acessar a API XML, deve-se verificar de forma estruturada:

1. O IP de origem está correto do ponto de vista da firewall?
2. A fonte está permitida como IP Host, intervalo de IP ou rede?
3. Um objeto apiconfig foi gerado após uma atualização, mas não foi ajustado adequadamente?
4. O Device Access permite acesso local WebAdmin/API a partir desta zona?
5. A ferramenta usa o endereço correto da firewall e a porta HTTPS de administração correta?
6. Nome de usuário, senha ou segredo estão corretos?
7. A conta tem os direitos necessários?
8. A conta exige MFA, embora a ferramenta não possa fornecer um token de uso único?
9. Existem efeitos de roteamento, NAT ou proxy entre a ferramenta e a firewall?
10. O acesso foi removido intencionalmente por uma medida de endurecimento?
11. O teste foi feito a partir do sistema de origem correto ou apenas a partir do cliente admin?

Se uma alteração na API tiver impactos inesperados, primeiro faça backup do último backup e depois verifique a trilha de auditoria, comparação do Config Studio e objetos de firewall afetados. Para problemas de tráfego ao vivo, o Log Viewer e o Packet Capture são mais úteis do que a própria API.

Lista de verificação

Antes da ativação:

• Documentar o propósito do acesso à API.
• Determinar claramente o sistema de origem.
• Criar um objeto IP Host com um nome descritivo.
• Verificar conta de serviço e permissões.
• Definir conscientemente o comportamento do MFA da conta de API.
• Estabelecer processo de backup e rollback.
• Definir um método de teste sem fuga de segredos.

Durante a operação:

• Permitir acesso à API apenas para fontes definidas.
• Não liberar redes amplas de clientes, convidados ou IoT.
• Verificar objetos apiconfig após atualizações.
• Controlar acessos de prestadores de serviços em termos de tempo e função.
• Armazenar segredos de forma protegida e renovar em caso de mudança de pessoal ou ferramenta.
• Rodar segredos se acabarem no histórico da shell, em tickets ou em armazenamento inseguro.
• Testar operações de leitura e escrita da API após atualizações do SFOS.

Durante a revisão:

• Revisar regularmente as fontes de API permitidas.
• Remover IP Hosts que não são mais necessários.
• Conciliar alterações com trilha de auditoria e tickets de mudança.
• Testar processos de automação após atualizações de firmware.

FAQ