Compartir por

Recomendacións para asegurar un ciclo de vida de desenvolvemento

Aplícase a esta recomendación da lista de verificación de seguridade ben arquitectada: Power Platform

SE:02 Manteña un ciclo de vida de desenvolvemento seguro mediante unha cadea de subministración de software reforzada, na súa maioría automatizada e auditable. Incorporar un deseño seguro mediante a modelización de ameazas para protexerse contra implementacións que prexudiquen a seguridade.

Esta guía describe as recomendacións para protexer o código e o entorno de desenvolvemento aplicando as mellores prácticas de seguridade ao longo de todo o ciclo de desenvolvemento.

No núcleo dunha carga de traballo están os compoñentes que implementan a lóxica empresarial. Estes compoñentes poden ser unha mestura de elementos de código baixo, como aplicacións e fluxos de lenzo, e elementos que priorizan o código, como complementos. Todos os compoñentes que conforman a súa carga de traballo deben estar libres de defectos de seguridade para garantir a confidencialidade, a integridade e a dispoñibilidade.

Protexer o plano da infraestrutura con controis de identidade e rede é importante, pero non abonda. Evita a mala implementación das cargas de traballo e as actividades comprometidas nesas cargas de traballo para fortalecer a túa postura de seguridade xeral. Power Platform O proceso de integración da seguridade no ciclo de vida do desenvolvemento é esencialmente un proceso de endurecemento. Do mesmo xeito que o endurecemento dos recursos, o reforzo do desenvolvemento de código tamén é agnóstico no contexto. O foco está en mellorar a seguridade, non nos requisitos funcionais da aplicación.

Definicións

Termo Definición
Ciclo de vida do desenvolvemento de seguridade (SDL) Un conxunto de prácticas proporcionadas por Microsoft que admiten os requisitos de garantía de seguridade e cumprimento.
Ciclo de vida do desenvolvemento de software (SDLC) Un proceso sistemático e de varias etapas para o desenvolvemento de sistemas de software.

Estratexias clave de deseño

As medidas de seguridade deberían integrarse en varios puntos do ciclo de vida do desenvolvemento de software (SDLC) existente para garantir:

  • As eleccións de deseño non provocan lagoas de seguridade.
  • Os compoñentes de código baixo e código primeiro, así como a configuración, non crean vulnerabilidades debido á implementación explotable e ás prácticas de codificación inadecuadas.
  • Os compoñentes e os procesos de implementación de código baixo e código primeiro non son alterados.
  • Mitíganse as vulnerabilidades reveladas a través de incidentes.
  • Os requisitos de cumprimento non se ven comprometidos nin reducidos.
  • O rexistro de auditoría está implementado en todos os entornos.

As seguintes seccións proporcionan estratexias de seguranza para as fases de SDLC que se practican habitualmente.

Fase de requisitos

O obxectivo da fase de requisitos é recompilar e analizar os requisitos funcionais e non funcionais para unha carga de traballo ou unha nova característica dunha carga de traballo. Esta fase é importante porque facilita a creación de barreiras adaptadas aos obxectivos da carga de traballo. Protexer os datos e a integridade da carga de traballo debería ser un requisito fundamental en cada fase do ciclo de vida do desenvolvemento.

Por exemplo, considere unha carga de traballo onde os usuarios introducirán e modificarán datos dentro dunha aplicación. As opcións de deseño de seguranza deberían incluír garantías para a interacción do usuario cos datos, como a autenticación e autorización da identidade do usuario e permitir só accións permitidas sobre os datos. Os requisitos non funcionais abarcan a dispoñibilidade, a usabilidade e a mantenibilidade. As opcións de seguridade deberían incluír límites de segmentación, entrada e saída do cortafuegos e outras preocupacións de seguridade transversais.

