Compartilhar via

Recomendações para proteger um ciclo de vida de desenvolvimento

  • Artigo

Aplica-se a esta recomendação da lista de verificação de segurança bem arquitetada: Power Platform

SE:02 Mantenha um ciclo de vida de desenvolvimento seguro usando uma cadeia de fornecedores de software reforçada, automatizada na maior parte e auditável. Incorpore um design seguro usando modelagem de ameaças para proteção contra implementações que superem a segurança.

Este guia descreve as recomendações para proteger seu código e ambiente de desenvolvimento aplicando as melhores práticas de segurança durante todo o ciclo de desenvolvimento.

No centro de uma carga de trabalho estão os componentes que implementam a lógica de negócios. Esses componentes podem ser uma combinação de elementos low-code, como aplicativos de tela e fluxos, e elementos que priorizam o código, como plug-ins. Todos os componentes que compõem sua carga de trabalho devem estar sem defeitos de segurança para garantir confidencialidade, integridade e disponibilidade.

Proteger o plano de infraestrutura com controles de identidade e rede é importante, mas não é o suficiente. Evite a má implementação de cargas de trabalho do Power Platform e atividades comprometidas nessas cargas de trabalho para fortalecer sua postura geral de segurança. O processo de integração da segurança em seu ciclo de vida de desenvolvimento é essencialmente um processo de proteção. Assim como a proteção de recursos, restringir o desenvolvimento de código também é independente do contexto. O foco está no aprimoramento da segurança, não nos requisitos funcionais do aplicativo.

Definições

Termo Definição
Security Development Lifecycle (SDL) Um conjunto de práticas fornecidas por Microsoft que oferecem suporte à garantia de segurança e aos requisitos de conformidade.
Ciclo de vida de desenvolvimento de software (SDLC) Um processo sistemático e de várias etapas para o desenvolvimento de sistemas de software.

Estratégias-chave de design

As medidas de segurança devem ser integradas em vários pontos do seu ciclo de vida de desenvolvimento de software (SDLC) existente para garantir que:

  • As opções de design não gerem falhas de segurança.
  • Os componentes low-code e que priorizam o código, bem como a configuração, não criem vulnerabilidades devido à implementação explorável e práticas de codificação inadequadas.
  • Os componentes low-code e que priorizam o código e os processos de implantação não sejam violados.
  • As vulnerabilidades reveladas por meio de incidentes sejam mitigadas.
  • Os requisitos de conformidade não sejam comprometidos nem reduzidos.
  • O log de auditoria seja implementado em todos os ambientes.

As seções a seguir fornecem estratégias de segurança para as fases comumente praticadas do SDLC.

Fase de requisitos

O objetivo da fase de requisitos é reunir e analisar os requisitos funcionais e não funcionais de uma carga de trabalho ou de um novo recurso de uma carga de trabalho. Essa fase é importante porque facilita a criação de proteções adaptadas aos objetivos da carga de trabalho. Proteger os dados e a integridade de sua carga de trabalho deve ser um requisito essencial em todas as fases do ciclo de vida de desenvolvimento.

Por exemplo, considere uma carga de trabalho na qual os usuários vão inserir e modificar dados em um aplicativo. As opções de design de segurança devem abranger garantias para a interação do usuário com os dados, como autenticar e autorizar a identidade do usuário e permitir somente ações autorizadas nos dados. Os requisitos não funcionais abrangem disponibilidade, usabilidade e capacidade de manutenção. As opções de segurança devem incluir limites de segmentação, entrada e saída de firewall e outras preocupações transversais de segurança.

Todas essas decisões devem levar a uma boa definição da postura de segurança da carga de trabalho. Documente os requisitos de segurança em uma especificação acordada e reflita-os na lista de pendências. O documento deve indicar explicitamente os investimentos em segurança, as vantagens e desvantagens e os riscos que a empresa está disposta a assumir se os investimentos não forem aprovados pelo stakeholders do negócio. Por exemplo, você pode documentar a necessidade de usar um firewall de IP nos ambientes do Power Platform para proteger seus dados organizacionais restringindo o acesso ao Dataverse somente a locais do IP permitidos. Se os stakeholders da empresa não estiverem dispostos a arcar com o custo extra do uso de uma solução como Ambientes Gerenciados, eles deverão estar prontos para aceitar o risco de recursos organizacionais serem acessados de locais públicos, como uma cafeteria. Como outro exemplo, imagine que seu aplicativo deve se conectar a um fonte de dados de terceiros. O Power Platform pode ter um conector pronto para isso, mas pode não oferecer suporte aos requisitos de autenticação aprovados por suas equipes de segurança. Nesse caso, os stakeholders da segurança podem estar dispostos a aceitar o risco de usar um método de autenticação não aprovado. Como alternativa, você pode explorar o uso de um conector personalizado, enquanto avalia os benefícios do aumento do tempo de desenvolvimento e do possível atraso do projeto.

