Procedure consigliate per i API Sicurezza

Per sviluppare software sicuro, è consigliabile usare le procedure consigliate seguenti per lo sviluppo di applicazioni. Per altre informazioni, vedere Ciclo di vita dello sviluppo della sicurezza Microsoft.

Ciclo di vita dello sviluppo della sicurezza

Security Development Life Cycle (SDL) è un processo che allinea una serie di attività incentrate sulla sicurezza e risultati finali a ogni fase dello sviluppo software. Queste attività e risultati finali includono:

• Sviluppo di modelli di minaccia
• Uso degli strumenti di analisi del codice
• Esecuzione di revisioni del codice e test di sicurezza

Per altre informazioni su SDL, vedere Microsoft Security Development Lifecycle.

Modelli di minaccia

L'esecuzione di un'analisi del modello di minaccia consente di individuare potenziali punti di attacco nel codice. Per altre informazioni sull'analisi del modello di minaccia, vedere Howard, Michael e LeBlanc, David [2003], Writing Secure Code, 2d ed., ISBN 0-7356-1722-8, Microsoft Press, Redmond, Washington. Questa risorsa potrebbe non essere disponibile in alcune lingue e paesi.

Service Pack e aggiornamenti della sicurezza

Gli ambienti di compilazione e test devono rispecchiare gli stessi livelli di Service Pack e gli aggiornamenti della sicurezza della base utenti di destinazione. È consigliabile installare i Service Pack e gli aggiornamenti della sicurezza più recenti per qualsiasi piattaforma o applicazione Microsoft che fa parte dell'ambiente di compilazione e test e incoraggiare gli utenti a eseguire le stesse operazioni per l'ambiente dell'applicazione completato. Per altre informazioni sui Service Pack e sugli aggiornamenti della sicurezza, vedere Update Windows e Microsoft Security.

Autorizzazione

È consigliabile creare applicazioni che richiedono il privilegio minimo possibile. L'uso del privilegio minimo possibile riduce il rischio di compromissione del sistema informatico da parte di codice dannoso. Per altre informazioni sull'esecuzione del codice nel livello di privilegio minimo possibile, vedere Esecuzione con privilegi speciali.

Procedure consigliate per la crittografia

Quando si implementa la crittografia nelle applicazioni Windows:

• Usare l'API di crittografia: Next Generation (CNG) per tutti i nuovi sviluppi. CryptoAPI viene mantenuto solo per la compatibilità con le versioni precedenti.
• Progetta in ottica di agilità crittografica e pianifica in ottica post-quantum. Non disseminare nel codice identificatori di algoritmo o dimensioni delle chiavi codificati in modo statico: isolali in modo che gli algoritmi possano essere sostituiti senza dover riscrivere il codice. La piattaforma sta passando agli standard post-quantistici NIST, ML-KEM (FIPS 203) per la creazione delle chiavi e ML-DSA (FIPS 204) per le firme, quindi favorire le progettazioni agile ora, soprattutto per i dati con una lunga durata di riservatezza, per resistere agli attacchi "harvest-now, decrypt-later".
• Preferisce la crittografia autenticata (AEAD). Usare AES-GCM in modo che la crittografia rilevi anche manomissioni. Se è necessario usare una modalità non autenticata, ad esempio CBC, associarla a un controllo di integrità separato (encrypt-then-MAC), la riservatezza da sola non protegge dalla modifica.
• Non riutilizzare mai un nonce (IV) con la stessa chiave in AES-GCM. Il riutilizzo del nonce in GCM è catastrofico: può esporre la chiave di autenticazione e consentire la falsificazione di messaggi. Generate un nonce univoco per ogni operazione di crittografia — ad esempio, un contatore incrementale o un nuovo valore casuale di 96 bit.
• Non usare mai la modalità di crittografia a blocchi della BCE. ECB crittografa i blocchi in modo indipendente, rivelando schemi nei dati in chiaro.
• Non impostare mai chiavi crittografiche hardcode nel codice sorgente. Usare DPAPI per la protezione della chiave locale o il provider di archiviazione chiavi CNG per le chiavi persistenti.
• Cancella le informazioni sensibili dalla memoria quando non ti servono più. Sovrascrivere il materiale della chiave, le password e altri buffer sensibili con SecureZeroMemory. A differenza di memset, non è ottimizzato dal compilatore.
• Usare lunghezze di chiave di 256 bit per AES, 2048+ bit per RSA (3072+ preferito) e 256+ bit per ECDSA.
• Usare SHA-256 o più forte per l'hashing. Non usare MD5 o SHA-1 a scopo di sicurezza.
• Controllare sempre i valori restituiti dalle funzioni di crittografia. Una chiamata di crittografia non riuscita in modo invisibile all'utente può lasciare i dati archiviati in testo non crittografato.
• Generare numeri casuali usando BCryptGenRandom (CNG), non rand() o altri prNG non crittografici. Passa BCRYPT_USE_SYSTEM_PREFERRED_RNG per usare il generatore preferito dal sistema senza gestire un handle dell'algoritmo.

Ulteriori informazioni

Per altre informazioni sulle procedure consigliate, vedere gli argomenti seguenti.

Argomento	Descrizione
Esecuzione con privilegi speciali	Vengono illustrate le implicazioni di sicurezza dei privilegi.
Evitare sovraccarichi del buffer	Fornisce informazioni su come evitare sovraccarichi del buffer.
Control Flow Guard (CFG)	Vengono illustrate le vulnerabilità di danneggiamento della memoria.
Creazione di un DACL	Illustra come creare un elenco di controllo di accesso discrezionale (DACL) usando il linguaggio SDDL (Security Descriptor Definition Language ).
Gestione delle password	Vengono illustrate le implicazioni per la sicurezza dell'uso delle password.
estendibilità per sviluppatori di Dynamic Controllo di accesso	Orientamento di base ad alcuni dei punti di estendibilità per gli sviluppatori per le nuove soluzioni di Controllo Accessi dinamico.