Dynamische Datenmaskierung

Gilt für: SQL Server 2016 (13.x) und höher Azure SQL-DatenbankAzure SQL Managed InstanceAzure Synapse Analytics

Diagram of dynamic data masking.

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:

Ü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()') NULL

Beispiel 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()') NULL

Beispiel 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],suffix

Wenn 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)') NULL

Beispiel 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, serveradmin, oder db_owner verfügen auf der Datenbank standardmäßig über die Berechtigungen CONTROL und können die 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 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 von SELECT INTO oder INSERT INTO zum 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, Serveradmin, 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. 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.

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

  1. Erstellen eines Schemas für Benutzertabellen:

    CREATE SCHEMA Data;
    GO
    
  2. Erstellen 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
    );
    
  3. 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');
    
  4. Erstellen eines Schemas für Diensttabellen:

    CREATE SCHEMA Service;
    GO
    
  5. Erstellen 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
        );
    
  6. 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');
    
  7. 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;
    GO
    
  8. Erteilen 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;
    
  9. 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;
    
  10. 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;
    
  11. 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;
    
  12. 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;
    
  13. Abfragen der Daten im Kontext des ServiceHead-Benutzers

    EXECUTE AS USER = 'ServiceHead';
    
    SELECT MemberID, FirstName, LastName, Phone, Email, BirthDay
    FROM Data.Membership;
    
    SELECT MemberID, Feedback, Rating
    FROM Service.Feedback;
    
    REVERT;
    
  14. 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;