Raccomandazioni per proteggere un ciclo di vita di sviluppo

Si applica a questa raccomandazione per l'elenco di controllo della sicurezza Well-Architected di Power Platform:

Questa guida descrive le raccomandazioni per proteggere il codice e l'ambiente di sviluppo applicando le migliori pratiche di sicurezza durante tutto il ciclo di sviluppo.

Al centro di un carico di lavoro ci sono i componenti che implementano la logica aziendale. Questi componenti possono essere un mix di elementi con poco codice come app e flussi canvas ed elementi code-first come i plug-in. Tutti i componenti che compongono il carico di lavoro devono essere privi di difetti di sicurezza per garantire riservatezza, integrità e disponibilità.

Proteggere il piano infrastrutturale con controlli di identità e di rete è importante, ma non è sufficiente. Previeni una cattiva implementazione dei carichi di lavoro di Power Platform e attività compromesse in tali carichi di lavoro per rafforzare il livello di sicurezza generale. Il processo di integrazione della sicurezza nel ciclo di vita dello sviluppo è essenzialmente un processo di rafforzamento. Proprio come il rafforzamento delle risorse, anche quello dello sviluppo del codice è indipendente dal contesto. L'attenzione è rivolta al miglioramento della sicurezza, non ai requisiti funzionali dell'applicazione.

Definizioni

Strategie di progettazione chiave

Le misure di sicurezza devono essere integrate in più punti nel ciclo di vita dello sviluppo software (SDLC) esistente per garantire che:

• Le scelte progettuali non portano a lacune di sicurezza.
• I componenti con poco codice e code-first, nonché la configurazione, non creano vulnerabilità a causa di implementazioni sfruttabili e pratiche di codifica improprie.
• I componenti e i processi di distribuzione con poco codice e code-first non vengono manomessi.
• Le vulnerabilità rivelate attraverso gli incidenti vengono mitigate.
• I requisiti di conformità non vengono compromessi o ridotti.
• La registrazione di controllo è implementata in tutti gli ambienti.

Le sezioni seguenti forniscono strategie di sicurezza per le fasi comunemente praticate di SDLC.

Fase dei requisiti

L'obiettivo della fase dei requisiti è raccogliere e analizzare i requisiti funzionali e non funzionali per un carico di lavoro o una nuova funzionalità di un carico di lavoro. Questa fase è importante perché facilita la creazione di protezioni adeguate agli obiettivi del carico di lavoro. La protezione dei dati e dell'integrità del carico di lavoro devono essere un requisito fondamentale in ogni fase del ciclo di vita dello sviluppo.

Prendi in considerazione, ad esempio, un carico di lavoro in cui gli utenti inseriranno e modificheranno i dati all'interno di un'applicazione. Le scelte di progettazione relative alla sicurezza devono coprire le garanzie per l'interazione dell'utente con i dati, come l'autenticazione e l'autorizzazione dell'identità dell'utente e consentendo solo le azioni permesse sui dati. I requisiti non funzionali riguardano la disponibilità, l’usabilità e la manutenibilità. Le scelte relative alla sicurezza devono includere limiti di segmentazione, ingresso e uscita dal firewall e altri problemi di sicurezza trasversali.

Tutte queste decisioni devono portare a una buona definizione del livello di sicurezza del carico di lavoro. Documenta i requisiti di sicurezza in una specifica concordata e riflettili nel backlog. Il documento deve indicare esplicitamente gli investimenti in sicurezza, i compromessi e i rischi che l'azienda è disposta ad assumersi se gli investimenti non vengono approvati dagli stakeholder dell'azienda. Ad esempio, potresti documentare la necessità di utilizzare un firewall IP negli ambienti Power Platform per proteggere i dati della tua organizzazione limitando l'accesso a Dataverse solo alle posizioni IP consentite. Se gli stakeholder dell'azienda non sono disposti a sostenere il costo aggiuntivo derivante dall'utilizzo di una soluzione come Ambienti gestiti, devono essere pronti ad accettare il rischio di accesso alle risorse organizzative da luoghi pubblici, come un bar. Come altro esempio, immagina che la tua applicazione debba connettersi a un origine dati di terze parti. Power Platform potrebbe avere un connettore già pronto per questo, ma potrebbe non supportare i requisiti di autenticazione approvati dai tuoi team di sicurezza. In questo caso, gli stakeholder della sicurezza potrebbero essere disposti ad accettare il rischio di utilizzare un metodo di autenticazione non approvato. In alternativa, potresti esplorare l'utilizzo di un connettore personalizzato, valutando al tempo stesso i vantaggi di un aumento dei tempi di sviluppo e del potenziale ritardo del progetto.