Todas estas decisións deberían levar a unha boa definición da postura de seguridade da carga de traballo. Documentar os requisitos de seguridade nunha especificación acordada e reflectilos na lista de traballos pendentes. O documento debe indicar explicitamente os investimentos en seguridade e as compensacións e riscos que a empresa está disposta a asumir se os investimentos non son aprobados polas partes interesadas da empresa. Por exemplo, podes documentar a necesidade de usar un cortafuegos IP en contornas para protexer os datos da túa organización restrinxindo o acceso só ás localizacións IP permitidas. Power Platform Dataverse Se as partes interesadas da empresa non están dispostas a asumir o custo adicional de usar unha solución como os Entornos Xestionados, deben estar preparadas para aceptar o risco de que se acceda aos recursos da organización desde lugares públicos, como unha cafetería. Como outro exemplo, imaxina que a túa aplicación debe conectarse a unha fonte de datos de terceiros. Power Platform pode ter un conector xa feito para isto, pero pode que non sexa compatible cos requisitos de autenticación aprobados polos seus equipos de seguridade. Neste caso, os responsables da seguridade poden estar dispostos a aceptar o risco de usar un método de autenticación non aprobado. Como alternativa, podes explorar o uso dun conector personalizado, sopesando ao mesmo tempo as vantaxes dun maior tempo de desenvolvemento e un posible atraso no proxecto.

A recollida de requisitos de seguridade é unha parte fundamental desta fase. Sen este esforzo, as fases de deseño e implementación basearanse en opcións non declaradas, o que pode levar a lagoas de seguridade ou a requisitos cambiantes que aumentarán o tempo de desenvolvemento. Pode que teñas que cambiar a implementación máis tarde para acomodar a seguridade, o que pode ser caro.

Fase de deseño

Nesta fase, os requisitos de seguridade convértense en requisitos técnicos. Na súa especificación técnica, documente todas as decisións de deseño para evitar ambigüidades durante a implementación. Aquí tes algunhas tarefas típicas:

  • Definir a dimensión de seguridade da arquitectura. Superpoñer a arquitectura con controis de seguridade. Por exemplo, controis prácticos sobre os límites de illamento da rede, os tipos de identidades e métodos de autenticación necesarios para os compoñentes da carga de traballo e o tipo de métodos de cifrado que se deben usar.

  • Avaliar as posibilidades proporcionadas pola plataforma. É importante comprender o división de responsabilidades entre vostede e Power Platform. Evitar solapamentos ou duplicacións con Power Platform controis de seguridade nativos. Obterás unha mellor cobertura de seguridade e poderás reasignar recursos de desenvolvemento ás necesidades da aplicación.

    Por exemplo, en lugar de crear lóxica personalizada que identifique e alerte de forma reactiva sobre patróns de uso non aprobados en aplicacións e fluxos, use políticas de datos para categorizar como se poden usar os conectores.

    Escolle só implementacións de referencia, modelos, compoñentes de código, scripts e bibliotecas de confianza. O teu deseño tamén debería especificar un control de versións seguro. As dependencias da aplicación deben proceder de terceiros de confianza. Os provedores externos deberían ser capaces de cumprir os teus requisitos de seguridade e compartir o seu plan de divulgación responsable. Calquera incidente de seguridade debe ser notificado de inmediato para que se poidan tomar as medidas necesarias. Ademais, a súa organización podería prohibir certas bibliotecas ou implementacións de referencia. Por exemplo, mesmo se é seguro e está libre de vulnerabilidades, pode que non estea permitido porque usa funcionalidades que aínda non foi aprobadas pola súa organización, restricións de licenza ou o modelo de soporte da implementación de referencia.

    Para garantir que se segue esta guía, manteña unha lista de marcos, bibliotecas e provedores aprobados e/ou non aprobados e asegúrese de que os seus creadores estean familiarizados con esta lista. Cando sexa posible, coloca varandas nas canles de desenvolvemento para apoiar a lista. Na medida do posible, automatiza o uso de ferramentas para analizar as dependencias en busca de vulnerabilidades.

  • Garda os segredos da aplicación de forma segura. Implementa de forma segura o uso dos segredos da aplicación e das claves precompartidas que usa a túa aplicación. As credenciais e os segredos da aplicación nunca se deben almacenar no código fonte da carga de traballo (aplicación ou fluxo). Usa recursos externos como Azure Key Vault para garantir que, se o teu código fonte se pon á disposición dun posible atacante, non se poida obter máis acceso.

  • Conéctate aos teus datos de forma segura. Aproveita as potentes funcións de seguranza que Microsoft Dataverse ofrece para protexer os teus datos, como a seguranza baseada en roles e a nivel de columna. Para outras fontes de datos, use conectores que teñan métodos de autenticación seguros. Evita as consultas que almacenan o nome de usuario e o contrasinal en texto sen formato. Evitar HTTP para crear conectores personalizados.

  • Definir como interactuarán os usuarios finais coa carga de traballo e os datos. Considere se os usuarios terán acceso directo aos datos, que nivel de acceso requiren e desde onde accederán aos datos. Pensa en como se compartirán as aplicacións cos usuarios finais. Asegúrate de que só teñan acceso a elas as persoas que precisen acceso á aplicación e aos datos. Evita modelos de seguridade complexos que fomenten solucións alternativas para evitar bloqueos de seguridade.

  • Evita a codificación dura. Evita a codificación fixa de URL e claves. Por exemplo, evita codificar de forma fixa nunha acción HTTP o URL ou a clave do servizo de backend. Power Automate No seu lugar, use un conector personalizado ou unha variable de ambiente para o URL e Azure Key Vault para a clave da API.

  • Definir plans de probas. Definir casos de proba claros para os requisitos de seguridade. Avalía se podes automatizar esas probas nas túas canles de produción. Se o teu equipo ten procesos para probas manuais, inclúe requisitos de seguranza para esas probas.

