Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo articolo descrive in che modo gli sviluppatori di motori di terze parti possono integrarsi con la sicurezza di OneLake per eseguire query sui dati da OneLake applicando al contempo la sicurezza a livello di riga e la sicurezza a livello di colonna (CLS). L'integrazione usa il modello di motore autorizzato, in cui il motore legge i dati direttamente da OneLake e applica i criteri di sicurezza nel proprio livello di calcolo.
Annotazioni
Questa funzionalità fa parte di una versione di anteprima e viene fornita solo a scopo di valutazione e sviluppo. Può cambiare in base al feedback e non è consigliato per l'uso in produzione.
Informazioni generali
La sicurezza di OneLake definisce criteri di controllo di accesso con granularità fine, tra cui sicurezza a livello di tabella, a livello di riga e a livello di colonna, una volta in OneLake. I motori di Microsoft Fabric come Spark e l'endpoint di analisi SQL applicano questi criteri in fase di query. Tuttavia, OneLake garantisce l'applicazione dei criteri di controllo di accesso con granularità fine indipendentemente dalla modalità di accesso ai dati. Di conseguenza, le richieste esterne non autorizzate per leggere i file da OneLake vengono bloccate per garantire che i dati non vengano persi.
Il modello del motore autorizzato risolve questo problema. Si registra un'identità dedicata (entità servizio o identità gestita) con accesso in lettura completo ai dati e può anche leggere i metadati di sicurezza. Il motore usa questa identità per:
- Leggere i file di dati non elaborati da OneLake.
- Recuperare i criteri di sicurezza effettivi per un determinato utente chiamando get authorized access for a principal API (Ottieni l'accesso autorizzato per un'API principale ).
- Applicare i filtri di riga e colonna restituiti nel rispettivo livello di esecuzione della query.
- Restituisce solo i dati consentiti all'utente finale.
Questo approccio offre al motore il controllo completo sulla pianificazione e la memorizzazione nella cache delle query, mantenendo il rispetto delle norme di sicurezza coerente con ciò che i motori di Fabric forniscono e mettendo il controllo dell'autorizzazione nelle mani dell'utente.
Prerequisiti
Prima di iniziare l'integrazione, assicurarsi di disporre degli elementi seguenti:
- Un'entità servizio Microsoft Entra o un'identità gestita usata dal motore per accedere a OneLake. Sono supportate solo le identità di Microsoft Entra.
- Ruolo di membro (o superiore) dell'area di lavoro per l'identità del motore nell'area di lavoro di destinazione. Ciò concede all'identità i privilegi necessari per leggere i file di dati e i metadati di sicurezza da OneLake.
- Elemento fabric (lakehouse, database con mirroring o catalogo con mirroring) con la sicurezza OneLake abilitata.
- Ruoli di sicurezza di OneLake configurati sull'elemento con qualsiasi criterio di sicurezza a livello di colonna (CLS) o a livello di riga (RLS) che si desidera applicare.
- L'identità del motore deve avere accesso in lettura illimitato alle tabelle che legge. Se le politiche RLS o CLS si applicano all'identità del motore stessa, le chiamate API restituiscono errori.
Architettura
Il diagramma seguente illustra il flusso di autorizzazione generale per l'integrazione di un motore autorizzato.
┌──────────────┐ ┌──────────────────┐ ┌───────────┐
│ End user │──1──▶│ 3rd-party engine │──2──▶│ OneLake │
│ (query) │ │(service principal)│◀──3──│ (data + │
│ │◀──6──│ │──4──▶│ security)│
└──────────────┘ └──────────────────┘ └───────────┘
- L'utente finale invia una query al motore di terze parti.
- L'identità del motore esegue l'autenticazione in OneLake e legge i file di dati non elaborati (Delta parquet) usando le API OneLake.
- OneLake restituisce i dati richiesti.
- Il motore chiama l'API
principalAccess, passando l'ID oggetto Microsoft Entra dell'utente finale, per ottenere l'accesso effettivo dell'utente. - Il motore applica i filtri di accesso restituiti (accesso alle tabelle, predicati di sicurezza a livello di riga, elenchi di colonne CLS) ai dati nel proprio strato di calcolo.
- Il motore restituisce solo i risultati filtrati e consentiti all'utente finale.
Passaggio 1: Configurare l'identità del motore
Il motore necessita di un'identità di Microsoft Entra che OneLake riconosce e considera attendibile. Questa identità legge i file di dati e i metadati di sicurezza per conto del motore.
Creare o identificare un principale del servizio o un'identità gestita in Microsoft Entra ID per il tuo motore. Per altre informazioni, vedere Oggetti applicazione e oggetti principali di servizio in Microsoft Entra ID.
Aggiungere l'identità al ruolo Membro dell'area di lavoro. Nel portale Fabric, passare alle impostazioni dell'area di lavoro e aggiungere il principale del servizio al ruolo Membro. In questo modo viene concessa l'identità:
- Autorizzazione di accesso in lettura a tutti i file di dati in OneLake per gli elementi nell'area di lavoro.
- Accesso alla consultazione dei metadati dei ruoli di sicurezza di OneLake tramite le API del motore autorizzato.
Per altre informazioni sui ruoli dell'area di lavoro, vedere Ruoli nelle aree di lavoro.
Verificare che l'identità abbia accesso senza restrizioni. L'identità del motore deve avere privilegi di lettura completi su ogni tabella che interroga. Se un ruolo di sicurezza OneLake applica restrizioni RLS o CLS all'identità del motore, le letture dei dati e le chiamate API falliscono. La procedura consigliata consiste nel non aggiungere l'identità del motore a tutti i ruoli di sicurezza di OneLake che contengono vincoli CLS o RLS.
Importante
È possibile revocare l'accesso del motore in qualsiasi momento rimuovendolo dal ruolo di workspace. La revoca dell'accesso diventa effettiva entro circa 2 minuti.
Passaggio 2: Leggere i dati da OneLake
Con l'identità del motore configurata, il motore può leggere i file di dati direttamente da OneLake usando le API compatibili con Azure Data Lake Storage (ADLS) Gen2 standard.
I dati di OneLake sono accessibili all'indirizzo:
https://onelake.dfs.fabric.microsoft.com/{workspaceId}/{itemId}/Tables/{schema}/{tableName}/
Il motore esegue l'autenticazione usando un token di connessione ottenuto tramite il flusso delle credenziali client di Microsoft Entra OAuth 2.0. Usare l'ambito https://storage.azure.com/.default della risorsa OneLake quando si richiede il token.
Esempio: Autenticare e leggere i dati (Python)
from azure.identity import ClientSecretCredential
from azure.storage.filedatalake import DataLakeServiceClient
tenant_id = "<your-tenant-id>"
client_id = "<your-service-principal-client-id>"
client_secret = "<your-service-principal-secret>"
credential = ClientSecretCredential(tenant_id, client_id, client_secret)
service_client = DataLakeServiceClient(
account_url="https://onelake.dfs.fabric.microsoft.com",
credential=credential
)
# Access a specific item in a workspace
file_system_client = service_client.get_file_system_client("<workspace-id>")
directory_client = file_system_client.get_directory_client("<item-id>/Tables/dbo/Customers")
# List and read Delta parquet files
for path in directory_client.get_paths():
if path.name.endswith(".parquet"):
file_client = file_system_client.get_file_client(path.name)
downloaded = file_client.download_file()
data = downloaded.readall()
# Process the parquet data with your engine
Per altre informazioni sulle API OneLake, vedere Accesso a OneLake con le API.
Passaggio 3: Recuperare l'accesso effettivo dell'utente
Dopo aver letto i dati non elaborati, il motore deve determinare cosa l'utente che effettua la query ha il permesso di visualizzare. Chiamare get authorized access for a principal API (Ottenere l'accesso autorizzato per un'API principale ) per ottenere l'accesso effettivo dell'utente per l'elemento.
Punto finale API
GET https://onelake.dfs.fabric.microsoft.com/v1.0/workspaces/{workspaceId}/artifacts/{artifactId}/securityPolicy/principalAccess
Corpo della richiesta
{
"aadObjectId": "<end-user-entra-object-id>",
"inputPath": "Tables",
"maxResults": 500 //optional, default is 500
}
| Parametro | Tipo | Obbligatorio | Descrizione |
|---|---|---|---|
| aadObjectId | corda | Sì | ID oggetto Microsoft Entra dell'utente finale di cui si desidera controllare l'accesso. |
| inputPath | corda | Sì |
Tables o Files. Restituisce l'accesso dell'utente per la sezione specificata dell'elemento. Per la maggior parte dei motori di query, inputPath sarà Tables. |
| continuationToken | corda | No | Usato per recuperare risultati continui quando il set di risultati supera maxResults. |
| maxResults | numero intero | No | Numero massimo di elementi per pagina. Il valore predefinito è 500. |
Risposta di esempio (solo Row-Level Security)
{
"identityETag": "3fc4dc476ded773e4cf43936190bf20fa9480a077b25edc0b4bbe247112542f6",
"metadataETag": "\"eyJhciI6IlwiMHg4R...\"",
"value": [
{
"path": "Tables/dbo/Customers",
"access": ["Read"],
"rows": "SELECT * FROM [dbo].[Customers] WHERE [customerId] = '123'",
"effect": "Permit"
},
{
"path": "Tables/dbo/Employees",
"access": ["Read"],
"rows": "SELECT * FROM [dbo].[Employees] WHERE [address] = '123'",
"effect": "Permit"
},
{
"path": "Tables/dbo/EmployeeTerritories",
"access": ["Read"],
"effect": "Permit"
}
]
}
Risposta di esempio (RLS e CLS)
Quando la sicurezza a livello di colonna è configurata in una tabella, la risposta include una columns matrice che elenca solo le colonne a cui l'utente può accedere. Le colonne non presenti in questa matrice sono nascoste all'utente.
{
"identityETag": "79372bc169b00882d9abec3d404032131e96bc406e15c6766514723021e153eb",
"metadataETag": "\"eyJhciI6IlwiMHg4R...\"",
"value": [
{
"path": "Tables/dbo/Customers",
"access": ["Read"],
"columns": [
{
"name": "address",
"columnEffect": "Permit",
"columnAction": ["Read"]
},
{
"name": "city",
"columnEffect": "Permit",
"columnAction": ["Read"]
},
{
"name": "contactTitle",
"columnEffect": "Permit",
"columnAction": ["Read"]
},
{
"name": "country",
"columnEffect": "Permit",
"columnAction": ["Read"]
},
{
"name": "fax",
"columnEffect": "Permit",
"columnAction": ["Read"]
},
{
"name": "phone",
"columnEffect": "Permit",
"columnAction": ["Read"]
},
{
"name": "postalCode",
"columnEffect": "Permit",
"columnAction": ["Read"]
},
{
"name": "region",
"columnEffect": "Permit",
"columnAction": ["Read"]
}
],
"rows": "SELECT * FROM [dbo].[Customers] WHERE [customerID] = 'ALFKI'",
"effect": "Permit"
},
{
"path": "Tables/dbo/Employees",
"access": ["Read"],
"rows": "SELECT * FROM [dbo].[Employees] WHERE [address] = '123'",
"effect": "Permit"
}
]
}
Informazioni sulla risposta
La risposta contiene una matrice di PrincipalAccessEntry oggetti, ognuno dei quali rappresenta una tabella a cui l'utente ha accesso. Le tabelle non presenti nella risposta non sono accessibili all'utente.
| Campo | Tipo | Descrizione |
|---|---|---|
path |
corda | Percorso della tabella a cui l'utente può accedere, ad esempio Tables/dbo/Customers. |
access |
string[] | Matrice di tipi di accesso concessi. Attualmente è supportato solo Read. |
columns |
object[] | Una matrice di oggetti colonna a cui l'utente può accedere. Ogni oggetto contiene name (nome colonna), columnEffect (Permit) e columnAction (["Read"]). Se questo campo è assente, non viene applicato alcun CLS e tutte le colonne sono consentite. Se presente, devono essere restituite solo le colonne elencate. |
rows |
corda | Istruzione T-SQL SELECT che rappresenta il filtro di sicurezza a livello di riga. All'utente devono essere restituite solo le righe corrispondenti a questo predicato. Se questo campo è assente, non viene applicato alcun RLS e tutte le righe sono permesse. |
effect |
corda | Tipo di effetto. Attualmente, sempre Permit. |
Importante
Il rows campo contiene un'espressione T-SQL che il motore deve analizzare e applicare come predicato di filtro. L'espressione usa un SELECT * FROM [schema].[table] WHERE ... formato. Il motore deve estrarre la WHERE clausola e applicarla ai dati restituiti.
ETag per la memorizzazione nella cache
La risposta include due valori ETag che consentono una memorizzazione nella cache efficiente:
-
identityETag: rappresenta lo stato corrente dell'identità e delle appartenenze ai gruppi dell'utente. Memorizzare nella cache il risultato di accesso dell'utente e riutilizzarlo fino a quando questo ETag non viene modificato. -
metadataETag: rappresenta lo stato corrente della configurazione di sicurezza dell'elemento. Memorizzare nella cache i metadati del ruolo e riutilizzarlo fino a quando questo ETag non viene modificato.
Usare questi ETag con l'intestazione della richiesta If-None-Match per evitare il recupero dei dati non modificati. Ciò migliora le prestazioni per le cache multiutente.
Esempio: Recuperare l'accesso effettivo (Python)
import requests
# Get a token for the OneLake DFS endpoint
token = credential.get_token("https://storage.azure.com/.default").token
workspace_id = "<workspace-id>"
artifact_id = "<artifact-id>"
user_object_id = "<end-user-entra-object-id>"
url = (
f"https://onelake.dfs.fabric.microsoft.com/v1.0/"
f"workspaces/{workspace_id}/artifacts/{artifact_id}/"
f"securityPolicy/principalAccess"
)
headers = {
"Authorization": f"Bearer {token}",
"Content-Type": "application/json"
}
body = {
"aadObjectId": user_object_id,
"inputPath": "Tables"
}
response = requests.get(url, headers=headers, json=body)
access_data = response.json()
# The response contains the user's effective access
for entry in access_data["value"]:
print(f"Table: {entry['path']}, Access: {entry['access']}")
if "columns" in entry:
col_names = [col["name"] for col in entry["columns"]]
print(f" CLS permitted columns: {col_names}")
if "rows" in entry:
print(f" RLS filter: {entry['rows']}")
Passaggio 4: Applicare i filtri di sicurezza
Dopo aver recuperato l'accesso effettivo dell'utente, il motore deve applicare i criteri di sicurezza ai dati prima di restituire i risultati. Questo passaggio è fondamentale: il motore è responsabile dell'applicazione corretta dei criteri.
Filtro a livello di tabella
Restituisce solo i dati dalle tabelle visualizzate nella principalAccess risposta. Se una tabella non è elencata, l'utente non ha accesso a tale tabella e non deve essere restituito alcun dato.
# Build a set of accessible tables for the user
accessible_tables = {entry["path"] for entry in access_data["value"]}
# Before returning query results, verify the table is accessible
def is_table_accessible(table_path: str) -> bool:
return table_path in accessible_tables
Filtro di sicurezza a livello di riga
Quando un rows campo è presente in una voce di accesso, il motore deve analizzare il predicato T-SQL e applicarlo come filtro ai dati della tabella. Il rows valore è un'istruzione SELECT con una WHERE clausola che definisce le righe che l'utente può visualizzare.
Importante
Se il motore non è in grado di analizzare le istruzioni SQL, le query sulle tabelle con una proprietà rows non null devono fallire con un errore e non restituire alcun dato. In questo modo si garantisce che agli utenti venga concesso l'accesso solo a ciò che è consentito visualizzare.
Ad esempio, il filtro RLS seguente:
SELECT * FROM [dbo].[Customers] WHERE [customerId] = '123' UNION SELECT * FROM [dbo].[Customers] WHERE [customerID] = 'ALFKI'
Il motore deve estrarre i predicati e applicarli per filtrare i dati:
import sqlparse
def extract_rls_predicates(rls_expression: str) -> list:
"""
Parse the RLS T-SQL expression and extract WHERE clause predicates.
The expression may contain UNION of multiple SELECT statements.
"""
predicates = []
statements = rls_expression.split(" UNION ")
for stmt in statements:
parsed = sqlparse.parse(stmt)[0]
where_seen = False
where_clause = []
for token in parsed.tokens:
if where_seen:
where_clause.append(str(token).strip())
if token.ttype is sqlparse.tokens.Keyword and token.value.upper() == "WHERE":
where_seen = True
if where_clause:
predicates.append(" ".join(where_clause))
return predicates
def apply_rls_filter(dataframe, access_entry: dict):
"""Apply RLS filtering to a dataframe based on the access entry."""
if "rows" not in access_entry:
return dataframe # No RLS, return all rows
predicates = extract_rls_predicates(access_entry["rows"])
# Combine predicates with OR (UNION semantic)
combined_filter = " OR ".join(f"({p})" for p in predicates)
return dataframe.filter(combined_filter)
Importante
Quando il rows campo è assente da una voce di accesso, non si applica RLS a quella tabella e tutte le righe devono essere restituite. Quando il campo è presente, il motore deve filtrare i dati. La restituzione di dati non filtrati per una tabella con RLS è una violazione della sicurezza.
Filtro di sicurezza a livello di colonna
Quando CLS è configurato in una tabella, la principalAccess risposta include una columns matrice che elenca in modo esplicito le colonne a cui l'utente può accedere. Ogni oggetto colonna contiene:
| Proprietà | Tipo | Descrizione |
|---|---|---|
name |
corda | Nome della colonna (sensibile al caso). |
columnEffect |
corda | Effetto applicato alla colonna. Attualmente, sempre Permit. |
columnAction |
string[] | Azioni consentite nella colonna. Attualmente è supportato solo Read. |
Se il columns campo è assente da una voce di autorizzazione, non viene applicato alcun CLS e l'accesso a tutte le colonne della tabella è consentito. Se il columns campo è presente, il motore dovrà restituire solo le colonne elencate.
def get_permitted_columns(access_entry: dict) -> list | None:
"""
Return the list of permitted column names for a table.
Returns None if no CLS applies (all columns are permitted).
"""
if "columns" not in access_entry:
return None # No CLS, all columns are permitted
return [
col["name"]
for col in access_entry["columns"]
if col.get("columnEffect") == "Permit"
and "Read" in col.get("columnAction", [])
]
def apply_cls_filter(dataframe, access_entry: dict):
"""Apply CLS filtering to a dataframe based on the access entry."""
permitted_columns = get_permitted_columns(access_entry)
if permitted_columns is None:
return dataframe # No CLS, return all columns
# Only keep columns that are in the permitted list
return dataframe.select(permitted_columns)
Importante
Quando il columns campo è assente da una voce di accesso, non viene applicato alcun CLS e tutte le colonne devono essere restituite. Quando il campo è presente, il motore deve restituire solo le colonne elencate. La restituzione di colonne nascoste è una violazione di sicurezza.
Gestione delle tabelle senza accesso
Se un utente esegue una query su una tabella che non viene visualizzata nella principalAccess risposta, il motore deve negare l'accesso. Evita di tornare alla restituzione di dati non filtrati.
def query_table(table_path: str, user_access: dict):
"""Query a table with OneLake security enforcement."""
# Find the user's access entry for this table
entry = next(
(e for e in user_access["value"] if e["path"] == table_path),
None
)
if entry is None:
raise PermissionError(
f"Access denied: user doesn't have permission to access {table_path}"
)
# Read the data from OneLake
data = read_table_from_onelake(table_path)
# Apply column-level security
data = apply_cls_filter(data, entry)
# Apply row-level security
data = apply_rls_filter(data, entry)
return data
Passaggio 5: Gestire la memorizzazione nella cache e il rilevamento delle modifiche
Per le integrazioni di livello di produzione, in particolare i motori con cache dei dati multiutente, è necessario gestire le modifiche ai criteri di sicurezza e alle appartenenze ai gruppi di utenti.
Metadati di sicurezza della cache
Usare i valori identityETag e metadataETag dalla risposta principalAccess per determinare quando le informazioni di sicurezza memorizzate nella cache sono obsolete.
-
identityETag: modifiche quando vengono aggiornate le appartenenze ai gruppi o le proprietà di identità dell'utente. Memorizzare nella cache l'accesso effettivo dell'utente utilizzando(userId, identityETag). -
metadataETag: cambia quando vengono aggiornati i ruoli o i criteri di sicurezza di OneLake nell'elemento. Definizioni dei ruoli della cache con chiave in(artifactId, metadataETag).
Controllo periodico delle modifiche
Eseguire periodicamente il polling dell'API principalAccess per rilevare le modifiche. L'API deve essere sottoposto a polling prima dell'esecuzione della query per assicurarsi che non sia stato modificato nulla, anziché gestire direttamente i risultati dalla cache. Utilizzare l'intestazione If-None-Match con il ETag ricevuto in precedenza per ridurre al minimo la larghezza di banda.
headers = {
"Authorization": f"Bearer {token}",
"Content-Type": "application/json",
"If-None-Match": f'"{cached_etag}"'
}
response = requests.get(url, headers=headers, json=body)
if response.status_code == 304:
# Security hasn't changed, use cached data
pass
elif response.status_code == 200:
# Security has changed, update cache
new_access_data = response.json()
update_cache(user_id, new_access_data)
Considerazioni sulla latenza
- La propagazione delle modifiche apportate alle definizioni dei ruoli di sicurezza di OneLake richiede circa 5 minuti .
- Le modifiche apportate alle appartenenze ai gruppi di utenti in Microsoft Entra ID richiedono circa 1 ora per riflettere in OneLake.
- Alcuni motori Fabric hanno un proprio livello di memoria cache, quindi potrebbero richiedere tempo aggiuntivo.
Progettate l'intervallo di polling e il TTL della cache di conseguenza. Un approccio consigliato consiste nel eseguire il polling ogni 5 minuti per le modifiche ai metadati di sicurezza e aggiornare l'accesso specifico dell'utente in ogni query o a un intervallo più breve.
Passaggio 6: Gestire la paginazione
L'API principalAccess supporta la paginazione per gli elementi con molte tabelle. Quando la risposta include più voci di maxResults, la risposta contiene un oggetto continuationToken.
all_entries = []
continuation_token = None
while True:
body = {
"aadObjectId": user_object_id,
"inputPath": "Tables",
"maxResults": 500
}
if continuation_token:
body["continuationToken"] = continuation_token
response = requests.get(url, headers=headers, json=body)
data = response.json()
all_entries.extend(data["value"])
# Check for continuation token in response
continuation_token = data.get("continuationToken")
if not continuation_token:
break
Gestione degli errori
Gestire gli scenari di errore seguenti nell'integrazione:
| Stato HTTP | Codice di errore | Descrizione | Azione consigliata |
|---|---|---|---|
| 200 | - | Successo. | Elaborare la risposta. |
| 404 | ElementoNonTrovato | L'area di lavoro o l'elemento non esiste, oppure l'identità motore non ha accesso. | Verificare l'ID dell'area di lavoro e l'ID dell'artefatto. Verificare che l'identità del motore disponga dell'accesso ai membri dell'area di lavoro. |
| 412 | PrecondizioneFallita | L'ETag specificato in If-Match non corrisponde alla risorsa corrente ETag. |
Recuperare nuovamente la risorsa senza l'intestazione If-Match per ottenere l'ETag più recente. |
| 429 | - | Limite di velocità superato. | Attendere la durata specificata nell'intestazione Retry-After prima di riprovare. |
Procedure consigliate per la sicurezza
Seguire queste procedure consigliate per garantire un'integrazione sicura:
- Proteggere le credenziali di identità del motore. Il service principal ha un accesso elevato ai dati in OneLake. Archiviare le credenziali in modo sicuro usando servizi come Azure Key Vault.
- Non esporre dati non elaborati agli utenti finali. Applicare sempre i filtri di sicurezza restituiti dall'API
principalAccessprima di restituire i dati. Ignorare l'imposizione è una violazione della sicurezza. - Convalidare attentamente i predicati RLS. Analizzare e applicare accuratamente i predicati della clausola T-SQL
WHERE. L'analisi non corretta può causare perdite di dati. Se si verificano errori di analisi o mappatura di sintassi incerta, fallire la query con un errore di analisi RLS anziché fornire risultati parziali o non sicuri per l'utente. - Gestire le tabelle mancanti come accesso negato. Se una tabella non è presente nella risposta dell'API, l'utente non ha accesso. Non ripiegare mai sui dati non filtrati, la sicurezza di OneLake utilizza sempre il rifiuto per impostazione predefinita.
- Verifica dell'accesso. Registrare gli utenti che accedono alle tabelle e ai criteri di sicurezza applicati per la conformità e la risoluzione dei problemi.
- Effettuare un sondaggio delle modifiche di sicurezza. Usare ETags per rilevare le modifiche e aggiornare tempestivamente i criteri memorizzati nella cache.
Limitazioni
- L'API
principalAccessè in anteprima e può cambiare in base al feedback. - Sono supportati oggi solo il tipo di accesso
Reade l'effettoPermit. - L'identità del motore deve avere accesso senza restrizioni a livello di root. Se RLS o CLS si applica all'identità del motore, le chiamate API falliscono.
- I predicati RLS usano la sintassi T-SQL. Il motore è responsabile dell'analisi e dell'applicazione corretta dei predicati.
- La propagazione delle modifiche ai criteri di sicurezza richiede circa 5 minuti. Le modifiche all'appartenenza ai gruppi di utenti richiedono circa 1 ora.
Contenuti correlati
- Ottenere l'accesso autorizzato per un riferimento all'API principale
- Panoramica delle integrazioni di sicurezza di OneLake
- Informazioni di riferimento sulle integrazioni di sicurezza di OneLake
- Modello di controllo dell'accesso alla sicurezza di OneLake
- Sicurezza a livello di riga in OneLake
- Sicurezza a livello di colonna in OneLake
- Introduzione alla sicurezza di OneLake