FGCyberSec
Laboratório de engenharia de segurança
Organizações que operam na internet tendem a acumular ativos, integrações e dependências mais rápido do que conseguem registrá-los. É nessa diferença — entre o que existe e o que se sabe que existe — que a exposição se forma.
Um domínio registrado há anos. Um subdomínio criado para um teste e nunca removido. Um painel administrativo acessível pela internet, sem restrição de rede. Uma integração via API que continuou ativa depois que o projeto terminou. Alguns desses itens são falhas de configuração isoladas; outros só passam a importar quando somados. O conjunto forma a superfície de ataque: os pontos por onde é possível interagir com os sistemas de uma organização, inclusive por quem já recebeu algum nível de acesso.
Parte dessa superfície fica em serviços de terceiros: e-mail, hospedagem, CRM, meios de pagamento, ferramentas de suporte. A responsabilidade nesses serviços é dividida, e a divisão nem sempre está explícita. O fornecedor opera a infraestrutura; o cliente normalmente administra contas, permissões, MFA, integrações via OAuth, chaves de API e prazos de retenção. Contratar um operador não transfere a responsabilidade sobre essas escolhas.
Entre esses sistemas existem relações de confiança. Um serviço aceita asserções emitidas por um provedor de identidade. Um processo roda com permissões herdadas. Um fornecedor mantém acesso administrativo concedido durante a implantação. Os lugares onde o nível de confiança muda são as fronteiras de confiança (trust boundaries). Modelagem de ameaças começa por identificá-las, porque é nelas que um problema restrito a um sistema passa a afetar os outros.
Levantar isso é, em boa parte, trabalho de observação: registros de Certificate Transparency, consultas de DNS público, cabeçalhos de resposta HTTP, metadados de certificados. O material é público e observável de fora. O trabalho está em registrar o que foi verificado, por qual método e em qual data, e em manter esse registro atualizado.
SEC.03 Ver a superfície exposta em um ambiente de referência
O diagrama abaixo descreve um arranjo comum em pequenas e médias empresas brasileiras. Ele não mostra falhas: mostra onde o nível de confiança muda entre um sistema e outro, que é onde um problema contido em um deles passa a alcançar os demais.
O diagrama mostra oito elementos de um ambiente hipotético. A empresa opera diretamente quatro deles: o site institucional, o domínio com sua conta de registro e zona DNS, o console de nuvem que hospeda o site, e o acesso administrativo da equipe. Fora do limite que ela opera estão o e-mail corporativo e o SaaS de CRM, ambos contratados em nuvem, além do fornecedor externo de TI, que é uma pessoa com acesso e não um sistema. Um visitante do site aparece como origem dos dados.
Os dados de contato seguem do visitante para o site e, de lá, por integração via API, para o SaaS de CRM. A zona DNS determina qual servidor responde pelo site e para onde chega o e-mail do domínio. A recuperação de conta do console de nuvem passa pelo e-mail do domínio. O console, a equipe e o fornecedor externo têm acesso administrativo à infraestrutura do site.
Três pontos estão marcados. M1: o acesso administrativo do fornecedor continua válido depois do fim do projeto. M2: controlar o registro do domínio ou a zona DNS permite redirecionar o site, receber o e-mail e obter certificados TLS válidos, o que alcança também a recuperação de contas. M3: os dados do formulário saem do ambiente operado pela empresa e passam a ser tratados por um operador, possivelmente fora do Brasil.
A topologia é ilustrativa e os marcadores são categorias de exposição, não vulnerabilidades identificadas.
As quatro áreas a seguir descrevem o escopo técnico que este laboratório estuda e testa em ambientes próprios e de referência. Nenhuma delas corresponde a um serviço comercial já entregue a terceiros; cada uma indica o que a área abrange, o que costuma ser observado nela, e que tipo de exposição ajuda a entender.
Refere-se ao conjunto de pontos por onde um sistema pode ser alcançado a partir da internet: domínios, subdomínios, serviços expostos, portas abertas, certificados e integrações com algum nível de acesso. O levantamento nessa área observa o que está publicamente descobrível — registros de DNS, Certificate Transparency, cabeçalhos de resposta HTTP, metadados de infraestrutura — e organiza esse material em um inventário verificável. O resultado ajuda a entender exposição não identificada: ativos esquecidos, configurações herdadas e acessos que continuam válidos além do que deveriam.
Trata da camada onde um sistema recebe entrada de usuários e processa lógica de negócio: formulários, autenticação, APIs, upload de arquivos, gerência de sessão. A avaliação examina como a aplicação trata entrada não confiável, como autoriza cada operação e como isola dados entre contas distintas. Compreender essa camada evidencia falhas de validação, controle de acesso quebrado e configuração insegura — categorias descritas em referências como o OWASP Top 10.
Envolve como a infraestrutura hospedada em provedores de nuvem é configurada: permissões entre contas e serviços, políticas de rede, chaves de acesso, armazenamento e o modelo de responsabilidade compartilhada entre provedor e cliente. A avaliação observa a configuração efetivamente aplicada — não apenas a política documentada — e como ela se compara às práticas de referência do provedor. Isso ajuda a identificar exposição criada por configuração, como armazenamento acessível publicamente ou permissões mais amplas do que a função exige.
É a disciplina que examina as três áreas anteriores de forma estruturada, combinando levantamento técnico, análise manual e, quando aplicável, verificação automatizada. Cobre desde o reconhecimento inicial de um alvo até o registro de evidências e a validação de que um ajuste efetivamente reduziu a exposição encontrada — sempre com escopo, técnica e resultado documentados o suficiente para que o trabalho possa ser revisado por outra pessoa.
A sequência abaixo organiza como este laboratório conduz o trabalho descrito na seção anterior: não é um método proprietário, é uma sequência de engenharia comum na área, adaptada ao que o laboratório efetivamente pratica em ambientes próprios e de referência.
Levantamento do que existe e pode ser observado externamente: domínios, subdomínios, serviços expostos, certificados, cabeçalhos e metadados públicos.
— inventário inicial dos ativos identificados, com a fonte e o método de cada verificação registrados.
Organização do inventário em relações: o que cada ativo faz, quem o opera, e onde estão as fronteiras de confiança entre sistemas e terceiros — como as descritas na Fig. 01.
— mapa de exposição indicando pontos onde o nível de confiança muda entre sistemas.
Análise técnica de cada ponto mapeado, combinando revisão manual e verificação automatizada quando aplicável, para determinar se a exposição observada representa um problema real e qual seu alcance.
— hipóteses de risco priorizadas por exposição e impacto potencial, não por gravidade genérica.
Aplicação de ajustes técnicos que reduzem a exposição identificada — restrição de acesso, remoção de ativos obsoletos, correção de configuração — seguindo o princípio de privilégio mínimo.
— ajuste técnico aplicado e documentado, com o estado anterior preservado para referência.
Confirmação de que o ajuste realmente reduziu a exposição, repetindo a técnica de observação usada no estágio de descoberta sobre o mesmo ponto.
— evidência de verificação — o mesmo tipo de observação, feita antes e depois do ajuste, comparável entre si.
Mesmo sem formulários, contas de usuário ou rastreamento, o simples ato de carregar esta página gera processamento de dados que podem se relacionar a uma pessoa identificável. A figura abaixo traça esse fluxo tal como a arquitetura atual do site realmente funciona — não uma arquitetura hipotética, nem o comportamento de uma versão futura com mais funcionalidades.
O diagrama mostra três estágios. O navegador da pessoa que visita o site inicia a conexão. Essa conexão chega primeiro à borda da rede da Cloudflare, o provedor de CDN e proteção de borda usado por este site: dependendo da configuração e de qual datacenter atende a conexão, a borda pode responder diretamente com uma cópia em cache do conteúdo ou encaminhar a solicitação até a origem, onde os arquivos estáticos do site estão hospedados. A resposta retorna pelo mesmo caminho, em sentido inverso.
Em qualquer solicitação HTTP comum, essa passagem envolve, no mínimo, o endereço IP de quem conecta, informações do user-agent (navegador e sistema operacional declarados), a URL solicitada e o horário da requisição. Esses dados são inerentes ao funcionamento de HTTP e de uma rede de borda: não são coletados por um script deste site, porque este site não executa nenhum script no navegador.
A travessia marcada como TB.02 indica a passagem entre o dispositivo da pessoa titular e a infraestrutura operada por terceiros. Isso pode envolver processamento fora do Brasil, dependendo de qual datacenter atende a conexão; os detalhes de retenção, papéis de controlador e operador, e mecanismo de transferência internacional dependem da configuração efetivamente aplicada e dos termos contratuais e de privacidade desses provedores, e precisam ser verificados diretamente nessas fontes antes de qualquer afirmação de conformidade.
Esta seção descreve o comportamento técnico observável da versão atual do site. Ela não constitui uma declaração de conformidade com a LGPD: essa análise depende de fatores contratuais e operacionais que precisam ser verificados separadamente, incluindo os associados aos provedores de infraestrutura utilizados.
Abordar, aqui, significa estudar, documentar e testar em ambiente próprio. Não significa prestar serviço nem executar avaliação em sistemas de terceiros. Testes são realizados apenas em sistemas deste projeto ou com autorização explícita de quem responde pelo sistema.
As notas abaixo documentam decisões técnicas específicas deste projeto — não um blog. Cada uma é sustentada por uma verificação que pode ser refeita a partir do próprio código ou do build atual.
A build gera HTML estático via renderToStaticMarkup e não inclui nenhum ponto de entrada JavaScript no cliente. Como nenhuma seção depende de estado interativo, não há necessidade de reidratar a árvore React no navegador: o HTML produzido no build já é o resultado final servido.
IBM Plex Sans e Mono são servidas como arquivos woff2 locais, em subconjunto Latin-1, com uma face de fallback com métricas ajustadas para não deslocar o layout durante a troca de fonte. Nenhuma fonte é carregada de um provedor externo.
Content-Security-Policy não estava configurada antes da implantação — isso pertencia à etapa de implantação na Cloudflare. Mas o código evita, desde o início, os padrões que normalmente forçam exceções nela: nenhum atributo style inline, nenhum uso de dangerouslySetInnerHTML, atributos de apresentação em vez de style em cada SVG. A decisão arquitetural foi tomada antes da implantação, e o cabeçalho está configurado e verificado em produção.
As seções anteriores descrevem exposição de forma geral. Esta encerra o documento reportando sobre o próprio site: como ele é construído e o que, neste momento, pode ser verificado sobre sua postura de borda.
fgcybersec.com.br está em produção em https://fgcybersec.com.br/; www.fgcybersec.com.br redireciona (301) para o domínio canônico. A tabela abaixo registra o estado, verificado diretamente na resposta HTTP, dos controles de borda configurados nesta implantação.
| Controle | Estado |
|---|---|
| TLS / HTTPS | ATIVO — verificado |
| DNSSEC | ATIVO — verificado |
| HSTS | ATIVO — verificado |
| Content-Security-Policy | ATIVO — verificado |
| Cabeçalhos de resposta adicionais | ATIVO — verificado |
| Bot Fight Mode / JavaScript Detections | DESABILITADO — deliberado |
«TLS / HTTPS» reúne modo de criptografia Full, versão mínima TLS 1.2, TLS 1.3 habilitado, 0-RTT desabilitado e certificado Universal SSL válido, incluindo o redirecionamento HTTP → HTTPS ativo no domínio canônico e em www.fgcybersec.com.br — que redireciona (301, preservando caminho e query string) para https://fgcybersec.com.br/. HSTS está ativo com max-age de 15552000 segundos (180 dias); includeSubDomains e preload não foram habilitados nesta primeira ativação.
Content-Security-Policy aplica default-src 'none', com exceções restritas a 'self' apenas para estilos, imagens e fontes. «Cabeçalhos de resposta adicionais» reúne X-Content-Type-Options, Referrer-Policy, Permissions-Policy, X-Frame-Options, Cross-Origin-Opener-Policy e Cross-Origin-Resource-Policy, todos observados na resposta de produção.
Bot Fight Mode e JavaScript Detections foram desligados deliberadamente para preservar a arquitetura de zero JavaScript no cliente — é uma escolha arquitetural, não um reforço de segurança, e não implica proteção equivalente contra tráfego automatizado. Browser Integrity Check permanece ativo. Os estados acima foram observados diretamente na resposta HTTP de produção em 11 ago. 2026; fgcybersec.com.br não passou por auditoria de segurança externa independente.
As ausências de processamento descritas na SEC.06 — analytics, cookies opcionais, armazenamento no cliente, formulário — são processamento deliberadamente desenhado para fora do sistema, não configurações pendentes.