Fail-closed
Decisão de arquitetura: se o controle de segurança fica indisponível, a requisição é barrada em vez de passar sem inspeção. O default protege o dado, não a conveniência.
Por que importa
Fail-closed é a decisão de, diante de uma falha no controle de segurança, barrar a requisição em vez de deixá-la passar. Importa porque todo controle encara a mesma pergunta no pior momento — o que acontece quando a verificação não consegue rodar? — e há só duas respostas opostas. Falhar aberto é deixar a chamada seguir quando o detector está fora do ar; falhar fechado é bloqueá-la quando não dá para verificar. A escolha define se o controle protege de verdade ou só quando convém.
O detalhe traiçoeiro é que falhar aberto parece inofensivo, porque a falha é rara e silenciosa. Mas é justamente no instante da falha que o dado sensível escapa sem ninguém ver. Um controle que falha aberto oferece proteção apenas enquanto tudo funciona — ou seja, deixa de proteger exatamente quando seria preciso. Na prática, não é proteção, é uma falsa sensação dela.
Como funciona
O comportamento na falha tem que acompanhar a intenção da política. Se a organização declarou que determinado dado não pode sair sem checagem, essa regra precisa valer inclusive quando a verificação está indisponível. Numa arquitetura fail-closed, a indisponibilidade do detector resulta em bloqueio: a chamada é recusada, não liberada. O pior resultado possível passa a ser uma requisição barrada que pode ser repetida — em vez de um vazamento silencioso e irreversível.
Tecnicamente, isso costuma se traduzir em timeouts curtos e respostas explícitas: se a camada de inspeção não responde a tempo, o caminho padrão é negar. O default é a parte que mais importa, porque é o que vale quando algo dá errado e ninguém está olhando. Fail-closed coloca a proteção do dado como default, e a conveniência como exceção que precisa ser conscientemente escolhida.
Como a Horse Labs trata
Na Horse Labs, o guardrail de DLP é fail-closed: com a camada de PII em Block e o Presidio inalcançável, a chamada é bloqueada, não liberada. O dado sensível não sai sem checagem nem durante uma falha. A escolha é deliberada — o pior caso é uma requisição recusada que dá para repetir, jamais um dado que vazou e não volta.
Nuance
Fail-closed não é a resposta certa para tudo, e é importante dizê-lo. Em sistemas onde a disponibilidade é o bem mais crítico, falhar fechado pode ser pior que o risco que evita. A decisão é sempre sobre o que se está protegendo: quando o ativo é dado sensível que não pode escapar, fail-closed é a postura correta, porque um vazamento é irreversível e uma chamada barrada não. O erro é adotar o default sem decidir — herdar fail-open por inércia e descobrir, tarde demais, que o controle cedeu na primeira pressão.