Partilhar via

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

  • Artigo

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

SE:02 Mantenha um ciclo de vida de desenvolvimento seguro utilizando uma cadeia de fornecimento de software reforçada, maioritariamente automatizada e auditável. Incorpore uma estrutura segura utilizando a modelação de ameaças para se proteger contra implementações que derrotam a segurança.

Este guia descreve as recomendações para proteger o seu código e ambiente de desenvolvimento ao aplicar as melhores práticas de segurança ao longo do ciclo de desenvolvimento.

No centro de uma carga de trabalho estão os componentes que implementam a lógica de negócio. Estes componentes podem ser uma mistura de elementos low-code, como aplicações de tela e fluxos, e elementos com prioridade ao código, como plug-ins. Todos os componentes que constituem a sua carga de trabalho devem estar isentos de defeitos de segurança para garantir a confidencialidade, integridade e disponibilidade.

Proteger o plano da infraestrutura com controlos de identidade e de rede é importante, mas não é suficiente. Evite a má aplicação das cargas de trabalho do Power Platform e as atividades comprometidas nessas cargas de trabalho para reforçar a sua postura de segurança global. O processo de integração da segurança no seu ciclo de vida de desenvolvimento é essencialmente um processo de reforço. Tal como a proteção dos recursos, o reforço do desenvolvimento do código também é independente do contexto. O foco é colocado no reforço da segurança e não nos requisitos funcionais da aplicação.

Definições

Termo Definição
Ciclo de Vida do Desenvolvimento de Segurança (SDL) Um conjunto de práticas fornecidas que Microsoft suporta a garantia de segurança e os requisitos de conformidade.
Ciclo de vida do desenvolvimento de software (SDLC) Um processo sistemático e em várias fases para o desenvolvimento de sistemas de software.

Principais estratégias de design

As medidas de segurança devem ser integradas em vários pontos do seu atual Ciclo de Vida de Desenvolvimento de Software (SDLC) para garantir:

  • As escolhas de design não conduzem a falhas de segurança.
  • Os componentes low-code e de prioridade ao código, bem como a configuração, não criam vulnerabilidades devido a uma implementação explorável e a práticas de codificação incorretas.
  • Os componentes de low-code e de prioridade ao código e os processos de implementação não são adulterados.
  • As vulnerabilidades reveladas pelos incidentes são mitigadas.
  • Os requisitos de conformidade não são comprometidos nem reduzidos.
  • O registo de auditoria é implementado em todos os ambientes.

As secções seguintes apresentam estratégias de segurança para as fases mais comuns 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 uma nova caraterística de uma carga de trabalho. Esta fase é importante porque facilita a criação de barreiras de proteção adaptadas aos objetivos do volume de trabalho. A proteção dos dados e da integridade da sua carga de trabalho deve ser um requisito essencial em todas as fases do ciclo de vida do desenvolvimento.

Por exemplo, considere uma carga de trabalho em que os utilizadores introduzem e modificam dados numa aplicação. As opções de design de segurança devem abranger garantias para a interação do utilizador com os dados, como autenticar e autorizar a identidade do utilizador e permitir apenas ações permitidas nos dados. Os requisitos não funcionais abrangem a disponibilidade, a facilidade de utilização e a facilidade de manutenção. As escolhas de segurança devem incluir limites de segmentação, entrada e saída de firewall e outras preocupações de segurança transversais.

Todas estas decisões devem conduzir a uma boa definição da postura de segurança da carga de trabalho. Documentar os requisitos de segurança numa especificação acordada e refleti-los na lista de pendências. O documento deve indicar explicitamente os investimentos em segurança e os compromissos e riscos que a empresa está disposta a assumir se os investimentos não forem aprovados pelas partes interessadas da empresa. Por exemplo, poderá documentar a necessidade de utilizar uma firewall de IP em ambientes do Power Platform para proteger os seus dados organizacionais, restringindo o acesso ao Dataverse apenas a localizações de IP permitidas. Se intervenientes de negócios não estiverem dispostas a suportar o custo adicional da utilização de uma solução como os Ambientes Geridos, têm de estar preparadas para aceitar o risco de os recursos organizacionais serem acedidos a partir de locais públicos, como um café. Como outro exemplo, imagine que a sua aplicação tem de se ligar a uma origem de dados de terceiros. O Power Platform poderá ter um conector pronto para isto, mas poderá não suportar os requisitos de autenticação aprovados pelas suas equipas de segurança. Neste caso, os intervenientes na segurança podem estar dispostos a aceitar o risco de utilizar um método de autenticação não aprovado. Em alternativa, pode explorar a utilização de um conetor personalizado, ponderando os benefícios do aumento do tempo de desenvolvimento e do potencial atraso do projeto.

