Proteger para habilitar: como integrar segurança e negócio

Ao longo da minha carreira, vi o mesmo padrão se repetir muitas vezes: para muitas pessoas que tomam decisões de negócio ou operacionais, a segurança aparece como um problema, um freio, algo que “complica”, “demora” ou “encarece”. Não como um habilitador, não como parte do design, mas como uma camada incômoda imposta de fora. E a verdade é que, em muitos casos, elas não estão totalmente erradas.

O erro não está tanto no fato de o negócio perceber a segurança como um obstáculo, mas sim em assumir que isso é inevitável. Daí nasce um mito: a ideia de que segurança e negócio são forças opostas, condenadas a nunca se entenderem. Como se melhorar uma implicasse necessariamente em piorar a outra.

E esse é um relato confortável. Para o negócio, porque permite culpar “o pessoal da segurança” quando algo não avança. Para a segurança, porque justifica controles rígidos sob o argumento de “eu apenas cuido do risco” e das fraquezas que possam perceber em “o negócio não acompanha”. Todos ficam relativamente tranquilos… e o sistema continua sendo ruim.

Essa abordagem colide de frente com uma ideia que a Intel formalizou anos atrás sob o lema “Protect to Enable”: a segurança não existe para dizer não, mas para permitir que o negócio avance de forma segura. Em relação ao que se vê comumente, isso supõe uma mudança completa de mentalidade. Proteger não é o objetivo final; o objetivo final é habilitar.

Sobre a implementação dessa ideia na Intel, existe o livro «Managing Risk and Information Security: Protect to Enable» de Malcolm Harkins, ex-Vice-Presidente de Segurança e Gestão de Riscos de Informação na Intel.

Quando essa filosofia é ignorada, a segurança é projetada de forma abstrata: como uma coleção de controles a serem impostos, desconectados de como as pessoas trabalham. É aí que aparecem as VPNs para tudo, os bloqueios na dúvida, os acessos que levam semanas, as exceções manuais, os processos opacos. Não é segurança sólida: é segurança desajeitada, controles incapazes de conviver com a operação real.

O negócio, por sua vez, raramente expressa isso em termos técnicos. Não diz “este controle não mitiga bem o risco” ou “isso introduz mais superfície de ataque indireta”. Diz algo muito mais brutal e honesto sob sua percepção: “assim não consigo trabalhar”. E quando trabalhar se torna difícil, as pessoas não param para debater modelos de ameaças: elas buscam atalhos.

Neste ponto é onde a fricção se torna perigrosa. Quando a segurança freia o negócio, o risco não desaparece. Ele apenas se desloca, chegando a se tornar invisível. Aí aparece o «shadow IT», os acessos compartilhados, os fluxos paralelos, as soluções “temporárias” que duram anos. O negócio continua avançando, mas fora do radar da segurança.

A filosofia de Protect to Enable visa justamente quebrar esse círculo vicioso: projetar controles que acompanhem o fluxo do negócio em vez de lutar contra ele. Controles que façam com que fazer o que é certo seja mais fácil do que evadi-los. Porque se a única forma de avançar é burlar a segurança, o sistema já falhou, mesmo que todos os checks do framework normativo estejam verdes. O problema não é “segurança vs negócio”. O problema é segurança projetada sem entender o negócio. É confundir rigor com rigidez. E quebrar esse mito é o primeiro passo para aceitar que a segurança não compete com o negócio, mas compete com a fricção desnecessária.

Quando a segurança é projetada a partir do medo

Boa parte dos controles de segurança que vemos em organizações que sofrem com o que foi mencionado anteriormente não nasce de uma análise de risco séria, mas de algo muito mais primitivo: o medo. Medo de um incidente recente ou futuro, de uma auditoria que se aproxima — ou, pior ainda — de ficar exposto perante a hierarquia.

Os exemplos são conhecidos. Após um ransomware, bloqueia-se tudo “até segunda ordem”. Depois de um phishing bem-sucedido, adicionam-se camadas de fricção ao acesso e mais filtros no e-mail e na navegação. Quando chega uma auditoria, aparecem controles de última hora que não são muito bem compreendidos. Não há redesenho, nem revisão sistêmica: há reação.

