Quais partes de uma aplicação auto-hospedada precisam de acesso à Internet? Uma checklist de mapeamento de exposição

Porque “acessível publicamente” não é um requisito completo de implementação

“A aplicação precisa ser pública” pode significar várias coisas muito diferentes. Pode significar que qualquer pessoa deve poder carregar um website, que apenas colaboradores identificados devem poder iniciar sessão a partir de qualquer lugar, que um sistema parceiro tem de entregar webhooks ou que a aplicação apenas precisa de chamar uma API externa. Estes requisitos resultam em decisões diferentes sobre a exposição de rede.

Trate a acessibilidade de entrada e a conectividade de saída como decisões separadas. Nas redes Docker, um contentor pode efetuar ligações de saída quando o respetivo anfitrião tem acesso à Internet, enquanto uma porta de contentor normalmente não é acessível fora do anfitrião, a menos que seja deliberadamente publicada ou encaminhada. Assim, uma aplicação pode precisar de acesso à Internet sem precisar de uma porta de aplicação publicamente acessível.

O objetivo não é tornar todos os componentes privados ou todos os componentes públicos. O objetivo é autorizar explicitamente cada fluxo de dados, expor apenas os pontos de entrada necessários e registar a razão de existir de cada um. Isto está alinhado com o resultado do NIST Cybersecurity Framework 2.0 relativo à manutenção de representações das comunicações e fluxos de dados internos e externos autorizados.

• Substitua “público” por uma declaração específica: quem se liga, de onde, a que nome de anfitrião, através de que protocolo e para que finalidade.
• Separe o acesso por navegador, pedidos de entrada máquina a máquina, chamadas de saída e acesso de administrador.
• Decida se cada fluxo ocorre pela Internet pública, é limitado a endereços IP conhecidos, é exclusivo de rede privada ou não é permitido.
• Registe os dados trocados em cada fluxo, sobretudo credenciais, dados pessoais, registos de clientes, ficheiros e tokens de API.

Comece por um mapa de exposição: utilizadores, administradores, integrações e serviços de suporte

Um mapa de exposição é um inventário prático dos caminhos de comunicação permitidos da aplicação. Crie-o antes de escolher domínios, abrir regras de firewall ou publicar portas de contentores. Deve abranger mais do que o ecrã principal da aplicação: serviços de suporte, ferramentas administrativas, sistemas de identidade, fornecedores de e-mail e destinos de monitorização também podem criar dependências de rede.

Comece por listar ativos e intervenientes. O NIST CSF 2.0 considera software, serviços, sistemas, dados e serviços de fornecedores como ativos que devem ser identificados e geridos. Numa implementação auto-hospedada, isto significa documentar tanto os seus próprios componentes como os serviços externos que contactam.

Depois, desenhe setas direcionais. Cada seta deve ter um responsável e uma decisão: permitido, restrito, apenas privado ou rejeitado. Isto torna visíveis antecipadamente pressupostos ocultos — por exemplo, um fluxo de automação que precisa de receber um webhook de um fornecedor ou um painel interno que se assumia estar acessível a partir de todas as redes dos colaboradores.

• Utilizadores: visitantes públicos, clientes, colaboradores, prestadores, utilizadores móveis e contas de serviço.
• Administradores: administradores da aplicação, administradores de infraestrutura e pessoal de suporte.
• Integrações de entrada: webhooks, clientes de API, callbacks de fornecedores de identidade e sistemas parceiros.
• Integrações de saída: entrega de e-mail, fornecedores de identidade, APIs externas, transferências de software, transferências de modelos e destinos de monitorização.
• Serviços de suporte: bases de dados, caches, filas, armazenamento de objetos, serviços de pesquisa, proxies reversos e painéis administrativos.
• Para cada fluxo, registe origem, destino, protocolo e porta, nome de anfitrião, direção, método de autenticação, classificação dos dados, responsável e justificação de negócio.

Classifique o acesso de entrada: interface web pública, utilizadores autenticados, endpoints de parceiros e recetores de webhooks

O acesso de entrada é aquilo que a maioria das equipas entende por exposição, mas deve ser dividido em classes distintas. Uma interface pública de marketing ou publicação tem um perfil de risco diferente de uma aplicação apenas para colaboradores. Um recetor de webhooks pode precisar de aceitar pedidos de um sistema externo, mesmo quando nenhuma interface direcionada a pessoas deve estar amplamente disponível.

