Test di penetrazione

Il test di penetrazione delle applicazioni è una parte importante dell'esecuzione in Azure. Non hai bisogno della previa approvazione di Microsoft per farlo, ma devi seguire le regole pubblicate. Questo articolo riepiloga tali regole e punta alle fonti autorevoli.

A partire dal 15 giugno 2017, Microsoft non richiede più la pre-approvazione per eseguire un test di penetrazione sulle risorse di Azure. Questo processo interessa esclusivamente Microsoft Azure e non è applicabile ad alcun altro servizio Microsoft Cloud.

Importante

La notifica non è più necessaria, ma i clienti e le terze parti autorizzate devono essere conformi alle regole di Microsoft Cloud Unified Penetration Testing Rules of Engagement. Le regole di coinvolgimento (ROE) sono l'origine autorevole; questo articolo è un riepilogo.

Chi può testare

È possibile eseguire test di penetrazione su Azure risorse di cui si è proprietari. Anche terze parti (ad esempio provider di servizi di sicurezza gestiti, società di consulenza e red teams) possono testare, purché dispongano di autorizzazioni scritte esplicite dal proprietario della risorsa. Documentare l'autorizzazione nel contratto di servizio prima dell'inizio di qualsiasi test. Microsoft non concede l'autorizzazione per conto del cliente.

Se si usa Azure come origine delle attività di test (ad esempio eseguendo strumenti di penetration test o di red teaming da macchine virtuali o Funzioni di Azure contro sistemi ospitati altrove), il ROE si applica comunque e l'uso di Azure rimane soggetto ai termini della sottoscrizione. L'roE vieta in modo specifico l'uso di servizi Microsoft per eseguire attacchi di phishing o altri attacchi di social engineering contro altri utenti.

Test consentiti

È possibile eseguire test di penetrazione su applicazioni e servizi ospitati Azure senza l'approvazione precedente. Ecco alcuni esempi:

  • Endpoint ospitati in macchine virtuali di Azure
  • Applicazioni del servizio app di Azure (app Web, app per le API, app per dispositivi mobili)
  • Funzioni di Azure ed endpoint API
  • Siti Web di Azure
  • Tutti gli altri servizi di Azure di cui si è proprietari o hanno l'autorizzazione esplicita per testare le risorse distribuite

I test standard che è possibile eseguire includono:

  • Test sugli endpoint per individuare le principali 10 vulnerabilità del progetto di sicurezza delle applicazioni web aperte (OWASP)
  • Test dinamico della sicurezza delle applicazioni (DAST) delle applicazioni Web e delle API
  • Test con dati casuali degli endpoint
  • Analisi delle porte degli endpoint

Questo elenco è illustrativo, non esaustivo. Le regole di engagement sono l'origine autorevole per ciò che è consentito.

Il ROE incoraggia inoltre esplicitamente attività quali la creazione di account di test o tenant di prova per scenari di test tra account diversi o tenant diversi, la generazione di traffico per testare la capacità di gestire picchi di carico all'interno delle proprie applicazioni, il test dei sistemi di monitoraggio e rilevamento della sicurezza del tenant, la valutazione dei criteri di Accesso condizionale o dei criteri di gestione delle applicazioni mobili (MAM) di Intune, il tentativo di evadere dai contenitori di servizi condivisi come Azure Websites o Funzioni di Azure (con divulgazione responsabile e cessazione immediata in caso di successo) e il tentativo di oltrepassare i confini dei sistemi di IA.

Attività del team rosso

