Mentoria de carreira em TI: o perigo das chaves de API no GitHub e como proteger credenciais no seu código desde a faculdade

Quando estamos desenvolvendo nossos primeiros projetos na faculdade ou criando um portfólio para apresentar em entrevistas de emprego, é muito comum focarmos apenas em “fazer o código funcionar”. No entanto, existe um erro simples e extremamente frequente que pode custar caro e comprometer a reputação de quem está começando na área: colocar senhas, tokens de acesso e chaves de API diretamente no código-fonte (hardcoded) e subir esse projeto para um repositório público no GitHub.

No momento em que você envia um código contendo uma chave de acesso (como uma credencial da AWS, OpenAI ou um banco de dados) para um repositório aberto, robôs automatizados (scanners) que varrem a internet identificam essa chave em questão de segundos. Se a chave der acesso a um serviço pago de nuvem, esses agentes maliciosos podem usá-la para criar servidores de mineração de criptomoedas, gerando contas astronômicas em seu nome ou vazando os dados da aplicação.

Para evitar esse tipo de incidente e demonstrar maturidade profissional nos seus projetos acadêmicos, adote a disciplina de Segurança no Desenvolvimento através de duas práticas fundamentais:

Utilize Variáveis de Ambiente (.env): nunca escreva senhas ou chaves diretamente no arquivo de código (.js, .py, .java). Crie um arquivo separado chamado .env para armazenar suas credenciais e faça com que o seu código leia esses valores a partir do sistema operacional.

