Seis decisões para escrever num contrato de acesso da nuvem ao backend

Pegue num serviço de relatórios numa conta de nuvem que precisa de resumos aprovados de um sistema interno de um cliente. Uma VPN ou uma ligação de aplicação autenticada protege o caminho e não decide mais nada. Não decide se a carga de trabalho de relatórios pode ler registos não relacionados, alterar o backend ou guardar o que obteve. Escreva o acordo de acesso em termos de operações e dados antes de escolher o conector, porque o conector é a parte mais barata de mudar depois e a mais fácil de errar primeiro.

Decida as operações antes do conector

A primeira decisão é o que a carga de trabalho pode fazer, nomeado como operações e não como intervalo de rede. No caso dos relatórios, uma API de relatórios estreita pode satisfazer a necessidade sem conceder administração de base de dados a uma carga de trabalho na nuvem.

Separe os dados de que o relatório precisa dos dados que apenas estão acessíveis. Escreva as operações permitidas como pontos finais e verbos no mesmo documento que a decisão de identidade. Essa distinção é a diferença entre uma integração que sobrevive a uma auditoria e uma que tem de ser explicada de novo todos os anos, e resolve discussões mais tarde sem outra reunião.

Decida a identidade da carga de trabalho, e dê-lhe um proprietário

Tarefas sem supervisão não podem responder a um pedido, por isso as equipas recorrem à conta ampla de uma pessoa e depois esquecem-na. Use uma conta de serviço ou uma credencial de máquina que o backend aceite de facto, e registe quem a possui, onde é guardada e como é rodada.

Três condições devem inclinar a decisão para uma identidade dedicada: a tarefa corre sem uma pessoa presente, a credencial sobrevive a uma única implementação, e mais do que uma pessoa precisa de saber que existe. Se as três forem verdadeiras, uma conta humana partilhada não é um atalho, é uma exceção permanente que ninguém consegue revogar de forma limpa.

Prefira uma credencial que a plataforma possa emitir e rodar para a carga de trabalho, como um token de identidade de carga de trabalho validado pelo backend, a um segredo estático colado na configuração. Os segredos estáticos nas definições da aplicação são a razão pela qual as rotações se tornam interrupções.

Decida o âmbito de rede, sabendo que não é permissão

Especifique que lado inicia a ligação, o transporte suportado e os pontos finais envolvidos. Mantenha as verificações de identidade do par ativas, e deixe os destinos de backend não relacionados inalcançáveis em vez de apenas não anunciados.

Uma rota de túnel estreita é um âmbito útil, mas não pode substituir a autorização ao nível da operação. O backend tem de fazer cumprir o contrato com os seus próprios controlos, porque a rede transporta de bom grado qualquer pedido que chegue a uma porta alcançável. Verifique as funções e permissões do próprio backend, não a tabela de rotas. Uma rota que chega ao servidor continua a deixar a decisão no servidor, e é aí que o contrato é aplicado ou ignorado.

O espelho também é verdadeiro: uma credencial de serviço válida não justifica publicar um ouvinte para cada origem. São necessários ambos os controlos, e nenhum substitui o outro.

Decida o tratamento dos dados e a divisão de responsabilidades

Registe o que sai do ambiente do cliente, onde a aplicação o processa, e as disposições reais de armazenamento, cópia de segurança, acesso e retenção. A retenção é a parte que se descobre tarde, normalmente quando alguém pergunta se a cópia do trimestre passado ainda existe num bucket que ninguém documentou.

Mantenha as partes distintas. O operador da aplicação, o fornecedor de software e o anfitrião de infraestrutura podem ter responsabilidades diferentes, e o modelo de serviço determina quem é quem. Leia o acordo real em vez de assumir que os três têm acesso idêntico, ou nenhum.

Decida a falha, a remoção e como a aceitará

Atribua responsabilidade pelos casos de falha antes de acontecerem. Quando o conector se estraga ou se suspeita que uma identidade foi comprometida, a resposta não deve ser uma exceção de rede ilimitada improvisada que sobreviva ao incidente.

A remoção merece a mesma precisão da instalação. Defina como a autorização é revogada, como o acesso ativo termina no comportamento suportado do produto, e o que acontece às cópias retidas quando a relação termina.

Aceite a integração com operações permitidas representativas e as recusas que o contrato exige, tudo sob a identidade de carga de trabalho prevista. Confirme o caminho do pedido e os dados realmente entregues, e depois exercite a substituição de credenciais e a remoção a sério. Um túnel ligado prova que existe um caminho; o contrato é o que dá um limite a esse caminho.