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, 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.
• 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

O acesso à API deve ser tratado com o mesmo princípio que o WebAdmin ou SSH: tão restrito quanto possível, tão amplo quanto necessário.

Fontes sensatas 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 de gestão interna,
• uma rede VPN ou de administração,
• um endereço de origem de parceiro ou MSP claramente definido.

Não são sensatos:

• redes de clientes inteiras,
• redes de convidados ou IoT,
• Any,
• permissões “rede de servidores completa” pouco claras,
• endereços IP de teste temporários que são esquecidos posteriormente.

Se prestadores de serviços externos precisarem de acesso à API, a fonte deve ser definida de forma tão específica quanto possível. Além disso, deve ser documentado para que o acesso é usado e quando será removido.

Procedimento recomendado

O caminho exato da interface do usuário pode variar ligeiramente dependendo da versão do SFOS. No SFOS 22, a configuração da API está sob Administration.

Procedimento prático:

1. Verificar qual sistema precisa de acesso à API.
2. Criar um objeto IP Host claro para esse sistema.
3. Se várias fontes forem necessárias, nomear IP Hosts ou redes de forma clara.
4. Permitir acesso à API apenas para esses objetos.
5. Não inserir redes de clientes ou servidores amplas.
6. Testar o acesso com a ferramenta afetada.
7. Remover fontes que não são mais necessárias.
8. Documentar a alteração no processo de mudança.

Em instalações existentes após uma atualização para o SFOS 22, deve-se procurar por objetos com o prefixo apiconfig. Esses objetos foram gerados a partir de entradas de permissão de API mais antigas e devem ser verificados, nomeados ou limpos.

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.

MFA e usuários de API após o SFOS 22

O MFA é importante para acessos administrativos interativos. Para processos de API e automação, deve-se planejar conscientemente como a autenticação funcionará. Um script, ferramenta de monitorização ou sistema de integração não pode simplesmente inserir um código OTP se o usuário utilizado exigir MFA.

Na lista de problemas conhecidos, um caso especial do SFOS 22 está documentado: Após uma atualização, alterações de configuração baseadas em API podem falhar para usuários migrados se o MFA estiver ativo e nenhum token de uso único for fornecido. Usuários não migrados podem se comportar de maneira diferente em certos casos. Para a operação, é importante não fazer um “MFA em todo lugar” desleixado, mas separar contas de API de forma limpa.

Abordagem recomendada:

1. Usar uma conta de serviço própria para processos de API.
2. Equipar a conta apenas com os direitos necessários.
3. Restringir o acesso à API adicionalmente a IP Hosts fixos ou redes de gestão.
4. Verificar se o MFA é tecnicamente e operacionalmente viável para essa conta.
5. Se o MFA não for prático para a conta de API, controlar a conta de forma especialmente restrita através de fonte, direitos, armazenamento de segredo e trilha de auditoria.
6. Após uma atualização do SFOS 22, testar todos os processos de API com operações de leitura e escrita.

⚠️ Usuários de API sem MFA não são um passe livre para direitos amplos. Se uma conta de API for operada sem MFA por razões técnicas, a IP de origem, direitos, armazenamento de senha, responsabilidade e auditabilidade devem ser controlados de forma mais rigorosa.

Este ponto é especialmente importante em automações que não apenas leem, mas também alteram configurações. Antes de alterações de API produtivas, deve haver um backup atual do Sophos Firewall. Para alterações em massa preparadas a partir do Sophos Firewall Config Studio, deve-se verificar adicionalmente se as chamadas de API ou curl geradas funcionam com a conta planejada.

Distinção de Device Access

O controle de acesso à API não é o mesmo que Device Access. 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 o acesso à interface de gestão da API XML.

No entanto, ambos os temas fazem parte do endurecimento da gestão. Cada camada limita uma parte diferente da superfície de ataque:

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

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. A ferramenta está usando o endereço e a porta corretos da firewall?
5. Nome de usuário, senha ou segredo estão corretos?
6. A conta tem os direitos necessários?
7. A conta exige MFA, embora a ferramenta não possa fornecer um token de uso único?
8. Existem efeitos de roteamento, NAT ou proxy entre a ferramenta e a firewall?
9. O acesso foi removido intencionalmente por uma medida de endurecimento?

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.

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.
• 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