Esse tipo de decisão tem uma lógica emocional muito clara. O cérebro humano não foi feito para lidar bem com riscos abstratos e de baixa frequência. A « Heurística da disponibilidade   » explica que as pessoas estimam a probabilidade de um evento de acordo com a facilidade com que conseguem lembrar de exemplos semelhantes. Portanto, um incidente concreto, visível e recente tem mais peso do que cem ameaças bem modeladas. É o viés de disponibilidade em ação: o que acabou de acontecer parece mais provável, mais perigoso e/ou mais urgente, embora estatisticamente não seja.

A isso soma-se outro fator-chave: a aversão à culpa. Em muitas organizações, a segurança não é medida por sua eficácia, mas por sua capacidade de demonstrar que “algo foi feito”. Adicionar um controle visível reduz a ansiedade interna: se algo voltar a acontecer, pelo menos pode-se dizer que a postura foi endurecida. Nesse contexto, o controle não precisa ser bom, ele precisa ser defensável.

Assim surgem decisões como forçar trocas massivas de senhas, bloquear acessos legítimos, impor processos manuais intermináveis ou exigir aprovações absurdas. São controles que tranquilizam quem os assina, mas não quem os utiliza.

O problema é que a segurança projetada a partir do medo tende a ser cumulativa e assimétrica. Cada incidente adiciona uma camada, mas quase nunca as anteriores são revisadas. O sistema torna-se mais pesado, mais frágil e mais difícil de operar. Ninguém se pergunta quais controles continuam sendo relevantes, apenas se adiciona mais um “por via das dúvidas”.

Do ponto de vista psicológico, isso é compreensível: o medo empurra para a maximização da sensação de controle imediato, mesmo que isso piore o resultado a longo prazo. Mas esse reflexo gera fricção, erros humanos e, paradoxalmente, mais risco operacional.

O negócio, por sua vez, reage como pode, adapta-se. Surgem os atalhos, as exceções informais, as credenciais compartilhadas, os processos paralelos, as ferramentas não aprovadas. A segurança, então, ao tornar-se impraticável, deixa de fazer parte do sistema real e passa a ser algo quase decorativo.

Projetar segurança a partir do medo não é um erro intelectual, é uma falha humana. E reconhecê-lo é fundamental, porque enquanto as decisões forem tomadas para acalmar ansiedades em vez de reduzir o risco real, o abismo entre segurança e operação só irá crescer.

Fricção operacional: o custo invisível

A fricção operacional é um efeito colateral subestimado da segurança mal projetada. Ela não aparece nos relatórios de auditoria, geralmente não possui um KPI próprio e é difícil de mensurar, mas está lá, roubando tempo, atenção e energia todos os dias. Cada etapa extra para acessar um sistema, cada aprovação manual, cada workaround improvisado é tempo de trabalho perdido. Um tempo que se esvai gota a gota e que, às vezes, é difícil de perceber, porque a organização não para, mas torna-se mais lenta e mais propensa ao erro.

Um exemplo que vi pessoalmente: acessos a sistemas que exigem o uso de VPN mesmo quando o serviço já está na nuvem, com a possibilidade de implementar autenticação forte e controles de identidade adequados. O resultado disso não é mais segurança, mas sim sessões instáveis, quedas e reconexões, o custo de manter um servidor VPN, e usuários que acabam deixando a VPN aberta o dia todo “por via das dúvidas”. O controle existe, mas seu uso real degrada o sistema.

Outro caso frequente: processos de concessão ou alteração de permissões que levam dias. Do ponto de vista da segurança, é “controle de acesso”. Do ponto de vista operacional é um bloqueio. Nesses casos, o negócio não espera: compartilha credenciais, reutiliza contas ou pede favores. A fricção não elimina o acesso indevido, mas o empurra para a informalidade.

Toda essa fricção também tem um efeito psicológico importante e contraproducente: se interagir com a segurança é constantemente frustrante, as pessoas deixam de vê-la como parte do sistema e a percebem como um obstáculo externo. O usuário não pensa “isso me protege”, ele pensa “isso me faz perder tempo”. A partir daí, qualquer controle é vivenciado como algo a ser evitado.

Paradoxalmente, muitos desses controles que foram pensados para reduzir o erro humano acabam aumentando a probabilidade de erro, porque forçam o trabalho sob estresse, com atalhos e sem clareza. A segurança, então, acaba criando as condições ideais para os mesmos incidentes que pretende evitar.

Há também um custo menos visível, porém mais profundo: o desgaste. Equipes cansadas de lutar com ferramentas, processos que ninguém entende e exceções que se tornam regra.

