Em 1988, quando a Contacta foi fundada, a tecnologia corporativa tinha endereço certo. Ficava em salas climatizadas, atrás de portas com controle de acesso, e os usuários chegavam a ela por terminais e redes que a própria empresa controlava de ponta a ponta. Proteger um sistema era, em boa medida, proteger o lugar onde ele estava.
Quase quatro décadas depois, essa imagem parece de outra era. Os sistemas que sustentam uma organização estão espalhados entre data centers próprios, provedores de nuvem e aplicações contratadas como serviço. São acessados de escritórios, de casas, de aeroportos, por telefones e computadores que ninguém na área de TI viu pessoalmente. Quase tudo mudou, do hardware às linguagens e da forma de contratar à forma de operar.
Acompanhar essa sequência de transformações nos deixou menos impressionados com a novidade e mais atentos ao que se repete. Cada geração de tecnologia chegou com uma promessa de simplificação, e em cada uma delas o trabalho difícil acabou sendo o mesmo: entender o que uma organização precisa, conectar as ferramentas disponíveis a esse propósito e garantir que as pessoas consigam, de fato, trabalhar com elas. Nossa missão sempre foi conectar pessoas por meio da tecnologia. Ela dá a medida do que a tecnologia deve entregar, mais do que o que ela é.
A nuvem e o mito da mudança de endereço
Ao longo da nossa história, atuamos bastante na migração de grandes organizações para a nuvem, e foi nessa experiência que aprendemos uma das lições mais importantes do nosso ofício.
À primeira vista, migrar parece uma operação logística: pegar aplicações e dados que vivem em servidores próprios e levá-los para outro lugar. Quem passa pelo processo descobre rapidamente que o endereço é o detalhe menos relevante. Uma aplicação raramente existe sozinha. Ela depende de outras, conversa com bases de dados, é consumida por pessoas com diferentes níveis de permissão e foi desenhada, muitas vezes anos antes, com premissas sobre rede e segurança que deixam de valer fora do ambiente original.
Por isso, migrar obriga a revisitar perguntas que muitas empresas não faziam havia tempo. Quem acessa o quê, e a partir de onde? O que acontece com a conectividade quando parte do ambiente muda de lugar e parte permanece? Como se garante continuidade se uma dependência que ninguém havia mapeado deixa de responder? Onde estão, afinal, os dados que precisam de proteção?
A lição que ficou é que transformar a tecnologia de uma empresa é muito mais do que mudar o lugar onde seus sistemas estão hospedados. Quando a migração é tratada como substituição de infraestrutura, o resultado costuma ser o mesmo ambiente de antes, só que mais caro de entender e mais difícil de proteger. Quando é tratada como oportunidade de rever arquitetura, processos e riscos, a nuvem passa a fazer sentido. A diferença quase nunca está na plataforma escolhida, e quase sempre está na qualidade da conversa que antecede a escolha.
O perímetro que deixou de existir
Houve um tempo em que proteger uma aplicação significava, em grande parte, proteger a rede em que ela estava instalada. O raciocínio era claro: havia um dentro e um fora, e a segurança se concentrava na fronteira entre os dois.
A expansão da nuvem, das aplicações SaaS e do acesso remoto desfez essa fronteira de maneira gradual. Em algum momento, a mesma aplicação passou a depender de diferentes serviços em nuvem e a ser acessada por usuários em várias localidades, com dispositivos pessoais e corporativos se misturando no mesmo dia de trabalho. Em nossas conversas com clientes e em nossos materiais, chamamos esse cenário de “caos topológico”: um ambiente em que usuários, aplicações, dispositivos e dados estão distribuídos, e a pergunta “onde fica a borda?” já não tem uma resposta simples.
A segurança teve de acompanhar essa mudança. Se o perímetro deixou de ser o ponto de referência, o que passou a importar foram as identidades, os dados e as aplicações, onde quer que estivessem. Hoje, saber quem é quem e a que cada um deveria ter acesso pesa tanto quanto qualquer muro, e talvez mais. Essa também é uma lição que a experiência nos ensinou: quanto mais conectada uma organização se torna, mais sofisticada precisa ser a forma de protegê-la.
Ferramentas não são arquitetura
Há um equívoco recorrente nesse caminho, e o vimos se repetir em diferentes gerações de tecnologia: a ideia de que a proteção cresce na proporção das soluções adquiridas. Uma empresa pode ter muitas ferramentas de segurança e, ainda assim, ter dificuldade para enxergar o próprio ambiente, integrar o que comprou e operar tudo isso no dia a dia. Cada ferramenta resolve bem o problema para o qual foi criada. O que ninguém compra pronto é a coerência entre elas.
Por isso, sempre nos pareceu mais honesto começar pelo entendimento do ambiente do que pelo produto. É preciso avaliar o que existe, desenhar uma arquitetura que faça sentido para aquela organização, implantar com cuidado e acompanhar a operação depois. Parece óbvio quando dito assim, mas é um trabalho que não aparece em nenhuma tabela de funcionalidades. A segurança de uma empresa é uma propriedade do conjunto e depende de decisões tomadas antes, durante e depois da compra.
Há ainda um aprendizado que costuma ser subestimado. Uma estratégia de segurança que ignora a experiência de quem usa os sistemas tende a ser contornada. Se proteger significa impedir que as pessoas trabalhem, elas encontram um atalho, e o atalho quase sempre é pior do que o problema que se queria resolver. A boa proteção é aquela que convive com a produtividade, a colaboração e a continuidade da operação. Foi isso que aprendemos ao lembrar, projeto após projeto, que do outro lado de qualquer sistema há alguém tentando fazer o seu trabalho.
Novas tecnologias, perguntas conhecidas
Hoje, a inteligência artificial ocupa o centro dessa conversa, e com razão. Ela traz riscos novos e exige formas novas de proteção. Não pretendemos minimizar nada disso.
Mas quem acompanhou outras transformações reconhece algo familiar quando examina os problemas de perto. Um agente de IA que acessa sistemas internos levanta perguntas sobre identidade e permissões. Um modelo alimentado com informações corporativas levanta perguntas sobre proteção e governança de dados. Uma aplicação que usa serviços de terceiros levanta perguntas sobre visibilidade: o que está rodando, com acesso a quê, e quem responde por isso? São versões novas de questões antigas, e as empresas que cuidaram bem dos fundamentos tendem a atravessar cada onda com menos sobressaltos.
Isso vale também para uma observação mais ampla. Não existe arquitetura definitiva. As necessidades das organizações mudam, as ameaças evoluem, as ferramentas se renovam, e decisões que eram acertadas há cinco anos podem deixar de ser. A capacidade de aprender, rever e ajustar vale mais do que qualquer escolha tecnológica isolada. É uma ideia que sempre nos acompanhou, algo próximo do que já chamamos de #AlwaysGetBetter: a disposição de continuar melhorando justamente porque nada está terminado.
O que permanece
Quando olhamos para trás, o que impressiona é menos a quantidade de tecnologias que passaram por nós do que a constância das perguntas que elas deixaram. Como garantir que as pessoas consigam acessar o que precisam? Como proteger o que importa sem travar a operação? Como decidir bem num ambiente que não para de mudar?
As ferramentas que respondem a essas perguntas serão outras daqui a dez anos, como já foram outras dez, vinte e trinta anos atrás. O trabalho de conectá-las às necessidades reais de uma organização, e às pessoas que dependem dela, continuará exigindo escuta, análise e critério. Foi isso que quase quarenta anos nos ensinaram, e é o que pretendemos continuar praticando.