A recolha de requisitos de segurança é uma parte essencial desta fase. Sem este esforço, as fases de design e implementação basear-se-ão em escolhas não declaradas, o que pode conduzir a lacunas de segurança ou a requisitos variáveis que aumentarão o tempo de desenvolvimento. Poderá ser necessário alterar a implementação mais tarde para acomodar a segurança, o que pode ser dispendioso.

Fase de design

Durante esta fase, os requisitos de segurança são convertidos em requisitos técnicos. Na sua especificação técnica, documente todas as decisões de conceção para evitar ambiguidades durante a implementação. Eis algumas tarefas típicas:

  • Defina a dimensão de segurança da arquitetura. Sobreponha a arquitetura aos controlos de segurança. Por exemplo, os controlos que são práticos nos limites de isolamento da rede, os tipos de identidades e métodos de autenticação necessários para os componentes da carga de trabalho e o tipo de métodos de encriptação a utilizar.

  • Avalie os recursos fornecidos pela plataforma. É importante compreender a divisão de responsabilidade entre o utilizador e o Power Platform. Evite a sobreposição ou a duplicação com os controlos de segurança nativos do Power Platform. Obterá uma melhor cobertura de segurança e poderá reafetar os recursos de desenvolvimento às necessidades da aplicação.

    Por exemplo, em vez de criar uma lógica personalizada que identifique e alerte de forma reativa sobre padrões de utilização não aprovados em aplicações e fluxos, utilize políticas de Prevenção contra a perda de dados para categorizar a forma como os conectores podem ser utilizados.

    Escolha apenas implementações de referência confiáveis, modelos, componentes de código, scripts e bibliotecas. O seu design também deve especificar o controlo de versões seguro. As dependências das aplicações devem ser obtidas junto de entidades de confiança. Os 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 comunicado para que se possam tomar as medidas necessárias. Além disso, determinadas bibliotecas ou implementações de referência podem ser proibidas pela sua organização. Por exemplo, mesmo que seja seguro e isento de vulnerabilidades, pode não ser permitido porque utiliza funcionalidades ainda não aprovadas pela sua organização, restrições de licenciamento ou o modelo de suporte da implementação de referência.

    Para garantir que esta orientação é seguida, mantenha uma lista de estruturas, bibliotecas e fornecedores aprovados e/ou não aprovados e garanta que os seus responsáveis estão familiarizados com esta lista. Sempre que possível, coloque barreiras de proteção nas condutas de desenvolvimento para apoiar a lista. Tanto quanto possível, automatize a utilização de ferramentas para analisar as dependências em busca de vulnerabilidades.

  • Armazene segredos de aplicações de forma segura. Implemente de forma segura a utilização de segredos de aplicação e chaves pré-partilhadas que a sua aplicação utiliza. As credenciais e os segredos da aplicação nunca devem ser armazenados no código fonte da carga de trabalho (aplicação ou fluxo). Utilize recursos externos, como o Azure Key Vault, para garantir que, se o seu código fonte ficar disponível para um potencial atacante, não é possível obter mais acesso.

  • Ligue-se aos seus dados de forma segura. Utilize as funcionalidades de segurança robustas que o Microsoft Dataverse oferece para proteger os seus dados, como a segurança baseada em funções e ao nível da coluna. Para outras origens de dados, utilize conectores que tenham métodos de autenticação seguros. Evite consultas que armazenem o nome de utilizador e a palavra-passe em texto simples. Evitar HTTP para criar conectores personalizados.

  • Defina como os utilizadores finais irão interagir com a carga de trabalho e os dados. Considere se os utilizadores terão acesso direto aos dados, qual o nível de acesso de que necessitam e a partir de onde acederão aos dados. Pense na forma como as aplicações serão partilhadas com os utilizadores finais. Certifique-se de que apenas as pessoas que precisam de aceder à aplicação e aos dados têm acesso. Evite modelos de segurança complexos que incentivem soluções alternativas para evitar os bloqueadores de segurança.

  • Evite o hard-coding. Evite o hard-coding de URLs e chaves. Por exemplo, evite o hard-coding numa ação HTTP do Power Automate do URL ou da chave para o serviço de back-end. Em vez disso, utilize um conetor personalizado ou uma variável de ambiente para o 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 pode automatizar esses testes nos seus pipelines. Se a sua equipa tiver processos para testes manuais, inclua requisitos de segurança para esses testes.

