Sicurezza a livello di riga nel data warehousing di Fabric

  • Articolo

Si applica a:✅ endpoint di Analisi SQL e Warehouse in Microsoft Fabric

La sicurezza a livello di riga (RLS) consente di usare l'appartenenza a gruppi o il contesto di esecuzione per controllare l'accesso alle righe in una tabella di database. Ad esempio, è possibile assicurarsi che i dipendenti possano accedere solo alle righe di dati pertinenti per il loro reparto. Un altro esempio può essere la limitazione dell'accesso ai dati dei clienti solo ai dati rilevanti per l'azienda in un’architettura multitenant. La funzionalità è simile alla sicurezza a livello di riga in SQL Server.

Sicurezza a livello di riga a livello di dati

La sicurezza a livello di riga semplifica la progettazione e la codifica della sicurezza nell'applicazione. La sicurezza a livello di riga facilita l'implementazione delle restrizioni di accesso alle righe di dati.

La logica di restrizione dell'accesso si trova sul livello del database e non in un singolo livello applicazione. Il database applica le restrizioni di accesso a ogni tentativo di accesso ai dati da qualsiasi livello, da qualsiasi applicazione o piattaforma di reporting incluso Power BI. Il sistema di sicurezza è così più affidabile e solido, grazie alla riduzione della superficie di attacco del sistema di sicurezza. La sicurezza a livello di riga si applica solo alle query in un endpoint di Warehouse o Analisi SQL in Fabric. Le query di Power BI in un magazzino in modalità Direct Lake eseguiranno il fallback alla modalità Direct Query per rispettare la sicurezza a livello di riga.

Limitare l'accesso a determinate righe a determinati utenti

Implementare RLS usando l'istruzione Transact-SQL CREATE SECURITY POLICY e i predicati creati come funzioni con valori di tabella inline.

La sicurezza a livello di riga viene applicata al warehouse condiviso o al lakehouse, perché l'origine dati sottostante non è stata modificata.

Sicurezza a livello di riga basata su predicato

La sicurezza a livello di riga in Fabric Synapse Data Warehouse supporta la sicurezza basata su predicato. I predicati del filtro filtrano automaticamente le righe disponibili per le operazioni di lettura.

L'accesso ai dati a livello di riga in una tabella è limitato da un predicato di sicurezza definito come una funzione inline con valori di tabella. La funzione viene quindi richiamata e applicata dai criteri di sicurezza. Nel caso dei predicati del filtro, l'applicazione non rileva le righe filtrate dal set di risultati. Se vengono filtrate tutte le righe, viene restituito un set Null.

I predicati di filtro vengono applicati durante la lettura dei dati dalla tabella di base Influiscono su tutte le operazioni Get:: SELECT, DELETE e UPDATE. Ogni tabella deve avere una propria sicurezza a livello di riga definita separatamente. Gli utenti che eseguono query sulle tabelle senza criteri di sicurezza a livello di riga visualizzeranno i dati non filtrati.

Gli utenti non possono selezionare o eliminare le righe filtrate. L'utente non può aggiornare le righe filtrate. Tuttavia, è possibile aggiornare le righe in modo che vengano filtrate in un secondo momento.

Il predicato del filtro e di blocco e i criteri di sicurezza si comportano nel modo seguente:

  • È possibile definire una funzione di predicato che si unisca a un'altra tabella e/o chiami una funzione. Se i criteri di sicurezza vengono creati con SCHEMABINDING = ON (valore predefinito), il join o la funzione è accessibile dalla query e funziona come previsto senza controlli aggiuntivi delle autorizzazioni.

  • È possibile inviare una query in una tabella con un predicato di sicurezza definito ma disabilitato. Le righe filtrate o bloccate non sono interessate.

  • Se un utente dbo, un membro del ruolo db_owner o il proprietario della tabella esegue query in una tabella con criteri di sicurezza definiti e abilitati, le righe vengono filtrate o bloccate in base a quanto definito nei criteri di sicurezza.

  • I tentativi di modificare lo schema di una tabella tramite un criterio di sicurezza associato allo schema generano un errore. Le colonne a cui non fa riferimento il predicato possono tuttavia essere modificate.

  • I tentativi di aggiunta di un predicato in una tabella in cui è già presente un predicato definito per l'operazione specificata generano un errore. Ciò si verifica indipendentemente dal fatto che il predicato sia abilitato o meno.

  • I tentativi di modifica di una funzione usata come predicato in una tabella inclusa in criteri di sicurezza associati a schema generano un errore.

  • La definizione di più criteri di sicurezza attivi contenenti predicati non sovrapposti riesce correttamente.