Configure o arquivo .gitignore: antes de fazer o seu primeiro envio (git commit), inclua o arquivo .env dentro do seu .gitignore. Isso garante que as suas senhas permaneçam apenas no seu computador e nunca sejam enviadas para a nuvem pública.

    Aprender a gerenciar credenciais de forma segura desde os primeiros semestres do curso não apenas protege os seus recursos, mas também mostra aos recrutadores e gestores de TI que você já possui a mentalidade e o cuidado de um desenvolvedor maduro. Adote esse hábito hoje mesmo!

    De Data Lakes concentrados à arquitetura Data Mesh: desafios de governança e segurança para o C-Level na gestão de Big Data

    Durante a última década, a estratégia de dados de grande parte das corporações esteve centrada na consolidação de arquiteturas de Data Warehouse e Data Lake em ambientes de nuvem. No entanto, para os líderes do C-Level (CIOs, CDOs e CISOs), o modelo de centralização absoluta do Big Data passou a apresentar gargalos operacionais severos. A dependência de um time central de engenharia de dados para processar, tratar e disponibilizar informações para diferentes unidades de negócio criou um ponto único de falha, desacelerando a tomada de decisões e reduzindo a eficiência organizacional.

    Para superar essas limitações de escala, o paradigma arquitetural do Data Mesh (Malha de Dados) tem ganhado destaque nas discussões de liderança executiva. Fundamentado em quatro pilares — Domínio de Dados descentralizado, Dados como Produto, Plataforma de Dados de Autoatendimento e Governança Computational Federada —, o Data Mesh transfere a responsabilidade da gestão dos dados para as próprias equipes de domínio de negócio que geram a informação.

    Sob a perspectiva da governança corporativa e gestão de riscos, a transição para um modelo descentralizado exige cuidados rigorosos do C-Level. Para evitar o surgimento de silos isolados e o descumprimento de normas regulatórias (como LGPD e GDPR), a liderança deve instituir o conceito de Governança Federada. Isso significa que, embora os negócios tenham autonomia para criar seus “produtos de dados”, os controles de criptografia, controle de acesso baseado em funções (RBAC/ABAC), anonimização e linhagem de dados (Data Lineage) devem ser padronizados e automatizados em nível corporativo por meio de políticas codificadas (Policy-as-Code).

    Ao adotar o Data Mesh com uma governança federada sólida, a alta gestão assegura a democratização do Big Data com agilidade operacional, sem abrir mão do controle de segurança e da conformidade exigir pelo conselho de administração.

    Compreendendo o DLL Side-Loading: a arte da evasão de defesas através da confiança em binários legítimos

    No ecossistema da segurança defensiva (Blue Team) e das simulações de ataque (Red Team), o desvio e a evasão de soluções tradicionais de detecção — como antivírus baseados em assinatura (AV) e plataformas de resposta em endpoint (EDR) — constituem um campo de estudo contínuo. Entre as técnicas de evasão mais refinadas e amplamente exploradas por grupos de ameaças persistentes avançadas (APTs), destaca-se o DLL Side-Loading (ou carregamento lateral de bibliotecas de vinculação dinâmica).

    A vulnerabilidade não reside primariamente em uma falha de estouro de memória, mas sim na lógica de busca e ordenação de dependências executada pelo sistema operacional Windows no carregamento de aplicações. Quando um processo executável (.exe) é iniciado, ele frequentemente requisita bibliotecas externas para a execução de funções específicas. Se o programa não especifica o caminho absoluto (Fully Qualified Domain/Path) da biblioteca necessária, a API do sistema operacional busca a DLL na seguinte ordem prioritária: primeiro no próprio diretório de onde o executável foi lançado e, subsequentemente, nos diretórios do sistema (System32, SysWOW64).

    Agentes de ameaça exploram esse comportamento posicionando um arquivo executável legítimo, homologado e assinado digitalmente por uma entidade confiável na mesma pasta de uma biblioteca maliciosa construída com o mesmo nome e exportações de funções da DLL original. Ao disparar o executável confiável, o sistema operacional carrega a DLL maliciosa local antes de buscar a versão autêntica do sistema. Como a execução ocorre sob o contexto de memória de um processo legítimo e assinado, as ferramentas de monitoramento de comportamento frequentemente falham em sinalizar a anomalia.

    Para mitigar os riscos associados ao DLL Side-Loading, equipes de arquitetura de segurança e auditoria devem implementar controles de endurecimento (hardening) baseados na imposição de mecanismos como o Safe DLL Search Mode, a assinatura digital obrigatória de dependências via Code Integrity, o monitoramento do carregamento de DLLs não assinadas por processos confiáveis através de regras de Event Tracing for Windows (ETW) e a restrição de gravação de arquivos por usuários não privilegiados em diretórios de execução. O entendimento detalhado dessa mecânica é indispensável para formar analistas capazes de antecipar táticas de persistência e evasão no ambiente corporativo.

    Análise forense do banco de dados SRUM no Windows: identificação de exfiltração de dados e telemetria de processos clandestinos

    No âmbito da investigação pericial de incidentes de segurança da informação e vazamento de dados (Data Exfiltration), a identificação da autoria e da volumetria de dados exfiltrados por agentes maliciosos frequentemente enfrenta o obstáculo da eliminação intencional de logs de auditoria primários. No entanto, o sistema operacional Windows (a partir da versão 8.1, consolidado no Windows 10 e 11) mantém um mecanismo nativo de monitoramento contínuo denominado System Resource Usage Monitor (SRUM). Armazenado no banco de dados Extensible Storage Engine (ESE) localizado em %SystemRoot%\System32\SRUM\SRUDB.dat, esse artefato constitui uma fonte de evidência pericial de altíssima relevância probatória.

    O valor forense do SRUM reside na sua capacidade de registrar, em intervalos regulares de 60 minutos, métricas granulares de consumo de recursos por cada identificador de aplicação (AppId) e Security Identifier (SID) de usuário. Dentre os parâmetros preservados pelo mecanismo, destacam-se a volumetria exata de dados enviados e recebidos pela interface de rede (distinguindo entre conexões Ethernet, Wi-Fi e redes móveis), o tempo acumulado de execução do processo em primeiro e segundo plano, e o consumo de energia da CPU.

    Em cenários periciais onde binários maliciosos ou utilitários de movimentação lateral e tunelamento (como ferramentas de proxiamento ou exfiltração via protocolos não convencionais) foram sumariamente expurgados do volume lógico pelo atacante, o parsing estruturado da base SRUDB.dat viabiliza a reconstituição do nexo de causalidade. A correlação entre o hash do executável (preservado em artefatos complementares como o Amcache.hve) e os registros de bytes transmitidos gravados no SRUM permite ao perito computacional demonstrar, matematicamente e com precisão temporal, o exato volume de dados exfiltrados do ativo investigado.

    A validação das evidências extraídas do SRUM fortalece a elaboração de laudos periciais e pareceres técnicos alinhados à norma ABNT NBR ISO/IEC 27037. Ao converter dados brutos de telemetria de recursos em prova material incontestável de tráfego de dados não autorizado, a perícia digital provê o suporte técnico rigoroso exigido em litígios judiciais, auditorias de conformidade regulatória e investigações de violação de propriedade intelectual.

    Guia de sobrevivência digital – Capítulo 18: o golpe do falso Pix e como proteger suas vendas e transações familiares

    O Pix revolucionou a forma como os brasileiros realizam pagamentos, trazendo agilidade e praticidade para o cotidiano. No entanto, a mesma velocidade que facilita o comércio também tem sido explorada por criminosos para aplicar fraudes presenciais e virtuais. No Capítulo 18 do nosso Guia de Sobrevivência Digital — desenvolvido em linguagem didática e acessível —, abordamos o golpe do falso Pix e do comprovante agendado.

    Essa fraude costuma afetar pequenos comerciantes, prestadores de serviço e pessoas que estão vendendo móveis, eletrônicos ou itens usados na internet. A abordagem acontece de duas formas principais:

    O Pix agendado ou editado: o comprador faz o agendamento da transferência para uma data futura e exibe a tela do celular com o comprovante. A vítima lê o título “Comprovante de Transferência”, não se atenta à palavra “Agendado” no topo da imagem e entrega o produto. Logo após sair do local, o golpista cancela o agendamento no aplicativo do banco dele.

    O golpe do Pix “em dobro” ou “do troco”: o golpista simula a transferência de um valor maior do que o combinado (por exemplo, envia um comprovante falso de R$ 500 para uma compra de R$ 50) e alega desesperadamente ter cometido um erro. Ele pede para a vítima devolver a “diferença” de R$ 450 na hora, via Pix ou em dinheiro vivo. A pessoa, agindo de boa-fé, faz a devolução antes de checar a própria conta e descobre mais tarde que o pagamento original jamais existiu.

      O insight humano: pense na apresentação de um comprovante de agendamento como se alguém te entregasse um pedaço de papel com o valor escrito à mão e prometesse: “Pode me entregar o produto agora, porque amanhã esse papel vai virar dinheiro no seu bolso”. Ninguém aceitaria uma promessa dessa no comércio tradicional. Na tecnologia, a regra é idêntica: comprovante na tela não é dinheiro na conta.

      Como proteger suas transações e vendas contra o Falso Pix:

      Confie apenas no seu próprio aplicativo do banco: nunca entregue um produto ou conclua um serviço baseando-se apenas na foto ou no comprovante mostrado na tela do comprador. Abra o aplicativo do seu banco e confirme se o valor entrou no seu saldo disponível.

      Entenda a diferença entre “Agendado” e “Realizado”: um comprovante de Pix agendado não garante o pagamento. Ele pode ser cancelado pelo pagador a qualquer momento antes da data estipulada.

      Mantenha a calma diante de supostos “erros”: se o comprador alegar que enviou dinheiro a mais por engano, não faça nenhuma devolução imediata. Verifique calmamente o extrato da sua conta. Se o saldo não mudou, nada foi transferido.

      Ative as notificações de recebimento do Pix: a maioria dos aplicativos bancários envia uma notificação push no celular no exato segundo em que uma transferência Pix entra na conta. Acostume-se a esperar por esse aviso oficial.

        Com atenção aos detalhes e sem ceder à pressa do momento, mantemos a nossa vida financeira protegida contra armadilhas e garantimos a paz nas nossas negociações.

        Compartilhe este capítulo no grupo da família e com os amigos que possuem pequenos negócios! A prevenção coletiva é o melhor remédio contra a fraude.

        Um Domingo abençoado, de muito descanso e serenidade em família para todos!