Nota

Execute a modelação da ameaça durante esta fase. A modelação de ameaças pode confirmar que as escolhas de design estão alinhadas com os requisitos de segurança e expor lacunas que devem ser atenuadas. Se a sua carga de trabalho lida com dados altamente confidenciais, invista em especialistas em segurança que o possam ajudar a modelizar as ameaças.

O exercício inicial de modelação das ameaças deve ocorrer durante a fase de conceção, quando a arquitetura do software e a conceção de alto nível estão a ser definidas. Fazê-lo durante essa fase ajuda-o a identificar potenciais problemas de segurança antes de estes serem incorporados na estrutura do sistema. No entanto, este exercício não é uma atividade única. Trata-se de um processo contínuo que deve continuar durante toda a evolução do software.

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

Fase de desenvolvimento e teste

Durante esta fase, o objetivo é evitar defeitos de segurança e adulteração em pipelines de código, criação e implementação.

Tenha formação adequada em práticas de código seguro

A equipa de desenvolvimento deve ter formação em práticas de codificação seguras. Por exemplo, os programadores devem estar familiarizados com os 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údos para aplicações condicionadas por modelo para restringir a incorporação a domínios fidedignos e métodos de autenticação de gateway/gateway no local.

Os programadores devem ser obrigados a concluir esta formação antes de começarem a trabalhar em cargas de trabalho do Power Platform.

Faça revisões internas do código pelos pares para promover a aprendizagem contínua.

Utilizar ferramentas de análise de código

O Verificador de Soluções deve ser usado em 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 as possíveis instâncias de exposição de credenciais e segredos no código fonte e nos ficheiros de configuração. Esta é uma boa altura para rever a forma como as credenciais de ligação serão tratadas na produção.

Realizar testes difusos

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

Escreva apenas código suficiente

Ao reduzir a quantidade de código, também se reduzem as hipóteses de defeitos de segurança. Reutilize o código e as bibliotecas que já estão em uso e passaram por validações de segurança em vez de duplicar o código. Deteção de software open-source e verificação de versões, vulnerabilidades e obrigações legais. Há uma quantidade crescente de recursos open-source do Power Platform, pelo que isto não deve ser ignorado. Sempre que possível, esta questão deve ser discutida durante a fase de design para evitar problemas de última hora.

Proteger os ambientes de programação

As estações de trabalho dos programadores têm de ser protegidas com fortes controlos de rede e de identidade para evitar a exposição. Certifique-se de que as atualizações de segurança são aplicadas com diligência.

O repositório de código-fonte também deve ser salvaguardado . Conceda acesso a repositórios de código com base na necessidade de conhecimento e reduza a exposição de vulnerabilidades tanto quanto possível para evitar ataques. Tenha um processo completo para revisar o código em busca de vulnerabilidades de segurança. Utilize grupos de segurança para esse efeito e implemente um processo de aprovação baseado em justificações comerciais.

Implementações de código seguro

Não basta apenas proteger o código. Se for executado em pipelines exploráveis, todos os esforços de segurança são inúteis e incompletos. Os ambientes de compilação e liberação também devem ser protegidos , pois você deseja impedir que agentes mal-intencionados executem códigos mal-intencionados em seu pipeline.

Mantenha um inventário atualizado de todos os componentes integrados na sua aplicação

Cada novo componente que está integrado numa aplicação aumenta a superfície de ataque. Para garantir uma responsabilização adequada e alertar quando são adicionados ou atualizados novos componentes, deve ter um inventário destes componentes. Regularmente, verifique se o seu manifesto corresponde ao que está no seu processo de compilação. Isso ajuda a garantir que não sejam adicionados inesperadamente novos componentes que contenham de back door ou outro malware.

Recomendamos a utilização de Pipelines para Power Platform para as suas implementações. Expandir pipelines utilizando o GitHub Actions. Se você usa fluxos de trabalho do GitHub, prefira Microsoft tarefas criadas. Além disso, valide as tarefas por serem executadas no contexto de segurança do seu pipeline.

Explore a utilização de principais de serviço para a implementação.

Fase de produção

A fase de produção apresenta a última oportunidade responsável para corrigir as lacunas de segurança. Mantenha um registo da imagem dourada que é lançada na produção.

Manter artefactos com controlo de versões