Utilize o proxy reverso como ponto de entrada de entrada intencional. No modelo do Traefik, os pontos de entrada recebem tráfego TCP ou UDP, os routers correspondem aos pedidos recebidos e os serviços recebem o tráfego de backend encaminhado. Isto permite um desenho em que o proxy aceita apenas tráfego aprovado, enquanto os contentores da aplicação permanecem atrás dele.

Quando um endpoint é usado apenas por partes conhecidas, documente se uma regra baseada em IP é adequada além da autenticação ao nível da aplicação. O Traefik disponibiliza um mecanismo de lista de permissões de IP que aceita ou recusa pedidos antes de chegarem a um backend. Isto pode reduzir a exposição desnecessária, mas depende de endereços de origem estáveis e corretamente identificados e não deve ser tratado como substituto de uma autenticação adequada.

• Interface web pública: destinada a visitantes não autenticados; exponha apenas as rotas web e o nome de anfitrião necessários.
• Acesso de utilizadores autenticados: destinado a clientes ou colaboradores; defina requisitos de identidade, início de sessão, sessão e acesso no desenho da aplicação.
• Endpoint de API de parceiro: defina o parceiro, o método de autenticação, a rede de origem esperada, as expectativas de taxa e as rotas exatas.
• Recetor de webhook: defina o remetente, a validação de assinatura ou autenticação, a rota, os dados de payload esperados e o tratamento de falhas.
• Interface administrativa: classifique-a separadamente da aplicação principal; não presuma que pertence ao nome de anfitrião público.
• Rejeite a exposição genérica: uma porta ou nome de anfitrião acessível externamente deve ter uma finalidade e um responsável identificados.

Identifique dependências de saída antes de presumir que a aplicação pode funcionar de forma privada

O acesso privado de entrada não significa que uma aplicação não tenha dependências da Internet. Muitas cargas de trabalho empresariais, de automação e de IA precisam de iniciar ligações a serviços externos ao anfitrião. Estes podem incluir serviços de entrega de e-mail, fornecedores de identidade, APIs de terceiros, fontes de pacotes, transferências de modelos ou destinos de monitorização.

Para cada dependência, determine se é necessária na instalação, no arranque, segundo uma agenda ou durante a atividade normal dos utilizadores. Esta distinção é importante em ambientes restritos. Uma transferência única de software ou modelo pode ser tratada de forma diferente de uma ligação permanente a um fornecedor de identidade ou a uma API empresarial externa.

Não descreva o acesso de saída como uma única permissão genérica. Identifique o nome de anfitrião ou serviço de destino, o protocolo, a finalidade operacional, os dados enviados e recebidos, a credencial utilizada e o comportamento alternativo quando o destino não está disponível. Consulte a documentação oficial da aplicação e integração específicas, pois as dependências variam conforme o produto e a configuração.

• Entrega de e-mail: identifique o fornecedor, o método de ligação, a identidade do remetente e se a aplicação precisa de enviar reposições de palavra-passe, notificações ou mensagens de fluxo de trabalho.
• Fornecedor de identidade: identifique os endpoints de autenticação, endpoints de token, detalhes do emissor e se o início de sessão deixa de funcionar quando o fornecedor não pode ser alcançado.
• APIs externas: liste cada fornecedor separadamente, os dados trocados, a abordagem de armazenamento de credenciais e se as chamadas são acionadas por utilizadores ou automatizadas.
• Transferências de pacotes, plugins ou modelos: determine se o acesso à Internet é necessário apenas durante a configuração ou atualizações, ou regularmente durante a execução.
• Monitorização e relatórios de erros: determine que dados de telemetria ou eventos saem do ambiente e quem aprova essa transferência.
• Verificações de atualizações e chamadas relacionadas com licenças: confirme-as diretamente na documentação oficial do fornecedor, em vez de presumir que são necessárias ou inexistentes.

Mantenha os serviços de dados privados por predefinição

