Panoramica della protezione dei dati
Servizi di Azure DevOps
Azure DevOps Services è un'applicazione ospitata nel cloud per i progetti di sviluppo, dalla pianificazione alla distribuzione. In base alle funzionalità locali, con più servizi cloud, viene gestito il codice sorgente, gli elementi di lavoro, le compilazioni e i test. Azure DevOps usa l'infrastruttura PaaS (Platform as a Service) e molti servizi di Azure, tra cui Azure SQL, per offrire un servizio affidabile e disponibile a livello globale per i progetti di sviluppo.
Questo articolo illustra i passaggi impiegato da Microsoft per mantenere i progetti al sicuro, disponibili, sicuri e privati. Descrive il ruolo svolto per garantire la sicurezza e la sicurezza dei progetti.
Questo articolo è destinato agli amministratori dell'organizzazione e ai professionisti IT che gestiscono quotidianamente le risorse del progetto. È più utile per gli utenti che hanno già familiarità con Azure DevOps e vogliono saperne di più su come Microsoft protegge gli asset archiviati in Azure DevOps.
Il nostro impegno
Microsoft consente di garantire che i progetti rimangano sicuri e sicuri, senza eccezioni. Quando si archiviano i progetti in Azure DevOps, traggono vantaggio da più livelli di tecnologie di sicurezza e governance, procedure operative e criteri di conformità. Applichiamo la privacy e l'integrità dei dati sia inattivi che in transito.
Le minacce affrontate si trovano in quattro categorie di base: disponibilità dei dati, disponibilità del servizio, sicurezza del servizio e privacy dei dati. Questo articolo illustra le minacce specifiche all'interno di ogni categoria e spiega cosa fa Azure DevOps per risolverle. L'articolo inizia descrivendo come vengono archiviati i dati e come Azure DevOps gestisce l'accesso ai dati.
La protezione dei dati richiede l'impegno attivo di amministratori e utenti che conoscono i passaggi da adottare per proteggere gli asset da divulgazione e manomissione non autorizzate. Essere espliciti quando si concedono le autorizzazioni ai punti di accesso degli utenti, quindi solo le persone giuste accedono ai dati all'interno di Azure DevOps.
È consigliabile considerare tutti i dati potenzialmente a rischio, indipendentemente dalla posizione o dal modo in cui vengono usati. Questa istruzione è vera sia per i dati archiviati nel cloud che per i dati archiviati in un data center privato. È importante classificare i dati, la sensibilità e il rischio e i danni che potrebbero verificarsi se vengono compromessi. Classificare anche i dati in relazione a un criterio generale per la gestione della sicurezza delle informazioni.
Basato su Azure
Azure DevOps viene ospitato interamente nei data center di Azure. Azure DevOps usa molti servizi di Azure di base, tra cui calcolo, archiviazione, rete, AZURE SQL, gestione delle identità e degli accessi e bus di servizio di Azure.
Azure DevOps usa Archiviazione di Azure come repository principale per i metadati del servizio e i dati dei clienti. A seconda del tipo di dati e dei requisiti di archiviazione e recupero, Azure DevOps usa Archiviazione BLOB di Azure e database SQL di Azure archiviazione.
Per comprendere l'approccio di Azure DevOps Services alla protezione dei dati, ecco alcune informazioni generali sui servizi di archiviazione:
Archiviazione BLOB di Azure archivia blocchi di dati non strutturati di grandi dimensioni. Tutti i progetti usano questo servizio. I dati includono informazioni potenzialmente riservate o private, ad esempio il contenuto dei file di origine e degli allegati degli elementi di lavoro. Per la maggior parte dei progetti, la maggior parte dell'archiviazione in uso è questo tipo di archiviazione BLOB non strutturata.
database SQL di Azure archivia gli aspetti strutturati e transazionali dell'organizzazione, inclusi i metadati del progetto, la cronologia del controllo del codice sorgente con controllo delle versioni e i dettagli degli elementi di lavoro. L'archiviazione del database consente di accedere rapidamente agli elementi importanti del progetto. Fornisce indici nell'archivio BLOB per cercare file e allegati.
Gli amministratori possono gestire l'accesso alle risorse concedendo o limitando le autorizzazioni per identità o gruppi utente. Azure DevOps usa l'autenticazione federata delle identità utente tramite microsoft Entra ID e account Microsoft.
Durante l'autenticazione, l'utente viene indirizzato al provider di autenticazione, in cui forniscono le credenziali. Dopo che il provider di autenticazione verifica le credenziali dell'utente, Azure DevOps rilascia un cookie di autenticazione all'utente. Questo cookie consente all'utente di rimanere autenticato in Azure DevOps.
In questo modo, le informazioni sulle credenziali dell'utente non vengono mai condivise direttamente con Azure DevOps. Per ogni risorsa di Azure DevOps a cui l'utente tenta di accedere, la convalida delle autorizzazioni si basa sulle autorizzazioni esplicite dell'utente e sulle autorizzazioni ereditate dall'utente tramite l'appartenenza al gruppo.
Gli amministratori possono usare i controlli di accesso per proteggere l'accesso all'organizzazione, alle raccolte di progetti, ai progetti team e ai dati e alle funzionalità con ambito team. Gli amministratori possono anche usare controlli di accesso per asset specifici, ad esempio cartelle per il controllo della versione e i percorsi di area per gli elementi di lavoro.
Disponibilità dei dati
Azure DevOps usa molte funzionalità di Archiviazione di Azure per garantire la disponibilità dei dati in caso di errore hardware, interruzione del servizio o emergenza a livello di area. Inoltre, il team di Azure DevOps segue le procedure per proteggere i dati da eliminazioni accidentali o dannose.
Ridondanza dei dati
Per proteggere i dati durante gli errori hardware o di servizio, Archiviazione di Azure replica geografica i dati dei clienti tra due aree nella stessa posizione geografica. Ad esempio, Archiviazione di Azure può replicare geograficamente i dati tra Europa settentrionale e occidentale o tra Stati Uniti nord e sud.
Per Archiviazione BLOB di Azure, i dati dei clienti vengono replicati tre volte all'interno di una singola area. I dati dei clienti vengono replicati in modo asincrono in una seconda area nella stessa posizione geografica. Di conseguenza, Azure mantiene sempre l'equivalente di sei copie dei dati.
La presenza di più copie consente di eseguire il failover in un'area separata se si verifica un'interruzione o un'emergenza gravi, con ridondanza locale anche per gli errori hardware all'interno di un'area. Per database SQL di Azure archiviazione, i backup giornalieri vengono mantenuti fuori sede in caso di emergenza a livello di area.
Per quanto riguarda la ridondanza e il failover dei dati:
- È presente un delta intrinseco, misurato in minuti, quando Microsoft replica i dati tra l'area primaria e quella secondaria.
- Il failover nell'area secondaria è una decisione che Microsoft deve prendere centralmente, perché influisce su tutti i clienti su una determinata unità di scala. Tranne in circostanze estreme, Microsoft sceglie di evitare il failover in modo che i dati dei clienti non vengano persi.
- Azure DevOps offre un contratto di servizio con tempo di attività del 99,9%. Azure DevOps restituisce una parte degli addebiti mensili se non viene concesso il contratto di servizio in un mese specifico.
- Poiché è presente una sola area in Brasile, i dati dei clienti in Brasile vengono replicati nell'area Stati Uniti centro-meridionali per scopi di ripristino di emergenza.
Si verificano errori
Per evitare perdite accidentali di dati, Microsoft usa backup temporizzato sia per i BLOB archiviati in Archiviazione BLOB di Azure che nei database all'interno di database SQL di Azure. Ogni account di archiviazione gestisce una copia separata di tutti i BLOB, con le modifiche aggiunte ai dati esistenti. Questi backup non sono modificabili, eliminando la necessità di riscrivere qualsiasi risorsa di archiviazione esistente durante le procedure di backup.
database SQL di Azure include funzionalità di backup standard usate da Azure DevOps. I dati vengono conservati per 28 giorni, con questi backup replicati anche in un'area abbinata per facilitare il ripristino durante un'interruzione a livello di area.
È possibile ripristinare le organizzazioni o i progetti eliminati all'interno della finestra di 28 giorni dopo l'eliminazione. Tuttavia, una volta trascorso questo periodo di tempo, queste entità vengono eliminate definitivamente e non possono essere ripristinate. Anche se questi backup fungono da componente fondamentale per il ripristino di emergenza, è essenziale per i clienti praticare strategie appropriate per la gestione dei dati e le strategie di backup per garantire una protezione completa dei dati.
Importante
- L'eliminazione accidentale in questo caso si riferisce a scenari che si verificano a causa di un evento imprevisto nei servizi. Non include l'eliminazione accidentale degli asset da parte dei clienti, ad esempio repository, elementi di lavoro, allegati o artefatti.
- Non è supportato il ripristino degli asset eliminati accidentalmente dai clienti. Questi backup sono destinati solo per la continuità aziendale e per facilitare il ripristino da scenari di interruzione o emergenza.
- In rari casi, il processo di eliminazione potrebbe richiedere fino a 70 giorni a causa di tentativi back-end e la necessità di eliminare i dati da più origini.
La pratica è fondamentale
La presenza di più backup dei dati è valida, ma senza pratica il ripristino può essere imprevedibile. La gente dice che "i backup non hanno mai esito negativo; i ripristini. Anche se l'istruzione è tecnicamente errata, il sentiment è corretto.
Microsoft esegue regolarmente il ripristino dei set di dati dal backup. Testiamo regolarmente l'archiviazione con ridondanza geografica da Azure. Esistono molte combinazioni di scenari di danneggiamento dei dati e di emergenza. Continuiamo a pianificare ed eseguire regolarmente nuovi test per questi scenari.
Disponibilità servizio
Azure DevOps offre protezioni DDoS (Distributed Denial of Service) e risposta al sito live per garantire l'accesso all'organizzazione e agli asset associati.
Protezioni DDoS
In alcuni casi, un attacco DDoS dannoso può influire sulla disponibilità del servizio. Azure dispone di un sistema di difesa DDoS che consente di evitare attacchi contro il servizio. Impiega tecniche di individuazione e riduzione standard come i cookie SYN, la limitazione della velocità e i limiti di connessione. Il sistema è progettato non solo per respingere gli attacchi dall'esterno,ma anche quelli provenienti dall'interno di Azure.
Per gli attacchi specifici dell'applicazione che possono penetrare nei sistemi di difesa di Azure, Azure DevOps stabilisce quote e limitazioni a livello di applicazione e a livello di organizzazione. Questa procedura consente di evitare l'uso eccessivo delle risorse del servizio chiave durante un attacco o un uso improprio accidentale delle risorse.
Live Site Response
In rari casi, potrebbe essere necessaria una risposta del sito in tempo reale a un problema con la disponibilità del servizio. Abbiamo un team operativo costantemente disponibile per identificare rapidamente il problema e coinvolgere le risorse del team di sviluppo necessarie.
Le risorse del team di sviluppo affrontano quindi il problema. L'obiettivo è anche aggiornare la pagina relativa allo stato del servizio entro pochi minuti dal rilevamento di un problema che interessa il servizio. Dopo che le risorse del team di sviluppo risodono un problema, identificano la causa radice e tengono traccia delle modifiche necessarie per evitare problemi simili in futuro.
I processi di Azure DevOps per la gestione dei siti live si concentrano sull'esperienza e sull'integrità del servizio. Questi processi riducono al minimo il tempo necessario per rilevare, rispondere e attenuare i problemi. Tutte le discipline di ingegneria sono coinvolte e responsabili, quindi i miglioramenti continui si evolvono dall'esperienza diretta. I processi di monitoraggio, diagnostica, resilienza e controllo della qualità migliorano nel tempo.
La gestione del sito live in Azure DevOps include tre tracce distinte: telemetria, gestione degli eventi imprevisti e revisione del sito live. Ecco cosa comportano queste tracce:
Il team operativo monitora anche le metriche di disponibilità per le singole organizzazioni. Queste metriche forniscono informazioni dettagliate su condizioni specifiche che potrebbero influire solo su alcuni dei nostri clienti. Le indagini su questi dati possono spesso comportare miglioramenti mirati per risolvere problemi specifici del cliente. In alcuni casi, Microsoft potrebbe anche contattare l'utente direttamente per comprendere l'esperienza e collaborare con l'utente per migliorare il servizio.
Microsoft pubblica un contratto di servizio e fornisce una garanzia finanziaria per garantire che il contratto venga soddisfatto ogni mese. Per altre informazioni, vedere Contratto di servizio per Azure DevOps.
In alcuni casi, i team partner o le dipendenze hanno eventi imprevisti che influiscono su Azure DevOps. Tutti i team partner seguono approcci simili per identificare, risolvere e apprendere da queste interruzioni del servizio.
Sicurezza del servizio
La sicurezza dei servizi richiede una vigilanza costante, dalla progettazione e dalle tecniche di codifica appropriate ai fattori operativi. Microsoft investe attivamente nella prevenzione dei problemi di sicurezza e nel rilevamento delle violazioni. In caso di violazione, Microsoft usa piani di risposta alla sicurezza per ridurre al minimo la perdita, la perdita o il danneggiamento dei dati. Per altre informazioni, vedere Informazioni sulla sicurezza, l'autenticazione e l'autorizzazione.
Sicurezza per impostazione predefinita
Azure DevOps è progettato per essere sicuro. Azure DevOps usa il ciclo di vita per lo sviluppo della sicurezza Microsoft al centro del processo di sviluppo. Il programma Microsoft Operational Security Assurance guida le procedure delle operazioni cloud in Azure DevOps.
Il team di Azure DevOps ha requisiti di formazione annuali per tutti i tecnici e il personale operativo. Il team sponsorizzerà anche riunioni informali ospitate dai tecnici Microsoft. Dopo che il team ha risolto un problema che si presenta in una riunione, condivide le lezioni apprese con altri team.
Le metodologie seguenti specificano i requisiti di training:
- Modellazione delle minacce durante la progettazione del servizio
- Procedure consigliate per la progettazione e il codice
- Verifica della sicurezza con strumenti e test standard
- Limitazione dell'accesso ai dati operativi e dei clienti
- Implementazione di nuove funzionalità tramite un processo di approvazione rigido
Un servizio cloud è sicuro come la piattaforma host. Azure DevOps usa PaaS per gran parte dell'infrastruttura. PaaS fornisce automaticamente aggiornamenti regolari per le vulnerabilità note della sicurezza.
Le macchine virtuali ospitate in Azure usano l'infrastruttura distribuita come servizio (IaaS), ad esempio per un servizio di compilazione ospitato. Tali immagini ricevono aggiornamenti regolari per includere le patch di sicurezza più recenti disponibili da Windows Update. Lo stesso rigore di aggiornamento si applica per i computer locali, inclusi i computer usati per la distribuzione, il monitoraggio e la creazione di report.
Il team di Azure DevOps esegue test regolari di penetrazione incentrati sulla sicurezza di Azure DevOps. I test di penetrazione tentano di sfruttare i servizi di produzione live e l'infrastruttura di Azure DevOps usando le stesse tecniche e meccanismi usati dagli utenti malintenzionati. L'obiettivo è identificare vulnerabilità, configurazioni, errori o altre lacune di sicurezza in un processo controllato.
Il team esamina i risultati di questi test per identificare altre aree di miglioramento e per aumentare la qualità dei sistemi preventivi e della formazione. È possibile esaminare i risultati dei recenti test di penetrazione di Azure DevOps in Microsoft Service Trust Portal.
Sicurezza delle credenziali
Microsoft si impegna a garantire che i progetti rimangano sicuri e sicuri, senza eccezioni. In Azure DevOps i progetti traggono vantaggio da più livelli di tecnologie di sicurezza e governance, procedure operative e criteri di conformità. Applichiamo la privacy e l'integrità dei dati sia inattivi che in transito. Inoltre, rispettiamo le procedure seguenti in relazione alle credenziali o ai segreti archiviati da Azure DevOps. Per altre informazioni su come scegliere il meccanismo di autenticazione corretto, vedere Linee guida per l'autenticazione.
Importante
Azure DevOps non supporta l'autenticazione delle credenziali alternative. Se si usano ancora credenziali alternative, è consigliabile passare a un metodo di autenticazione più sicuro.
Token di accesso personale
- Viene archiviato un hash del pat.
- I PT non elaborati generano in memoria sul lato server. 32 byte generati in modo casuale tramite RNGCryptoServiceProvider e vengono condivisi con il chiamante come stringa con codifica base 32. Questo valore non è archiviato.
- L'hash PAT genera in memoria sul lato server come HMACSHA256Hash del pat non elaborato usando una chiave di firma simmetrica a 64 byte archiviata nell'insieme di credenziali delle chiavi.
- L'hash viene archiviato nel database.
Chiavi SSH (Secure Shell)
- Viene archiviato un hash dell'ID organizzazione contenitore e della chiave pubblica SSH.
- Le chiavi pubbliche non elaborate vengono fornite direttamente dal chiamante tramite SSL.
- L'hash SSH genera in memoria sul lato server come HMACSHA256Hash dell'ID organizzazione e della chiave pubblica non elaborata usando una chiave di firma simmetrica a 64 byte archiviata nell'insieme di credenziali delle chiavi.
- L'hash viene archiviato nel database.
Credenziali OAuth (JWT)
- Problemi di credenziali OAuth come token Web JSON completamente autodescrittura (JWT) e non vengono archiviati nel servizio.
- Le attestazioni nei token JWT rilasciate e presentate al servizio vengono convalidate usando un certificato archiviato nell'insieme di credenziali delle chiavi.
Segnalazione di errori di sicurezza
Se si ritiene che il test di penetrazione abbia rivelato un potenziale difetto di sicurezza correlato al servizio Azure DevOps, segnalarlo a Microsoft entro 24 ore. Per altre informazioni, vedere la pagina Web Microsoft per segnalare una vulnerabilità di sicurezza del computer.
Importante
Anche se non è necessario informare Microsoft sulle attività di test di penetrazione, è necessario rispettare le regole di engagement dei test di penetrazione Microsoft.
Programma Bounty
Azure DevOps partecipa al programma Microsoft Bug Bounty. Questo programma premia i ricercatori della sicurezza che segnalano problemi a microsoft e incoraggia più persone a proteggere Azure DevOps. Per altre informazioni, vedere Programma Bounty di Microsoft Azure DevOps.
Limitazione dell'accesso
Microsoft mantiene un controllo rigoroso su chi ottiene l'accesso all'ambiente di produzione e ai dati dei clienti. L'accesso viene concesso al livello di privilegio minimo richiesto e solo dopo la verifica delle motivazioni di un utente. Se un membro del team deve accedere per risolvere un problema urgente o distribuire una modifica di configurazione, deve richiedere l'accesso JITE al servizio di produzione. L'accesso viene revocato non appena viene risolta la situazione.
Vengono monitorate e monitorate le richieste di accesso e le approvazioni in un sistema separato. Tutti gli accessi al sistema sono correlati a queste approvazioni. Se viene rilevato l'accesso non approvato, si avvisa il team operativo di analizzare.
Viene usata l'autenticazione a due fattori per tutti gli accessi al sistema remoto. Se il nome utente e la password per uno dei nostri sviluppatori o personale operativo vengono rubati, i dati rimangono protetti. Prima di consentire l'accesso remoto al servizio, è necessario eseguire ulteriori controlli di autenticazione tramite smart card o una telefonata a un numero preapprovato.
Per gestire e gestire il servizio, Microsoft usa segreti come password RDP, certificati SSL e chiavi di crittografia. Questi segreti sono tutti gestiti, archiviati e trasmessi in modo sicuro tramite il portale di Azure. Qualsiasi accesso a questi segreti richiede autorizzazioni specifiche, registrate e registrate in modo sicuro. Tutti i segreti vengono ruotati a cadenza regolare e possiamo ruotarli su richiesta se è presente un evento di sicurezza.
Il team operativo di Azure DevOps usa workstation di amministratore con protezione avanzata per gestire il servizio. Questi computer eseguono un numero minimo di applicazioni e operano in un ambiente segmentato logicamente.
I membri del team operativo devono fornire credenziali specifiche con l'autenticazione a due fattori per accedere alle workstation. Tutti gli accessi vengono monitorati e registrati in modo sicuro. Per isolare il servizio da manomissioni esterne, non sono consentite applicazioni come Outlook e Office, perché sono spesso bersagli di spear phishing e altri tipi di attacchi.
Protezione e risposta alle intrusioni
I dati vengono crittografati tramite HTTPS e SSL per garantire che non vengano intercettati o modificati durante il transito tra l'utente e Azure DevOps. I dati archiviati per conto dell'utente in Azure DevOps vengono crittografati come segue:
I dati archiviati nei database SQL di Azure vengono crittografati tramite Transparent Data Encryption. Questa funzionalità consente di proteggersi da attività dannose eseguendo la crittografia in tempo reale del database, dei backup associati e dei file di log delle transazioni inattivi.
Archiviazione BLOB di Azure le connessioni vengono crittografate per proteggere i dati in transito. Per i dati inattivi archiviati in Archiviazione BLOB di Azure, Azure DevOps usa la crittografia lato servizio.
Il team di Azure DevOps usa l'infrastruttura di Azure per registrare e monitorare gli aspetti chiave del servizio. La registrazione e il monitoraggio garantiscono che le attività all'interno del servizio siano legittime e consentano di rilevare violazioni o tentativi di violazione.
Tutte le attività di distribuzione e amministratore vengono registrate in modo sicuro, così come è l'accesso dell'operatore all'archiviazione di produzione. Le informazioni di log vengono analizzate automaticamente e qualsiasi comportamento potenzialmente dannoso o non autorizzato genera avvisi in tempo reale.
Quando il team di Azure DevOps identifica una possibile vulnerabilità di sicurezza ad alta priorità o intrusione, ha un piano di risposta chiaro. Questo piano descrive le parti responsabili, i passaggi necessari per proteggere i dati dei clienti e le istruzioni su come interagire con esperti di sicurezza in Microsoft. Il team invia anche una notifica ai proprietari dell'organizzazione se i dati sono stati divulgati o danneggiati, in modo che possano adottare misure appropriate per risolvere la situazione.
Per combattere le minacce emergenti, Azure DevOps usa una strategia di presupposizione della violazione . Un team altamente specializzato di esperti di sicurezza all'interno di Microsoft assume il ruolo di avversari sofisticati. Questo team testa il rilevamento e la risposta delle violazioni per misurare accuratamente l'idoneità e l'impatto degli attacchi reali. Questa strategia rafforza il rilevamento, la risposta e la difesa delle minacce del servizio. Consente inoltre al team di convalidare e migliorare l'efficacia dell'intero programma di sicurezza.
Protezione dagli attacchi ransomware
Azure DevOps usa i controlli di Azure per prevenire, rilevare e rispondere a un attacco ransomware. Per altre informazioni su come Azure consente di proteggere i clienti da attacchi ransomware, vedere Protezione ransomware in Azure.
Privacy dei dati
È consigliabile avere la certezza di gestire i dati in modo appropriato e per usi legittimi. Parte di tale garanzia implica una limitazione accurata dell'utilizzo.
Regolamento generale sulla protezione dei dati
Il Regolamento generale sulla protezione dei dati (GDPR) è il cambiamento più importante delle leggi sulla protezione dei dati in Europa dall'introduzione della direttiva sulla protezione dei dati dell'Unione europea (UE) 95/46/EC. Per altre informazioni sul GDPR, vedere la pagina di panoramica nel Centro protezione Microsoft.
Residenza e sovranità dei dati
Azure DevOps è disponibile nelle otto località geografiche seguenti in tutto il mondo: Stati Uniti, Canada, Europa, Regno Unito, India, Australia, Asia Pacifico e Brasile. Per impostazione predefinita, l'organizzazione viene assegnata alla località più vicina. Tuttavia, è possibile scegliere una posizione diversa quando si crea l'organizzazione. Se si cambia idea in un secondo momento, è possibile eseguire la migrazione dell'organizzazione in una posizione diversa con l'assistenza del supporto tecnico Microsoft.
Azure DevOps non sposta o replica i dati dei clienti all'esterno della posizione scelta. I dati vengono invece replicati geograficamente in una seconda area all'interno della stessa posizione. L'unica eccezione è il Brasile, che replica i dati nell'area Stati Uniti centro-meridionali a scopo di ripristino di emergenza.
Nota
Per le build e le versioni eseguite negli agenti macOS forniti da Microsoft, i dati vengono trasferiti a un data center GitHub nel Stati Uniti.
Per altre informazioni, vedere Località dei dati per Azure DevOps.
Accesso alle forze dell'ordine
In alcuni casi, terze parti, ad esempio le forze dell'ordine, potrebbero avvicinarsi a Microsoft per ottenere l'accesso ai dati dei clienti archiviati in Azure DevOps. Si tenta di reindirizzare le richieste al proprietario dell'organizzazione per la risoluzione. Quando un ordine giudiziario impone a Microsoft di divulgare i dati dei clienti a terze parti, Microsoft fa un ragionevole sforzo per notificare in anticipo al proprietario dell'organizzazione, a meno che non sia legalmente vietato farlo.
Alcuni clienti richiedono l'archiviazione dei dati in una determinata posizione geografica per garantire una specifica giurisdizione legale per qualsiasi attività di applicazione della legge. Tutti i dati dei clienti, ad esempio il codice sorgente, gli elementi di lavoro, i risultati dei test e i mirror con ridondanza geografica e i backup fuori sede, vengono mantenuti all'interno di una delle posizioni indicate in precedenza.
Accesso Microsoft
Di tanto in tanto, i dipendenti Microsoft devono ottenere l'accesso ai dati dei clienti archiviati in Azure DevOps. Per precauzione, tutti i dipendenti che hanno (o potrebbero avere) accesso ai dati dei clienti devono superare un controllo in background che include precedenti condanne penali e lavorative. È consentito l'accesso ai sistemi di produzione solo quando si verifica un evento imprevisto del sito attivo o un'altra attività di manutenzione approvata, registrata e monitorata.
Poiché non tutti i dati all'interno del sistema vengono trattati nello stesso modo, i dati vengono classificati in questi tipi:
- Dati del cliente: cosa si carica in Azure DevOps.
- Dati dell'organizzazione: informazioni inviate all'iscrizione o all'amministrazione dell'organizzazione.
- Dati Microsoft: informazioni necessarie per o raccolte tramite il funzionamento del servizio.
In base alla classificazione, controlliamo gli scenari di utilizzo, i requisiti di posizione geografica, le restrizioni di accesso e i requisiti di conservazione.
Uso promozionale Microsoft
Microsoft vuole occasionalmente contattare i clienti per comunicare loro maggiori funzionalità e servizi che potrebbero essere utili. Poiché non tutti i clienti vogliono essere contattati su queste offerte, è possibile acconsentire esplicitamente e rifiutare esplicitamente le comunicazioni di posta elettronica di marketing.
Microsoft non usa mai i dati dei clienti per specificare offerte specifiche per utenti o organizzazioni specifiche. Vengono invece usati i dati dell'organizzazione e le statistiche di utilizzo aggregate a livello di organizzazione per determinare i gruppi che devono ricevere offerte specifiche.
Creazione di fiducia
È possibile essere sicuri di altri sforzi compiuti da Microsoft per conto di Azure DevOps. Questi sforzi includono i criteri di adozione interni di Microsoft, il livello di trasparenza nello stato del nostro servizio e il progresso verso la ricezione della certificazione dei nostri sistemi per la gestione della sicurezza delle informazioni.
Adozione interna
I team Microsoft adottano internamente Azure DevOps. Il team di Azure DevOps si è trasferito in un'organizzazione nel 2014 e lo usa ampiamente. Sono stati stabiliti linee guida per abilitare i piani di adozione per altri team.
I team di grandi dimensioni si spostano più gradualmente rispetto a quelli più piccoli, a causa degli investimenti nei sistemi DevOps esistenti. Per i team che si spostano rapidamente, è stato definito un approccio di classificazione del progetto. Valuta la tolleranza ai rischi, in base alle caratteristiche del progetto, per determinare se il progetto è appropriato per Azure DevOps. Per i team più grandi, l'adozione avviene in genere in fasi, con una maggiore pianificazione.
Altri requisiti per i progetti interni includono l'associazione dell'organizzazione all'ID Microsoft Entra per garantire la corretta complessità del ciclo di vita dell'identità utente e delle password. Anche i progetti più sensibili richiedono l'autenticazione a due fattori.
Certificazioni per la conformità
Potresti essere interessato a comprendere la valutazione di terze parti delle procedure per la sicurezza dei dati. Azure DevOps ha ottenuto le certificazioni seguenti:
- ISO 27001:2013
- ISO 27018:2019
- ISO 26262:2023
- Health Insurance Portability and Accountability Act (HIPAA)
- Contratto di business associate (BAA)
- Clausole modello UE
- Controlli di sistema e organizzazione (SOC) 1 tipo 2
- SOC 2 Type 2
- Germania C5
- Australia IRAP
- ENS-Spagna
Il controllo SOC per Azure DevOps copre i controlli per la sicurezza, la disponibilità, l'integrità dell'elaborazione e la riservatezza dei dati. I report SOC per Azure DevOps sono disponibili tramite Microsoft Service Trust Portal.
Il questionario sull'iniziativa di valutazione del consenso (CAIQ) aiuta le organizzazioni a valutare e valutare le procedure e le funzionalità di sicurezza dei provider di servizi cloud. In linea con il nostro impegno per la sicurezza e la trasparenza, abbiamo recentemente completato la valutazione CAIQ per Azure DevOps. Invitiamo l'utente a esaminare il report completo in Microsoft Service Trust Portal.
Passaggi che è possibile eseguire
La protezione dei dati appropriata richiede un impegno attivo da parte dell'utente, degli amministratori e degli utenti. I dati del progetto archiviati in Azure DevOps sono sicuri come i punti di accesso degli utenti. Corrisponde al livello di severità e granularità delle autorizzazioni per tali organizzazioni con il livello di riservatezza del progetto.
Classificare i dati
Il primo passaggio consiste nel classificare i dati. Classificare i dati in base alla sensibilità e all'orizzonte di rischio, insieme ai danni che potrebbero verificarsi se compromessi. Molte aziende hanno metodi di classificazione esistenti che possono riutilizzare quando i progetti passano ad Azure DevOps. Per altre informazioni, è possibile scaricare la classificazione dei dati per la conformità al cloud da Microsoft Trustworthy Computing.
Adottare l'ID Microsoft Entra
Usare Microsoft Entra ID per gestire l'accesso dell'organizzazione ad Azure DevOps. Microsoft Entra ID offre un altro modo per migliorare la sicurezza delle credenziali degli utenti.
Microsoft Entra ID consente al reparto IT di gestire i criteri di accesso utente, la complessità delle password, gli aggiornamenti delle password e la scadenza quando gli utenti lasciano l'organizzazione. Tramite la federazione di Active Directory, è possibile collegare direttamente Microsoft Entra ID alla directory centrale dell'organizzazione, in modo da avere una sola posizione per gestire questi dettagli per l'azienda.
La tabella seguente confronta le caratteristiche dell'account Microsoft e di Microsoft Entra rispetto all'accesso ad Azure DevOps:
| Proprietà | Account Microsoft | Microsoft Entra ID |
|---|---|---|
| Creatore di identità | User | Organizzazione |
| Nome utente singolo e password per tutti gli asset di lavoro | No | Sì |
| Durata delle password e controllo della complessità | User | Organizzazione |
| Limiti di appartenenza ad Azure DevOps | Qualsiasi account Microsoft | Directory dell'organizzazione |
| Identità tracciabile | No | Sì |
| Organizzazione e proprietà IP | Ambiguo | Organizzazione |
| Registrazione dell'autenticazione a due fattori | User | Organizzazione |
| Accesso condizionale basato su dispositivo | No | Organizzazione |
Altre informazioni sulla configurazione di questo supporto per l'organizzazione.
Richiedere l'autenticazione a due fattori
È possibile limitare l'accesso all'organizzazione richiedendo più di un fattore per l'accesso. È possibile richiedere più fattori usando Microsoft Entra ID. Ad esempio, è possibile richiedere l'autenticazione tramite telefono, oltre a un nome utente e una password, per tutte le richieste di autenticazione.
Usare BitLocker
Per i progetti sensibili, è possibile usare BitLocker nel computer portatile o desktop Windows. BitLocker crittografa l'intera unità in cui risiedono Windows e i dati. Quando BitLocker è abilitato, crittografa automaticamente qualsiasi file salvato in tale unità. Se il computer rientra nelle mani sbagliate, BitLocker impedisce l'accesso non autorizzato di copie locali di dati dai progetti.
Limitare l'uso delle credenziali di autenticazione alternative
Il meccanismo di autenticazione predefinito per gli strumenti correlati a Git è l'autenticazione alternativa (talvolta denominata autenticazione di base). Questo meccanismo consente a un utente di configurare un nome utente e una password alternativi da usare durante le operazioni della riga di comando Git. L'utente può usare questa combinazione di nome utente/password per accedere a qualsiasi altro dato per cui l'utente dispone delle autorizzazioni. Per natura, le credenziali di autenticazione alternative sono meno sicure rispetto all'autenticazione federata predefinita.
È comunque possibile effettuare scelte per una maggiore sicurezza. Tutte le comunicazioni vengono inviate tramite HTTPS e sono previsti requisiti di complessità delle password. L'organizzazione deve continuare a valutare se sono necessari più criteri per soddisfare i requisiti di sicurezza dei progetti.
È possibile disabilitare le credenziali di autenticazione alternative se si decide che non soddisfa i requisiti di sicurezza dell'organizzazione. Per altre informazioni, vedere Modificare la connessione all'applicazione e i criteri di sicurezza per l'organizzazione.
Proteggere l'accesso all'organizzazione
Gli amministratori possono usare Microsoft Entra ID per controllare l'accesso alle risorse e alle applicazioni di Azure, ad esempio Azure DevOps. Con il controllo dell'accesso condizionale sul posto, Microsoft Entra ID verifica le condizioni specifiche impostate per consentire a un utente di accedere a un'applicazione. Dopo che l'utente soddisfa i requisiti di accesso, l'utente viene autenticato e può accedere all'applicazione.
Azure DevOps supporta l'applicazione di determinati tipi di criteri di accesso condizionale (ad esempio, isolamento IP) per meccanismi di autenticazione personalizzati di Azure DevOps. Questi meccanismi includono token di accesso personale, autenticazione alternativa, chiavi OAuth e Secure Shell (SSH). Se gli utenti accedono ad Azure DevOps tramite un client di terze parti, vengono rispettati solo i criteri basati su IPv4.