Mantenha um catálogo de todos os ativos implementados e respetivas versões. Estas informações são úteis durante a triagem de incidentes, quando se está a atenuar os problemas e quando se está a colocar o sistema novamente em estado de funcionamento. Os ativos com controlo de versões também podem ser comparados com as notificações de Vulnerabilidades e Exposições Comuns (CVE) publicadas. Deve utilizar a automatização para efetuar estas comparações.

Correções de emergência

O design do pipeline automatizado deve ter a flexibilidade de suportar implementações regulares e de emergência. Esta flexibilidade é importante para suportar correções de segurança rápidas e responsáveis.

Uma versão está normalmente associada a várias portas de aprovação. Considere a possibilidade de criar um processo de emergência para acelerar as correções de segurança. O processo pode envolver a comunicação entre equipas. O pipeline deve permitir implementações rápidas de variação e reversão que abordem correções de segurança, bugs críticos e atualizações de código que ocorram fora do ciclo de vida regular da implementação.

Nota

Dê sempre prioridade às correções de segurança em detrimento da conveniência. Uma correção de segurança não deve introduzir uma regressão ou um erro. Se pretende acelerar a correção através de um pipeline de emergência, considere cuidadosamente quais os testes automatizados que podem ser contornados. Avalie o valor de cada teste em função do tempo de execução. Por exemplo, os testes unitários são normalmente concluídos rapidamente. Os testes de integração ou ponto a ponto podem ser executados durante muito tempo.

Mantenha os diferentes ambientes separados

Os dados de produção não devem ser utilizados em ambientes inferiores** porque esses ambientes podem não ter os controlos de segurança estritos que a produção tem. Evite ligar de uma aplicação que não seja de produção a uma base de dados de produção e evite ligar componentes que não sejam de produção a redes de produção.

Utilizar a exposição progressiva

Utilize a exposição progressiva para lançar funcionalidades para um subconjunto de utilizadores com base nos critérios escolhidos. Se existirem problemas, o impacto é minimizado para esses utilizadores. Esta abordagem é uma estratégia comum de atenuação do risco porque reduz a área de superfície. À medida que a funcionalidade amadurece e tem mais confiança nas garantias de segurança, pode lançá-la gradualmente para um conjunto mais vasto de utilizadores.

Fase de manutenção

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

Melhoria contínua. Avalie e melhore continuamente a segurança do processo de desenvolvimento de software, tendo em conta as revisões de código, o feedback, as lições aprendidas e a evolução das ameaças, bem como as novas funcionalidades disponibilizadas pelo Power Platform.

Descomissionar ativos legados que estão obsoletos ou não estão mais em uso. Ao fazê-lo, reduz a área de superfície da aplicação.

A manutenção também inclui correções de incidentes. Se forem detetados problemas na produção, estes devem ser prontamente integrados no processo para que não se repitam.

Melhore continuamente as suas práticas de codificação segura para se manter a par do panorama de ameaças.

SDL no Microsoft Power Platform

O Power Platform foi criado sobre uma cultura e metodologia de conceção segura. Tanto a cultura quanto a metodologia são constantemente reforçadas por meio Microsoft das práticas líderes do setor de Ciclo de Vida de Desenvolvimento de Segurança (SDL) e Modelagem de Ameaças .

O robusto processo de revisão da Modelação de Ameaças garante que as ameaças são identificadas durante a fase de conceção, mitigadas e validadas para garantir que foram mitigadas.

A Modelação de Ameaças também é responsável por todas as alterações aos serviços que já estão em direto através de revisões regulares contínuas. Confiar no modelo STRIDE ajuda a abordar os problemas mais comuns com um conceção insegura.

MicrosoftO SDL do é equivalente ao Modelo de Maturidade do Software Assurance (SAMM) do OWASP. Ambos são construídos no pressuposto de que o design seguro é parte integrante da segurança da aplicação web. Para mais informações, consulte 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 de desenvolvimento de segurança.

O Defender para DevOps e as ferramentas SAST (Static Application Security Testing) estão incluídas como parte do GitHub Advanced Security e Azure DevOps. Estas ferramentas podem ajudá-lo a registar uma classificação de segurança para a sua organização.

Com a funcionalidade do verificador de soluções pode executar uma análise estática avançada em soluções contra um conjunto de regras de práticas recomendadas e rapidamente identificar estes padrões problemáticos. Consulte Utilizar o verificador de soluções para validar as suas soluções.

Lista de verificação de segurança

Consulte o conjunto completo de recomendações.

Lista de verificação de segurança