Comparteix via

Recomanacions per assegurar un cicle de vida de desenvolupament

S'aplica a aquesta Power Platform recomanació de la llista de verificació de seguretat ben arquitectada:

SE:02 Mantingueu un cicle de vida de desenvolupament segur mitjançant una cadena de subministrament de programari reforçada, majoritàriament automatitzada i auditable. Incorporeu un disseny segur mitjançant el modelatge d'amenaces per protegir-vos contra implementacions que anul·len la seguretat.

Aquesta guia descriu les recomanacions per protegir el codi i l'entorn de desenvolupament aplicant les pràctiques recomanades de seguretat durant tot el cicle de desenvolupament.

Al nucli d'una càrrega de treball hi ha els components que implementen la lògica de negoci. Aquests components poden ser una barreja d'elements de codi baix, com ara aplicacions i fluxos de llenç, i elements de codi primer, com ara connectors. Tots els components que formen la vostra càrrega de treball han d'estar lliures de defectes de seguretat per garantir la confidencialitat, la integritat i la disponibilitat.

Assegurar el pla d'infraestructura amb controls d'identitat i xarxa és important, però no és suficient. Eviteu una mala implementació de càrregues de Power Platform treball i activitats compromeses en aquestes càrregues de treball per reforçar la vostra postura de seguretat general. El procés d'integració de la seguretat en el cicle de vida del desenvolupament és essencialment un procés d'enduriment. Igual que l'enduriment de recursos, l'enduriment del desenvolupament de codi també és agnòstic del context. L'objectiu és millorar la seguretat, no els requisits funcionals de l'aplicació.

Definicions

Terme Definició
Cicle de vida de desenvolupament de seguretat (SDL) Un conjunt de pràctiques proporcionades per Microsoft que admet els requisits de garantia de seguretat i compliment.
Cicle de vida de desenvolupament de programari (SDLC) Un procés sistemàtic de diverses etapes per al desenvolupament de sistemes de programari.

Estratègies clau de disseny

Les mesures de seguretat s'han d'integrar en diversos punts del cicle de vida de desenvolupament de programari (SDLC) existent per assegurar:

  • Les opcions de disseny no comporten llacunes de seguretat.
  • Els components de codi baix i de codi primer, així com la configuració, no creen vulnerabilitats a causa de la implementació explotable i les pràctiques de codificació inadequades.
  • Els components i els processos de desplegament de codi baix i primer no es manipulen.
  • Es mitiguen les vulnerabilitats revelades a través dels incidents.
  • Els requisits de compliment no es veuen compromesos ni reduïts.
  • El registre d'auditoria s'implementa en tots els entorns.

Les seccions següents proporcionen estratègies de seguretat per a les fases comunament practicades de SDLC.

Fase de requisits

L'objectiu de la fase de requisits és recopilar i analitzar els requisits funcionals i no funcionals per a una càrrega de treball o una nova característica d'una càrrega de treball. Aquesta fase és important perquè facilita la creació de baranes adaptades als objectius de la càrrega de treball. Protegir les dades i la integritat de la vostra càrrega de treball hauria de ser un requisit bàsic en totes les fases del cicle de vida del desenvolupament.

Per exemple, considereu una càrrega de treball en què els usuaris introduiran i modificaran dades dins d'una aplicació. Les opcions de disseny de seguretat han de cobrir garanties per a la interacció de l'usuari amb les dades, com ara autenticar i autoritzar la identitat de l'usuari i permetre només accions permeses sobre les dades. Els requisits no funcionals cobreixen la disponibilitat, la usabilitat i el manteniment. Les opcions de seguretat haurien d'incloure límits de segmentació, entrada i sortida del tallafoc i altres problemes de seguretat transversals.