Nota

Realizar modelaxe de ameazas durante esta fase. A modelización de ameazas pode confirmar que as opcións de deseño están aliñadas cos requisitos de seguridade e expoñer lagoas que debes mitigar. Se a túa carga de traballo xestiona datos moi confidenciais, inviste en expertos en seguridade que che poidan axudar a realizar modelizacións de ameazas.

O exercicio inicial de modelado de ameazas debería ter lugar durante a fase de deseño, cando se define a arquitectura e o deseño de alto nivel do software. Facelo durante esa fase axúdache a identificar posibles problemas de seguridade antes de que se incorporen á estrutura do sistema. Non obstante, este exercicio non é unha actividade puntual. É un proceso continuo que debería continuar ao longo da evolución do software.

Para obter máis información, consulte *Recomendacións sobre a análise de ameazas* .

Fase de desenvolvemento e probas

Durante esta fase, o obxectivo é evitar defectos de seguranza e manipulacións no código, na compilación e nas canles de despregamento.

Estar ben adestrado en prácticas de código seguro

O equipo de desenvolvemento debería ter formación en prácticas de codificación segura . Por exemplo, os desenvolvedores deben estar familiarizados cos conceptos de seguranza para implementar un modelo de seguranza con privilexios mínimos, as políticas de seguranza de contido para aplicacións baseadas en modelos para restrinxir a incrustación a dominios de confianza e os métodos de autenticación de conectores/portas de enlace locais. Microsoft Dataverse

Os desenvolvedores deberían completar esta formación antes de comezar a traballar en cargas de traballo. Power Platform

Realizar revisións internas de código por pares para promover a aprendizaxe continua.

Usar ferramentas de análise de código

Deberíase usar o Verificador de solucións para os recursos e poderíase comprobar o código fonte de calquera código tradicional para detectar posibles fallos de seguridade, incluída a presenza de credenciais no código. Power Platform Identificar posibles instancias de exposición de credenciais e segredos no código fonte e nos ficheiros de configuración. Este é un bo momento para revisar como se xestionarán as credenciais de conexión en produción.