Uma base de dados, cache, fila, armazenamento de objetos ou serviço de pesquisa é normalmente um componente de suporte, não um produto voltado para a Internet. Comece pelo acesso exclusivamente privado e adicione uma rota apenas quando houver uma razão operacional documentada. Numa configuração Docker bridge, os serviços ligados ao anfitrião ou à mesma rede podem comunicar conforme configurado, enquanto as portas dos contentores não são acessíveis fora do anfitrião por predefinição, salvo se forem publicadas ou encaminhadas deliberadamente.

Tenha especial cuidado com a publicação por conveniência. O Docker documenta que publicar uma porta sem especificar um endereço de anfitrião faz a associação a todos os endereços do anfitrião por predefinição, o que pode tornar o serviço acessível externamente. Se um serviço se destina apenas ao anfitrião local no cenário documentado de modo NAT, associá-lo ao loopback é uma forma de impedir que anfitriões remotos acedam a essa porta publicada.

Os planos de controlo administrativos merecem o mesmo tratamento de privado por predefinição. O Traefik alerta que a sua API e painel em produção podem expor elementos de configuração, incluindo dados sensíveis, e recomenda restringir a sua porta de API a redes internas. Aplique este princípio também a interfaces de administração de aplicações, interfaces de gestão de contentores e ferramentas de observabilidade.

• Bases de dados: permita o acesso apenas a componentes da aplicação e a percursos de manutenção aprovados.
• Caches e filas: mantenha-as em redes privadas; não as exponha apenas para simplificar a resolução de problemas.
• Armazenamento de objetos e serviços internos de ficheiros: defina quais os componentes da aplicação que necessitam de acesso e como as cópias de segurança interagem com eles.
• Serviços de pesquisa, vetores e suporte de IA: documente se são backends internos ou APIs deliberadas para outros sistemas.
• Painéis de proxy, painéis de administração da aplicação e planos de controlo de infraestrutura: utilize percursos de acesso separados e restritos.
• Antes do lançamento, reveja todas as portas publicadas e confirme a associação ao anfitrião, os clientes pretendidos e o responsável.

Verifique casos comuns que alteram o desenho de acesso

Vários detalhes de implementação são fáceis de descobrir demasiado tarde, depois de já se ter escolhido um nome de anfitrião ou uma política de firewall. Trate-os antecipadamente, pois podem determinar se é necessário um nome de anfitrião público, um caminho de callback estável ou uma origem de rede específica.

O OAuth é um exemplo fundamental. Os URLs de redirecionamento e callback são requisitos de implementação, não definições meramente estéticas. A RFC 9700 exige que os servidores de autorização utilizem correspondência exata de cadeias com URIs de redirecionamento pré-registados, exceto no tratamento localhost especificado para aplicações nativas. Por isso, uma alteração de esquema, nome de anfitrião, caminho ou barra final pode interromper o início de sessão.

Proteja também o próprio caminho de callback. A RFC 9700 alerta que endpoints de URI de redirecionamento não devem atuar como redirecionadores abertos. Também identifica um risco quando páginas que processam respostas OAuth têm ligações para páginas controladas por atacantes ou carregam conteúdo de terceiros que poderia divulgar o URL da resposta de autorização através do cabeçalho Referer. Mantenha o tratamento de callbacks intencionalmente limitado e evite conteúdo de terceiros incorporado desnecessário nessa página.

• OAuth e SSO: confirme o URL externo exato, protocolo, nome de anfitrião e caminho de callback que têm de ser registados no fornecedor de identidade.
• Conteúdo incorporado: identifique iframes, scripts, imagens ou widgets que se ligam a terceiros, sobretudo em páginas de resposta de autenticação.
• Clientes móveis e de desktop: confirme se necessitam de um endpoint público, um nome de anfitrião fixo, tratamento localhost ou um percurso de rede privada.
• Listas de permissões de IP: valide os endereços de origem reais após considerar intermediários, NAT, redes de distribuição de conteúdos ou infraestrutura de parceiros.
• E-mail de entrada ou transferências de ficheiros: determine se são entregues diretamente à aplicação ou obtidos por saída a partir de outro serviço.
• WebSockets, streaming e ligações de longa duração: verifique os requisitos do proxy e da aplicação na documentação oficial em vez de presumir que as predefinições normais de HTTP são suficientes.

Questões a verificar na documentação oficial da aplicação antes da implementação