La raccolta dei requisiti di sicurezza è una parte fondamentale di questa fase. Senza questo sforzo, le fasi di progettazione e implementazione si baseranno su scelte non dichiarate, che possono portare a lacune di sicurezza o modifiche dei requisiti che aumenteranno i tempi di sviluppo. Potrebbe essere necessario modificare l'implementazione in un secondo momento per garantire la sicurezza, il che può essere costoso.

Fase di progettazione

Durante questa fase i requisiti di sicurezza vengono convertiti in requisiti tecnici. Nelle specifiche tecniche, documenta tutte le decisioni di progettazione per evitare ambiguità durante l'implementazione. Di seguito sono riportate alcune attività tipiche:

• Definisci la dimensione di sicurezza dell'architettura. Sovrapponi l'architettura con controlli di sicurezza. Ad esempio, controlli pratici sui confini di isolamento della rete, i tipi di identità e metodi di autenticazione necessari per i componenti del carico di lavoro e il tipo di metodi di crittografia da utilizzare.

• Valuta le garanzie fornite dalla piattaforma. È importante comprendere la divisione delle responsabilità tra te e Power Platform. Evita sovrapposizioni o duplicazioni con controlli di sicurezza nativi di Power Platform. Otterrai una migliore copertura di sicurezza e sarai in grado di riallocare le risorse di sviluppo in base alle esigenze dell'applicazione.

  Ad esempio, invece di creare una logica personalizzata che identifichi in modo reattivo e avvisi su modelli di utilizzo non approvati nelle app e nei flussi, utilizza i criteri DLP per classificare come possono essere utilizzati i connettori.

  Scegli solo implementazioni, modelli, componenti di codice, script e librerie di riferimento attendibili. Il tuo progetto deve anche specificare il controllo sicuro della versione. Le dipendenze dell'applicazione devono essere originate da parti attendibili. I fornitori di terze parti devono essere in grado di soddisfare i tuoi requisiti di sicurezza e condividere il loro piano di divulgazione responsabile. Qualsiasi incidente di sicurezza deve essere segnalato tempestivamente in modo che tu possa intraprendere le azioni necessarie. Inoltre, alcune librerie o implementazioni di riferimento potrebbero essere vietate dalla tua organizzazione. Ad esempio, anche se sicure e prive di vulnerabilità, potrebbero comunque non essere consentite perché utilizzano funzionalità non ancora approvate dalla tua organizzazione, restrizioni di licenza o il modello di supporto dell'implementazione di riferimento.

  Per garantire che queste linee guida vengano seguite, mantieni un elenco di framework, librerie e fornitori approvati e/o non approvati e assicurati che i tuoi creatori abbiano familiarità con questo elenco. Quando possibile, posiziona delle protezioni nelle pipeline di sviluppo per supportare l'elenco. Per quanto possibile, automatizza l'uso degli strumenti per scansionare le dipendenze alla ricerca di vulnerabilità.

• Archivia i segreti dell'applicazione in modo sicuro. Implementa in modo sicuro l'uso dei segreti dell'applicazione e delle chiavi precondivise utilizzate dall'applicazione. Le credenziali e i segreti dell'applicazione non devono mai essere archiviati nel codice sorgente del carico di lavoro (app o flusso). Usa risorse esterne come Azure Key Vault per garantire che, se il codice sorgente diventa disponibile per un potenziale utente malintenzionato, non sia possibile ottenere ulteriore accesso.

• Connettiti ai dati del cliente Utilizza le potenti funzionalità di sicurezza che Microsoft Dataverse offre per salvaguardare i tuoi dati, come la sicurezza basata su ruoli e a livello di colonna. Per altre origini dati, utilizza connettori dotati di metodi di autenticazione sicuri. Evita query che memorizzano nome utente e password in testo semplice. Non utilizzare il protocollo HTTP per creare connettori personalizzati.

• Definire il modo in cui gli utenti finali interagiranno con il carico di lavoro e i dati. Prendi in considerazione se gli utenti avranno accesso diretto ai dati, quale livello di accesso richiedono e da dove accederanno ai dati. Pensa a come le applicazioni verranno condivise con gli utenti finali. Assicurati che solo coloro che hanno bisogno di accedere all'app e ai dati possano accedervi. Evita modelli di sicurezza complessi che incoraggiano soluzioni alternative per evitare blocchi di sicurezza.

• Evita l'hardcoding. Evita l'hardcoding di URL e chiavi. Ad esempio, in un'azione HTTP Power Automate evita l'hardcoding dell'URL o della chiave del servizio backend. Usa invece un connettore personalizzato o una variabile di ambiente per l'URL e Azure Key Vault per la chiave API.

• Definisci piani di test. Definisci casi di test chiari per i requisiti di sicurezza. Valuta se puoi automatizzare questi test nelle tue pipeline. Se il tuo team dispone di processi per test manuali, includi i requisiti di sicurezza per tali test.

