Cosa è possibile ottenere con i criteri DevOps di Microsoft Purview?
Questo articolo descrive come gestire l'accesso alle origini dati nel patrimonio dati usando il portale di governance di Microsoft Purview. È incentrato sui concetti di base dei criteri DevOps. Ovvero, fornisce informazioni di base sui criteri DevOps che è necessario conoscere prima di seguire altri articoli per ottenere i passaggi di configurazione.
Nota
Questa funzionalità è diversa dal controllo di accesso interno nel portale di governance di Microsoft Purview.
L'accesso ai metadati di sistema è fondamentale per il personale IT e DevOps per garantire che i sistemi di database critici siano integri, siano in grado di rispettare le aspettative e siano sicuri. È possibile concedere e revocare tale accesso in modo efficiente e su larga scala tramite i criteri DevOps di Microsoft Purview.
Qualsiasi utente che ha il ruolo Autore criteri a livello di raccolta radice in Microsoft Purview può creare, aggiornare ed eliminare criteri DevOps. Dopo aver salvato i criteri DevOps, vengono pubblicati automaticamente.
Criteri di accesso e criteri DevOps
I criteri di accesso di Microsoft Purview consentono ai clienti di gestire l'accesso ai sistemi dati nell'intero data estate, il tutto da una posizione centrale nel cloud. È possibile considerare questi criteri come concessioni di accesso che possono essere create tramite Microsoft Purview Studio, evitando la necessità di codice. Determinano se un elenco di entità Microsoft Entra, ad esempio utenti e gruppi, deve essere consentito o negato a un tipo specifico di accesso a un'origine dati o a un asset al suo interno. Microsoft Purview comunica questi criteri alle origini dati, dove vengono applicati in modo nativo.
I criteri DevOps sono un tipo speciale di criteri di accesso di Microsoft Purview. Concedono l'accesso ai metadati del sistema di database anziché ai dati utente. Semplificano il provisioning degli accessi per le operazioni IT e il personale di controllo della sicurezza. I criteri DevOps concedono solo l'accesso. Non negano l'accesso.
Elementi di un criterio DevOps
Tre elementi definiscono un criterio DevOps:
Oggetto
Questo è un elenco di Microsoft Entra utenti, gruppi o entità servizio a cui viene concesso l'accesso.
Risorsa dati
Questo è l'ambito in cui vengono applicati i criteri. Il percorso della risorsa dati è la composizione dell'origine dati del gruppo > di risorse della sottoscrizione>.
I criteri DevOps di Microsoft Purview supportano attualmente le origini dati di tipo SQL. È possibile configurarle in singole origini dati e in interi gruppi di risorse e sottoscrizioni. È possibile creare criteri DevOps solo dopo aver registrato la risorsa dati in Microsoft Purview con l'opzione Di imposizione dei criteri di dati attivata.
Ruolo
Un ruolo esegue il mapping a un set di azioni consentite dai criteri sulla risorsa dati. I criteri DevOps supportano i ruoli sql Monitor prestazioni e revisore della sicurezza SQL. Entrambi questi ruoli forniscono l'accesso ai metadati del sistema SQL e in modo più specifico alle viste a gestione dinamica (DMV) e alle funzioni di gestione dinamica (DMV). Ma il set di DMV e DMV concesse da questi ruoli è diverso. Più avanti in questo articolo vengono forniti alcuni esempi comuni.
L'articolo Creare, elencare, aggiornare ed eliminare i criteri di Microsoft Purview DevOps descrive in dettaglio la definizione del ruolo per ogni tipo di origine dati. Ovvero, fornisce un mapping dei ruoli in Microsoft Purview alle azioni consentite in tale tipo di origine dati. Ad esempio, la definizione del ruolo per SQL Monitor prestazioni e SQL Security Auditor include le azioni Connect a livello di server e database sul lato origine dati.
In sostanza, il criterio DevOps assegna le autorizzazioni correlate del ruolo all'oggetto e viene applicato nell'ambito del percorso della risorsa dati.
Imposizione gerarchica dei criteri
Un criterio DevOps in una risorsa dati viene applicato alla risorsa dati stessa e a tutte le risorse figlio in essa contenute. Ad esempio, un criterio DevOps in una sottoscrizione di Azure si applica a tutti i gruppi di risorse, a tutte le origini dati abilitate per i criteri all'interno di ogni gruppo di risorse e a tutti i database all'interno di ogni origine dati.
Scenario di esempio per illustrare il concetto e i vantaggi
Bob e Alice sono coinvolti nel processo DevOps presso la loro azienda. Devono accedere a decine di istanze di SQL Server in locale e Azure SQL server logici per monitorare le prestazioni in modo che i processi DevOps critici non si interrompano. Il responsabile Mateo inserisce tutte queste origini dati SQL nel gruppo di risorse 1. Crea quindi un gruppo Microsoft Entra e include Alice e Bob. Successivamente, usa i criteri DevOps di Microsoft Purview (Criteri 1 nel diagramma seguente) per concedere a questo gruppo di Microsoft Entra l'accesso al gruppo di risorse 1, che ospita i server logici.
.
Ecco i vantaggi:
- Mateo non deve creare account di accesso locali in ogni server.
- I criteri di Microsoft Purview migliorano la sicurezza limitando l'accesso con privilegi locali. Essi sostengono il principio dei privilegi minimi. Nello scenario Mateo concede solo l'accesso minimo necessario a Bob e Alice per eseguire l'attività di monitoraggio dell'integrità e delle prestazioni del sistema.
- Quando vengono aggiunti nuovi server al gruppo di risorse, Mateo non deve aggiornare i criteri in Microsoft Purview affinché vengano applicati ai nuovi server.
- Se Alice o Bob lascia l'organizzazione e il processo viene riempito di nuovo, Mateo aggiorna solo il gruppo Microsoft Entra. Non deve apportare modifiche ai server o ai criteri creati in Microsoft Purview.
- In qualsiasi momento, Mateo o il revisore dell'azienda possono visualizzare tutte le autorizzazioni concesse direttamente in Microsoft Purview Studio.
| Principio | Benefici |
|---|---|
| Semplificare | Le definizioni di ruolo SQL Monitor prestazioni e SQL Security Auditor acquisiscono le autorizzazioni necessarie per l'esecuzione del processo da parte dei tipici utenti IT e DevOps. |
| È meno necessaria l'esperienza di autorizzazione per ogni tipo di origine dati. | |
| Ridurre l'impegno | Un'interfaccia grafica consente di spostarsi rapidamente nella gerarchia degli oggetti dati. |
| Microsoft Purview supporta i criteri per interi gruppi di risorse e sottoscrizioni di Azure. | |
| Sicurezza superiore | L'accesso viene concesso centralmente e può essere facilmente esaminato e revocato. |
| È meno necessario che gli account con privilegi configurino l'accesso direttamente nell'origine dati. | |
| I criteri DevOps supportano il principio dei privilegi minimi tramite gli ambiti delle risorse dati e le definizioni dei ruoli. | |
API dei criteri DevOps
Molti clienti sofisticati preferiscono interagire con Microsoft Purview tramite script anziché tramite l'interfaccia utente. I criteri di Microsoft Purview DevOps supportano ora un'API REST che offre funzionalità complete di creazione, lettura, aggiornamento ed eliminazione (CRUD). Questa funzionalità include l'elenco, i criteri per sql Monitor prestazioni e i criteri per il revisore della sicurezza SQL. Per altre informazioni, vedere la specifica dell'API.
Mapping di DMV e DMV popolari
I metadati dinamici SQL includono un elenco di oltre 700 DMV e DMV. La tabella seguente illustra alcuni dei più diffusi. La tabella esegue il mapping delle DMV e delle DMV alle relative definizioni di ruolo nei criteri DevOps di Microsoft Purview. Fornisce anche collegamenti al contenuto di riferimento.
| Ruolo DevOps | Categoria | DMV o DMF di esempio |
|---|---|---|
| SQL Monitor prestazioni | Eseguire query sui parametri di sistema per comprendere il sistema | sys.configurations |
| sys.dm_os_sys_info | ||
| Identificare i colli di bottiglia delle prestazioni | sys.dm_os_wait_stats | |
| Analizzare le query attualmente in esecuzione | sys.dm_exec_query_stats | |
| Analizzare i problemi di blocco | sys.dm_tran_locks | |
| sys.dm_exec_requests | ||
| sys.dm_os_waiting_tasks | ||
| Analizzare l'utilizzo della memoria | sys.dm_os_memory_clerks | |
| Analizzare l'utilizzo e le prestazioni dei file | sys.master_files | |
| sys.dm_io_virtual_file_stats | ||
| Analizzare l'utilizzo e la frammentazione degli indici | sys.indexes | |
| sys.dm_db_index_usage_stats | ||
| sys.dm_db_index_physical_stats | ||
| Gestire le connessioni utente attive e le attività interne | sys.dm_exec_sessions | |
| Ottenere le statistiche di esecuzione della procedura | sys.dm_exec_procedure_stats | |
| Usare il Query Store | sys.query_store_plan | |
| sys.query_store_query | ||
| sys.query_store_query_text | ||
| Ottenere il log degli errori (non ancora supportato) | sys.sp_readerrorlog | |
| Revisore della sicurezza SQL | Ottenere i dettagli del controllo | sys.dm_server_audit_status |
| Sia SQL Monitor prestazioni che SQL Security Auditor | sys.dm_audit_actions | |
| sys.dm_audit_class_type_map | ||
Per altre informazioni sulle operazioni che il personale di supporto IT può eseguire quando si concede loro l'accesso tramite i ruoli di Microsoft Purview, vedere le risorse seguenti:
- SQL Monitor prestazioni: usare Microsoft Purview per fornire accesso su larga scala ai dati sulle prestazioni in Azure SQL e SQL Server
- Revisore della sicurezza SQL: funzioni e viste a gestione dinamica correlate alla sicurezza
Passaggi successivi
Per iniziare a usare i criteri DevOps, vedere le risorse seguenti:
- Provare i criteri DevOps per Azure SQL Database: Guida introduttiva.
- Vedere altri video, blog e articoli.