Segurança da Informação sob a Ótica do Arquiteto: Entre o "Castelo de Cartas" e o "Sarcófago de Concreto"
Este artigo explora a tensão inerente entre os requisitos de segurança da informação (SI) e a arquitetura de sistemas. Discute como a SI, quando tratada como um filtro externo em vez de uma propriedade de design fundamental, pode levar a sistemas inflexíveis ou inutilizáveis, impactando o desenvolvimento e a inovação.
MundiX News·08 de junho de 2026·15 min de leitura·👁 6 views
A arquitetura ideal frequentemente encontra seu fim no momento em que se depara com o primeiro requisito sério de segurança da informação. Nesse exato instante, a própria segurança morre, transformando-se em uma sobreposição "de papel" que a equipe de projeto sabotará a qualquer oportunidade. O resultado desse confronto é um "cadáver seguro" — um sistema teoricamente protegido contra tudo, mas praticamente incapaz de evoluir, escalar e gerar receita para o negócio.
A questão não reside na rigidez dos reguladores, mas em uma falha sistêmica: acostumamo-nos a encarar a segurança da informação como um filtro externo, e não como uma propriedade fundamental do design. Consequentemente, o arquiteto projeta "castelos no ar", enquanto o especialista em SI constrói muros de concreto ao redor deles. Brincamos demais e esquecemos que somos apenas um serviço para garantir o funcionamento do produto.
Paradoxo do Desenvolvimento Moderno
O paradoxo do desenvolvimento moderno reside no fato de que, por um lado, o negócio exige velocidade na entrega de novas funcionalidades ao mercado, enquanto, por outro lado, a abordagem clássica para garantir a segurança da informação, ainda amplamente utilizada, se transforma em uma barreira intransponível, cuja superação pode levar a consequências imprevisíveis.
A abordagem tradicional, na qual a SI atua como um "ministério de proibições", para onde o arquiteto ou a equipe do projeto leva a solução para aprovação, parece ter se esgotado completamente. Com essa metodologia, a segurança frequentemente se torna ou um status formal de conformidade com os requisitos de SI, ou uma âncora pesada que afunda o projeto. O resultado muitas vezes depende não do cumprimento de requisitos específicos de SI, mas de quem consegue convencer, argumentar, escalar ou resistir à pressão superior.
Hoje, a segurança não é uma cerca externa ao sistema, mas sim seu DNA. A segurança é uma propriedade arquitetural fundamental que, muitas vezes, determina a viabilidade e o sucesso de um projeto, ou seu fim. Estamos em uma situação onde os requisitos de proteção ou quebram a lógica do sistema pela raiz, ou elevam a arquitetura do projeto a um nível qualitativamente novo.
É evidente que, em tal cenário, um arquiteto que não compreende os fundamentos de SI projeta um "castelo de cartas" que desmoronará na primeira carga ou ataque sério. Ao mesmo tempo, um especialista em SI distante do contexto arquitetural e da tarefa de negócio constrói um "sarcófago de concreto" — um sistema tão protegido que se torna impossível de usar e, com uma probabilidade não nula, morrerá sem nunca ter trazido benefícios ao negócio.
A segurança da informação impacta a arquitetura de forma tão significativa que as abordagens modernas para organizar o processo de desenvolvimento de sistemas de informação frequentemente deixam de cumprir sua função e descambam para soluções seguras e inflexíveis, ou para soluções ágeis, de rápida implementação e inseguras.
Segurança como Propriedade da Arquitetura
Recorrendo à literatura, no livro "Fundamentos de Arquitetura de Software" (Fundamentals of Software Architecture), Mark Richards e Neal Ford destacam a "Segurança" como uma das características chave da arquitetura. Os autores enfatizam que a segurança não existe no vácuo: é um atributo de qualidade intrínseco que deve ser considerado juntamente com outras propriedades arquiteturais.
A especificidade da segurança como propriedade arquitetural reside em seu impacto colossal sobre todas as outras características do sistema; ela pode entrar em conflito direto com outros objetivos de design. A importância dessa propriedade, segundo os autores, reside no fato de que é praticamente impossível implementá-la efetivamente "por cima" de uma estrutura já pronta. Se a segurança não foi incorporada ao alicerce da arquitetura como uma escolha consciente, qualquer tentativa de adicioná-la posteriormente levará à degradação do sistema. Os autores concluem que o arquiteto moderno é obrigado a possuir habilidades de design de segurança, pois ela define os limites do que é permitido para todas as outras decisões arquiteturais.
Quando consideramos a segurança como uma propriedade interna, ela deixa de ser um conjunto de "remendos" externos, torna-se parte integrante e começa a satisfazer os seguintes critérios:
Inseparabilidade: Ao contrário de sistemas antigos onde a segurança vivia "por fora", você não pode "desligar" a criptografia de tráfego ou a verificação de permissões sem comprometer a funcionalidade da lógica de negócio.
Influência no Design: Todas as propriedades do sistema, incluindo a "segurança", são requisitos não funcionais de igual importância e devem ser consideradas desde a fase de design do sistema.
Projetabilidade: A segurança deixa de ser um ponto de controle no final do processo de desenvolvimento e se transforma em uma tarefa de engenharia. O arquiteto não "espera aprovação" do especialista em SI, mas escolhe desde o início os padrões que implementam o nível de proteção desejado por padrão.
Se a segurança for incorporada como uma propriedade, o sistema permanece resiliente por si só, e não porque foi cercado por uma "cerca" de ferramentas de monitoramento externas.
Consideremos exemplos de restrições:
Não é permitido transmitir dados não criptografados entre componentes do sistema.
Um mecanismo de revogação de direitos de usuário deve ser implementado no sistema.
Um mecanismo de revogação de tokens de autenticação deve ser implementado no sistema.
No contexto de implantação: as alterações devem ser propagadas estritamente de segmentos de rede mais confiáveis para menos confiáveis.
Todas as requisições de um segmento menos confiável para um mais confiável devem passar por um rigoroso controle de formato e lógica (FCL).
E assim por diante...
Como se pode notar, tais restrições ditam diretamente as decisões arquiteturais e inevitavelmente afetam outras características do sistema. Por exemplo, a implementação de um FCL profundo nas fronteiras dos segmentos certamente reduzirá a responsividade do sistema, e a criptografia obrigatória de todas as comunicações internas aumentará a carga sobre os recursos e complicará o diagnóstico. Ignorar essa influência na fase de design leva a segurança a ser percebida não como uma vantagem, mas como um obstáculo a ser superado nas fases posteriores de implementação do projeto.
Outro exemplo de restrições semelhantes pode ser o requisito de usar mTLS. Frequentemente, as equipes o implementam formalmente, cometendo um erro crítico: usam o mesmo certificado para todo o cluster ou par de sistemas. Essa implementação é, na prática, equivalente à ausência de autenticação: ela não permite identificar um serviço específico e transforma a proteção em ficção. No final, isso apenas complica a infraestrutura sem adicionar segurança real. Para que o mTLS traga benefícios, ele deve garantir a unicidade de cada entidade, o que requer a implementação de uma infraestrutura PKI completa para gerenciar o ciclo de vida das chaves. Frequentemente, na prática, isso força a arquitetura a migrar para o uso de soluções Service Mesh, que automatizam a emissão e rotação de certificados. Sem essas ferramentas adicionais e controle rigoroso por parte da SI, a implementação de requisitos de segurança se transforma em um "culto à carga" (cargo cult), que apenas atrapalha o desenvolvimento.
É importante entender que a segurança da informação não se resume exclusivamente a propriedades arquiteturais. É uma disciplina complexa onde o controle operacional, a investigação de incidentes e o desenvolvimento de regulamentos desempenham um papel não menor. No entanto, do ponto de vista da arquitetura, os requisitos de SI para o sistema permanecem uma parte criticamente importante. Eles podem ter um impacto radical na arquitetura: se não forem considerados no início, o custo do erro pode levar a uma reformulação completa da lógica da aplicação.
Imposto sobre Segurança e Dificuldades Tributárias
A pressão excessiva dos requisitos de SI e a falta de mecanismos para encontrar um compromisso arquitetural tornam-se uma barreira séria para o desenvolvimento do sistema.
É necessário reconhecer: a segurança da informação inevitavelmente torna o sistema mais complexo, caro e lento. Isso nunca é "gratuito". A SI sempre consome recursos reais: a criptografia sobrecarrega a CPU, o mTLS aumenta a latência da rede, e os logs de auditoria sobrecarregam o espaço em disco.
A magnitude desse "imposto sobre segurança" deve ser conscientemente aceita por todos os participantes do processo. No entanto, o recurso mais caro que perdemos não são os ciclos de processador, mas o tempo e a eficiência da equipe, que se esgotam no conflito de interesses entre segurança e arquitetura na ausência de compromissos.
O principal desafio reside no conflito de objetivos: arquitetos focam na criação de valor, muitas vezes ignorando vetores de ataque, enquanto especialistas em segurança focam na minimização de riscos, sem considerar o contexto de negócio. Sem um contexto comum, a SI se transforma em um "ministério de proibições", que dita condições rígidas, mas não compartilha a responsabilidade pelos prazos e pelo sucesso do negócio. O arquiteto, nessa situação, torna-se um "advogado do negócio", que percebe a segurança como um incômodo e busca contornar os requisitos apenas para lançar uma feature a tempo.
Como resultado, surgem duas extremidades: ou um "castelo de cartas" — uma arquitetura vulnerável criada sem o entendimento das ameaças, ou um "sarcófago de concreto" — um sistema excessivamente protegido, impossível de usar. Em ambos os casos, o negócio sofre: o sistema ou desmorona no primeiro ataque, ou morre sem trazer benefícios devido à sua complexidade.
Caso: Implementação de Logical Air Gap no Design de Integrações
Vamos considerar uma tarefa: exibir dados de perfil na UI. Parece simples, coisa de algumas horas: expõe-se um endpoint e pronto. Mas e se a SI proibir tráfego de entrada na rede protegida?
O primeiro cenário, sem considerar o requisito de SI, poderia ser assim:
"Aplicação Cliente", localizada na "Internet", inicia a função "Solicitar Dados de Perfil" e envia uma requisição HTTPS para o gateway "DMZ entry point", que atua como o único ponto de entrada. O gateway recebe a requisição, a transmite para a "Interface HTTPS interna do Serviço de Perfil do Cliente", que, por sua vez, atende à função "Formatação do Perfil do Cliente". Como resultado do processamento, o "Serviço de Perfil do Cliente" cria um objeto digital de dados "Perfil do Cliente" e o envia de volta pela cadeia, após o que a "Aplicação Cliente" exibe as informações ao usuário.
É justo notar que, "no fundo", a arquitetura pode ser complementada por WAF, API Gateway ou reverse proxy para controle de tráfego. Mas se esses meios resolvem tarefas de nível de aplicação, o requisito que consideraremos a seguir muda a topologia de rede em si e o padrão fundamental de troca de dados.
Este esquema possui propriedades arquiteturais bastante compreensíveis:
Agora, adicionemos uma instrução da SI: "Nenhuma conexão de entrada na rede interna". Geralmente, tais regras são conhecidas desde o início e é para isso que aspiramos, mas para o nosso exemplo, vamos imaginar que o requisito surgiu de repente.
Mover o serviço de perfil para fora não é possível — há dados sensíveis lá. Como resultado, uma ligação simples se transforma em um labirinto arquitetural: para obter os dados sem abrir portas de entrada, é preciso implementar intermediários e mudar a própria direção da requisição. Veja como esse "monstro" pode parecer no diagrama:
Entre o "DMZ entry point" e o serviço de destino, são inseridos um Receptor, que processa requisições de entrada, um Broker para armazenamento de filas de requisições e respostas, e um Processador, responsável por gerenciar a interação com o serviço de destino. Conexões de rede da zona protegida são estabelecidas apenas de dentro para fora.
Abordagem Arquitetural Logical Air Gap ("espaço aéreo lógico") — isola dados ou sistemas em nível de software. Fisicamente o cabo está no lugar, mas logicamente construímos uma "parede" pela qual uma requisição não pode simplesmente passar.
Como as propriedades da arquitetura mudaram com o aumento radical da segurança?
Vimos um bom exemplo que ilustra como o atributo Segurança entra em conflito direto com outras propriedades da arquitetura, forçando o arquiteto a buscar um compromisso complexo. Uma saída viável em tal situação pode ser a transição completa para um modelo baseado em eventos, eliminando a necessidade de chamadas síncronas entre segmentos isolados.
SI como Catalisador de Degradação e Paralisia
Na realidade, o impacto da segurança na arquitetura muitas vezes parece muito menos harmonioso do que no exemplo descrito acima com Logical Air Gap. Aqui entramos na zona de paradoxos, onde os requisitos de proteção começam a conflitar diretamente com o conceito de "boa arquitetura".
Paradoxo do "Aterro Sanitário Inexpugnável"
Existe um equívoco perigoso de que um sistema construído a partir de "soluções não padronizadas e amontoados caóticos" é mais seguro simplesmente porque sua estrutura interna é um caos que não pode ser escaneado por métodos padrão. Por um lado, isso parece um "fortificação intransponível": o atacante não entende como funciona porque funciona contra a lógica.
Por outro lado, tal arquitetura é um antipadrão por definição. Se um sistema não é hackeado apenas porque é muito torto para um estranho entender — isso não é segurança, é sorte temporária. A violação da pureza do código e dos padrões para "confundir" rastros torna a arquitetura frágil e o custo de sua manutenção — exorbitante.
Causa da Paralisia Arquitetural
Em indústrias com regulamentação rigorosa (fintech, setor público), frequentemente observamos "paralisia arquitetural". Os requisitos de SI podem contradizer fundamentalmente os padrões modernos:
Cloud Native? — Não pode, os dados devem estar em um contorno fechado.
Serverless? — Inadmissível, não controlamos o ambiente de execução.
Lançamentos rápidos? — Esqueça, cada commit deve passar por um ciclo de aprovação de uma semana.
Este é o estado de paralisia arquitetural: novas tecnologias são bloqueadas na entrada, e o sistema existente acumula camadas de mecanismos de proteção que o tornam inflexível. Nessas condições, a segurança se torna efetivamente a "morte da inovação", e o arquiteto precisa projetar não a solução ótima, mas a mais "aprovável".
Existe uma opinião alternativa e ela não é desprovida de sentido. Ela afirma que a implementação de tecnologias inseguras não é um avanço inovador, mas a implantação de um MVP não testado em uma arquitetura viva.
Os requisitos de SI apenas delineiam os limites de maturidade do produto, transformando um experimento perigoso em uma solução de negócio sustentável.
Sem dúvida, quando requisitos excessivos de SI bloqueiam a implementação de produtos já testados pelo mercado e pela indústria, isso freia o negócio. No entanto, aqui é importante distinguir: uma coisa é adaptar a prática mundial existente às estruturas de conformidade internas, e outra coisa completamente diferente é apresentar um produto inseguro e não testado como uma inovação completa.
Tragédia do HSM: Quem é o Culpado Quando Tudo Cai?
Um exemplo clássico de colisão entre teoria e prática é a implementação de Hardware Security Modules (HSM). O requisito de SI de armazenar chaves de forma inalienável — absolutamente correto do ponto de vista teórico. Mas quando o sistema cai sob carga porque o HSM se tornou um "gargalo", surge a eterna questão: quem é o culpado?
Especialistas em SI, que exigiram a implementação sem olhar o perfil de carga?
Arquiteto, que não previu o RPS e não "defendeu" a decisão na fase de design?
Negócio, que lançou uma promoção sem perguntar sobre a capacidade de processamento do núcleo criptográfico?
Neste ponto, o impacto da SI na arquitetura atinge o pico: a responsabilidade é distribuída entre todos os participantes do processo, o que na prática significa sua ausência total. A arquitetura se transforma em um refém, onde a SI espera argumentos dos projetistas, e estes, por sua vez, projetam "do avesso", tentando encaixar os requisitos de segurança nas possibilidades reais de hardware e software.
Caminho para a Sinergia
Como vimos, a tentativa de construir a arquitetura exclusivamente "a partir da segurança" leva à criação de uma fortaleza intransponível que é incapaz de se mover e se adaptar às demandas do negócio. Por outro lado, ignorar a SI transforma o sistema em um castelo de cartas. A solução não reside em buscar um compromisso entre segurança e flexibilidade, mas em uma profunda reavaliação dos próprios padrões arquiteturais.
Do Direito de "Veto" ao Shift Left
Tradicionalmente, a SI é percebida como uma instância de controle com direito a veto, que as equipes de projeto tentam "contornar" nas fases finais. Para que a arquitetura não se transforme em um "monólito improvisado" pouco antes do lançamento, é necessário implementar a abordagem Shift Left.
O sentido é simples: os requisitos de segurança devem ser "incorporados" ao sistema na fase de design, e não chegar na fase de aceitação, quando refazer algo já é tarde demais e caro.
Para isso, são críticos:
Troca Constante de Conhecimento: O arquiteto deve entender a lógica das ameaças, e o especialista em SI — as limitações das tecnologias utilizadas (por exemplo, por que um HSM pode se tornar um gargalo).
KPI Comum — "Time to Compliance": Em vez de confronto — uma métrica comum: quão rápido uma decisão arquitetural passa pela auditoria de SI. Isso força ambos os lados a trabalhar na simplificação e automação das verificações.
DevSecOps: Integração de verificações de segurança diretamente no pipeline CI/CD. A segurança deve se tornar uma parte tão natural do processo quanto os testes unitários.
Arquitetura e SI como Serviço para o Produto
Nas discussões intermináveis sobre padrões e ameaças, arquitetos e especialistas em SI frequentemente esquecem a existência de uma "terceira parte" — a equipe de produto. É importante admitir honestamente: nem a arquitetura em si, nem a SI trazem dinheiro para a empresa. Dinheiro traz a feature que o cliente utiliza. Nós somos pessoal de apoio e funções de serviço, cuja tarefa é garantir a sobrevivência dessa feature.
Se a arquitetura e a SI se empolgam com seus próprios jogos, projetando Air Gaps ideais ou um "adaptador" de microsserviços, esquecendo aqueles com quem viverão com isso, elas se tornam um fardo.
Cada decisão "segura" do arquiteto é um peso potencial nas pernas do desenvolvimento. Assim que as regras se tornam muito complexas, o desenvolvedor começa a procurar maneiras de contornar o sistema. Assim nasce a "TI Sombra" (Shadow IT), que, no final, é muito mais perigosa do que qualquer ausência de HSM.
Para não se tornar um freio à inovação, o especialista em SI e o arquiteto devem se unir e criar para a equipe do projeto um conjunto de ferramentas prontas, já aprovadas e testadas, onde toda a complexidade técnica e regulatória está oculta "sob o capô" (Golden Path).
Como funciona:
O desenvolvedor precisa de um banco de dados? Ele não precisa desenvolver esquemas de segmentação ou aprovar portas. Ele aperta um botão e recebe um recurso que já está no contorno desejado, com backups e criptografia configurados.
Critério de Sucesso:
A equipe do projeto deve escrever lógica de negócio, e não se aprofundar nas complexidades dos requisitos de infraestrutura. Se o desenvolvedor precisa passar por 10 círculos de aprovação e configurar 5 gateways proxy para simplesmente lançar um botão — você, como serviço, falhou.
Conclusão
Do Controle ao Design Colaborativo
Para sair do impasse "arquiteto contra SI", é necessário mudar o próprio modelo de interação:
Abordagem Orientada a Riscos: Proteger o que é realmente importante, considerando o custo da proteção versus o custo do risco. Isso elimina "improvisações" excessivas onde não são necessárias.
SI como Serviço: O especialista em SI deve deixar de ser um "inspetor com direito a veto" e começar a fornecer ao arquiteto "blocos seguros" prontos (padrões típicos, bibliotecas testadas, módulos de infraestrutura configurados).
Automação via DevSecOps: Esta é uma boa maneira de remover a subjetividade das aprovações "manuais". Quando as regras de verificação são transparentes e incorporadas ao pipeline, a questão "a SI aprovará ou não" desaparece por si só.
Restrições Claras no Início: O arquiteto precisa de limites técnicos claros e compreensíveis antes de começar a trabalhar na solução, e não proibições abstratas.
Papel do Arquiteto e Responsabilidade Geral
O problema não é a falta de KPIs, mas o conflito de vetores: o arquiteto busca velocidade (Time-to-Market), enquanto o especialista em SI busca segurança (Compliance). A saída aqui é uma só — responsabilidade compartilhada perante o negócio.
O Arquiteto se torna um mediador. Ele deve ser capaz de "vender" soluções para especialistas em SI através de cálculos de carga e propor alternativas seguras ao negócio.
O Especialista em SI senta-se no mesmo barco com os engenheiros, sendo responsável não apenas pela ausência de invasões, mas também por garantir que o sistema funcione de forma rápida e estável, e seja lançado no final.
"Enterprise Integration Patterns" — Gregor Hohpe, Bobby Woolf. Interrupção da comunicação síncrona entre sistemas (tanto em tempo quanto em espaço de rede).
"Designing Data-Intensive Applications" — Martin Kleppmann. Descreve o isolamento de estados de sistemas. Kleppmann explica por que sistemas que leem de filas (modelo Pull) são fundamentalmente mais protegidos contra falhas em cascata e ataques externos.
"Cybersecurity Blue Team Toolkit" — Nadean H. Tanner. Tipos de separação tecnológica de redes (Logical vs. Physical Air Gap).
Sem cartão para começar · Planos a partir de R$49/mês
A arquitetura ideal frequentemente encontra seu fim no momento em que se depara com o primeiro requisito sério de segurança da informação. Nesse exato instante, a própria segurança morre, transformando-se em uma sobreposição "de papel" que a equipe de projeto sabotará a qualquer oportunidade. O resultado desse confronto é um "cadáver seguro" — um sistema teoricamente protegido contra tudo, mas praticamente incapaz de evoluir, escalar e gerar receita para o negócio.
A questão não reside na rigidez dos reguladores, mas em uma falha sistêmica: acostumamo-nos a encarar a segurança da informação como um filtro externo, e não como uma propriedade fundamental do design. Consequentemente, o arquiteto projeta "castelos no ar", enquanto o especialista em SI constrói muros de concreto ao redor deles. Brincamos demais e esquecemos que somos apenas um serviço para garantir o funcionamento do produto.
Paradoxo do Desenvolvimento Moderno
O paradoxo do desenvolvimento moderno reside no fato de que, por um lado, o negócio exige velocidade na entrega de novas funcionalidades ao mercado, enquanto, por outro lado, a abordagem clássica para garantir a segurança da informação, ainda amplamente utilizada, se transforma em uma barreira intransponível, cuja superação pode levar a consequências imprevisíveis.
A abordagem tradicional, na qual a SI atua como um "ministério de proibições", para onde o arquiteto ou a equipe do projeto leva a solução para aprovação, parece ter se esgotado completamente. Com essa metodologia, a segurança frequentemente se torna ou um status formal de conformidade com os requisitos de SI, ou uma âncora pesada que afunda o projeto. O resultado muitas vezes depende não do cumprimento de requisitos específicos de SI, mas de quem consegue convencer, argumentar, escalar ou resistir à pressão superior.
Hoje, a segurança não é uma cerca externa ao sistema, mas sim seu DNA. A segurança é uma propriedade arquitetural fundamental que, muitas vezes, determina a viabilidade e o sucesso de um projeto, ou seu fim. Estamos em uma situação onde os requisitos de proteção ou quebram a lógica do sistema pela raiz, ou elevam a arquitetura do projeto a um nível qualitativamente novo.
É evidente que, em tal cenário, um arquiteto que não compreende os fundamentos de SI projeta um "castelo de cartas" que desmoronará na primeira carga ou ataque sério. Ao mesmo tempo, um especialista em SI distante do contexto arquitetural e da tarefa de negócio constrói um "sarcófago de concreto" — um sistema tão protegido que se torna impossível de usar e, com uma probabilidade não nula, morrerá sem nunca ter trazido benefícios ao negócio.
A segurança da informação impacta a arquitetura de forma tão significativa que as abordagens modernas para organizar o processo de desenvolvimento de sistemas de informação frequentemente deixam de cumprir sua função e descambam para soluções seguras e inflexíveis, ou para soluções ágeis, de rápida implementação e inseguras.
Segurança como Propriedade da Arquitetura
Recorrendo à literatura, no livro "Fundamentos de Arquitetura de Software" (Fundamentals of Software Architecture), Mark Richards e Neal Ford destacam a "Segurança" como uma das características chave da arquitetura. Os autores enfatizam que a segurança não existe no vácuo: é um atributo de qualidade intrínseco que deve ser considerado juntamente com outras propriedades arquiteturais.
A especificidade da segurança como propriedade arquitetural reside em seu impacto colossal sobre todas as outras características do sistema; ela pode entrar em conflito direto com outros objetivos de design. A importância dessa propriedade, segundo os autores, reside no fato de que é praticamente impossível implementá-la efetivamente "por cima" de uma estrutura já pronta. Se a segurança não foi incorporada ao alicerce da arquitetura como uma escolha consciente, qualquer tentativa de adicioná-la posteriormente levará à degradação do sistema. Os autores concluem que o arquiteto moderno é obrigado a possuir habilidades de design de segurança, pois ela define os limites do que é permitido para todas as outras decisões arquiteturais.
Quando consideramos a segurança como uma propriedade interna, ela deixa de ser um conjunto de "remendos" externos, torna-se parte integrante e começa a satisfazer os seguintes critérios:
Inseparabilidade: Ao contrário de sistemas antigos onde a segurança vivia "por fora", você não pode "desligar" a criptografia de tráfego ou a verificação de permissões sem comprometer a funcionalidade da lógica de negócio.
Influência no Design: Todas as propriedades do sistema, incluindo a "segurança", são requisitos não funcionais de igual importância e devem ser consideradas desde a fase de design do sistema.
Projetabilidade: A segurança deixa de ser um ponto de controle no final do processo de desenvolvimento e se transforma em uma tarefa de engenharia. O arquiteto não "espera aprovação" do especialista em SI, mas escolhe desde o início os padrões que implementam o nível de proteção desejado por padrão.
Se a segurança for incorporada como uma propriedade, o sistema permanece resiliente por si só, e não porque foi cercado por uma "cerca" de ferramentas de monitoramento externas.
Consideremos exemplos de restrições:
Não é permitido transmitir dados não criptografados entre componentes do sistema.
Um mecanismo de revogação de direitos de usuário deve ser implementado no sistema.
Um mecanismo de revogação de tokens de autenticação deve ser implementado no sistema.
No contexto de implantação: as alterações devem ser propagadas estritamente de segmentos de rede mais confiáveis para menos confiáveis.
Todas as requisições de um segmento menos confiável para um mais confiável devem passar por um rigoroso controle de formato e lógica (FCL).
E assim por diante...
Como se pode notar, tais restrições ditam diretamente as decisões arquiteturais e inevitavelmente afetam outras características do sistema. Por exemplo, a implementação de um FCL profundo nas fronteiras dos segmentos certamente reduzirá a responsividade do sistema, e a criptografia obrigatória de todas as comunicações internas aumentará a carga sobre os recursos e complicará o diagnóstico. Ignorar essa influência na fase de design leva a segurança a ser percebida não como uma vantagem, mas como um obstáculo a ser superado nas fases posteriores de implementação do projeto.
Outro exemplo de restrições semelhantes pode ser o requisito de usar mTLS. Frequentemente, as equipes o implementam formalmente, cometendo um erro crítico: usam o mesmo certificado para todo o cluster ou par de sistemas. Essa implementação é, na prática, equivalente à ausência de autenticação: ela não permite identificar um serviço específico e transforma a proteção em ficção. No final, isso apenas complica a infraestrutura sem adicionar segurança real. Para que o mTLS traga benefícios, ele deve garantir a unicidade de cada entidade, o que requer a implementação de uma infraestrutura PKI completa para gerenciar o ciclo de vida das chaves. Frequentemente, na prática, isso força a arquitetura a migrar para o uso de soluções Service Mesh, que automatizam a emissão e rotação de certificados. Sem essas ferramentas adicionais e controle rigoroso por parte da SI, a implementação de requisitos de segurança se transforma em um "culto à carga" (cargo cult), que apenas atrapalha o desenvolvimento.
É importante entender que a segurança da informação não se resume exclusivamente a propriedades arquiteturais. É uma disciplina complexa onde o controle operacional, a investigação de incidentes e o desenvolvimento de regulamentos desempenham um papel não menor. No entanto, do ponto de vista da arquitetura, os requisitos de SI para o sistema permanecem uma parte criticamente importante. Eles podem ter um impacto radical na arquitetura: se não forem considerados no início, o custo do erro pode levar a uma reformulação completa da lógica da aplicação.
Imposto sobre Segurança e Dificuldades Tributárias
A pressão excessiva dos requisitos de SI e a falta de mecanismos para encontrar um compromisso arquitetural tornam-se uma barreira séria para o desenvolvimento do sistema.
É necessário reconhecer: a segurança da informação inevitavelmente torna o sistema mais complexo, caro e lento. Isso nunca é "gratuito". A SI sempre consome recursos reais: a criptografia sobrecarrega a CPU, o mTLS aumenta a latência da rede, e os logs de auditoria sobrecarregam o espaço em disco.
A magnitude desse "imposto sobre segurança" deve ser conscientemente aceita por todos os participantes do processo. No entanto, o recurso mais caro que perdemos não são os ciclos de processador, mas o tempo e a eficiência da equipe, que se esgotam no conflito de interesses entre segurança e arquitetura na ausência de compromissos.
O principal desafio reside no conflito de objetivos: arquitetos focam na criação de valor, muitas vezes ignorando vetores de ataque, enquanto especialistas em segurança focam na minimização de riscos, sem considerar o contexto de negócio. Sem um contexto comum, a SI se transforma em um "ministério de proibições", que dita condições rígidas, mas não compartilha a responsabilidade pelos prazos e pelo sucesso do negócio. O arquiteto, nessa situação, torna-se um "advogado do negócio", que percebe a segurança como um incômodo e busca contornar os requisitos apenas para lançar uma feature a tempo.
Como resultado, surgem duas extremidades: ou um "castelo de cartas" — uma arquitetura vulnerável criada sem o entendimento das ameaças, ou um "sarcófago de concreto" — um sistema excessivamente protegido, impossível de usar. Em ambos os casos, o negócio sofre: o sistema ou desmorona no primeiro ataque, ou morre sem trazer benefícios devido à sua complexidade.
Caso: Implementação de Logical Air Gap no Design de Integrações
Vamos considerar uma tarefa: exibir dados de perfil na UI. Parece simples, coisa de algumas horas: expõe-se um endpoint e pronto. Mas e se a SI proibir tráfego de entrada na rede protegida?
O primeiro cenário, sem considerar o requisito de SI, poderia ser assim:
"Aplicação Cliente", localizada na "Internet", inicia a função "Solicitar Dados de Perfil" e envia uma requisição HTTPS para o gateway "DMZ entry point", que atua como o único ponto de entrada. O gateway recebe a requisição, a transmite para a "Interface HTTPS interna do Serviço de Perfil do Cliente", que, por sua vez, atende à função "Formatação do Perfil do Cliente". Como resultado do processamento, o "Serviço de Perfil do Cliente" cria um objeto digital de dados "Perfil do Cliente" e o envia de volta pela cadeia, após o que a "Aplicação Cliente" exibe as informações ao usuário.
É justo notar que, "no fundo", a arquitetura pode ser complementada por WAF, API Gateway ou reverse proxy para controle de tráfego. Mas se esses meios resolvem tarefas de nível de aplicação, o requisito que consideraremos a seguir muda a topologia de rede em si e o padrão fundamental de troca de dados.
Este esquema possui propriedades arquiteturais bastante compreensíveis:
Agora, adicionemos uma instrução da SI: "Nenhuma conexão de entrada na rede interna". Geralmente, tais regras são conhecidas desde o início e é para isso que aspiramos, mas para o nosso exemplo, vamos imaginar que o requisito surgiu de repente.
Mover o serviço de perfil para fora não é possível — há dados sensíveis lá. Como resultado, uma ligação simples se transforma em um labirinto arquitetural: para obter os dados sem abrir portas de entrada, é preciso implementar intermediários e mudar a própria direção da requisição. Veja como esse "monstro" pode parecer no diagrama:
Entre o "DMZ entry point" e o serviço de destino, são inseridos um Receptor, que processa requisições de entrada, um Broker para armazenamento de filas de requisições e respostas, e um Processador, responsável por gerenciar a interação com o serviço de destino. Conexões de rede da zona protegida são estabelecidas apenas de dentro para fora.
Abordagem Arquitetural Logical Air Gap ("espaço aéreo lógico") — isola dados ou sistemas em nível de software. Fisicamente o cabo está no lugar, mas logicamente construímos uma "parede" pela qual uma requisição não pode simplesmente passar.
Como as propriedades da arquitetura mudaram com o aumento radical da segurança?
Vimos um bom exemplo que ilustra como o atributo Segurança entra em conflito direto com outras propriedades da arquitetura, forçando o arquiteto a buscar um compromisso complexo. Uma saída viável em tal situação pode ser a transição completa para um modelo baseado em eventos, eliminando a necessidade de chamadas síncronas entre segmentos isolados.
SI como Catalisador de Degradação e Paralisia
Na realidade, o impacto da segurança na arquitetura muitas vezes parece muito menos harmonioso do que no exemplo descrito acima com Logical Air Gap. Aqui entramos na zona de paradoxos, onde os requisitos de proteção começam a conflitar diretamente com o conceito de "boa arquitetura".
Paradoxo do "Aterro Sanitário Inexpugnável"
Existe um equívoco perigoso de que um sistema construído a partir de "soluções não padronizadas e amontoados caóticos" é mais seguro simplesmente porque sua estrutura interna é um caos que não pode ser escaneado por métodos padrão. Por um lado, isso parece um "fortificação intransponível": o atacante não entende como funciona porque funciona contra a lógica.
Por outro lado, tal arquitetura é um antipadrão por definição. Se um sistema não é hackeado apenas porque é muito torto para um estranho entender — isso não é segurança, é sorte temporária. A violação da pureza do código e dos padrões para "confundir" rastros torna a arquitetura frágil e o custo de sua manutenção — exorbitante.
Causa da Paralisia Arquitetural
Em indústrias com regulamentação rigorosa (fintech, setor público), frequentemente observamos "paralisia arquitetural". Os requisitos de SI podem contradizer fundamentalmente os padrões modernos:
Cloud Native? — Não pode, os dados devem estar em um contorno fechado.
Serverless? — Inadmissível, não controlamos o ambiente de execução.
Lançamentos rápidos? — Esqueça, cada commit deve passar por um ciclo de aprovação de uma semana.
Este é o estado de paralisia arquitetural: novas tecnologias são bloqueadas na entrada, e o sistema existente acumula camadas de mecanismos de proteção que o tornam inflexível. Nessas condições, a segurança se torna efetivamente a "morte da inovação", e o arquiteto precisa projetar não a solução ótima, mas a mais "aprovável".
Existe uma opinião alternativa e ela não é desprovida de sentido. Ela afirma que a implementação de tecnologias inseguras não é um avanço inovador, mas a implantação de um MVP não testado em uma arquitetura viva.
Os requisitos de SI apenas delineiam os limites de maturidade do produto, transformando um experimento perigoso em uma solução de negócio sustentável.
Sem dúvida, quando requisitos excessivos de SI bloqueiam a implementação de produtos já testados pelo mercado e pela indústria, isso freia o negócio. No entanto, aqui é importante distinguir: uma coisa é adaptar a prática mundial existente às estruturas de conformidade internas, e outra coisa completamente diferente é apresentar um produto inseguro e não testado como uma inovação completa.
Tragédia do HSM: Quem é o Culpado Quando Tudo Cai?
Um exemplo clássico de colisão entre teoria e prática é a implementação de Hardware Security Modules (HSM). O requisito de SI de armazenar chaves de forma inalienável — absolutamente correto do ponto de vista teórico. Mas quando o sistema cai sob carga porque o HSM se tornou um "gargalo", surge a eterna questão: quem é o culpado?
Especialistas em SI, que exigiram a implementação sem olhar o perfil de carga?
Arquiteto, que não previu o RPS e não "defendeu" a decisão na fase de design?
Negócio, que lançou uma promoção sem perguntar sobre a capacidade de processamento do núcleo criptográfico?
Neste ponto, o impacto da SI na arquitetura atinge o pico: a responsabilidade é distribuída entre todos os participantes do processo, o que na prática significa sua ausência total. A arquitetura se transforma em um refém, onde a SI espera argumentos dos projetistas, e estes, por sua vez, projetam "do avesso", tentando encaixar os requisitos de segurança nas possibilidades reais de hardware e software.
Caminho para a Sinergia
Como vimos, a tentativa de construir a arquitetura exclusivamente "a partir da segurança" leva à criação de uma fortaleza intransponível que é incapaz de se mover e se adaptar às demandas do negócio. Por outro lado, ignorar a SI transforma o sistema em um castelo de cartas. A solução não reside em buscar um compromisso entre segurança e flexibilidade, mas em uma profunda reavaliação dos próprios padrões arquiteturais.
Do Direito de "Veto" ao Shift Left
Tradicionalmente, a SI é percebida como uma instância de controle com direito a veto, que as equipes de projeto tentam "contornar" nas fases finais. Para que a arquitetura não se transforme em um "monólito improvisado" pouco antes do lançamento, é necessário implementar a abordagem Shift Left.
O sentido é simples: os requisitos de segurança devem ser "incorporados" ao sistema na fase de design, e não chegar na fase de aceitação, quando refazer algo já é tarde demais e caro.
Para isso, são críticos:
Troca Constante de Conhecimento: O arquiteto deve entender a lógica das ameaças, e o especialista em SI — as limitações das tecnologias utilizadas (por exemplo, por que um HSM pode se tornar um gargalo).
KPI Comum — "Time to Compliance": Em vez de confronto — uma métrica comum: quão rápido uma decisão arquitetural passa pela auditoria de SI. Isso força ambos os lados a trabalhar na simplificação e automação das verificações.
DevSecOps: Integração de verificações de segurança diretamente no pipeline CI/CD. A segurança deve se tornar uma parte tão natural do processo quanto os testes unitários.
Arquitetura e SI como Serviço para o Produto
Nas discussões intermináveis sobre padrões e ameaças, arquitetos e especialistas em SI frequentemente esquecem a existência de uma "terceira parte" — a equipe de produto. É importante admitir honestamente: nem a arquitetura em si, nem a SI trazem dinheiro para a empresa. Dinheiro traz a feature que o cliente utiliza. Nós somos pessoal de apoio e funções de serviço, cuja tarefa é garantir a sobrevivência dessa feature.
Se a arquitetura e a SI se empolgam com seus próprios jogos, projetando Air Gaps ideais ou um "adaptador" de microsserviços, esquecendo aqueles com quem viverão com isso, elas se tornam um fardo.
Cada decisão "segura" do arquiteto é um peso potencial nas pernas do desenvolvimento. Assim que as regras se tornam muito complexas, o desenvolvedor começa a procurar maneiras de contornar o sistema. Assim nasce a "TI Sombra" (Shadow IT), que, no final, é muito mais perigosa do que qualquer ausência de HSM.
Para não se tornar um freio à inovação, o especialista em SI e o arquiteto devem se unir e criar para a equipe do projeto um conjunto de ferramentas prontas, já aprovadas e testadas, onde toda a complexidade técnica e regulatória está oculta "sob o capô" (Golden Path).
Como funciona:
O desenvolvedor precisa de um banco de dados? Ele não precisa desenvolver esquemas de segmentação ou aprovar portas. Ele aperta um botão e recebe um recurso que já está no contorno desejado, com backups e criptografia configurados.
Critério de Sucesso:
A equipe do projeto deve escrever lógica de negócio, e não se aprofundar nas complexidades dos requisitos de infraestrutura. Se o desenvolvedor precisa passar por 10 círculos de aprovação e configurar 5 gateways proxy para simplesmente lançar um botão — você, como serviço, falhou.
Conclusão
Do Controle ao Design Colaborativo
Para sair do impasse "arquiteto contra SI", é necessário mudar o próprio modelo de interação:
Abordagem Orientada a Riscos: Proteger o que é realmente importante, considerando o custo da proteção versus o custo do risco. Isso elimina "improvisações" excessivas onde não são necessárias.
SI como Serviço: O especialista em SI deve deixar de ser um "inspetor com direito a veto" e começar a fornecer ao arquiteto "blocos seguros" prontos (padrões típicos, bibliotecas testadas, módulos de infraestrutura configurados).
Automação via DevSecOps: Esta é uma boa maneira de remover a subjetividade das aprovações "manuais". Quando as regras de verificação são transparentes e incorporadas ao pipeline, a questão "a SI aprovará ou não" desaparece por si só.
Restrições Claras no Início: O arquiteto precisa de limites técnicos claros e compreensíveis antes de começar a trabalhar na solução, e não proibições abstratas.
Papel do Arquiteto e Responsabilidade Geral
O problema não é a falta de KPIs, mas o conflito de vetores: o arquiteto busca velocidade (Time-to-Market), enquanto o especialista em SI busca segurança (Compliance). A saída aqui é uma só — responsabilidade compartilhada perante o negócio.
O Arquiteto se torna um mediador. Ele deve ser capaz de "vender" soluções para especialistas em SI através de cálculos de carga e propor alternativas seguras ao negócio.
O Especialista em SI senta-se no mesmo barco com os engenheiros, sendo responsável não apenas pela ausência de invasões, mas também por garantir que o sistema funcione de forma rápida e estável, e seja lançado no final.
"Enterprise Integration Patterns" — Gregor Hohpe, Bobby Woolf. Interrupção da comunicação síncrona entre sistemas (tanto em tempo quanto em espaço de rede).
"Designing Data-Intensive Applications" — Martin Kleppmann. Descreve o isolamento de estados de sistemas. Kleppmann explica por que sistemas que leem de filas (modelo Pull) são fundamentalmente mais protegidos contra falhas em cascata e ataques externos.
"Cybersecurity Blue Team Toolkit" — Nadean H. Tanner. Tipos de separação tecnológica de redes (Logical vs. Physical Air Gap).
"Zero Trust Networks" (Evan Gilman, Doug Barth) https://soclibrary.futa.edu.ng/books/Zero trust networks building secure systems in untrusted networks by Barth, Doug Gilman, Evan (z-lib.org).pdf
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