A coleta de requisitos de segurança é uma parte fundamental dessa fase. Sem esse esforço, as fases de design e implementação serão baseadas em escolhas não mencionadas, o que pode levar a falhas de segurança ou alterar requisitos que aumentarão o tempo de desenvolvimento. Talvez seja necessário alterar a implementação posteriormente para acomodar a segurança, o que pode custar caro.

Fase de design

Durante essa fase, os requisitos de segurança são convertidos em requisitos técnicos. Em sua especificação técnica, documente todas as decisões de design para evitar ambiguidade durante a implementação. Veja algumas tarefas típicas:

  • Defina a dimensão de segurança da arquitetura. Sobreponha a arquitetura com controles de segurança. Por exemplo, controles que são práticos nos limites de isolamento de rede, os tipos de identidades e métodos de autenticação necessários para os componentes da carga de trabalho e os tipos de métodos de criptografia a serem usados.

  • Avalie os recursos fornecidos pela plataforma. É importante entender a divisão de responsabilidades entre você e o Power Platform. Evite sobreposição ou duplicação com os controles de segurança nativos do Power Platform. Você terá uma melhor cobertura de segurança e poderá realocar recursos de desenvolvimento de acordo com as necessidades do aplicativo.

    Por exemplo, em vez de criar uma lógica personalizada que identifique e alerte de forma reativa sobre padrões de uso não aprovados em aplicativos e fluxos, use políticas de prevenção contra perda de dados para categorizar como os conectores podem ser usados.

    Escolha apenas implementações de referência, modelos, componentes de código, scripts e bibliotecas confiáveis. Seu design também deve especificar o controle de versão seguro. As dependências do aplicativo devem ser originadas de partes confiáveis. Fornecedores terceirizados devem ser capazes de atender aos seus requisitos de segurança e compartilhar seu plano de divulgação responsável. Qualquer incidente de segurança deve ser imediatamente relatado para que você possa tomar as medidas necessárias. Além disso, certas bibliotecas ou implementações de referência podem ser proibidas por sua organização. Por exemplo, mesmo que seja segura e sem vulnerabilidades, ela ainda pode não ser permitida porque usa recursos ainda não aprovados por sua organização, por restrições de licenciamento ou o pelo modelo de suporte da implementação de referência.

    Para garantir que essas orientações sejam seguidas, mantenha uma lista de estruturas, bibliotecas e fornecedores aprovados e/ou não aprovados e certifique-se de que seus criadores estejam familiarizados com essa lista. Quando possível, coloque proteções nos pipelines de desenvolvimento para oferecer suporte à lista. Na medida do possível, automatize o uso de ferramentas para verificar dependências em busca de vulnerabilidades.

  • Armazene segredos do aplicativo com segurança. Implemente com segurança o uso de segredos do aplicativo e chaves pré-compartilhadas que seu aplicativo usa. As credenciais e os segredos do aplicativo nunca devem ser armazenados no código-fonte da carga de trabalho (aplicativo ou fluxo). Use recursos externos, como o Azure Key Vault, para garantir que, se o seu código-fonte ficar disponível para um possível invasor, nenhum outro acesso possa ser obtido.

  • Conecte-se a seus dados de forma segura. Faça uso dos fortes recursos de segurança que o Microsoft Dataverse oferece para proteger seus dados, como segurança baseada em função e segurança em nível de coluna. Para outras fontes de dados, use conectores que tenham métodos de autenticação seguros. Evite consultas que armazenem nome de usuário e senha em texto sem formatação. Evite HTTP para criar conectores personalizados.

  • Defina como os usuários finais vão interagir com a carga de trabalho e os dados. Considere se os usuários terão acesso direto aos dados, que nível de acesso eles precisam e de onde eles acessarão os dados. Pense em como os aplicativos serão compartilhados com os usuários finais. Certifique-se de que somente aqueles que precisam de acesso ao aplicativo e aos dados terão acesso. Evite modelos de segurança complexos que incentivem soluções alternativas para evitar bloqueadores de segurança.

  • Evite a codificação rígida. Evite a codificação rígida de URLs e chaves. Por exemplo, evite a codificação rígida em uma ação HTTP do Power Automate da URL ou da chave do serviço de back-end. Em vez disso, use um conector personalizado ou uma variável de ambiente para a URL e o Azure Key Vault para a chave de API.

  • Defina planos de teste. Defina casos de teste claros para os requisitos de segurança. Avalie se é possível automatizar esses testes em seus pipelines. Se a sua equipe tiver processos para testes manuais, inclua requisitos de segurança para esses testes.

Observação

