Descrição geral do desenvolvimento e operações de segurança
Como é que 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 equipas de desenvolvimento de software da Microsoft têm de seguir os requisitos de SDL e atualizamos continuamente o SDL para refletir o panorama das ameaças em mudança, as melhores práticas do setor e as normas regulamentares de conformidade.
Como é que o SDL da Microsoft melhora a segurança das aplicações?
O processo de SDL na Microsoft pode ser pensado em termos de cinco fases de desenvolvimento: requisitos, conceção, implementação, verificação e lançamento. Ele começa definindo requisitos de software com a segurança em mente. Fazemos perguntas relevantes sobre a segurança sobre o que a aplicação tem de realizar. Por exemplo, a aplicação precisa de recolher 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 de o código poder ser lançado, as novas funcionalidades e alterações materiais passam por uma revisão final de segurança e privacidade para garantir que todos os requisitos são cumpridos.
Para obter mais informações sobre o SDL, leia Ciclo de Vida de Desenvolvimento de Segurança da Microsoft.
Como é que 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 os nossos programadores utilizarem, como compiladores e ambientes de desenvolvimento, juntamente com as verificações de segurança incorporadas que são executadas automaticamente nos pipelines de compilação da Microsoft.
Antes de o código poder ser verificado num ramo de versão, o SDL requer uma revisão manual do 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. Assim que o código tiver sido considerado satisfatório pelo revisor, o revisor fornece aprovação, que é necessária antes de o código poder avançar para a fase de implementação seguinte.
Além das ferramentas de desenvolvimento seguras e da revisão manual de código, a Microsoft impõe os requisitos de SDL através de ferramentas de segurança automatizadas. Muitas destas ferramentas estão incorporadas no pipeline de consolidação e analisam automaticamente o código quanto a falhas de segurança à medida que são verificadas e à medida que são compiladas novas compilações. Os exemplos incluem a análise de código estático para falhas de segurança comuns e scanners de credenciais que analisam código para segredos incorporados. Os problemas detetados pelas ferramentas de segurança automatizadas têm de ser corrigidos antes de as novas compilações poderem passar na revisão de segurança e serem aprovadas para lançamento.
Como é que a Microsoft gere o software open source?
A Microsoft adotou uma estratégia de alto nível para gerir a segurança open source, que utiliza ferramentas e fluxos de trabalho concebidos 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 alcançar esta segurança em escala, a Microsoft criou capacidades essenciais em sistemas de engenharia através da Governação de Componentes (CG), que automatiza a deteção open source, fluxos de trabalho de requisitos legais e alertas para componentes vulneráveis. As ferramentas de CG automatizadas analisam as compilações na Microsoft para obter componentes open source 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 regularmente auditados relativamente à conformidade com as certificações e regulamentos externos. Veja a tabela seguinte para obter a validação de controlos relacionados com o desenvolvimento e a operação de segurança.
Azure e Dynamics 365
| Auditorias externas | Section | Data do relatório mais recente |
|---|---|---|
|
ISO 27001 Declaração de Aplicabilidade Certificado |
A.12.1.2: Alterar controlos de gestão A.14.2: Segurança nos processos de desenvolvimento e suporte |
8 de abril de 2024 |
|
ISO 27017 Declaração de Aplicabilidade Certificado |
A.12.1.2: Alterar controlos de gestão A.14.2: Segurança nos processos de desenvolvimento e suporte |
8 de abril de 2024 |
|
SOC 1 SOC 2 SOC 3 |
SDL-1: Metodologia do Ciclo de Vida de Desenvolvimento de Segurança (SDL) SDL-2: Requisitos de controlo de segurança documentados em versões SDL-4: Segregação de ambientes de teste e produção SDL-6: Análises de software maligno em builds de código fonte SDL7: Revisão semestral do SDL |
20 de maio de 2024 |
Microsoft 365
| Auditorias externas | Section | Data do relatório mais recente |
|---|---|---|
| FedRAMP | SA-3: Ciclo de Vida de Desenvolvimento do Sistema | 21 de agosto de 2024 |
|
ISO 27001/27017 Declaração de Aplicabilidade Certificação (27001) Certificação (27017) |
A.12.1.2: Alterar controlos de gestão A.14.2: Segurança nos processos de desenvolvimento e suporte |
Março de 2024 |
|
SOC 1 SOC 2 |
CA-03: Gestão de riscos CA-18: Gestão de alterações CA-19: Monitorização de alterações CA-21: Teste de alteração CA-38: Configurações de linha de base CA-46: Revisão de segurança |
1 de agosto de 2024 |