E o mais irônico: por fora, tudo parece funcionar. Os controles estão lá, as políticas existem, os acessos estão “gerenciados”. Já vi organizações passarem em auditorias assim. Mas o sistema real, aquele que as pessoas usam para trabalhar, opera em paralelo. Quando se chega a esse ponto, não importa quantos controles existam. O custo operacional supera qualquer benefício teórico, e o risco real aumenta, não mais por falta de controles, mas por excesso de fricção.

Shadow IT: o sintoma visível

Devido à fricção operacional, costuma surgir o «Shadow IT». Com este termo, descrevemos o conjunto de ferramentas, serviços e processos que o negócio adota fora dos canais formais de TI e segurança.

O Shadow IT não aparece porque as pessoas são irresponsáveis ou “não entendem de segurança”. Ele surge quando os caminhos oficiais se mostram lentos, rígidos ou diretamente impraticáveis. É uma resposta adaptativa: o negócio não tem o objetivo de violar políticas, mas sim de cumprir metas. Quando o acesso a uma ferramenta demora semanas ou meses, quando compartilhar informações de forma segura é mais difícil do que enviá-las por qualquer SaaS gratuito, ou quando solicitar uma permissão implica em paralisar um projeto, o caminho informal torna-se o mais lógico. Em geral, eu diria que não é uma decisão reflexiva, mas pura eficiência humana.

A segurança tradicionalmente interpreta o Shadow IT como um problema de disciplina. Portanto, a resposta típica é endurecer os controles, bloquear serviços e emitir políticas mais rigorosas. Dito de outra forma: atacar o sintoma com mais fricção, justamente o mecanismo que gerou o problema em primeiro lugar. Mas, se olharmos do ponto de vista da psicologia, o Shadow IT é coerente. As pessoas otimizam para realizar seu trabalho com o menor custo cognitivo possível. Se o caminho “seguro” é longo ou frustrante, o cérebro escolherá o atalho. Nisso, como em tantas outras coisas, é importante levar em conta o comportamento humano para projetar sistemas considerando-o, e não contra ele.

O interessante em tudo isso é que a existência do Shadow IT não elimina a necessidade de segurança, mas a desloca para fora do radar. As ferramentas não aprovadas continuam manipulando dados sensíveis, as contas compartilhadas continuam existindo e os fluxos paralelos continuam operando. Mas agora ninguém os vê, ninguém os monitora e ninguém os melhora.

Em organizações maduras, o Shadow IT é tratado como um sinal. Um alerta de que os controles não estão alinhados com a realidade operacional. Não se pergunta “por que as pessoas descumprem as regras?”, mas sim “o que estamos impedindo que elas façam de forma segura?”. Aí surge uma oportunidade fundamental: muitas vezes o Shadow IT revela necessidades reais do negócio antes dos processos formais. Ignorá-lo ou simplesmente proibi-lo é desperdiçar informações valiosas.

Voltando à filosofia de Protect to Enable: se você projeta controles que habilitam o trabalho, o Shadow IT perde o sentido. Não porque seja proibido especificamente, mas porque deixa de ser necessário. O caminho oficial torna-se mais curto, mais confiável e mais seguro do que o atalho.

Mesmo quando a segurança funciona bem, é esperado que o Shadow IT não desapareça totalmente, mas que se reduza a casos pontuais e, fundamentalmente, visíveis. Quando a segurança funciona mal, o Shadow IT se converte na infraestrutura real da organização, e a “oficial” em uma fachada vazia. Observar isso é um indicador valioso: se você tem muito Shadow IT, você não tem um problema de usuários, você tem um problema de design.

Modelagem de ameaças

Depois de ver como a fricção operacional e o Shadow IT aparecem quando a segurança é projetada sem contexto, surge uma pergunta inevitável: como modelar a segurança para que isso não ocorra? A resposta não está em mais controles, mas em melhores decisões. É aí que entra uma modelagem de ameaças bem feita. Um modelo de ameaças não deve ser um documento apenas para conformidade nem uma planilha para auditoria. É uma ferramenta para pensar antes de controlar. Para decidir o que proteger, de quem, como e com qual custo. E também, o que não proteger da mesma forma.

O primeiro passo mental é aceitar que nem tudo tem o mesmo valor nem o mesmo risco. Parece óbvio, mas muitas arquiteturas de segurança são projetadas como se todos os sistemas fossem igualmente críticos e todos os acessos igualmente perigosos. Isso leva diretamente a controles uniformes, rígidos e, em muitas ocasiões, caros.