Execute a modelagem de ameaças durante essa fase. A modelagem de ameaças pode confirmar que as opções de design estejam alinhadas com os requisitos de segurança e expor lacunas que devem ser mitigas. Se a carga de trabalho lida com dados altamente confidenciais, invista em especialistas em segurança que possam ajudar você a conduzir a modelagem de ameaças.

O exercício inicial de modelagem de ameaças deve ocorrer durante a fase de projeto, quando a arquitetura do software e o design de alto nível estão sendo definidos. Fazer isso durante essa fase ajuda a identificar possíveis problemas de segurança antes que eles sejam incorporados à estrutura do sistema. No entanto, esse exercício não é uma atividade única. É um processo contínuo que deve continuar ao longo da evolução do software.

Para obter mais informações, consulte Recomendações sobre a análise de ameaças.

Fase de desenvolvimento e teste

Durante essa fase, o objetivo é evitar defeitos de segurança e adulteração no código, na compilação e nos pipelines de implantação.

Ser bem treinado em práticas de código seguras

A equipe de desenvolvimento deve ter treinamento nas práticas seguras de codificação. Por exemplo, os desenvolvedores devem estar familiarizados com conceitos de segurança no Microsoft Dataverse para implementar um modelo de segurança de privilégios mínimos, políticas de segurança de conteúdo para aplicativos baseados em modelo para restringir a incorporação a domínios confiáveis e métodos de autenticação de conectores/gateways locais.

Deve ser exigido que os desenvolvedores concluam esse treinamento antes de começarem a trabalhar em cargas de trabalho do Power Platform.

Realize revisões internas de código de pares para promover o aprendizado contínuo.

Usar ferramentas de análise de código

O Verificador de Solução deve ser usado para recursos do Power Platform, e o código-fonte de qualquer código tradicional pode ser verificado quanto a possíveis falhas de segurança, incluindo a presença de credenciais no código. Identifique possíveis instâncias de exposição de credenciais e segredos no código-fonte e nos arquivos de configuração. Este é um bom momento para revisar como as credenciais de conexão serão tratadas na produção.

Executar testes de fuzzing

Use dados malformados e inesperados para verificar vulnerabilidades e validar o tratamento de erros, especialmente importante com soluções que incluem o Power Pages.

Escreva apenas o código suficiente

Ao reduzir o volume de código, você também reduz as chances de defeitos de segurança. Reutilize códigos e bibliotecas que já estão em uso e passaram por validações de segurança em vez de duplicar códigos. Detecção de software de código aberto e verificação de versão, vulnerabilidades e obrigações legais. Há uma quantidade crescente de recursos de código aberto do Power Platform, então isso não deve ser negligenciado. Quando possível, isso deve ser discutido durante a fase de design para evitar problemas de última hora.

Proteger ambientes de desenvolvedor

As estações de trabalho do desenvolvedor devem ser protegidas com fortes controles de rede e identidade para evitar exposição. Certifique-se de que as atualizações de segurança sejam aplicadas diligentemente.

O repositório de código-fonte também deve ser protegido . Conceda acesso a repositórios de código com base na necessidade de conhecimento e reduza ao máximo a exposição de vulnerabilidades para evitar ataques. Tenha um processo completo para revisar o código em busca de vulnerabilidades de segurança. Use grupos de segurança para essa finalidade e implemente um processo de aprovação baseado em justificativas comerciais.

Implantações de código seguras

Não basta apenas proteger o código. Se ele for executado em pipelines exploráveis, todos os esforços de segurança serão inúteis e incompletos. Ambientes de construção e lançamento também devem ser protegidos porque você quer evitar que agentes mal-intencionados executem códigos maliciosos em seu pipeline.

Manter um inventário atualizado de todos os componentes integrados ao seu aplicativo

Cada novo componente integrado a um aplicativo aumenta a superfície de ataque. Para garantir a devida responsabilidade e alertas quando novos componentes são adicionados ou atualizados, você deve ter um inventário desses componentes. Regularmente, verifique se o seu manifesto corresponde ao que está em seu processo de compilação. Isso ajuda a garantir que nenhum novo componente que contenha "acessos ilegais" ou outro malware seja adicionado inesperadamente.

É recomendável o uso de Pipelines para o Power Platform para suas implantações. Estenda os pipelines usando o GitHub Actions. Se você usa fluxos de trabalho do GitHub, prefira tarefas criadas por Microsoft. Além disso, valide as tarefas porque elas são executadas no contexto de segurança do seu pipeline.

Explore o uso de entidades de serviço para a implantação.

Fase de produção

A fase de produção apresenta a última oportunidade responsável para corrigir falhas de segurança. Mantenha um registro da imagem da versão final (gold) que é lançada na produção.

Manter artefatos com controle de versão

Mantenha um catálogo de todos os ativos implantados e suas versões. Essas informações são úteis durante a triagem de incidentes, quando você estiver mitigando problemas e quando o sistema estiver voltando ao funcionamento. Os ativos com controle de versão também podem ser comparados com avisos de CVE (Vulnerabilidades e Exposições Comuns) publicados. Você deve usar a automação para realizar essas comparações.

