Dynamische Datenmaskierung
Gilt für:
SQL Server 2016 (13.x) und höher Azure SQL-DatenbankAzure SQL Managed InstanceAzure Synapse Analytics
Die dynamische Datenmaskierung (Dynamic Data Masking, DDM) begrenzt die Offenlegung vertraulicher Daten, indem sie für nicht privilegierte Benutzer maskiert wird. Sie kann den Entwurf und die Sicherheitscodierung in Ihrer Anwendung erheblich vereinfachen.
Die dynamische Datenmaskierung verhindert nicht autorisierten Zugriff auf vertrauliche Daten, indem Kunden angeben können, wie viele vertrauliche Daten mit minimaler Auswirkung auf die Anwendungsebene offengelegt werden sollen. 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).
Definieren einer dynamischen Datenmaske
Eine Maskierungsregel kann für eine Spalte in einer Tabelle definiert werden, um die Daten in dieser Spalte zu verschleiern. Es stehen vier Arten von Masken zur Verfügung.
| Funktion | BESCHREIBUNG | Beispiele |
|---|---|---|
| Standard | Die vollständige Maskierung gemäß der Datentypen der festgelegten Felder. Verwenden Sie XXXX für Zeichenfolgendatentypen (oder weniger), wenn die Größe des Felds 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). Verwenden Sie 1900-01-01 00:00:00.0000000 für datums- und uhrzeitdatentypen (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()') |
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 Suffixs nicht verfügbar gemacht. |
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 in umgewandelt 5XXXXXXX. Weiteres Beispiel: ALTER COLUMN [Phone Number] ADD MASKED WITH (FUNCTION = 'partial(5,"XXXXXXX",0)') Dadurch wird eine Telefonnummer wie 555.123.1234 in umgewandelt 555.1XXXXXXX. |
| Datetime | Gilt für: SQL Server 2022 (16.x) Maskierungsmethode für Spalte, die mit dem Datentyp datetime, datetime2, date, time, datetimeoffset, smalldatetime definiert ist. 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 des datetime-Werts :ALTER COLUMN BirthDay ADD MASKED WITH (FUNCTION = 'datetime("Y")')Beispiel für das Maskieren des Monats des datetime-Werts : ALTER COLUMN BirthDay ADD MASKED WITH (FUNCTION = 'datetime("M")')Beispiel für das Maskieren der Minute des datetime-Werts : ALTER COLUMN BirthDay ADD MASKED WITH (FUNCTION = 'datetime("m")') |
Berechtigungen
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.
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.
Die CONTROL-Berechtigung für die Datenbank umfasst sowohl die ALTER ANY MASK - als auch die UNMASK-Berechtigung , mit der der Benutzer unmaskierte Daten anzeigen kann. Administrative Benutzer oder Rollen wie sysadmin, serveradmin oder db_owner verfügen standardmäßig über die CONTROL-Berechtigung für die Datenbank und können nicht maskierte Daten anzeigen.
Hinweis
Die UNMASK-Berechtigung hat keinen Einfluss auf die Sichtbarkeit von Metadaten: Wenn Sie UNMASK nur erteilen, werden keine Metadaten offengelegt. UNMASK muss immer von einer SELECT-Berechtigung begleitet werden, damit sie eine Auswirkung hat. Beispiel: Das Zuweisen von UNMASK zum Datenbankbereich und von SELECT für eine einzelne Tabelle führt dazu, dass der Benutzer nur die Metadaten der einzelnen Tabelle sehen kann, aus der er auswählen kann, keine anderen. 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
SELECT INTOvon oderINSERT INTOzum Kopieren von Daten aus einer maskierten Spalte in eine andere Tabelle führt zu maskierten Daten in der Zieltabelle (vorausgesetzt, sie werden von einem Benutzer ohne UNMASK-Berechtigungen exportiert).Die dynamische Datenmaskierung wird beim Ausführen von Import- und Exportvorgängen in SQL Server angewendet. Eine Datenbank mit maskierten Spalten führt zu einer exportierten Datendatei mit maskierten Daten (vorausgesetzt, sie wird von einem Benutzer ohne UNMASK-Berechtigungen exportiert), und die importierte Datenbank enthält statisch maskierte Daten.
Abfrage für maskierte Spalten
Verwenden Sie die sys.masked_columns Ansicht, um Tabellenspalten abzufragen, auf die eine Maskierungsfunktion angewendet wurde. Diese Ansicht erbt von der sys.columns Ansicht. Es gibt alle Spalten in der sys.columns Ansicht sowie die is_masked Spalten und masking_function zurück, was angibt, ob die Spalte maskiert ist und wenn ja, welche Maskierungsfunktion definiert ist. 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 CONTROL SERVER oder CONTROL auf Datenbankebene können maskierte Daten in ihrer ursprünglichen Form anzeigen. Dies schließt Administratorbenutzer oder -rollen wie sysadmin, serveradmin, db_owner usw. ein.
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 einer MASK abhängt, 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. 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.
Wenn Sie einen Ausdruck projizieren, der auf eine Spalte verweist, für die eine Datenmaskierungsfunktion definiert ist, 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.
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 vordefinierter Abfragen beschränkt wird, die von der Anwendung verwendet werden. Die dynamische Datenmaskierung kann auch nützlich sein, um die versehentliche Offenlegung vertraulicher Daten beim direkten Zugriff auf eine Produktionsdatenbank zu verhindern, es ist jedoch wichtig zu beachten, dass nicht privilegierte Benutzer mit Ad-hoc-Abfrageberechtigungen Techniken anwenden können, um Zugriff auf die tatsächlichen Daten zu erhalten. Wenn ein solcher Ad-hoc-Zugriff gewährt werden muss, sollte die Überwachung verwendet werden, um die gesamte Datenbankaktivität zu überwachen und dieses Szenario zu entschärfen.
Betrachten Sie beispielsweise 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 letztendlich 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, wodurch letztendlich der [Salary] -Wert einer Reihe von Mitarbeitern gefolgert wird:
SELECT ID, Name, Salary FROM Employees
WHERE Salary > 99999 and Salary < 100001;
Id Name Gehalt 62543 Jana Hoffmann 0 91245 Johan Lorenz 0
Dies zeigt, dass die dynamische Datenmaskierung nicht als isoliertes Measure verwendet werden sollte, um vertrauliche Daten von Benutzern, die Ad-hoc-Abfragen für die Datenbank ausführen, vollständig zu schützen. Es ist geeignet, um versehentliche Offenlegung vertraulicher Daten zu verhindern, schützt aber nicht vor böswilliger Absicht, die zugrunde liegenden Daten abzuleiten.
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 den nicht autorisierten Zugriff auf vertrauliche Daten verhindern und die Kontrolle erlangen, indem Sie sie für einen nicht autorisierten Benutzer auf verschiedenen Ebenen der Datenbank maskieren. Sie können einem Benutzer, einer Datenbankrolle, einer Azure AD-Identität oder einer Azure AD-Gruppe die UNMASK-Berechtigung auf Datenbank-, Schema-, Tabellen- oder Spaltenebene erteilen oder widerrufen. 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 einer dynamischen 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, indem die Daten wie folgt geändert werden:
1 Roberto Tamburello 555.123.4567 RTamburello@contoso.com 10
In:
1 Rxxxxxo Tamburello xxxx RXXX@XXXX.com 91
Wobei die Zahl in DiscountCode für jedes Abfrageergebnis zufällig ist.
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 ungemaskierten Daten
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 eines dynamischen Datenformats
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;