I predicati del filtro si comportano nel modo seguente:

  • Definire i criteri di sicurezza per filtrare le righe di una tabella. L'applicazione non rileva le righe filtrate per operazioni SELECT, UPDATE e DELETE. Sono incluse le situazioni in cui vengono filtrate tutte le righe. L'applicazione può eseguire INSERT per le righe, anche se verranno filtrate durante qualunque altra operazione.

Autorizzazioni

La creazione, la modifica o l'eliminazione di criteri di sicurezza richiede l'autorizzazione ALTER ANY SECURITY POLICY. La creazione o l'eliminazione di criteri di sicurezza richiede l'autorizzazione ALTER nello schema.

Inoltre, per ogni predicato che viene aggiunto sono richieste le autorizzazioni seguenti:

  • Le autorizzazzioni SELECT REFERENCES per la funzione usata come predicato.

  • L’autorizzazione REFERENCES per la tabella di destinazione associata ai criteri.

  • L’autorizzazione REFERENCES per ogni colonna della tabella di destinazione usata come argomento.

I criteri di sicurezza sono applicati a tutti gli utenti, inclusi gli utenti dbo nel database. Gli utenti dbo possono modificare o eliminare i criteri di sicurezza, tuttavia tali modifiche ai criteri di sicurezza possono essere controllate. Se i membri di ruoli come Amministratore, Membro o Collaboratore devono visualizzare tutte le righe per risolvere i problemi o convalidare i dati, i criteri di sicurezza devono essere scritti per consentire tale operazione.

Se i criteri di sicurezza vengono creati con SCHEMABINDING = OFF, per eseguire query nella tabella di destinazione gli utenti devono disporre dell'autorizzazione SELECT o EXECUTE per la funzione di predicato e per qualunque tabella, vista o funzione aggiuntiva usata nella funzione di predicato. Se i criteri di sicurezza vengono creati con SCHEMABINDING = ON (impostazione predefinita), questi controlli delle autorizzazioni vengono ignorati quando gli utenti eseguono query sulla tabella di destinazione.

Considerazioni sulla sicurezza: attacchi side-channel

Considerare e prepararsi per i seguenti due scenari.

Gestore dei criteri di sicurezza malintenzionato