Correções emergenciais

Seu design de pipeline automatizado deve ter a flexibilidade para oferecer suporte a implantações regulares e de emergência. Essa flexibilidade é importante para oferecer suporte a correções de segurança rápidas e responsáveis.

Uma liberação geralmente está associada a vários portões de aprovação. Considere a criação de um processo de emergência para acelerar as correções de segurança. O processo pode envolver a comunicação entre as equipes. O pipeline deve permitir implantações rápidas de roll-forward e de reversão que abordam correções de segurança, bugs críticos e atualizações de código que ocorrem fora do ciclo de vida de implantação regular.

Observação

Sempre priorize as correções de segurança em relação à conveniência. Uma correção de segurança não deve introduzir uma regressão ou bug. Se quiser acelerar a correção por meio de um pipeline de emergência, considere cuidadosamente quais testes automatizados podem ser ignorados. Avalie o valor de cada teste em relação ao tempo de execução. Por exemplo, os testes de unidade geralmente são concluídos rapidamente. A integração ou testes de ponta a ponta podem ser executados por um longo tempo.

Manter ambientes diferentes separados

Os dados de produção não devem ser usados em ambientes inferiores**, pois esses ambientes podem não ter os controles de segurança rígidos que a produção tem. Evite conectar-se a partir de um aplicativo de não produção a um banco de dados de produção e evite conectar componentes que não sejam de produção a redes de produção.

Usar exposição progressiva

Use a exposição progressiva para liberar recursos para um subconjunto de usuários com base nos critérios escolhidos. Se houver problemas, o impacto será minimizado para esses usuários. Essa abordagem é uma estratégia comum de mitigação de riscos porque reduz a área de superfície. À medida que o recurso amadurece e você tem mais confiança nas garantias de segurança, é possível liberá-lo gradualmente para um conjunto mais amplo de usuários.

Fase de manutenção

O objetivo dessa fase é garantir que a postura de segurança não decaia com o tempo. O SDLC é um processo ágil contínuo. Os conceitos abordados nas fases anteriores se aplicam a essa fase porque os requisitos mudam com o tempo.

Melhoria contínua. Avalie e melhore continuamente a segurança do processo de desenvolvimento de software, levando em consideração revisões de código, feedback, lições aprendidas e ameaças em evolução, bem como novos recursos disponibilizados pelo Power Platform.

Descomissione ativos legados que estão obsoletos ou não são mais utilizados. Isso reduz a área de superfície do aplicativo.

A manutenção também inclui correções de incidentes. Se forem encontrados problemas na produção, eles deveram ser prontamente integrados de volta ao processo para que não se repitam.

Melhore continuamente suas práticas de codificação seguras para acompanhar o cenário de ameaças.

SDL no Microsoft Power Platform

O Power Platform é baseado em uma cultura e metodologia de design seguro. Tanto a cultura quanto a metodologia são constantemente reforçadas por meio das práticas líderes do setor de MicrosoftCiclo de Vida de Desenvolvimento de Segurança (SDL) e Modelagem de Ameaças .

O processo de revisão de Modelagem de Ameaças garante as ameaças sejam identificadas durante a fase de projeto, mitigadas e validadas para garantir que sejam mitigadas.

A Modelagem de Ameaças também leva em consideração todas as alterações nos serviços que já estão ativos por meio de revisões regulares contínuas. Depender do modelo STRIDE ajuda a resolver os problemas mais comuns com o design inseguro.

MicrosoftO SDL é equivalente ao Modelo de Maturidade de Garantia de Software OWASP (SAMM). Ambos se baseiam na premissa de que o design seguro é parte essencial da segurança de aplicativos Web. Para obter mais informações, consulte Os 10 principais riscos da OWASP: mitigações no Power Platform.

Facilitação do Power Platform

Microsoft O Security Development Lifecycle (SDL) recomenda práticas seguras que você pode aplicar ao seu ciclo de vida de desenvolvimento. Para obter mais informações, consulte Microsoft Ciclo de vida do desenvolvimento de segurança.

O Defender para DevOps e as ferramentas de SAST (teste de segurança de aplicativos estáticos) estão incluídos como parte do GitHub Advanced Security e do Azure DevOps. Essas ferramentas podem ajudar você a acompanhar uma pontuação de segurança para sua organização.

Com o recurso verificador de soluções, é possível executar uma rica verificação de análise estática em suas soluções em relação a um conjunto de regras de práticas recomendadas e identificar rapidamente esses padrões problemáticos. Consulte Usar o verificador de solução para validar suas soluções.

Lista de verificação de segurança

Consulte o conjunto completo de recomendações.

Lista de verificação de segurança