Realizar probas de fuzz

Empregar datos incorrectos e inesperados para comprobar se hai vulnerabilidades e validar a xestión de erros, algo especialmente importante coas solucións que inclúen Power Pages.

Escribe o código xusto

Ao reducir a pegada do código, tamén se reducen as posibilidades de defectos de seguridade. Reutiliza código e bibliotecas que xa están en uso e que pasaron por validacións de seguranza en lugar de duplicar código. Detección e comprobación de versións, vulnerabilidades e obrigas legais de software de código aberto. Hai unha cantidade crecente de recursos de código aberto, polo que isto non se debe pasar por alto. Power Platform Sempre que sexa posible, isto debería discutirse durante a fase de deseño para evitar problemas de última hora.

Protexer os entornos de desenvolvemento

As estacións de traballo dos desenvolvedores deben estar protexidas con controis de rede e identidade sólidos para evitar a exposición. Asegúrate de que as actualizacións de seguridade se apliquen con dilixencia.

O repositorio de código fonte tamén debe estar protexido . Conceder acceso aos repositorios de código segundo a necesidade e reducir a exposición de vulnerabilidades tanto como sexa posible para evitar ataques. Dispoñer dun proceso exhaustivo para revisar o código en busca de vulnerabilidades de seguranza. Emprega grupos de seguranza para ese propósito e implementa un proceso de aprobación baseado en xustificacións empresariais.

Implementacións de código seguras

Non abonda con protexer o código. Se se executa en canles explotables, todos os esforzos de seguridade son fútiles e incompletos. Os entornos de compilación e lanzamento tamén deben estar protexidos para evitar que os malos actores executen código malicioso na súa canle.

Manteña un inventario actualizado de todos os compoñentes integrados na súa aplicación

Cada novo compoñente que se integra nunha aplicación aumenta a superficie de ataque. Para garantir a axeitada responsabilidade e a recepción de alertas cando se engadan ou actualicen novos compoñentes, debes ter un inventario destes compoñentes. De xeito regular, comproba que o teu manifesto coincide co que está no teu proceso de compilación. Facer isto axuda a garantir que non se engadan de forma inesperada novos compoñentes que conteñan portas traseiras ou outro software malicioso.

Recomendamos usar Tuberías para Power Platform para os teus despregamentos. Ampliar as canles usando accións de GitHub. Se usas fluxos de traballo de GitHub, prefire tarefas creadas por Microsoft. Ademais, valide as tarefas porque se executan no contexto de seguranza da súa canle.

Explorar o uso de principais servizos para a implementación.

Fase de produción

A fase de produción presenta a última oportunidade responsable para arranxar as lagoas de seguridade. Garda un rexistro da imaxe dourada que se publica en produción.

Manter os artefactos versionados

Manter un catálogo de todos os recursos despregados e as súas versións. Esta información é útil durante a avaliación de incidentes, cando se mitigan problemas e cando se volve poñer o sistema en funcionamento. Os activos versionados tamén se poden comparar cos avisos de vulnerabilidades e exposicións comúns (CVE) publicados. Deberías usar a automatización para realizar estas comparacións.

Correccións de emerxencia

O deseño automatizado da súa canle debería ter a flexibilidade de apoiar tanto os despregamentos regulares como os de emerxencia. Esta flexibilidade é importante para permitir correccións de seguridade rápidas e responsables.

Unha versión de lanzamento adoita estar asociada a varias portas de aprobación. Considere a creación dun proceso de emerxencia para acelerar as correccións de seguridade. O proceso podería implicar comunicación entre equipos. A canle debería permitir implementacións rápidas de avance e retroceso que aborden correccións de seguranza, erros críticos e actualizacións de código que se produzan fóra do ciclo de vida normal da implementación.

Nota