Fase di sviluppo e test

Durante questa fase, l'obiettivo è di protezioneprevenire difetti di sicurezza e la manomissione delle pipeline di codice, compilazione e distribuzione.

Acquisire una formazione appropriata sulle pratiche di codice sicuro

Al team di sviluppo deve essere fornita formazione sulle pratiche di codifica sicura. Ad esempio, gli sviluppatori devono avere familiarità con i concetti di sicurezza in Microsoft Dataverse per implementare un modello di sicurezza con privilegi minimi, criteri di sicurezza dei contenuti per le app basate su modello per limitare l'incorporamento a domini attendibili e metodi di autenticazione del connettore/gateway locale.

Agli sviluppatori deve essere richiesto di completare questa formazione prima di iniziare a lavorare su carichi di lavoro di Power Platform.

Esegui revisioni interne di codice peer per promuovere l'apprendimento continuo.

Utilizzare strumenti di analisi del codice

Verifica soluzione deve essere utilizzato per le risorse Power Platform e il codice sorgente di qualsiasi codice tradizionale potrebbe essere controllato per verificare l'esistenza di potenziali difetti di sicurezza, inclusa la presenza di credenziali nel codice. Identifica possibili istanze di esposizione di credenziali e segreti nel codice sorgente e nei file di configurazione. Questo è un buon momento per esaminare come verranno gestite le credenziali di connessione in produzione.

Eseguire test con dati casuali

Utilizza dati non corretti e imprevisti per verificare la presenza di vulnerabilità e convalidare la gestione degli errori, aspetto particolarmente importante con soluzioni che includono Power Pages.

Scrivere solo il codice necessario

Riducendo l'impronta del codice, riduci anche le possibilità di difetti di sicurezza. Riutilizza il codice e le librerie già in uso e che sono stati sottoposti a convalide di sicurezza invece di duplicare il codice. Rendi open source il rilevamento di software e il controllo di versione, vulnerabilità e obblighi legali. C'è una quantità crescente di risorse Power Platform open source quindi ciò non deve essere trascurato. Quando possibile, questo argomento deve essere discusso durante la fase di progettazione per evitare problemi dell’ultimo minuto.

Proteggere gli ambienti per sviluppatori

Le workstation degli sviluppatori devono essere protette con forti controlli di rete e identità per prevenire l'esposizione. Assicurati che gli aggiornamenti di sicurezza vengano applicati diligentemente.

Anche il repository del codice sorgente deve essere salvaguardato. Concedi l'accesso a repository di codice in base alle necessità e ridurre il più possibile l'esposizione delle vulnerabilità per evitare attacchi. Dotati di un processo di revisione del codice approfondito per identificare le vulnerabilità nella sicurezza. Utilizza gruppi di sicurezza a tale scopo e implementa un processo di approvazione basato su giustificazioni aziendali.

Proteggere le distribuzioni di codice

Non è sufficiente solo proteggere il codice. Se viene eseguito in pipeline sfruttabili, tutti gli sforzi di sicurezza sono inutili e incompleti. Anche gli ambienti di creazione e rilascio devono essere protetti perché vuoi impedire ai malintenzionati di eseguire codice dannoso nella tua pipeline.

Gestire un inventario aggiornato di ogni componente integrato nell'applicazione

Ogni nuovo componente integrato in un'applicazione aumenta la superficie di attacco. Per garantire la corretta responsabilità e ricevere avvisi quando vengono aggiunti o aggiornati nuovi componenti, devi disporre di un inventario di questi componenti. Controlla regolarmente che il tuo manifesto corrisponda a ciò che è presente nel tuo processo di creazione. Ciò aiuta a garantire che nessun nuovo componente contenente back door o altro malware venga aggiunto inaspettatamente.

Ti consigliamo di utilizzare Pipeline per Power Platform per le tue distribuzioni. Estendi le pipeline usando GitHub Actions. Se utilizzi flussi di lavoro GitHub, preferisci le attività create da Microsoft. Inoltre, convalida le attività perché vengono eseguite nel contesto di protezione della pipeline.

Esplora l'uso delle entità servizio per la distribuzione.

Fase di produzione

La fase di produzione rappresenta l'ultima opportunità responsabile per colmare le lacune di sicurezza. Crea un record dell'immagine dorata rilasciata in produzione.

Conservare artefatti con versione

Conserva un catalogo di tutte le risorse distribuite e delle relative versioni. Queste informazioni sono utili durante la valutazione degli incidenti, quando si mitigano i problemi e quando si riporta il sistema allo stato funzionante. Le risorse con versione possono anche essere confrontate con gli avvisi CVE (Common Vulnerabilities and Exposures) pubblicati. Devi utilizzare l'automazione per eseguire questi confronti.