A documentação da aplicação é a autoridade para requisitos específicos do produto. Não deduza que uma aplicação suporta uma implementação privada, um comportamento específico de proxy, um fornecedor de SSO ou um padrão de webhook apenas porque outra aplicação o suporta. Confirme os requisitos na documentação oficial da versão e configuração que planeia utilizar.

As respostas devem ser registadas no mapa de exposição e revistas quando as integrações mudarem. Se a documentação deixar uma questão por resolver, trate-a como um risco de implementação em vez de preencher a lacuna com uma suposição.

Esta verificação é especialmente importante para aplicações que combinam uma interface web com workers em segundo plano, motores de automação, serviços de modelos de IA ou vários contentores de suporte. A interface visível no navegador é frequentemente apenas uma parte do desenho operacional.

• Que portas e protocolos de entrada são necessários, se algum, e que componente termina TLS?
• A aplicação pode funcionar atrás de um proxy reverso e requer definições de proxy fidedigno ou URL externo?
• Que URL canónico ou URL base a aplicação exige?
• Que rotas devem receber webhooks, callbacks OAuth, asserções SSO ou pedidos de API de parceiros?
• Que nomes de anfitrião de saída ou categorias de serviço são necessários para funcionamento normal, configuração, atualizações, e-mail, identidade, monitorização ou integrações opcionais?
• Que serviços de dados são necessários e as respetivas portas devem permanecer privadas?
• São necessários processos ou contentores de worker separados e a que precisam de chegar?
• Que dados de cópia de segurança, localizações de armazenamento e passos de restauro são necessários? A Airbip disponibiliza cópias de segurança diárias, semanais e mensais configuráveis, mas o responsável pela aplicação ainda precisa de decidir que dados estão no âmbito e testar procedimentos de restauro adequados ao seu ambiente.

Integre domínios, TLS e proxies reversos no desenho sem expor serviços desnecessários

Escolha os domínios depois de identificar os pontos de entrada pretendidos. Um nome de anfitrião deve representar uma finalidade de acesso deliberada, como uma aplicação voltada para utilizadores, um endpoint de webhook de âmbito limitado ou um caminho administrativo com restrições adicionais. Evite criar nomes DNS públicos para serviços internos apenas por serem convenientes de memorizar.

A validação de certificados TLS também faz parte do desenho de exposição. Com a validação HTTP-01 do Let’s Encrypt, a autoridade de certificação obtém um ficheiro de desafio no nome de anfitrião, e o desafio HTTP-01 está limitado à porta 80. Isto pode ser adequado para um endpoint web público, mas é um requisito concreto de acessibilidade que deve ser planeado. A validação DNS-01 do Let’s Encrypt pode validar nomes cujos servidores web não estão expostos à Internet pública, pois a validação ocorre através de um registo DNS TXT.

Um proxy reverso permite a uma equipa tornar o proxy — e não cada componente da aplicação — na extremidade pública selecionada. Pode encaminhar nomes de anfitrião e caminhos aprovados para serviços de backend, enquanto as portas de backend permanecem privadas. Isto não torna automaticamente uma arquitetura segura; a equipa continua a precisar de configuração correta da aplicação, controlos de acesso, propriedade de DNS, renovação de certificados e controlo de alterações.

A Airbip implementa aplicações de catálogo como cargas de trabalho Docker em servidores cloud da Airbip e automatiza o encaminhamento e os certificados TLS através de Traefik e Let’s Encrypt. Os clientes podem usar um subdomínio Airbip ou um domínio personalizado compatível. Estas capacidades são úteis quando o desenho documentado exige um endpoint público de aplicação gerido, mas não eliminam a necessidade de decidir quais as rotas e fluxos de dados aprovados.

• Atribua um responsável a cada zona DNS e nome de anfitrião.
• Documente se a validação de certificados utiliza um caminho HTTP público ou validação DNS, com base no desenho de acesso.
• Exponha os pontos de entrada do proxy reverso necessários pelos serviços públicos aprovados; mantenha privadas as portas dos serviços de backend.
• Utilize nomes de anfitrião separados ou rotas cuidadosamente limitadas quando as funções públicas e restritas não puderem ser separadas de forma clara dentro da aplicação.
• Teste o resultado visível externamente a partir de fora da rede do servidor, não apenas a partir do próprio anfitrião.
• Reveja as responsabilidades pela renovação de certificados e alterações de DNS como parte da responsabilidade operacional.