Prioriza sempre as solucións de seguridade por riba da comodidade. Unha corrección de seguranza non debería introducir unha regresión ou un erro. Se queres acelerar a corrección a través dunha canle de emerxencia, considera coidadosamente que probas automatizadas se poden omitir. Avaliar o valor de cada proba en función do tempo de execución. Por exemplo, as probas unitarias adoitan completarse rapidamente. As probas de integración ou de extremo a extremo poden executarse durante moito tempo.

Manteña os diferentes ambientes separados

Os datos de produción non se deben usar en contornas de nivel inferior porque estas poden non ter os controis de seguranza estritos que ten a produción.** Evite conectar desde unha aplicación que non sexa de produción a unha base de datos de produción e evite conectar compoñentes que non sexan de produción a redes de produción.

Usar exposición progresiva

Usar exposición progresiva para lanzar funcionalidades a un subconxunto de usuarios baseándose nos criterios escollidos. Se hai problemas, o impacto minimízase para eses usuarios. Esta estratexia é unha estratexia común de mitigación de riscos porque reduce a superficie. A medida que a funcionalidade madure e teñas máis confianza nas garantías de seguridade, poderás lanzala gradualmente a un conxunto máis amplo de usuarios.

Fase de mantemento

O obxectivo desta fase é garantir que a postura de seguridade non decaia co tempo. O SDLC é un proceso áxil continuo. Os conceptos tratados nas fases anteriores aplícanse a esta fase porque os requisitos cambian co tempo.

Mellora continua. Avaliar e mellorar continuamente a seguridade do proceso de desenvolvemento de software tendo en conta as revisións de código, os comentarios, as leccións aprendidas e as ameazas en evolución, así como as novas funcionalidades postas a disposición por Power Platform...

Desmantelar os activos herdados que estean obsoletos ou que xa non estean en uso. Facer isto reduce a superficie da aplicación.

O mantemento tamén inclúe a corrección de incidencias. Se se atopan problemas na produción, deben integrarse de novo no proceso de produción para que non se repitan.

Mellora continuamente as túas prácticas de codificación segura para manterte ao día co panorama das ameazas.

SDL en Microsoft Power Platform

Power Platform baséase nunha cultura e metodoloxía de deseño seguro. Tanto a cultura como a metodoloxía refórzanse constantemente a través das prácticas líderes do sector de Ciclo de vida de desenvolvemento de seguridade (SDL) e de modelado de ameazas de Microsoft.

O proceso de revisión do modelado de ameazas garante que as ameazas se identifiquen durante a fase de deseño, se mitiguen e se validen para asegurarse de que se mitigaron.

O modelado de ameazas tamén ten en conta todos os cambios nos servizos que xa están activos mediante revisións periódicas continuas. Basearse no modelo STRIDE axuda a abordar os problemas máis comúns do deseño inseguro. ...

O SDL de Microsoft é equivalente ao OWASP Software Assurance Maturity Model (SAMM). Os dous están construídos sobre a premisa de que o deseño seguro é parte integrante da seguridade das aplicacións web. Para obter máis información, consulte Os 10 principais riscos da OWASP: Mitigacións en Power Platform.

Power Platform facilitación

O Ciclo de vida do desenvolvemento de seguranza de Microsoft (SDL) recomenda prácticas seguras que podes aplicar ao teu ciclo de vida de desenvolvemento. Para obter máis información, consulte o Ciclo de vida do desenvolvemento de seguranza de Microsoft.

Defender para DevOps e as ferramentas SAST (Static Application Security Testing) inclúense como parte de GitHub Advanced Security e Azure DevOps. Estas ferramentas poden axudarche a rastrexar unha puntuación de seguridade para a túa organización.

Coa funcionalidade do verificador de solucións pode realizar unha completa verificación de análise estática das súas solucións con un conxunto de regras de prácticas recomendadas e identificar rapidamente estes padróns problemáticos. Consulta Usa o verificador de solucións para validar as túas solucións.

Lista de verificación de seguridade

Consulta o conxunto completo de recomendacións.

Lista de verificación de seguridade

  • Last updated on