Recentemente, houve muitas notícias sobre vazamentos aleatórios de vários dados confidenciais de um serviço da Web para hospedar projetos de TI e seu desenvolvimento conjunto pelo GitHub.
Enfatizo que será sobre vazamentos aleatórios, ou seja, por negligência e sem intenção maliciosa por parte dos autores dos incidentes. Reduza esses vazamentos sobre a inexperiência dos funcionários em questões de TI não funcionará, porque Os usuários do GitHub são majoritariamente desenvolvedores, ou seja, pessoal totalmente qualificado e competente. Infelizmente, até mesmo especialistas muito bons às vezes cometem erros triviais, especialmente quando se trata de problemas de segurança. Vamos considerar negligência.
Aqui estão alguns exemplos muito famosos relacionados ao GitHub:
- 2014 - O Uber vazou os dados pessoais de 50 mil de seus motoristas. O motivo foi que, no repositório público do GitHub, os desenvolvedores do Uber salvaram o Amazon Cloud Access Keys (AWS), que, por sua vez, armazenou os mesmos dados perdidos.
- 2017 - verificou-se que os desenvolvedores do fabricante de quadrocopters DJI armazenados no repositório público GitHub a chave privada do certificado SSL da empresa e as chaves AES para criptografar o firmware. Além disso, as credenciais do Amazon Web Services foram armazenadas no local, que, por sua vez, continham registros de voo, dados de passaporte e informações de licença de cliente DJI.
- 2017 - Engenheiro de um importante fornecedor de TI dos EUA, a DXC Technologies enviou as chaves de acesso da AWS ao repositório público do GitHub.
- 2017 - códigos-fonte, relatórios e planos de desenvolvimento para várias grandes instituições financeiras no Canadá, Estados Unidos e Japão, que foram colocados lá por funcionários da empresa indiana de terceirização Tata Consultancy Service, cujos clientes foram afetados por instituições financeiras, foram descobertos no repositório público do GitHub.
Obviamente, todos esses casos de vazamentos não intencionais poderiam ser facilmente evitados pelo monitoramento dos dados enviados ao GitHub. Ninguém fala sobre uma proibição total de acesso ao GitHub, essa é uma idéia sem sentido e até prejudicial (se houver uma proibição, mas o serviço for necessário, os desenvolvedores irão contornar essa proibição). Precisamos de uma solução que evite o vazamento de informações e tenha um analisador de conteúdo em tempo real que impeça o GitHub de carregar apenas dados que não deveriam estar lá por razões de segurança (por exemplo, chaves de acesso à nuvem da Amazon).
Vou mostrar como resolver esse problema específico, usando o DeviceLock DLP como exemplo. Os dados iniciais que temos são os seguintes:
- Conta GitHub,
- Chave da AWS,
- DeviceLock DLP versão 8.3.
Para começar, determinamos que a chave da AWS são os dados protegidos e que eles devem ser impedidos de acessar o GitHub.
Como a chave é um conjunto de bytes sem assinaturas expressas (sim, eu conheço o texto "BEGIN / END PRIVATE KEY" no início e no final, mas essa é uma assinatura muito fraca e é melhor não confiar nela), usaremos a identificação em impressões digitais .
Adicionaremos o arquivo de chave ao banco de dados de impressão digital DeviceLock DLP para que o produto "conheça" nossa chave "pessoalmente" e depois possa identificá-la exclusivamente (e não confundi-la, por exemplo, com chaves de teste que podem ser carregadas no GitHub).
Agora vamos criar uma regra de filtragem de conteúdo para armazenamento de arquivos no DeviceLock DLP (o GitHub se enquadra na nossa classificação "armazenamento de arquivos", na qual, além do GitHub, são suportados mais de 15 serviços diferentes de troca e sincronização de arquivos).
De acordo com esta regra, qualquer usuário é proibido de baixar dados com impressões digitais que correspondam às especificadas acima e, se forem detectados dados proibidos, os eventos correspondentes (registros de incidentes) e cópias de sombra devem ser registrados nos logs de arquivo centralizado, além da execução real da ação com a proibição de baixar dados para o GitHub .
Vamos agora tentar carregar a chave da AWS no repositório do GitHub.
Como você pode ver, o processo de download "por algum motivo" falhou e o DeviceLock DLP nos avisou que ele havia bloqueado essa operação (é claro, a mensagem é personalizável e desativada).
Ao mesmo tempo, se você olhar o log de cópias de sombra DeviceLock DLP, poderá encontrar a mesma chave lá.
Portanto, este exemplo mostrou como usar o DeviceLock DLP para resolver o problema específico de impedir o vazamento de dados confidenciais (impressões digitais podem ser obtidas de quase qualquer arquivo) para o armazenamento na nuvem.
Obviamente, além de impedir o vazamento de dados no GitHub, você também pode inventariar periodicamente repositórios e identificar informações neles que não deveriam estar lá. Com o objetivo de verificar os repositórios do GitHub, foram criados os utilitários gratuitos Gittyleaks, Git Secrets, Git Hound, Truffle Hog e muitos outros.