Visão geral do desenvolvimento e das operações de segurança
Como a Microsoft implementa práticas de desenvolvimento seguras?
O SDL (Security Development Lifecycle) da Microsoft é um processo de garantia de segurança focado no desenvolvimento e operação de software seguro. O SDL fornece requisitos de segurança detalhados e mensuráveis para desenvolvedores e engenheiros da Microsoft reduzirem o número e a gravidade das vulnerabilidades em nossos produtos e serviços. Todas as equipes de desenvolvimento de software da Microsoft devem seguir os requisitos de SDL e atualizamos continuamente o SDL para refletir o cenário de ameaças em mudança, as melhores práticas do setor e os padrões regulatórios para conformidade.
Como o SDL da Microsoft melhora a segurança do aplicativo?
O processo de SDL na Microsoft pode ser pensado em termos de cinco fases de desenvolvimento: requisitos, design, implementação, verificação e versão. Ele começa definindo requisitos de software com a segurança em mente. Para cumprir essa meta, fazemos perguntas relevantes para a segurança sobre o que o aplicativo deve realizar. O aplicativo precisa coletar dados confidenciais? O aplicativo executará tarefas confidenciais ou importantes? O aplicativo precisa aceitar a entrada de fontes não confiáveis?
Depois que os requisitos de segurança relevantes forem identificados, projetamos nosso software para incorporar recursos de segurança que atendam a esses requisitos. Nossos desenvolvedores implementam requisitos de SDL e design no código, que verificamos por meio de revisão manual de código, ferramentas de segurança automatizadas e testes de penetração. Por fim, antes que o código possa ser lançado, novos recursos e alterações materiais passam por revisão final de segurança e privacidade para garantir que todos os requisitos sejam atendidos.
Como a Microsoft testa o código-fonte para vulnerabilidades comuns?
Para dar suporte aos nossos desenvolvedores na implementação de requisitos de segurança durante o desenvolvimento de código e após o lançamento, a Microsoft fornece um pacote de ferramentas de desenvolvimento seguro para verificar automaticamente o código-fonte em caso de falhas e vulnerabilidades de segurança. A Microsoft define e publica uma lista de ferramentas aprovadas para nossos desenvolvedores usarem, como compiladores e ambientes de desenvolvimento, juntamente com as verificações de segurança internas executadas automaticamente nos pipelines de build da Microsoft. Nossos desenvolvedores usam as versões mais recentes das ferramentas aprovadas para aproveitar os novos recursos de segurança.
Antes que o código possa ser verificado em um branch de versão, o SDL requer revisão manual de código por um revisor separado. Os revisores de código verificam se há erros de codificação e se as alterações no código atendem aos requisitos de SDL e de design, passam nos testes funcionais e de segurança e têm um desempenho confiável. Eles também analisam a documentação, configurações e dependências associadas para garantir que as alterações no código sejam documentadas de forma adequada e não causem efeitos colaterais indesejados. Se um revisor encontrar problemas durante a revisão do código, ele pode pedir ao remetente para reenviar o código com as alterações sugeridas e testes adicionais. Os revisores de código também podem decidir bloquear totalmente o check-in de código que não atenda aos requisitos. Depois que o código for considerado satisfatório pelo revisor, o revisor fornecerá a aprovação, que é necessária para que o código possa prosseguir para a próxima fase de implantação.
Além de ferramentas de desenvolvimento seguras e revisão manual de código, a Microsoft impõe requisitos de SDL usando ferramentas de segurança automatizadas. Muitas dessas ferramentas são incorporadas ao pipeline de commit e analisam automaticamente o código para falhas de segurança à medida que ele é verificado e à medida que novos builds são compilados. Exemplos incluem a análise de código estático para falhas de segurança comuns e scanners de credencial que analisam código para segredos inseridos. Os problemas descobertos pelas ferramentas de segurança automatizadas devem ser corrigidos antes que novos builds possam passar pela revisão de segurança e serem aprovados para lançamento.
Como a Microsoft gerencia o software de código aberto?
A Microsoft adotou uma estratégia de alto nível para gerenciar a segurança de software livre, que usa ferramentas e fluxos de trabalho projetados para:
- Entender quais componentes de software livre estão sendo usados em nossos produtos e serviços.
- Acompanhar onde e como esses componentes são usados.
- Determinar se esses componentes têm vulnerabilidades.
- Responder corretamente quando forem descobertas vulnerabilidades que afetam esses componentes.
As equipes de engenharia da Microsoft mantêm a responsabilidade pela segurança de todos os softwares livres incluídos em um produto ou serviço. Para obter essa segurança em escala, a Microsoft criou recursos essenciais em sistemas de engenharia por meio do CG (Component Governance), que automatiza a detecção de software livre, os fluxos de trabalho de requisitos legais e o alerta para componentes vulneráveis. Ferramentas de CG automatizadas verificam builds na Microsoft para componentes de código aberto e vulnerabilidades de segurança associadas ou obrigações legais. Os componentes descobertos são registrados e enviados para as equipes apropriadas para revisões de negócios e segurança. Essas revisões foram projetadas para avaliar quaisquer obrigações legais ou vulnerabilidades de segurança associadas a componentes de software livre e resolvê-las antes de aprovar componentes para implantação.
Regulamentos externos relacionados & certificações
Os serviços online da Microsoft são auditados regularmente para conformidade com regulamentos e certificações externas. Consulte a tabela a seguir para validação de controles relacionados ao desenvolvimento e à operação de segurança.
Azure e Dynamics 365
| Auditorias externas | Section | Data do relatório mais recente |
|---|---|---|
| ISO 27001/27002 Instrução de Aplicabilidade Certificado |
A.12.1.2: Controles de gerenciamento de alterações A.14.2: Segurança nos processos de desenvolvimento e suporte |
6 de novembro de 2023 |
| ISO 27017 Instrução de Aplicabilidade Certificado |
A.12.1.2: Controles de gerenciamento de alterações A.14.2: Segurança nos processos de desenvolvimento e suporte |
6 de novembro de 2023 |
| SOC 1 SOC 2 SOC 3 |
SDL-1: metodologia SDL (Ciclo de Vida do Desenvolvimento de Segurança) SDL-2: requisitos de controle de segurança documentados em versões SDL-4: Segregação de ambientes de teste e produção SDL-6: verificações de malware em builds de código-fonte SDL7: Revisão semestral do SDL |
17 de novembro de 2023 |
Microsoft 365
| Auditorias externas | Section | Data do relatório mais recente |
|---|---|---|
| FedRAMP (Office 365) | SA-3: Ciclo de vida do desenvolvimento do sistema | 31 de julho de 2023 |
| ISO 27001/27002/27017 Instrução de Aplicabilidade Certificação (27001/27002) Certificação (27017) |
A.12.1.2: Controles de gerenciamento de alterações A.14.2: Segurança nos processos de desenvolvimento e suporte |
março de 2024 |
| SOC 1 SOC 2 |
CA-03: Gerenciamento de riscos CA-18: Gerenciamento de alterações CA-19: Alterar o monitoramento CA-21: alterar o teste CA-38: configurações de linha de base CA-46: Revisão de segurança |
23 de janeiro de 2024 |
Recursos
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de