Totes aquestes decisions haurien de conduir a una bona definició de la postura de seguretat de la càrrega de treball. Documenteu els requisits de seguretat en una especificació acordada i reflectiu-los en el backlog. El document ha d'indicar explícitament les inversions en seguretat i les compensacions i els riscos que l'empresa està disposada a assumir si les inversions no són aprovades per les parts interessades de l'empresa. Per exemple, podeu documentar la necessitat d'utilitzar un tallafoc IP en Power Platform entorns per protegir les dades de l'organització restringint Dataverse l'accés només a les ubicacions IP permeses. Si les parts interessades de l'empresa no estan disposades a assumir el cost addicional d'utilitzar una solució com els Entorns administrats, han d'estar preparades per acceptar el risc que s'accedeixi als recursos organitzatius des d'ubicacions públiques, com ara una cafeteria. Com a exemple, imagineu que la vostra aplicació s'ha de connectar a una font de dades de tercers. Power Platform Pot ser que tingui un connector preparat per a això, però pot ser que no admeti els requisits d'autenticació aprovats pels vostres equips de seguretat. En aquest cas, les parts interessades en seguretat poden acceptar el risc d'utilitzar un mètode d'autenticació no aprovat. Alternativament, podeu explorar l'ús d'un connector personalitzat, mentre sospeseu els avantatges de l'augment del temps de desenvolupament i el possible retard del projecte.

La recopilació de requisits de seguretat és una part crítica d'aquesta fase. Sense aquest esforç, les fases de disseny i implementació es basaran en opcions no declarades, que poden provocar llacunes de seguretat o canvis en els requisits que augmentaran el temps de desenvolupament. És possible que hàgiu de canviar la implementació més endavant per adaptar-vos a la seguretat, que pot ser costosa.

Fase de disseny

Durant aquesta fase, els requisits de seguretat es converteixen en requisits tècnics. A la vostra especificació tècnica, documenteu totes les decisions de disseny per evitar ambigüitats durant la implementació. Aquí teniu algunes tasques típiques:

  • Definir la dimensió de seguretat de l'arquitectura. Superposa l'arquitectura amb controls de seguretat. Per exemple, controls pràctics sobre els límits d'aïllament de la xarxa, els tipus d'identitats i mètodes d'autenticació necessaris per als components de la càrrega de treball i el tipus de mètodes de xifratge a utilitzar.

  • Avaluar les possibilitats proporcionades per la plataforma. És important entendre la divisió de responsabilitats entre vosaltres i Power Platform. Eviteu la superposició o la duplicació amb Power Platform controls de seguretat natius. Obtindreu una millor cobertura de seguretat i podreu reassignar recursos de desenvolupament a les necessitats de l'aplicació.

    Per exemple, en lloc de crear una lògica personalitzada que identifiqui i alerti de manera reactiva sobre patrons d'ús no aprovats en aplicacions i fluxos, utilitzeu normes de dades per classificar com es poden utilitzar els connectors.

    Trieu només implementacions de referència, plantilles, components de codi, scripts i biblioteques de confiança. El vostre disseny també ha d'especificar un control de versions segur. Les dependències de l'aplicació s'han d'obtenir de parts de confiança. Els proveïdors externs haurien de poder complir els vostres requisits de seguretat i compartir el seu pla de divulgació responsable. Qualsevol incident de seguretat s'ha d'informar ràpidament perquè pugueu prendre les mesures necessàries. A més, és possible que la vostra organització prohibeixi determinades biblioteques o implementacions de referència. Per exemple, fins i tot si és segur i lliure de vulnerabilitats, encara es pot no permetre perquè utilitza característiques encara no aprovades per la vostra organització, restriccions de llicència o el model de suport de la implementació de referència.

    Per assegurar-vos que es segueixen aquestes directrius, mantingueu una llista de marcs, biblioteques i proveïdors aprovats i/o no aprovats, i assegureu-vos que els vostres creadors estiguin familiaritzats amb aquesta llista. Quan sigui possible, col·loqueu barreres de seguretat en els pipelines de desenvolupament per donar suport a la llista. En la mesura del possible, automatitzeu l'ús d'eines per escanejar les dependències a la recerca de vulnerabilitats.

  • Emmagatzema els secrets de l'aplicació de manera segura. Implementeu de manera segura l'ús de secrets d'aplicació i claus compartides prèviament que utilitza la vostra aplicació. Les credencials i els secrets de l'aplicació no s'han d'emmagatzemar mai al codi font de la càrrega de treball (aplicació o flux). Utilitzeu recursos externs com Azure Key Vault per assegurar-vos que, si el vostre codi font està disponible per a un atacant potencial, no es pugui obtenir més accés.

  • Connecteu-vos a les vostres dades de manera segura. Utilitzeu les característiques de seguretat sòlides que Microsoft Dataverse ofereix protegir les vostres dades, com ara la seguretat basada en funcions i a nivell de columna. Per a altres fonts de dades, utilitzeu connectors que tinguin mètodes d'autenticació segurs. Eviteu les consultes que emmagatzemen el nom d'usuari i la contrasenya en text sense format. Eviteu HTTP per crear connectors personalitzats.

  • Definiu com els usuaris finals interactuaran amb la càrrega de treball i les dades. Considereu si els usuaris tindran accés directe a les dades, quin nivell d'accés necessiten i des d'on accediran a les dades. Penseu en com es compartiran les aplicacions amb els usuaris finals. Assegureu-vos que només hi tinguin accés a l'aplicació i a les dades. Eviteu models de seguretat complexos que fomentin solucions alternatives per evitar bloquejadors de seguretat.

  • Eviteu la codificació dura. Eviteu la codificació rígida d'URL i claus. Per exemple, eviteu codificar en una Power Automate acció HTTP l'URL o la clau del servei de backend. En lloc d'això, utilitzeu un connector personalitzat o utilitzeu una variable d'entorn per a l'adreça URL i Azure Key Vault per a la clau d'API.

  • Definir plans de prova. Definiu casos de prova clars per als requisits de seguretat. Avalueu si podeu automatitzar aquestes proves en els vostres pipelines. Si el vostre equip té processos per a proves manuals, incloeu requisits de seguretat per a aquestes proves.