Le attività di red teaming contro le proprie risorse Azure (o contro quelle di un cliente, con esplicita autorizzazione scritta) sono disciplinate dalle stesse ROE. Nell'ambito autorizzato, il ROE non specifica quali tecniche dell'avversario siano consentite, quindi il testo di riferimento è l'elenco delle attività vietate. Prestare particolare attenzione a questi vincoli, che influiscono direttamente sulle procedure operative del red team:

  • Non è possibile usare, accedere o recuperare credenziali o altri segreti non personalizzati, incluse le credenziali perse pubblicamente. All'interno del proprio ambiente, l'attacco degli account di cui si è proprietari è corretto; non è possibile riutilizzare le credenziali di terze parti.
  • Se durante un test si individua una vulnerabilità nei servizi online di Microsoft, è necessario interrompere il test e segnalarla tramite Microsoft Security Response Center (MSRC). Sono vietate le azioni post-exploit contro gli asset Microsoft, inclusi l'enumerazione di reti interne, l'estrazione di segreti, l'esecuzione di codice aggiuntivo, il movimento laterale o l'estensione dell'accesso oltre la prova di concetto iniziale.
  • I test DDoS sono vietati in tutte le circostanze. Usare invece i partner di simulazione DDoS elencati di seguito.
  • I test automatizzati o fuzzing a elevato utilizzo di rete che generano traffico eccessivo non sono consentiti.

Per il red teaming specifico per l'IA per i carichi di lavoro di Azure AI (incluse le distribuzioni di Azure OpenAI e Microsoft Foundry), vedi Pianificazione del red teaming per modelli linguistici di grandi dimensioni (LLM) e relative applicazioni e la serie di formazione del team di red teaming per l'IA di Microsoft.

Test non consentiti

Le attività seguenti non sono consentite indipendentemente dall'autorizzazione. Questo elenco è illustrativo; roE è l'origine autorevole.

  • Test di Denial of Service (DoS) di qualsiasi tipo, inclusi i test che identificano, dimostrano o simulano un DoS. Gli attacchi DDoS sono rigorosamente vietati in tutte le circostanze.
  • Accedere a tenant di Azure, sistemi, log, dati o account di archiviazione che non si possiedono, oppure analizzarli o testarli senza disporre di un'autorizzazione esplicita.
  • Uso, accesso o recupero di credenziali o altri segreti non personalizzati.
  • Test automatizzati o fuzzing a elevato utilizzo di rete che generano traffico eccessivo.
  • Attacchi di phishing o di ingegneria sociale rivolti ai dipendenti Microsoft, oppure uso dei servizi Microsoft (incluso Azure) per effettuare attacchi di phishing o di ingegneria sociale contro altri.
  • Azioni successive alla compromissione o allo sfruttamento contro i servizi online Microsoft, oltre il proof of concept iniziale, ad esempio l'enumerazione delle reti interne, l'estrazione di segreti, l'esecuzione di codice aggiuntivo, il movimento laterale o il pivoting verso altri sistemi.

Test di simulazione DDoS

Se è necessario testare la resilienza DDoS, è possibile usare partner di simulazione approvati da Microsoft. Questi partner forniscono servizi di simulazione DDoS controllati che non violano le regole di test di penetrazione:

  • BreakingPoint Cloud: generatore di traffico self-service in cui i clienti possono generare traffico sugli endpoint pubblici abilitati per protezione DDoS per le simulazioni.
  • MazeBolt: la piattaforma RADAR™ identifica continuamente e consente l'eliminazione di vulnerabilità DDoS, in modo proattivo e senza interruzioni per le operazioni aziendali.
  • Red Button: collaborare con un team dedicato di esperti dove si può simulare scenari di attacco DDoS reali in un ambiente controllato.
  • RedWolf: provider di test DDoS self-service o guidato con controllo in tempo reale.

Per altre informazioni su questi partner di simulazione, vedere Test con partner di simulazione.

Se l'attività di test viene segnalata

Azure esegue il rilevamento automatizzato degli abusi sul traffico in uscita e in ingresso. I test legittimi vengono occasionalmente segnalati e le ROE indicano che Microsoft può, a sua discrezione, interrompere l'attività in corso anche se si tratta di un test valido. Se ricevete una notifica di abuso per un'attività conforme alle ROE, rispondete alla notifica con l'autorizzazione del cliente e una descrizione dell'attività che rientra nell'ambito consentito. Mantenere i documenti di autorizzazione facilmente accessibili riduce notevolmente questo processo.

Passaggi successivi

  • Last updated on