è importante osservare che un gestore dei criteri di sicurezza malintenzionato, con autorizzazioni sufficienti per creare criteri di sicurezza per una colonna sensibile e per creare o modificare le funzioni inline con valori di tabella, può agire in collusione con un altro utente con autorizzazioni Select su una tabella al fine di estrarre dolosamente i dati creando funzioni inline con valori di tabella progettate per usare attacchi al canale laterale per estrapolare i dati. Questi attacchi richiedono la collusione con altre persone (o autorizzazioni eccessive concesse a un utente malintenzionato) e richiedono probabilmente diversi tentativi di modifica dei criteri (che richiede autorizzazioni per rimuovere il predicato per interrompere l'associazione allo schema), la modifica delle funzioni con valori di tabella inline e diverse esecuzioni delle istruzioni Select nella tabella di destinazione. È consigliabile limitare le autorizzazioni in base alle esigenze e monitorare le attività sospette. Si dovrebbero monitorare le attività come modifiche costanti dei criteri e di funzioni inline con valori di tabella correlate alla sicurezza a livello di riga.

Query appositamente create

L’uso di query create con attenzione che usano errori per esfiltrare i dati può causare perdite di informazioni. Ad esempio, SELECT 1/(SALARY-100000) FROM PAYROLL WHERE NAME='John Doe'; consentirebbe a un utente malintenzionato di sapere che lo stipendio di Mario Rossi ammonta esattamente a 100.000 dollari. Anche se è disponibile un predicato di sicurezza per impedire le query dirette di un utente malintenzionato relative allo stipendio degli altri dipendenti, l'utente può determinare quando la query restituisce un'eccezione di divisione per zero.

Esempi

È possibile dimostrare la sicurezza a livello di riga Warehouse e l'endpoint di analisi SQL in Microsoft Fabric.

Nell'esempio seguente vengono create tabelle di esempio che funzioneranno con Warehouse in Fabric, ma nell'endpoint di analisi SQL vengono usate tabelle esistenti. Nell'endpoint di analisi SQL non è possibile CREATE TABLE, ma è possibile CREATE SCHEMA, CREATE FUNCTION e CREATE SECURITY POLICY.

In questo esempio, creare prima uno schema sales, una tabella sales.Orders.

CREATE SCHEMA sales;
GO

-- Create a table to store sales data
CREATE TABLE sales.Orders (
    SaleID INT,
    SalesRep VARCHAR(100),
    ProductName VARCHAR(50),
    SaleAmount DECIMAL(10, 2),
    SaleDate DATE
);

-- Insert sample data
INSERT INTO sales.Orders (SaleID, SalesRep, ProductName, SaleAmount, SaleDate)
VALUES
    (1, 'Sales1@contoso.com', 'Smartphone', 500.00, '2023-08-01'),
    (2, 'Sales2@contoso.com', 'Laptop', 1000.00, '2023-08-02'),
    (3, 'Sales1@contoso.com', 'Headphones', 120.00, '2023-08-03'),
    (4, 'Sales2@contoso.com', 'Tablet', 800.00, '2023-08-04'),
    (5, 'Sales1@contoso.com', 'Smartwatch', 300.00, '2023-08-05'),
    (6, 'Sales2@contoso.com', 'Gaming Console', 400.00, '2023-08-06'),
    (7, 'Sales1@contoso.com', 'TV', 700.00, '2023-08-07'),
    (8, 'Sales2@contoso.com', 'Wireless Earbuds', 150.00, '2023-08-08'),
    (9, 'Sales1@contoso.com', 'Fitness Tracker', 80.00, '2023-08-09'),
    (10, 'Sales2@contoso.com', 'Camera', 600.00, '2023-08-10');

Creare uno schema Security, una funzione Security.tvf_securitypredicate e criteri di sicurezza SalesFilter.

-- Creating schema for Security
CREATE SCHEMA Security;
GO
 
-- Creating a function for the SalesRep evaluation
CREATE FUNCTION Security.tvf_securitypredicate(@SalesRep AS nvarchar(50))
    RETURNS TABLE
WITH SCHEMABINDING
AS
    RETURN SELECT 1 AS tvf_securitypredicate_result
WHERE @SalesRep = USER_NAME() OR USER_NAME() = 'manager@contoso.com';
GO
 
-- Using the function to create a Security Policy
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.tvf_securitypredicate(SalesRep)
ON sales.Orders
WITH (STATE = ON);
GO

Per modificare una funzione di sicurezza a livello di riga, è prima necessario eliminare i criteri di sicurezza. Nello script seguente i criteri SalesFilter vengono rilasciati prima di emettere un'istruzione ALTER FUNCTION su Security.tvf_securitypredicate. Ricreare quindi il criterio SalesFilter.

-- Drop policy so we can change the predicate function.
DROP SECURITY POLICY SalesFilter;
GO

-- Alter the function for the SalesRep evaluation
ALTER FUNCTION Security.tvf_securitypredicate(@SalesRep AS nvarchar(50))
    RETURNS TABLE
WITH SCHEMABINDING
AS
    RETURN SELECT 1 AS tvf_securitypredicate_result
WHERE @SalesRep = USER_NAME() OR USER_NAME() = 'president@contoso.com';
GO
 
-- Re-create a Security Policy
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.tvf_securitypredicate(SalesRep)
ON sales.Orders
WITH (STATE = ON);
GO

Passaggio successivo

Implementare la sicurezza a livello di riga in Fabric Data Warehousing

Contenuto correlato