Nota

Realitzeu el modelatge d'amenaces durant aquesta fase. El modelatge d'amenaces pot confirmar que les opcions de disseny estan alineades amb els requisits de seguretat i exposar les llacunes que hauríeu de mitigar. Si la vostra càrrega de treball gestiona dades altament sensibles, invertiu en experts en seguretat que us puguin ajudar a dur a terme el modelatge d'amenaces.

L'exercici inicial de modelatge d'amenaces s'ha de produir durant la fase de disseny quan es defineix l'arquitectura del programari i el disseny d'alt nivell. Fer-ho durant aquesta fase us ajuda a identificar possibles problemes de seguretat abans que s'incorporin a l'estructura del sistema. Tanmateix, aquest exercici no és una activitat única. És un procés continu que hauria de continuar al llarg de l'evolució del programari.

Per obtenir més informació, vegeu Recomanacions sobre l'anàlisi d'amenaces.

Fase de desenvolupament i proves

Durant aquesta fase, l'objectiu és evitar defectes de seguretat i manipulacions en els pipelines de codi, compilació i implementació.

Estar ben format en pràctiques de codi segur

L'equip de desenvolupament ha de tenir formació en pràctiques de codificació segures. Per exemple, els desenvolupadors haurien d'estar familiaritzats amb els conceptes Microsoft Dataverse de seguretat per implementar un model de seguretat amb privilegis mínims, polítiques de seguretat de contingut per a aplicacions basades en models per restringir la incrustació a dominis de confiança i mètodes d'autenticació de connectors/passarel·les locals.

Els desenvolupadors haurien de completar aquesta formació abans de començar a treballar en Power Platform càrregues de treball.

Realitzar revisions internes de codi per afavorir l'aprenentatge continu.

Utilitzar eines d'anàlisi de codi

S'ha d'utilitzar el verificador de solucions per als Power Platform recursos, i el codi font de qualsevol codi tradicional es pot comprovar per detectar possibles defectes de seguretat, inclosa la presència de credencials en el codi. Identificar possibles instàncies d'exposició credencial i secreta en el codi font i fitxers de configuració. Aquest és un bon moment per revisar com es gestionaran les credencials de connexió en producció.