Correzioni di emergenza

La progettazione automatizzata delle pipeline deve avere la flessibilità per supportare distribuzioni regolari che di emergenza. Questa flessibilità è importante per supportare soluzioni di sicurezza rapide e responsabili.

Una versione è in genere associata a più controlli di approvazione. Prendi in considerazione la creazione di un processo di emergenza per accelerare le correzioni di sicurezza. Il processo potrebbe comportare la comunicazione tra team. La pipeline deve consentire distribuzioni rapide di rollforward e rollback che risolvano correzioni di sicurezza, bug critici e aggiornamenti del codice che si verificano al di fuori del normale ciclo di vita della distribuzione.

Mantenere separati i diversi ambienti

I dati di produzione non devono essere utilizzati in ambienti inferiori** perché tali ambienti potrebbero non avere i rigidi controlli di sicurezza di cui dispone la produzione. Evita la connessione tra un'applicazione non di produzione e un database di produzione ed evita la connessione di componenti non di produzione a reti di produzione.

Usare l'esposizione progressiva

Utilizzare l'esposizione progressiva alle funzionalità di rilascio per un sottoinsieme di utenti in base ai criteri scelti. Se si verificano problemi, l'impatto per gli utenti è ridotto al minimo. Questo approccio è una strategia comune di mitigazione del rischio perché riduce la superficie. Man mano che la funzionalità viene migliorata e acquisisci maggiore fiducia nelle garanzie di sicurezza, puoi rilasciarla gradualmente a un gruppo più ampio di utenti.

Fase di manutenzione

L'obiettivo di questa fase è assicurarsi che il livello di sicurezza non decada nel tempo. SDLC è un processo agile e continuo. I concetti trattati nelle fasi precedenti si applicano a questa fase perché i requisiti cambiano nel tempo.

Miglioramento continuo. Valuta e migliora continuamente la sicurezza del processo di sviluppo del software tenendo conto di revisioni del codice, feedback, lezioni apprese e minacce in evoluzione, nonché di nuove funzionalità rese disponibili da Power Platform.

Rimuovi le risorse legacy che sono obsolete o non più in uso. In questo modo si riduce la superficie dell'applicazione.

La manutenzione include anche la risoluzione degli incidenti. Se vengono rilevati problemi nella produzione, è necessario reintegrarli tempestivamente nel processo in modo che non si ripetano.

Migliora continuamente le tue pratiche di codifica sicura per stare al passo con il panorama delle minacce.

SDL in Microsoft Power Platform

Power Platform si basa su una cultura e una metodologia di progettazione sicura. La cultura e la metodologia sono costantemente rafforzati delle procedure Security Development Lifecycle (SDL) e Modellazione delle minacce.

Il processo di revisione della modellazione delle minacce garantisce che le minacce vengano identificate durante la fase di progettazione, mitigate e convalidate per assicurarsi che le minacce siano state mitigate.

La modellazione delle minacce tiene conto anche di tutte le modifiche ai servizi già attivi attraverso continue revisioni periodiche. Il modello STRIDE aiuta ad affrontare i problemi più comuni con una progettazione insicura.

SDL di Microsoft è equivalente al Modello OWASP Software Assurance Maturity (SAMM). Entrambi si basano sul presupposto che una progettazione sicura è parte integrante della sicurezza delle applicazioni web. Per ulteriori informazioni, vedi I 10 principali rischi di OWASP: mitigazioni in Power Platform.

Facilitazione di Power Platform

Microsoft Security Development Lifecycle (SDL) consiglia pratiche sicure che è possibile applicare al ciclo di vita di sviluppo. Per ulteriori informazioni, consulta Microsoft Security Development Lifecycle.

Defender per DevOps e gli strumenti SAST (Static Application Security Testing) sono inclusi come parte di GitHub Advanced Security e Azure DevOps. Questi strumenti possono aiutarti a tenere traccia del punteggio di sicurezza della tua organizzazione.

Con la funzionalità verifica soluzione, è possibile eseguire un controllo di analisi statica completo delle soluzioni rispetto a un set di regole di procedure consigliate e individuare rapidamente gli schemi problematici. Vedi Usare Verifica soluzione per convalidare le soluzioni.

Vedi anche

• Gestione del ciclo di vita delle applicazioni (ALM) con Microsoft Power Platform
• Panoramica delle pipeline in Power Platform
• Application Lifecycle Management per Power Platform
• Serie per architetti di soluzioni - Pianificazione di Application Lifecycle Management per Power Platform
• Utilizzare le variabili di ambiente nelle soluzioni
• Utilizzare la verifica della soluzione per convalidare le soluzioni

Elenco di controllo della sicurezza

Fare riferimento alla serie completa di raccomandazioni.