Freigeben über


Whitepaper zur Azure Synapse Analytics-Sicherheit: Zugriffssteuerung

Hinweis

Dieser Artikel ist Teil der Artikelserie zum Whitepaper Azure Synapse Analytics-Sicherheit. Eine Übersicht über die Artikelserie finden Sie unter Whitepaper zur Azure Synapse Analytics-Sicherheit.

Je nachdem, wie die Daten modelliert und gespeichert wurden, kann die Datengovernance und Zugriffssteuerung erfordern, dass Entwickler*innen und Sicherheitsadministrator*innen unterschiedliche Ansätze oder eine Kombination von Techniken verwenden, um eine stabile Sicherheitsgrundlage zu implementieren.

Azure Synapse unterstützt eine Vielzahl von Funktionen, um zu steuern, wer auf welche Daten zugreifen kann. Diese Funktionen bauen auf einer Reihe erweiterter Zugriffssteuerungsfeatures auf, einschließlich:

Sicherheit auf Objektebene

Jedes Objekt in einem dedizierten SQL-Pool verfügt über zugeordnete Berechtigungen, die einem Prinzipal erteilt werden können. Im Kontext von Benutzer*innen und Dienstkonten werden auf diese Weise einzelne Tabellen, Ansichten, gespeicherte Prozeduren und Funktionen geschützt. Objektberechtigungen wie SELECT können Benutzerkonten (SQL-Anmeldungen, Microsoft Entra-Benutzer*innen oder -Gruppen) und Datenbankrollen gewährt werden, was Datenbankadministrator*innen Flexibilität bietet. Darüber hinaus können Berechtigungen, die für Tabellen und Ansichten erteilt werden, mit anderen Zugriffssteuerungsmechanismen wie der Sicherheit auf Spaltenebene, Sicherheit auf Zeilenebene und der dynamische Datenmaskierung kombiniert werden (siehe unten).

In Azure Synapse werden allen Benutzer*innen und Rollen auf Datenbankebene alle Berechtigungen erteilt. Darüber hinaus wird allen Benutzer*innen, denen die integrierte Rolle Synapse-RBAC-Administrator auf Arbeitsbereichsebene erteilt wurde, automatisch Vollzugriff auf alle dedizierten SQL-Pools gewährt.

Neben SQL-Tabellen können in Azure Synapse auch dedizierte SQL-Pools (früher SQL DW), serverlose SQL-Pools und Spark-Tabellen geschützt werden. Standardmäßig verfügen Benutzer*innen, denen die Rolle Mitwirkender an Storage-Blobdaten für mit dem Arbeitsbereich verbundene Data Lakes zugewiesen wurde, über READ-, WRITE- und EXECUTE-Berechtigungen für alle mit Spark erstellten Tabellen, wenn Benutzer*innen Code interaktiv im Notebook ausführen. Dies wird als Microsoft Entra-Passthrough bezeichnet und gilt für alle mit dem Arbeitsbereich verbundene Data Lakes. Wenn jedoch dieselben Benutzer*innen dasselbe Notebook über eine Pipeline ausführen, wird die verwaltete Dienstidentität (Managed Service Identity, MSI) des Arbeitsbereichs für die Authentifizierung verwendet. Damit die Pipeline die Arbeitsbereich-MSI erfolgreich ausführen kann, muss sie auch zur Rolle Mitwirkender an Storage-Blobdaten des Data Lake gehören, auf den zugegriffen wird.

Sicherheit auf Zeilenebene

Mithilfe der Sicherheit auf Zeilenebene können Sicherheitsadministrator*innen basierend auf dem Profil von Benutzer*innen (oder Prozessen), die eine Abfrage ausführen, differenzierten Zugriff auf bestimmte Tabellenzeilen einrichten und steuern. Profil- oder Benutzermerkmale können sich auf die Gruppenmitgliedschaft oder den Ausführungskontext beziehen. Die Sicherheit auf Zeilenebene hilft dabei, nicht autorisierten Zugriff zu verhindern, wenn Benutzer*innen Daten aus denselben Tabellen abfragen, aber unterschiedliche Teilmengen von Daten anzeigen müssen.

Hinweis

Die Sicherheit auf Zeilenebene wird in Azure Synapse und dedizierten SQL-Pools (früher SQL DW) unterstützt, aber nicht für Apache Spark-Pools und serverlose SQL-Pools.

Sicherheit auf Spaltenebene

Die Sicherheit auf Spaltenebene ermöglicht Sicherheitsadministrator*innen das Festlegen von Berechtigungen, die einschränken, wer auf vertrauliche Spalten in Tabellen zugreifen kann. Sie wird auf Datenbankebene festgelegt und kann implementiert werden, ohne dass der Entwurf des Datenmodells oder der Anwendungsebene geändert werden muss.

Hinweis

Die Sicherheit auf Spaltenebene wird in Azure Synapse, erverlosen SQL-Poolansichten und dedizierten SQL-Pools (früher SQL DW) unterstützt, aber nicht für externe serverlose SQL-Pooltabellen und Apache Spark-Pools. Bei einer serverlosen Problemumgehung für externe Tabellen im SQL-Pool kann eine Ansicht über einer externen Tabelle erstellt werden.

Dynamische Datenmaskierung

Mithilfe der dynamischen Datenmaskierung können Sicherheitsadministrator*innen die Gefährdung vertraulicher Daten einschränken, indem sie sie beim Lesen für nicht privilegierte Benutzer*innen maskieren. Dies hilft dabei, nicht autorisierten Zugriff auf vertrauliche Daten zu verhindern, indem Administrator*innen bestimmen können, wie die Daten zur Abfragezeit angezeigt werden. Basierend auf der Identität der authentifizierten Benutzer*innen und deren Gruppenzuweisung im SQL-Pool gibt eine Abfrage entweder maskierte oder nicht maskierte Daten zurück. Die Maskierung wird immer angewendet, unabhängig davon, ob direkt aus einer Tabelle oder mithilfe einer Ansicht oder einer gespeicherten Prozedur auf Daten zugegriffen wird.

Hinweis

Die dynamische Datenmaskierung wird in Azure Synapse und dedizierten SQL-Pools (früher SQL DW) unterstützt, aber nicht für Apache Spark-Pools und serverlose SQL-Pools.

Rollenbasierte Zugriffssteuerung in Synapse

Azure Synapse umfasst auch Rollen für die rollenbasierte Zugriffssteuerung (RBAC) in Synapse zum Verwalten verschiedener Aspekte von Synapse Studio. Nutzen Sie diese integrierten Rollen, um Benutzer*innen, Gruppen oder anderen Sicherheitsprinzipalen Berechtigungen zu erteilen. So können Sie verwalten, wer die folgenden Aktionen ausführen kann:

  • Veröffentlichen von Codeartefakten und Auflisten von veröffentlichten Codeartefakten bzw. Zugreifen auf diese
  • Ausführen von Code in Apache Spark-Pools und Integration Runtimes
  • Zugreifen auf verknüpfte Dienste (Daten), die durch Anmeldeinformationen geschützt sind
  • Überwachen oder Abbrechen von Auftragsausführungen, Überprüfen von Auftragsausgaben und Ausführungsprotokollen

Nächste Schritte

Im nächsten Artikel in dieser Whitepaperserie erfahren Sie mehr über die Authentifizierung.