Realitza proves de difusa

Utilitzeu dades incorrectes i inesperades per comprovar si hi ha vulnerabilitats i validar la gestió d'errors, especialment important amb solucions que inclouen Power Pages.

Escriu prou codi

Quan reduïu l'empremta del codi, també reduïu les possibilitats de defectes de seguretat. Reutilitzeu el codi i les biblioteques que ja s'utilitzen i han passat per validacions de seguretat en lloc de duplicar el codi. Detecció de programari de codi obert i comprovació de versions, vulnerabilitats i obligacions legals. Hi ha una quantitat creixent de recursos de codi Power Platform obert, de manera que no s'ha de passar per alt. Quan sigui possible, s'ha de discutir durant la fase de disseny per evitar problemes d'última hora.

Protegir els entorns de desenvolupadors

Les estacions de treball dels desenvolupadors han d'estar protegides amb forts controls de xarxa i identitat per evitar l'exposició. Assegureu-vos que les actualitzacions de seguretat s'apliquin amb diligència.

El repositori de codi font també s'ha de protegir . Concediu accés als repositoris de codi segons la necessitat de conèixer i reduïu l'exposició de vulnerabilitats tant com sigui possible per evitar atacs. Tenir un procés exhaustiu per revisar el codi per detectar vulnerabilitats de seguretat. Utilitzeu grups de seguretat per a aquest propòsit i implementeu un procés d'aprovació basat en justificacions empresarials.

Implementacions de codi segur

No n'hi ha prou amb protegir el codi. Si s'executa en canonades explotables, tots els esforços de seguretat són inútils i incomplets. Els entorns de compilació i llançament també han d'estar protegits perquè voleu evitar que els actors maliciosos executin codi maliciós al pipeline.

Mantingueu un inventari actualitzat de tots els components integrats a la vostra aplicació

Cada component nou que s'integra en una aplicació augmenta la superfície d'atac. Per garantir una responsabilitat i alertes adequades quan s'afegeixen o actualitzen nous components, hauríeu de tenir un inventari d'aquests components. Regularment, comproveu que el vostre manifest coincideixi amb el que hi ha al vostre procés de compilació. Fer-ho ajuda a garantir que no s'afegeixin inesperadament components nous que continguin portes del darrere o altres programes maliciosos.

Us recomanem que utilitzeu Pipelines per Power Platform a les vostres implementacions. Estendre els pipelines mitjançant GitHub Actions. Si utilitzeu fluxos de treball de GitHub, preferiu les tasques creades per Microsoft. A més, valideu les tasques perquè s'executen en el context de seguretat del pipeline.

Exploreu l'ús de les entitats de servei per a la implementació.

Fase de producció

La fase de producció presenta l'última oportunitat responsable per solucionar les bretxes de seguretat. Mantingueu un registre de la imatge daurada que es publica en producció.

Mantenir els artefactes versionats

Mantingueu un catàleg de tots els actius desplegats i les seves versions. Aquesta informació és útil durant el triatge d'incidents, quan mitigueu els problemes i quan torneu el sistema a l'estat de funcionament. Els actius versionats també es poden comparar amb els avisos publicats de vulnerabilitats i exposicions comunes (CVE). Hauríeu d'utilitzar l'automatització per realitzar aquestes comparacions.

Solucions d'emergència

El disseny de canonades automatitzades ha de tenir la flexibilitat per admetre desplegaments regulars i d'emergència. Aquesta flexibilitat és important per donar suport a correccions de seguretat ràpides i responsables.

Normalment, un llançament s'associa amb diverses portes d'aprovació. Penseu en crear un procés d'emergència per accelerar les correccions de seguretat. El procés pot implicar la comunicació entre equips. El pipeline ha de permetre implementacions ràpides de reversió i retrocés que abordin correccions de seguretat, errors crítics i actualitzacions de codi que es produeixen fora del cicle de vida de la implementació normal.

Nota