Uma boa modelagem de ameaças começa pelo entendimento do negócio, não pela tecnologia. Quais processos geram valor? Quais dados, se comprometidos, realmente doem? Quais interrupções são toleráveis e quais não são? Sem essas respostas, qualquer controle é um tiro no escuro. O ideal é ter um bom inventário de ativos de informação como base para modelar as ameaças.

O segundo passo é identificar ameaças realistas, não imaginárias. Não se trata de pensar em atacantes onipotentes, mas sim priorizar adversários plausíveis considerando a indústria, o contexto e a exposição real. Quando o modelo de ameaças exagera o adversário, os controles reagem de forma desproporcional. E a sobrerreação quase sempre resulta em fricção operacional. É fundamental avaliar probabilidade e impacto sem dramatismo. Nem todo acesso externo é uma catástrofe. Nem todo erro humano termina em desastre. A segurança madura aceita a incerteza e trabalha com ela, em vez de tentar eliminá-la à força através da fricção.

Um terceiro ponto-chave é entender onde convém colocar o controle. A modelagem de ameaças permite escolher pontos de controle que reduzam o risco sem interferir — ou com interferência mínima — na operação. Falo de decisões como proteger a identidade em vez da rede, usar automação em vez de aprovações manuais, ou priorizar visibilidade e alertas acionáveis antes de restrições rígidas. Por exemplo: se a ameaça principal é o roubo de credenciais, impor VPNs e restrições de rede pode ser menos eficaz do que fortalecer a identidade , implementar MFA resistente a phishing e detecção de comportamento anômalo. O controle certo no lugar certo é menos intrusivo e mais eficaz.

Outro ponto importante: um modelo de ameaças honesto reconhece que existem riscos que não valem a pena mitigar totalmente, o que chamamos de risco aceito. Não porque não possam ser mitigados, mas porque o custo — operacional, econômico ou humano — supera o benefício. Quando bem analisados e gerenciados, esses riscos não supõem negligência, mas sim um design consciente.

Por último, uma modelagem de ameaças bem feita é algo vivo, não é algo que se faz uma vez e se arquiva. Ela muda com o negócio, com a tecnologia e com o contexto. Mas cada iteração tende a reduzir a fricção, não a aumentá-la, porque aprende com a operação real. Em contraste, a segurança projetada a partir do medo acumula controles, enquanto a segurança projetada a partir de um modelo de ameaças escolhe controles.

Métricas que importam

As métricas são fundamentais para avaliar a eficácia de um sistema, mas é crucial saber o que medir. Se você mede as coisas erradas, acaba forçando decisões ruins, mesmo que a intenção seja boa. Em segurança, isso acontece com frequência: celebram-se números que não dizem nada sobre o risco real nem sobre o impacto no negócio.

Na prática, vi muitas organizações que continuam medindo a segurança pela atividade visível: quantidade de controles implementados, volume de bloqueios, número de alertas gerados ou porcentagem de conformidade (compliance). São métricas confortáveis porque são fáceis de contar e de reportar, mas perigosas porque premiam a fricção em vez da eficácia. Quando o sucesso é definido como “bloquear mais”, a única coisa que acontece é exatamente isso: mais bloqueios, mais fricção. Por outro lado, organizações que nem sequer têm clareza sobre o que deveriam medir acabam usando qualquer número disponível como indicador de “boa segurança” — o que, obviamente, também não ajuda a avaliar a segurança real.

Uma métrica útil não mede a existência do controle, mas sim o seu efeito. Ela deve permitir responder a uma pergunta simples: este controle reduz o risco sem prejudicar a operação? Se a métrica não ajuda a visualizar isso, possivelmente ela não serve para nada.

Alguns exemplos de métricas que realmente dizem algo:

Tempo médio para habilitar um acesso legítimo. Não quanto tempo o ticket leva para ser fechado, mas quanto tempo passa até que uma pessoa consiga, de fato, trabalhar. Se este número cresce, a segurança está introduzindo fricção.

Quantidade e tipo de exceções ativas. As exceções não são uma falha pontual; são um sinal estrutural. Muitas exceções indicam que o controle não se ajusta à realidade.

Uso real dos controles (não apenas a existência). Um controle que existe, mas é evitado sistematicamente, não protege nada. Medir a adoção efetiva — por exemplo, acessos diretos vs. acessos por atalhos — é muito mais valioso do que contar regras configuradas.

