Central de segurança e confiança

Nosso programa público de recompensas por bugs , promovido pelo HackerOne, permite que um coletivo global de pesquisadores de segurança cibernética e testadores de penetração testem a Databricks em busca de vulnerabilidades de segurança. Algumas das principais decisões que tomamos para tornar o programa bem-sucedido incluem:

• Incentivar uma comunidade engajada de hackers a ser ativa em nosso programa, fornecendo transparência às estatísticas de nosso programa HackerOne, como taxa de resposta e pagamentos
• Responder prontamente aos envios de recompensas por bugs, com um tempo médio de entrega da recompensa de menos de uma semana
• Realizar análise de variantes em cada envio válido para identificar maneiras alternativas de usar um exploit e verificar 100% das correções
• Adicionar bônus que direcionam a atenção para as áreas mais importantes do produto

Trabalhamos duro para que nosso programa seja bem-sucedido e para aprender com cada envio. Com a abordagem aberta e colaborativa de nosso programa de recompensa de bugs, mais de 100 pesquisadores de segurança foram reconhecidos por mais de 200 relatórios. Obrigado a todos vocês por nos ajudarem a manter a Databricks segura!

Queremos que nossos clientes tenham confiança nos workloads que executam na Databricks. Se sua equipe quiser realizar uma verificação de vulnerabilidade ou um teste de penetração na Databricks, recomendamos que:

1. Execute verificações de vulnerabilidade em sistemas de plano de dados localizados dentro da sua conta de provedor de serviços de nuvem.
2. Realize testes em relação ao seu código, desde que esses testes estejam inteiramente contidos no plano de dados (ou em outros sistemas) localizado em sua conta de provedor de serviços de nuvem e estejam avaliando seus controles.
3. Junte-se ao programa de recompensas por bugs da Databricks para acessar uma implantação dedicada da Databricks para realizar testes de penetração. Qualquer teste de penetração em nosso plano de controle multi-tenant requer participação no programa.

A Databricks utiliza um Portal de ideias que rastreia as solicitações de recursos e permite votar tanto para clientes quanto para funcionários. Nosso processo de design de recursos inclui privacidade e segurança por design. Após uma avaliação inicial, os recursos de alto impacto estão sujeitos a uma revisão de design de segurança da equipe de segurança do produto em associação com os campeões de segurança da engenharia, juntamente com modelagem de ameaças e outras verificações específicas de segurança.

Usamos uma metodologia de desenvolvimento ágil que divide novos recursos em vários sprints. A Databricks não terceiriza o desenvolvimento da plataforma Databricks, e todos os desenvolvedores devem passar por treinamento de desenvolvimento de software seguro, incluindo o OWASP Top 10, quando contratados e anualmente a partir de então. Os dados e ambientes de produção são separados dos ambientes de desenvolvimento, controle de qualidade e preparação. Todo o código é verificado em um sistema de controle de origem que requer logon único com autenticação multifator e permissões granulares. Os merges de código exigem a aprovação dos proprietários de engenharia funcional de cada área afetada e todo o código é revisado por pares. A equipe de segurança do produto revisa manualmente o código de segurança confidencial para eliminar erros de lógica de negócios.

Usamos as melhores ferramentas do mercado para identificar pacotes ou códigos vulneráveis. A automação em um ambiente de pré-produção executa verificações autenticadas de vulnerabilidade de contêiner e host do sistema operacional e dos pacotes instalados, juntamente com verificações de análise de código dinâmicas e estáticas. Os tíquetes de engenharia são criados automaticamente para quaisquer vulnerabilidades e atribuídos a equipes relevantes. A equipe de segurança do produto também detecta vulnerabilidades críticas para avaliar sua gravidade na arquitetura Databricks.

Realizamos verificações de qualidade (como testes unitários e testes de ponta a ponta) em vários estágios do processo SDLC, incluindo merge de código, após merge de código, no lançamento e em produção. Nossos testes incluem testes positivos, de regressão e negativos. Uma vez implementado, temos um amplo monitoramento para identificar falhas, e os usuários podem receber alertas sobre a disponibilidade do sistema por meio da Página de status. No caso de qualquer problema com P0 ou P1, a automação Databricks desencadeia uma metodologia de análise de causa raiz "5 porquês" que seleciona um membro da equipe para supervisionar a revisão. Os achados são comunicados à liderança executiva e os itens de acompanhamento são monitorados.

A Databricks tem um processo formal de gerenciamento de versão que inclui uma decisão formal de ir em frente/não ir antes de liberar o código. As alterações passam por testes projetados para evitar regressões e confirmar que a nova funcionalidade foi testada em workloads realistas. Além disso, há uma implementação em etapas com monitoramento para identificar problemas antecipadamente. Para implementar a separação de tarefas, apenas nosso sistema de gerenciamento de implantação pode liberar alterações para produção, e a aprovação de várias pessoas é necessária para todas as implantações.

Seguimos um modelo de infraestrutura imutável, onde os sistemas são substituídos, em vez de corrigidos, para melhorar a confiabilidade e a segurança e evitar o risco de drift da configuração. Quando novas imagens do sistema ou código do aplicativo são iniciados, transferimos workloads para novas instâncias que são iniciadas com o novo código. Isso ocorre tanto para o plano de controle quanto para o plano de dados (consulte a seção Recursos de segurança para mais sobre a arquitetura Databricks). Quando o código está em produção, um processo de verificação confirma que os artefatos não são adicionados, removidos ou alterados sem autorização.

A fase final do processo SDLC é a criação de documentação voltada ao cliente. Os documentos da Databricks são gerenciados da mesma forma que nosso código-fonte, e a documentação é armazenada no mesmo sistema de controle do código-fonte. Mudanças significativas exigem revisão da equipe técnica e de documentos antes que possam passar pelo merge e ser publicadas.
Visite a documentação →