Prioritzeu sempre les correccions de seguretat sobre la comoditat. Una correcció de seguretat no hauria d'introduir una regressió o un error. Si voleu accelerar la solució mitjançant una canonada d'emergència, considereu acuradament quines proves automatitzades es poden evitar. Avalueu el valor de cada prova en relació amb el temps d'execució. Per exemple, les proves unitàries solen completar-se ràpidament. Les proves d'integració o d'extrem a extrem es poden executar durant molt de temps.

Mantingueu diferents entorns separats

Les dades de producció no s'han d'utilitzar en entorns inferiors** perquè aquests entorns poden no tenir els estrictes controls de seguretat que té la producció. Eviteu connectar-vos des d'una aplicació que no sigui de producció a una base de dades de producció i eviteu connectar components que no siguin de producció a xarxes de producció.

Utilitzar l'exposició progressiva

Utilitzeu l'exposició progressiva per publicar funcions a un subconjunt d'usuaris en funció dels criteris escollits. Si hi ha problemes, l'impacte es minimitza per a aquests usuaris. Aquest enfocament és una estratègia comuna de mitigació de riscos perquè redueix la superfície. A mesura que la funció maduri i tingueu més confiança en les garanties de seguretat, podeu alliberar-la gradualment a un conjunt més ampli d'usuaris.

Fase de manteniment

L'objectiu d'aquesta fase és assegurar-se que la postura de seguretat no disminueixi amb el temps. SDLC és un procés àgil continu. Els conceptes tractats en les fases anteriors s'apliquen a aquesta fase perquè els requisits canvien amb el temps.

Millora contínua. Avaluar i millorar contínuament la seguretat del procés de desenvolupament de programari tenint en compte les revisions de codi, els comentaris, les lliçons apreses i les amenaces en evolució, així com les noves funcions disponibles per Power Platform.

Retireu els actius heretats que estiguin obsolets o que ja no s'utilitzin. Fer-ho redueix la superfície de l'aplicació.

El manteniment també inclou correccions d'incidents. Si es troben problemes en producció, s'han d'integrar ràpidament al procés perquè no es repeteixin.

Millora contínuament les teves pràctiques de codificació segura per mantenir-te al dia amb el panorama d'amenaces.

SDL a Microsoft Power Platform

Power Platform està creat en una cultura i metodologia de disseny segur. Tant la cultura com la metodologia es reforçen constantment a través del cicle de vida del desenvolupament de seguretat (SDL) i de les pràctiques del modelatge d'amenaça de Microsoft.

El procés de revisió del modelatge d'amenaces garanteix que s'identifiquen amenaces durant l'amenaces de disseny, mitigar i validar-se per assegurar-se que s'han mitigar.

El modelatge d'amenaces també mostra tots els canvis en els serveis que ja estan animats mitjançant revisions periòdiques contínues. Confiar en el model STRIDE ajuda a abordar els problemes més comuns amb el disseny insegur.

L'SDL de Microsoft s'equivalent al model de l'assurència de programari d'OWASP (SAMM). Ambdós estan integrats a la premissa que el disseny segur és exclusiu de la seguretat de l'aplicació web. Per obtenir més informació, vegeu Els 10 principals riscos de l'OWASP: mitigacions a Power Platform.

Power Platform facilitació

Microsoft Cicle de vida de desenvolupament de seguretat (SDL) recomana pràctiques segures que podeu aplicar al vostre cicle de vida de desenvolupament. Per obtenir més informació, vegeu Microsoft Cicle de vida del desenvolupament de la seguretat.

Defender for DevOps i les eines SAST (Static Application Security Testing) s'inclouen com a part de GitHub Advanced Security i Azure DevOps. Aquestes eines us poden ajudar a fer un seguiment d'una puntuació de seguretat per a la vostra organització.

Amb la característica del verificador de solucions, podeu realitzar una verificació d'anàlisi estàtica rica en les vostres solucions amb un conjunt de regles de les pràctiques recomanades i identificar ràpidament aquests patrons problemàtics. Vegeu Utilitzar el verificador de solucions per validar les solucions.

Llista de comprovació de seguretat

Consulteu el conjunt complet de recomanacions.

Llista de comprovació de seguretat

  • Last updated on