Incidentes por fricção operacional. Erros causados pela complexidade: credenciais compartilhadas, acessos mal configurados, bypasses “temporários”.

Tempo de recuperação diante de acessos bloqueados incorretamente. Falsos positivos importam. Um sistema que bloqueia muito, mas demora para corrigir o erro, pune o negócio.

Proporção de controles preventivos vs. reativos. Mais prevenção bem alocada geralmente significa menos interrupções.

Feedback do usuário como dado operacional. Não falo de pesquisas de satisfação, mas de sinais concretos: quantos tickets são abertos devido à fricção, quantos passos uma ação segura exige, quantas vezes a ajuda é solicitada para o mesmo problema.

Essas métricas têm algo em comum: obrigam a olhar para o sistema completo e não apenas para a postura de segurança isolada. Elas tornam visível o custo operacional do controle e permitem compará-lo com o risco que ele mitiga. Sob a lógica de Protect to Enable, um controle que bloqueia o trabalho não está protegendo nada relevante. Medir a segurança em termos de impacto real é a única forma de distinguir entre controles que habilitam o negócio e controles que o freiam.

O papel do arquiteto de segurança

Considerando tudo o que foi dito, o papel do arquiteto de segurança é projetar sistemas que gerenciem o risco de forma deliberada e permitam operar sem fricção desnecessária ou, em outras palavras: projetar sistemas seguros que as pessoas possam usar sem precisar pensar em segurança.

Quando a segurança falha, raramente é por falta de controles. É por falta de design. E projetar implica entender como o negócio trabalha, como as pessoas se enganam, o que dói quando algo quebra e o que não dói. Implica aceitar que a perfeição não existe e que o risco não se elimina: ele se gerencia.

Um arquiteto de segurança não deveria começar perguntando “qual controle aplicamos?”, mas sim “o que estamos tentando habilitar?”. A diferença é sutil, mas muda tudo. Em vez de impor barreiras, projetam-se caminhos. Em vez de regras rígidas, definem-se princípios que se sustentam quando o contexto muda.

Ele também é quem traduz. Traduz o risco técnico em impacto de negócio, e as urgências de negócio em decisões técnicas conscientes. Não simplifica demais, mas também não adiciona complexidade desnecessária. Torna explícitos os trade-offs, mesmo quando isso gera desconforto.

Outra função fundamental é resistir à tentação do medo mencionada anteriormente. Após um incidente, é comum que tudo empurre para o endurecimento. O arquiteto de segurança é quem deve frear, olhar para o sistema completo e perguntar se o novo controle realmente reduz o risco ou apenas acalma ansiedades.

Com tudo isso, o Protect to Enable torna-se um critério de design. Se um controle não habilita o trabalho seguro ou não escala, ele é revisado, e então redesenhado ou substituído.

Quando a segurança freia o negócio, o problema não é o negócio

Ao longo dos anos, vi inúmeros casos em que segurança e negócio estão em constante tensão. Quase como se fosse algo inevitável. Mas, na minha experiência — e pelo que tenho lido — quando isso ocorre, não se trata de um choque de objetivos ou de uma verdadeira incompatibilidade, mas sim de um problema de design.

Não é necessário esclarecer que este artigo não trata de relaxar controles nem de escolher velocidade em detrimento da segurança. Trata, na verdade, de como o medo, a fricção mal alocada e as métricas erradas empurram a construção de sistemas que obrigam o negócio a burlar a segurança para conseguir avançar.

Proteger para habilitar não é um lema otimista: é uma disciplina de design. Implica partir do que se quer tornar possível, modelar ameaças reais, aceitar trade-offs explícitos e construir controles que reduzam o risco sem transferir o custo para a operação. Projetar controles que funcionem na prática, não apenas em auditorias.

A segurança bem projetada não compete com o negócio: ela o acompanha. Quando isso não acontece, o problema não é o negócio querer ser rápido, é a segurança estar sendo pensada como um obstáculo — e, nesses casos, ela precisa ser redesenhada.

Para encerrar, para quem quiser se aprofundar nessa forma de pensar, Protect to Enable é uma leitura excelente — aprendi muito lendo esse livro —, junto com qualquer outra que coloque a ênfase no design, no contexto e nos efeitos reais, antes de focar em checklists e proibições. Além disso, se você quiser conversar sobre isso, adoraria ler seus comentários, críticas e experiências próprias. Você encontrará meus métodos de contato no rodapé deste blog.