Gerenciamento de alterações do Microsoft 365

  • Artigo

O Microsoft 365 impõe procedimentos de gerenciamento de alterações quando alterações de código e não código em seus sistemas são feitas para manter sua postura de segurança. Qualquer descompasso de configuração da postura inicial pode introduzir vulnerabilidades, interromper a funcionalidade ou interromper a disponibilidade. Depois que um sistema de informações no Microsoft 365 tiver sido implantado com uma postura de segurança robusta, os processos detalhados de gerenciamento de alterações serão impostos para manter a integridade do sistema.

Há muitos drivers de alteração no Microsoft 365, incluindo novos requisitos funcionais ou de segurança, comentários de clientes, vulnerabilidades identificadas e descobertas de auditoria. Independentemente do driver de alteração, as equipes de serviço usam ferramentas de tíquetes ou controle do código-fonte para documentar evidências de aprovação e controlar todas as alterações.

Alterações no código-fonte

As alterações são implantadas por meio do SDL (Ciclo de Vida de Desenvolvimento Seguro) da Microsoft, que é seguido por todos os projetos de engenharia e desenvolvimento no Microsoft 365. Esse é um modelo de desenvolvimento de software que inclui considerações de segurança específicas relacionadas a revisões de código, testes e aprovações antes de serem lançadas sistematicamente no ambiente do Microsoft 365.

Processo de alteração de código.

O SDL atua como uma estrutura e inclui a identificação de possíveis riscos para o projeto de desenvolvimento concluído e estratégias de mitigação que podem ser implementadas e testadas durante as fases de desenvolvimento. Pontos de verificação de aprovação e revisão de segurança críticos também estão incluídos.

Identificação e planejamento de alterações

As equipes de serviço se reúnem regularmente para discutir as alterações propostas, incluindo justificativa, escopo, impacto de segurança, prioridade, dependências, planos de implantação, funções e responsabilidades. Essas informações estão documentadas no sistema de controle de gerenciamento de alterações. Se a alteração for rejeitada, a justificativa será explicitamente documentada no tíquete para referência futura.

Revisões de código de pessoal

Os desenvolvedores com a tarefa de implementar uma alteração de código enviam uma solicitação de pull que replica o código do branch principal, permitindo que eles façam as modificações necessárias. Antes que qualquer novo código possa ser incluído em um novo build e implantado, ele deve passar pela revisão de código de pessoal. A imposição dessas revisões é tratada por meio de um pipeline de código automatizado anexado a cada repositório de código e não pode ser contornado. Depois que a aprovação necessária for recebida, o código poderá passar para a próxima fase.

Os revisores de código verificam se há erros de codificação, verificam se as alterações atendem aos requisitos e executam uma análise de impacto de segurança. As revisões devem ser realizadas por alguém diferente das pessoas que desenvolveram o código, impondo o princípio da separação de direitos. Impedir que as mesmas pessoas enviem e apunham seu próprio código é um controle crítico que a Microsoft impõe estritamente. Isso reduz consideravelmente a possibilidade de liberação de pessoas de forma única, intencional ou não intencionalmente, prejudicial ou código com bugs. Se os revisores encontram problemas durante a revisão de código, eles interrompem a alteração e fazem com que os desenvolvedores reenviem o código com alterações sugeridas e testes adicionais. Os revisores de código também podem optar por rejeitar o check-in inteiramente para um código que não atenda aos requisitos identificados. Depois que o código é considerado satisfatório pelo revistor, a aprovação é fornecida e o código é verificado no branch principal como uma confirmação.

Verificações automatizadas de segurança e pipeline de build

Depois que todas as alterações para o sprint forem confirmadas no branch principal, o processo de build automatizado será iniciado. É aqui que o código está sujeito a várias verificações de segurança automatizadas. Essas verificações incluem análise de código estático, análise binária e verificação de criptografia. O Microsoft 365 define um conjunto de testes essenciais que cada build deve passar antes da implantação para ambientes de pré-produção. Os builds que não são aprovados são rejeitados e enviados de volta para a equipe de desenvolvimento em que os ajustes necessários são feitos até que possam atingir a taxa de aprovação de limite. Os builds bem-sucedidos prosseguem para o ambiente de pré-produção por meio de um pipeline de implantação automatizado.

Versão de build

Os builds são lançados inicialmente apenas para a equipe de serviço que desenvolveu o recurso. Ele deve funcionar sem problemas antes de ser liberado para grupos de teste progressivamente maiores em ambientes de nuvem logicamente isolados chamados anéis. Após a equipe de serviço, o build é liberado para todos os grupos internos do Microsoft 365, seguido pelo lançamento do build para todos os grupos internos da Microsoft. Esse teste, geralmente conhecido internamente como dogfooding, permite que a Microsoft identifique bugs no ambiente de produção verdadeiro antes do lançamento do build para clientes externos. Esses métodos de teste garantem que o código da Microsoft esteja seguro e funcionando conforme o esperado antes de atingir os clientes e a implantação em todo o mundo. Os builds anteriores são sempre retidos para fins de reversão.

As equipes de engenharia determinam a quantidade de tempo que um build gasta em cada anel durante períodos de alta carga antes de prosseguir para o próximo anel. Se todos os testes forem bem-sucedidos em cada anel interno, o build será lançado para clientes em todo o mundo, primeiro como uma Versão Direcionada para locatários do cliente que aceitaram esse anel, seguido por uma Versão Padrão Mundial.

Alterações sem código

As alterações sem código são definidas como quaisquer modificações nos sistemas do Microsoft 365 que não envolvem a criação ou edição do código-fonte do serviço. Isso pode incluir a abertura de portas, a alteração de acLs (listas de Controle de Acesso) ou outras alterações no sistema subjacente. Em comparação, as alterações sem código ocorrem com menos frequência do que as alterações de código, mas ainda exigem um alto nível de escrutínio.

Processo de alteração sem código.

Uma descrição da alteração é documentada junto com etapas de implementação, etapas de validação e um plano de reversão. Antes que a alteração seja implementada, os planos são revisados por pares para obter a precisão e o impacto de segurança por pelo menos uma pessoa. Depois de aprovados, os planos documentados são implementados. Se todas as etapas de validação forem aprovadas com êxito, os resultados serão documentados no tíquete e serão marcados como resolvidos.

Se a implementação da alteração não for bem-sucedida, os planos de reversão serão disparados e a equipe retornará à fase de planejamento e repetirá o processo até que seja bem-sucedido.

Recursos