Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für:
SQL Server 2016 (13.x) und höhere Versionen Azure SQL-Datenbank Azure SQL verwaltete Instanz Azure Synapse AnalyticsSQL-Datenbank in Microsoft Fabric
Dynamische Datenmaskierung (DDM) schränkt die Offenlegung sensibler Daten ein, indem diese für nicht berechtigte Benutzer maskiert werden. Sie kann den Entwurf und die Sicherheitscodierung in Ihrer Anwendung erheblich vereinfachen.
Dieser Inhalt gilt für dynamische Datenmaskierungskonzepte im Allgemeinen und spezifisch für SQL Server. Spezielle Inhalte für andere Plattformen sind verfügbar:
- Mehr Informationen zu Dynamischer Datenmaskierung in Azure SQL-Datenbank, Azure SQL Managed Instance und Azure Synapse Analytics finden Sie unter Erste Schritte mit SQL Database Dynamische Datenmaskierung.
- Informationen zur dynamischen Datenmaskierung in Microsoft Fabric finden Sie unter Dynamische Datenmaskierung in Fabric Data Warehousing.
Überblick über die Dynamische Datenmaskierung
Mit der dynamischen Datenmaskierung können Sie unbefugten Zugriff auf sensible Daten verhindern. Kund*innen können festlegen, wie viele sensible Daten offengelegt werden sollen – mit minimaler Auswirkung auf die Anwendungsschicht. DDM kann für designierte Datenbankfelder zum Ausblenden sensibler Daten in den Resultsets von Abfragen konfiguriert werden. Mit der dynamischen Datenmaskierung (DDM) werden Daten in der Datenbank nicht geändert. DDM ist für vorhandene Anwendungen einfach zu verwenden, da Maskierungsregeln auf die Abfrageergebnisse angewandt werden. Viele Clientanwendungen können sensible Daten maskieren, ohne vorhandene Abfragen zu ändern.
- Eine zentrale Datenmaskierungsrichtlinie wirkt sich direkt auf vertrauliche Felder in der Datenbank aus.
- Festlegen berechtigter Benutzer oder Rollen, die Zugriff auf vertrauliche Daten haben.
- DDM umfasst Funktionen zur vollständigen und partiellen Maskierung sowie eine willkürliche Maske für numerische Daten.
- Zum Definieren und Verwalten von Masken werden einfache Transact-SQL-Befehle verwendet.
Der Zweck der dynamischen Datenmaskierung besteht darin, die Offenlegung sensibler Daten zu beschränken, indem Benutzer an der Anzeige von Daten gehindert werden, auf die sie keinen Zugriff haben sollen. Die dynamische Datenmaskierung ist nicht darauf ausgerichtet, Datenbankbenutzer daran zu hindern, eine direkte Verbindung mit der Datenbank herzustellen und umfassende Abfragen auszuführen, die Teile der vertraulichen Daten verfügbar machen. Die dynamische Datenmaskierung ist eine Ergänzung zu anderen SQL Server-Sicherheitsfeatures (Überwachung, Verschlüsselung, Sicherheit auf Zeilenebene usw.), und es wird dringend empfohlen, sie in Verbindung mit diesen anderen Features zu verwenden, um die vertraulichen Daten in der Datenbank besser zu schützen.
Die dynamische Datenmaskierung steht in SQL Server 2016 (13.x) und in Azure SQL-Datenbank zur Verfügung und wird mithilfe von Transact-SQL -Befehlen konfiguriert. Weitere Informationen zum Konfigurieren der dynamischen Datenmaskierung über das Azure-Portal finden Sie unter Erste Schritte mit der dynamischen Datenmaskierung für SQL-Datenbank (Azure-Portal).
Hinweis
Microsoft Entra ID war bisher unter Azure Active Directory (Azure AD) bekannt.
Definieren eines dynamischen Datenformats
Eine Maskierungsregel kann für eine Spalte in einer Tabelle definiert werden, um die Daten in dieser Spalte unkenntlich zu machen. Es stehen fünf Arten von Masken zur Verfügung.
| Funktion | Beschreibung | Beispiele |
|---|---|---|
| Standard | Die vollständige Maskierung gemäß der Datentypen der festgelegten Felder. Für String-Datentypen verwenden Sie XXXX (oder weniger) wenn die Größe des Feldes weniger als 4 Zeichen beträgt (char, nchar, varchar, nvarchar, text, ntext).Verwenden Sie für numerische Datentypen den Wert 0 (null) (bigint, bit, decimal, int, money, numeric, smallint, smallmoney, tinyint, float, real). Für Datums- und Zeitdatentypen verwenden Sie 1900-01-01 00:00:00.0000000 (date, datetime2, datetime, datetimeoffset, smalldatetime, time).Verwenden Sie für binäre Datentypen ein Einzelbyte des ASCII-Werts 0 (binary, varbinary, image). |
Beispielsyntax der Spaltendefinition: Phone# varchar(12) MASKED WITH (FUNCTION = 'default()') NULLBeispiel für die alter-Syntax: ALTER COLUMN Gender ADD MASKED WITH (FUNCTION = 'default()') |
| E‑Mail | Eine Maskierungsmethode, die den ersten Buchstaben einer E-Mail-Adresse und das konstante Suffix „.com“ in Form einer E-Mail-Adresse verfügbar macht. aXXX@XXXX.com. |
Beispielsyntax der Definition: Email varchar(100) MASKED WITH (FUNCTION = 'email()') NULLBeispiel für die alter-Syntax: ALTER COLUMN Email ADD MASKED WITH (FUNCTION = 'email()') |
| Zufällig | Eine zufällige Maskierungsfunktion, die für alle numerischen Typen verwendet werden kann, um den ursprünglichen Wert mit einem zufälligen Wert innerhalb eines bestimmten Bereichs zu maskieren. | Beispielsyntax der Definition: Account_Number bigint MASKED WITH (FUNCTION = 'random([start range], [end range])')Beispiel für die alter-Syntax: ALTER COLUMN [Month] ADD MASKED WITH (FUNCTION = 'random(1, 12)') |
| Benutzerdefinierte Zeichenfolge | Eine Maskierungsmethode, die den ersten und letzten Buchstaben verfügbar macht und in der Mitte eine benutzerdefinierte Zeichenfolge zur Auffüllung hinzufügt. prefix,[padding],suffixWenn der ursprüngliche Wert zu kurz ist, um die gesamte Maske zu vervollständigen, wird ein Teil des Präfixes oder Suffixes nicht angezeigt. |
Beispielsyntax der Definition: FirstName varchar(100) MASKED WITH (FUNCTION = 'partial(prefix,[padding],suffix)') NULLBeispiel für die alter-Syntax: ALTER COLUMN [Phone Number] ADD MASKED WITH (FUNCTION = 'partial(1,"XXXXXXX",0)')Dadurch wird eine Telefonnummer wie 555.123.1234 zu 5XXXXXXX umgewandelt. Weiteres Beispiel: ALTER COLUMN [Phone Number] ADD MASKED WITH (FUNCTION = 'partial(5,"XXXXXXX",0)') Dadurch wird eine Telefonnummer wie 555.123.1234 zu 555.1XXXXXXX umgewandelt. |
| Datetime | Gilt für: SQL Server 2022 (16.x) Maskierungsmethode für Spalten, die mit dem Datentyp datetime, datetime2, date, time, datetimeoffset odersmalldatetime definiert sind. Hilft dabei, die Komponente year => datetime("Y"), month=> datetime("M"), day=>datetime("D"), hour=>datetime("h"), minute=>datetime("m"), oder seconds=>datetime("s") des Tages zu maskieren. |
Beispiel für das Maskieren des Jahres im datetime-Wert:ALTER COLUMN BirthDay ADD MASKED WITH (FUNCTION = 'datetime("Y")')Beispiel zum Maskieren des Monats im datetime-Wert: ALTER COLUMN BirthDay ADD MASKED WITH (FUNCTION = 'datetime("M")')Beispiel zum Maskieren der Minute im datetime-Wert: ALTER COLUMN BirthDay ADD MASKED WITH (FUNCTION = 'datetime("m")') |
Berechtigungen
Benutzer mit der Berechtigung SELECT für eine Tabelle können die Tabellendaten anzeigen. Spalten, die als maskiert definiert sind, zeigen die maskierten Daten an. Erteilen Sie die Berechtigung UNMASK einem Benutzer, damit dieser Daten ohne Maskierung aus den Spalten abrufen kann, für die eine Maskierung definiert ist.
Benutzer und Rollen mit Administratorrechten können die nicht maskierten Daten dank der Berechtigung CONTROL jederzeit anzeigen. Diese Berechtigung umfasst die Berechtigungen ALTER ANY MASK und UNMASK. Benutzer und Rollen mit Administratorrechten wie sysadmin oder db_owner verfügen für die Datenbank standardmäßig über CONTROL-Berechtigungen und können nicht maskierten Daten anzeigen.
Zum Erstellen einer Tabelle mit einer dynamischen Datenmaske benötigen Sie keine speziellen Berechtigungen. Lediglich die Standardschemaberechtigungen CREATE TABLE und ALTER sind erforderlich.
Das Hinzufügen, Ersetzen oder Entfernen der Maske einer Spalte erfordert die Berechtigungen ALTER ANY MASK und ALTER für die Tabelle. Es empfiehlt sich, die Berechtigung ALTER ANY MASK einem Sicherheitsbeauftragten zu erteilen.
Hinweis
Die UNMASK-Berechtigung wirkt sich nicht auf die Sichtbarkeit von Metadaten aus: Durch das Erteilen von UNMASK allein werden keine Metadaten offengelegt. UNMASK muss immer von einer SELECT-Berechtigung begleitet werden, damit sie wirksam ist. Beispiel: Das Erteilen von UNMASK für den Datenbankbereich und von SELECT für eine einzelne Tabelle führt dazu, dass die benutzende Person nur die Metadaten der Tabelle sehen kann, für die er die SELECT-Berechtigung hat. Sehen Sie sich hierzu auch die Seite zur Konfiguration der Sichtbarkeit von Metadaten an.
Bewährte Methoden und gängige Anwendungsfälle
Das Erstellen einer Maske für eine Spalte verhindert keine Aktualisierungen dieser Spalte. Obwohl die Benutzer beim Abfragen der maskierten Spalte auch maskierte Daten erhalten, können dieselben Benutzer die Daten aktualisieren, wenn sie über die entsprechenden Schreibberechtigungen verfügen. Eine ordnungsgemäße Zugriffssteuerungsrichtlinie sollte weiterhin verwendet werden, um Aktualisierungsberechtigungen einzuschränken.
Die Verwendung von
SELECT INTOoderINSERT INTOzum Kopieren von Daten aus einer maskierten Spalte in eine andere Tabelle führt zu maskierten Daten in der Zieltabelle (vorausgesetzt, es wird von einem Benutzer ohne UNMASK-Berechtigung exportiert).Die dynamische Datenmaskierung wird beim Ausführen von SQL Server Import- und Exportvorgängen angewendet. Eine Datenbank mit maskierten Spalten führt zu einer exportierten Datendatei mit maskierten Daten (vorausgesetzt, sie wird durch einen Benutzer ohne Berechtigungen vom Typ UNMASK exportiert), und die importierte Datenbank enthält statisch maskierte Daten.
Abfragen maskierter Spalten
Verwenden Sie die sys.masked_columns-Ansicht zum Abfragen von Tabellenspalten, auf die eine Maskierungsfunktion angewendet wird. Diese Ansicht erbt von der sys.columns-Ansicht. Sie gibt alle Spalten in der sys.columns-Ansicht sowie die Spalten is_masked und masking_function zurück, wobei angegeben wird, ob die Spalte maskiert ist. Ist dies der Fall, gibt die Ansicht die definierte Maskierungsfunktion an. Diese Ansicht enthält nur die Spalten, auf die eine Maskierungsfunktion angewendet wird.
SELECT c.name, tbl.name as table_name, c.is_masked, c.masking_function
FROM sys.masked_columns AS c
JOIN sys.tables AS tbl
ON c.[object_id] = tbl.[object_id]
WHERE is_masked = 1;
Einschränkungen
Benutzer mit der Berechtigung CONTROL SERVER oder CONTROL auf Datenbankebene haben die Möglichkeit, die maskierten Daten im Originalformat anzuzeigen. Dazu gehören Administratorbenutzer oder Rollen wie sysadmin, db_owner usw.
Für die folgenden Spaltentypen kann keine Maskierungsregel definiert werden:
Verschlüsselte Spalten (Always Encrypted)
FILESTREAM
COLUMN_SET oder eine Sparsespalte, die Teil eines Spaltensatzes ist.
Eine Maske kann nicht für eine berechnete Spalte konfiguriert werden, aber wenn die berechnete Spalte von einer Spalte mit abhängig ist, gibt die berechnete Spalte maskierte Daten zurück.
Eine Spalte mit Datenmaskierung kann kein Schlüssel für einen FULLTEXT-Index sein.
Eine Spalte in einer externen Tabelle in PolyBase.
Für Benutzer ohne Berechtigung vom Typ UNMASK funktionieren die als veraltet markierten Anweisungen READTEXT, UPDATETEXT und WRITETEXT nicht ordnungsgemäß für eine Spalte, die für die dynamische Datenmaskierung konfiguriert ist.
Das Hinzufügen einer dynamischen Datenmaske wird als Schemaänderung für die zugrunde liegende Tabelle implementiert und kann deshalb nicht für eine Spalte mit Abhängigkeiten ausgeführt werden (zum Beispiel eine Spalte, die von einer berechneten Spalte referenziert wird). Wenn Sie versuchen, eine dynamische Datenmaske für Spalten mit Abhängigkeit hinzuzufügen, führt das zum Fehler ALTER TABLE ALTER COLUMN _columnname_ failed because one or more objects access this column. Um diese Einschränkung zu umgehen, können Sie zunächst die Abhängigkeiten entfernen und anschließend die dynamische Datenmaske hinzufügen. Danach erstellen Sie die Abhängigkeiten erneut. Wenn z.B. die Abhängigkeit dadurch entsteht, dass ein Indexes von dieser Spalte abhängt, können Sie den Index löschen und anschließend die Maske hinzufügen und dann den abhängigen Index wieder herstellen.
Immer wenn Sie einen Ausdruck projizieren, der auf eine Spalte verweist, für die eine Datenmaskierungsfunktion definiert wurde, wird der Ausdruck ebenfalls maskiert. Unabhängig von der Funktion (Standard, E-Mail, zufällig, benutzerdefinierte Zeichenfolge) zum Maskieren der Spalte, auf die verwiesen wird, wird der resultierende Ausdruck immer mit der Standardfunktion maskiert.
Datenbankübergreifende Abfragen, die zwei verschiedene Azure SQL-Datenbank-Instanzen oder Datenbanken umfassen, die in verschiedenen SQL Server-Instanzen gehostet werden und eine beliebige Art von Vergleichs- oder Joinvorgang für maskierte Spalten umfassen, liefern keine korrekten Ergebnisse. Die vom Remoteserver zurückgegebenen Ergebnisse sind bereits maskiert und nicht für lokale Vergleichs- oder Joinvorgänge geeignet.
Hinweis
Die dynamische Datenmaskierung wird nicht unterstützt, wenn die zugrunde liegende Basistabelle in einer indizierten Sicht referenziert wird.
Sicherheitshinweis: Umgehen der Maskierung mithilfe von Rückschluss- oder Brute-Force-Verfahren
Die dynamische Datenmaskierung wurde entwickelt, um die Anwendungsentwicklung zu vereinfachen, indem die Datenexposition in einer Reihe von vordefinierten Abfragen, die von der Anwendung verwendet werden, begrenzt wird. Die dynamische Datenmaskierung kann auch dazu dienen, eine versehentliche Offenlegung sensibler Daten beim direkten Zugriff auf eine Produktionsdatenbank zu verhindern. Es ist wichtig zu beachten, dass nicht berechtigte Benutzer mit Berechtigungen für Ad-hoc-Abfragen entsprechende Verfahren anwenden können, um Zugriff auf die eigentlichen Daten zu erhalten. Wenn es erforderlich ist, diesen Ad-hoc-Zugriff zu gewähren, sollten alle Datenbankaktivitäten überwacht werden, um dieses Szenario zu vermeiden.
Betrachten Sie dazu als Beispiel einen Datenbankprinzipal, der über ausreichende Berechtigungen zum Ausführen von Ad-hoc-Abfragen für die Datenbank verfügt und versucht, die zugrunde liegenden Daten zu „erraten“ und letztlich die tatsächlichen Werte abzuleiten. Nehmen Sie an, es liegt eine definierte Maske für die [Employee].[Salary] -Spalte vor, und dieser Benutzer stellt eine direkte Verbindung zur Datenbank her und beginnt mit dem Raten von Werten, um schließlich auf den [Salary] Wert in der Employees Tabelle zu schließen:
SELECT ID, Name, Salary FROM Employees
WHERE Salary > 99999 and Salary < 100001;
Kennung Name Gehalt 62543 Jana Hoffmann 0 91245 Johan Lorenz 0
Dies zeigt, dass die dynamische Datenmaskierung nicht als isolierte Maßnahme verwendet werden sollte, um vertrauliche Daten vollständig vor Benutzern zu schützen, die Ad-hoc-Abfragen für die Datenbank ausführen. Sie ist geeignet, um die versehentliche Offenlegung sensibler Daten zu verhindern, schützt aber nicht vor der böswilligen Absicht, auf die zugrunde liegenden Daten zu schließen.
Es ist wichtig, die Berechtigungen für die Datenbank ordnungsgemäß zu verwalten und stets das Prinzip der minimal erforderlichen Berechtigungen zu verfolgen. Beachten Sie auch, dass die Überwachung aktiviert ist, um alle Aktivitäten zu verfolgen, die für die Datenbank ausgeführt werden
In SQL Server 2022 eingeführte präzise Berechtigungen
Ab SQL Server 2022 (16.x) können Sie nicht autorisierten Zugriff auf vertrauliche Daten verhindern und die Kontrolle übernehmen, indem Sie die Daten für nicht autorisierte Benutzer auf verschiedenen Ebenen der Datenbank maskieren. Sie können Benutzernen, einer Datenbankrolle, einer Microsoft Entra-ID oder einer Microsoft Entra-Gruppe die UNMASK-Berechtigung auf Datenbank-, Schema-, Tabellen- oder Spaltenebene erteilen oder entziehen. Diese Erweiterung bietet eine präzisere Möglichkeit, nicht autorisierten Zugriff auf die in der Datenbank gespeicherten Daten zu kontrollieren und einzuschränken und die Datensicherheitsverwaltung zu verbessern.
Beispiele
Erstellen Sie eine dynamische Datenmaske
Mit dem folgenden Beispiel wird eine Tabelle mit drei verschiedenen Typen von dynamischen Datenmasken erstellt. Das Beispiel füllt die Tabelle und wählt sie aus, um das Ergebnis anzuzeigen.
-- schema to contain user tables
CREATE SCHEMA Data;
GO
-- table with masked columns
CREATE TABLE Data.Membership (
MemberID INT IDENTITY(1, 1) NOT NULL PRIMARY KEY CLUSTERED,
FirstName VARCHAR(100) MASKED WITH (FUNCTION = 'partial(1, "xxxxx", 1)') NULL,
LastName VARCHAR(100) NOT NULL,
Phone VARCHAR(12) MASKED WITH (FUNCTION = 'default()') NULL,
Email VARCHAR(100) MASKED WITH (FUNCTION = 'email()') NOT NULL,
DiscountCode SMALLINT MASKED WITH (FUNCTION = 'random(1, 100)') NULL
);
-- inserting sample data
INSERT INTO Data.Membership (FirstName, LastName, Phone, Email, DiscountCode)
VALUES
('Roberto', 'Tamburello', '555.123.4567', 'RTamburello@contoso.com', 10),
('Janice', 'Galvin', '555.123.4568', 'JGalvin@contoso.com.co', 5),
('Shakti', 'Menon', '555.123.4570', 'SMenon@contoso.net', 50),
('Zheng', 'Mu', '555.123.4569', 'ZMu@contoso.net', 40);
GO
Ein neuer Benutzer wird erstellt, und diesem wird die Berechtigung SELECT in dem Schema erteilt, in dem sich die Tabelle befindet. Abfragen werden für durch die MaskingTestUser -Ansicht maskierte Daten ausgeführt.
CREATE USER MaskingTestUser WITHOUT LOGIN;
GRANT SELECT ON SCHEMA::Data TO MaskingTestUser;
-- impersonate for testing:
EXECUTE AS USER = 'MaskingTestUser';
SELECT * FROM Data.Membership;
REVERT;
Das Ergebnis veranschaulicht die Masken durch Ändern der Daten von:
1 Roberto Tamburello 555.123.4567 RTamburello@contoso.com 10
nach:
1 Rxxxxxo Tamburello xxxx RXXX@XXXX.com 91
Dabei ist die Zahl in DiscountCode bei jedem Abfrageergebnis zufällig.
Hinzufügen oder Bearbeiten einer Maske für eine vorhandene Spalte
Verwenden Sie die ALTER TABLE-Anweisung zum Hinzufügen einer Maske zu einer vorhandenen Spalte in der Tabelle oder zum Bearbeiten der Maske für die betreffende Spalte.
Im folgenden Beispiel wird eine Maskierungsfunktion zur Spalte LastName hinzugefügt:
ALTER TABLE Data.Membership
ALTER COLUMN LastName ADD MASKED WITH (FUNCTION = 'partial(2,"xxxx",0)');
Im folgenden Beispiel wird eine Maskierungsfunktion für die Spalte LastName geändert:
ALTER TABLE Data.Membership
ALTER COLUMN LastName VARCHAR(100) MASKED WITH (FUNCTION = 'default()');
Erteilen von Berechtigungen zum Anzeigen von Daten ohne Maskierung
Das Erteilen der UNMASK -Berechtigung ermöglicht dem MaskingTestUser das Anzeigen der Daten ohne Maskierung.
GRANT UNMASK TO MaskingTestUser;
EXECUTE AS USER = 'MaskingTestUser';
SELECT * FROM Data.Membership;
REVERT;
-- Removing the UNMASK permission
REVOKE UNMASK TO MaskingTestUser;
Löschen einer dynamischen Datenmaske
Die folgende Anweisung löscht die Maske für die Spalte LastName , die im vorherigen Beispiel erstellt wurde:
ALTER TABLE Data.Membership
ALTER COLUMN LastName DROP MASKED;
Beispiele für präzise Berechtigungen
Erstellen eines Schemas für Benutzertabellen:
CREATE SCHEMA Data; GOErstellen einer Tabelle mit maskierten Spalten:
CREATE TABLE Data.Membership ( MemberID INT IDENTITY(1, 1) NOT NULL PRIMARY KEY CLUSTERED, FirstName VARCHAR(100) MASKED WITH (FUNCTION = 'partial(1, "xxxxx", 1)') NULL, LastName VARCHAR(100) NOT NULL, Phone VARCHAR(12) MASKED WITH (FUNCTION = 'default()') NULL, Email VARCHAR(100) MASKED WITH (FUNCTION = 'email()') NOT NULL, DiscountCode SMALLINT MASKED WITH (FUNCTION = 'random(1, 100)') NULL, BirthDay DATETIME MASKED WITH (FUNCTION = 'default()') NULL );Einfügen von Beispieldaten:
INSERT INTO Data.Membership (FirstName, LastName, Phone, Email, DiscountCode, BirthDay) VALUES ('Roberto', 'Tamburello', '555.123.4567', 'RTamburello@contoso.com', 10, '1985-01-25 03:25:05'), ('Janice', 'Galvin', '555.123.4568', 'JGalvin@contoso.com.co', 5, '1990-05-14 11:30:00'), ('Shakti', 'Menon', '555.123.4570', 'SMenon@contoso.net', 50, '2004-02-29 14:20:10'), ('Zheng', 'Mu', '555.123.4569', 'ZMu@contoso.net', 40, '1990-03-01 06:00:00');Erstellen eines Schemas für Diensttabellen:
CREATE SCHEMA Service; GOErstellen einer Diensttabelle mit maskierten Spalten:
CREATE TABLE Service.Feedback ( MemberID INT IDENTITY(1, 1) NOT NULL PRIMARY KEY CLUSTERED, Feedback VARCHAR(100) MASKED WITH (FUNCTION = 'default()') NULL, Rating INT MASKED WITH (FUNCTION = 'default()'), Received_On DATETIME );Einfügen von Beispieldaten:
INSERT INTO Service.Feedback(Feedback, Rating, Received_On) VALUES ('Good', 4, '2022-01-25 11:25:05'), ('Excellent', 5, '2021-12-22 08:10:07'), ('Average', 3, '2021-09-15 09:00:00');Erstellen verschiedener Benutzer in der Datenbank:
CREATE USER ServiceAttendant WITHOUT LOGIN; GO CREATE USER ServiceLead WITHOUT LOGIN; GO CREATE USER ServiceManager WITHOUT LOGIN; GO CREATE USER ServiceHead WITHOUT LOGIN; GOErteilen von Leseberechtigungen für die Benutzer in der Datenbank:
ALTER ROLE db_datareader ADD MEMBER ServiceAttendant; ALTER ROLE db_datareader ADD MEMBER ServiceLead; ALTER ROLE db_datareader ADD MEMBER ServiceManager; ALTER ROLE db_datareader ADD MEMBER ServiceHead;Erteilen verschiedener UNMASK-Berechtigungen für Benutzer:
--Grant column level UNMASK permission to ServiceAttendant GRANT UNMASK ON Data.Membership(FirstName) TO ServiceAttendant; -- Grant table level UNMASK permission to ServiceLead GRANT UNMASK ON Data.Membership TO ServiceLead; -- Grant schema level UNMASK permission to ServiceManager GRANT UNMASK ON SCHEMA::Data TO ServiceManager; GRANT UNMASK ON SCHEMA::Service TO ServiceManager; --Grant database level UNMASK permission to ServiceHead; GRANT UNMASK TO ServiceHead;Abfragen der Daten im Kontext des
ServiceAttendant-Benutzers:EXECUTE AS USER = 'ServiceAttendant'; SELECT MemberID, FirstName, LastName, Phone, Email, BirthDay FROM Data.Membership; SELECT MemberID, Feedback, Rating FROM Service.Feedback; REVERT;Abfragen der Daten im Kontext des
ServiceLead-Benutzers:EXECUTE AS USER = 'ServiceLead'; SELECT MemberID, FirstName, LastName, Phone, Email, BirthDay FROM Data.Membership; SELECT MemberID, Feedback, Rating FROM Service.Feedback; REVERT;Abfragen der Daten im Kontext des
ServiceManager-Benutzers:EXECUTE AS USER = 'ServiceManager'; SELECT MemberID, FirstName, LastName, Phone, Email, BirthDay FROM Data.Membership; SELECT MemberID, Feedback, Rating FROM Service.Feedback; REVERT;Abfragen der Daten im Kontext des
ServiceHead-BenutzersEXECUTE AS USER = 'ServiceHead'; SELECT MemberID, FirstName, LastName, Phone, Email, BirthDay FROM Data.Membership; SELECT MemberID, Feedback, Rating FROM Service.Feedback; REVERT;Verwenden Sie zum Widerrufen von UNMASK-Berechtigungen die folgenden T-SQL-Anweisungen:
REVOKE UNMASK ON Data.Membership(FirstName) FROM ServiceAttendant; REVOKE UNMASK ON Data.Membership FROM ServiceLead; REVOKE UNMASK ON SCHEMA::Data FROM ServiceManager; REVOKE UNMASK ON SCHEMA::Service FROM ServiceManager; REVOKE UNMASK FROM ServiceHead;