Como importar envios de formulários públicos para uma rede privada

Acompanhe um envio de formulário público desde o registro de entrada até o importador privado e mantenha a validação, as credenciais e o tratamento de novas tentativas do lado certo.

Um formulário público que nunca fala com a rede privada ainda produz dados que a rede privada precisa julgar. O túnel só muda quem disca para quem. Tudo depois do download é uma decisão de importação, e ela pertence ao lado privado. Este guia acompanha um envio do navegador até um registro interno consolidado.

Comece onde o envio chega

O navegador envia para um endpoint público, que grava uma linha em um armazenamento de entrada controlado e devolve nada além de uma confirmação. Esse armazenamento é o ponto de entrega e deve ser a única coisa em que a camada pública pode gravar. Mantenha o conteúdo bruto ali sem alteração, junto com o horário de chegada e um identificador de registro estável.

Depois, um trabalhador privado puxa as linhas pendentes pelo túnel e decide o que fazer com cada uma. Ele roda sob a própria identidade, e esse é o assunto da próxima seção.

curl --silent --fail \
  --cert /etc/importer/client.crt --key /etc/importer/client.key \
  "https://intake.corp.internal/api/pending?limit=20" \
  -o /var/lib/importer/pending.json

Dê ao importador apenas a autoridade de que ele precisa

O processo web público e a identidade que grava na aplicação interna devem ser dois principais diferentes. Um servidor público não precisa de administração interna só porque tem de entregar dados de formulário, e uma conta compartilhada para os dois lados transforma qualquer falha web em gravação interna. Emita credenciais próprias para o trabalhador, limite-as à única operação de importação e registre qual principal executou cada importação. É essa separação que torna a fronteira do túnel significativa em vez de decorativa.

Restrinja também de qual origem o trabalhador pode ler. Se a implementação usa uma fila ou um serviço de transferência, esse serviço mantém a própria autenticação e política de acesso, porque a VPN não autentica nada dentro do conteúdo.

Uma função de curta duração não está isenta da mesma revisão. Enquanto roda, sua posição na rede e suas credenciais ainda concedem autoridade, e uma vida útil menor apenas estreita a janela. A vida útil não substitui a decisão sobre quais operações a identidade pode executar.

Valide antes que algo interno mude

Campos de formulário público são texto controlado pelo atacante até que se prove o contrário, e as orientações da OWASP sobre validação de entrada incluem os fluxos de backend entre as origens não confiáveis exatamente por isso. Uma transferência criptografada diz que os bytes chegaram intactos, não que descrevem uma requisição permitida. Faça o parsing e a validação antes de qualquer etapa privilegiada, para que uma linha ruim nunca chegue a um caminho de código capaz de agir.

Defina os campos permitidos, seus formatos, seus tamanhos e as regras de negócio que precisam valer. Uma data pode estar bem formada e ainda assim errada para a operação pedida, e um conteúdo que nomeia uma conta interna ou um status de aprovação não pode conseguir conceder nenhum dos dois a si mesmo.

Envie as linhas rejeitadas para um resultado de revisão em vez de adivinhar uma correção ou encaminhá-las para um shell ou uma interface crua de banco de dados. Registre o identificador do registro e a regra que falhou, não cada campo que o solicitante digitou.

Crie um ponto de nova tentativa em uma operação

Se o registro submission-1042 for puxado duas vezes porque a primeira confirmação se perdeu, o trabalhador precisa de uma forma durável de reconhecer o registro de origem e seu resultado consolidado. Um agendamento que roda a tarefa uma vez não estabelece que cada linha foi aplicada uma vez. A entrega duplicada é normal, então o projeto precisa absorvê-la.

Use a transação e o mecanismo de tratamento de duplicatas da própria aplicação interna, e mantenha o identificador de origem, o resultado e a confirmação em uma sequência coerente. Confirme somente depois que a operação pretendida estiver consolidada ou atribuída de forma durável, e nunca apague a linha de entrada só porque os bytes foram baixados.

Depois prove isso com três fixtures: uma linha válida, uma linha malformada e o mesmo identificador de origem controlado entregue duas vezes. Cada uma passa pelo mesmo endpoint que o trabalhador usa.

for f in fixtures/valid-submission.json fixtures/bad-date.json; do
  curl --silent --fail --cert /etc/importer/client.crt \
    -X POST --data @"$f" https://intake.corp.internal/api/records
done
curl --silent --fail --cert /etc/importer/client.crt \
  -X POST --data @fixtures/valid-submission.json https://intake.corp.internal/api/records

As duas primeiras linhas devem terminar em estados internos diferentes, e a terceira deve devolver o identificador já consolidado para aquele registro de origem em vez de criar um segundo. Qualquer outra coisa significa que a importação ainda não é repetível.

Artigos relacionados