• Entwicklung/Architektur
  • Methoden
  • Programmiersprachen
• Betrieb
  • Datenbanken
  • Server
  • IT-Security
  • Speicher
  • Netzwerke
  • Virtualisierung
  • Verfügbarkeit
  • Künstliche Intelligenz
• Management und Recht
  • Projektmanagement
  • Digitalisierung
  • IT-Recht
  • IT-Selbständige
• Aktuelles
• Termine
• IT-Jobs

☰

• Entwicklung
• Betrieb
• Management und Recht
• News
• IT-Jobs
• Newsletter

William Durkin 13. September 2016

SQL Server 2016: Was ist neu? – Teil 1: Security

Row Level Security

Aber...... Es ist nicht alles Gold was glänzt

In Abb.4 sehen wir eine Tabelle mit fünf Spalten; vier davon haben eine Maskierung definiert. Es gibt, wie oben zu sehen, die Möglichkeit, die Maskierungsfunktion zu beeinflussen. Die default-Funktion zeigt eine von Microsoft definierte Standardausgabe, die für die unterstützten Datentypen automatisch angewendet wird. Zusätzlich dazu gibt es noch die Funktionen email, partial und random; bis auf random sind die Funktionen in Abb.4 zu sehen. Diese Funktionen wurden während der Betaphase von SQL Server 2016 erweitert und verbessert. Die Einschränkungen der Funktionen und unterstützte Datentypen finden Sie bei Books Online.

Sobald die Maskierung definiert wurde, werden die Daten bei einer Abfrage, so wie in Abb.4, nur bei der Anzeige verschleiert. Die Entscheidung, ob ein Benutzer die verschleierten Daten sehen darf, wird derzeit auf Datenbankebene gesteuert. Das heißt, ein Benutzer darf derzeit entweder alle verschleierten Daten in einer Datenbank sehen oder gar keine. Die Granularität der Berechtigung ist also noch nicht ganz ausgereift. Meine Hoffnung ist es jedoch, dass Microsoft bis auf Spaltenebene die Berechtigungen steuern lassen wird. Es muss sich zeigen, ob und wie Microsoft dieses Berechtigungskonzept weiterentwickelt.

Diese Maskierung greift bei allen Datenbankzugriffen, egal ob per T-SQL in SQL Server Management Studio, ob per Excel-Pivottabelle oder mit einer gewöhnlichen .Net-Applikation. Wenn die Berechtigung, die Daten zu sehen, nicht vorhanden ist, werden nur verschleierte Werte angezeigt. So können wir sicher sein, dass alle Benutzer nur die Spalteninhalte sehen können, die sie tatsächlich sehen dürfen.

Fazit

Microsoft hat mit SQL Server 2016 einige wichtige neue Funktionen eingebaut, um die Sicherheit der Dateninhalte zu erhöhen. Da Security mit mehreren Schichten aufgebaut werden muss, ist jede weitere Schicht ein wichtiger und guter Zusatz zu dem Gesamtsystem.

Wie immer in der IT-Welt sollte man aber nicht versuchen, die oben erwähnten Technologien zu nehmen und nach einem Problem zu suchen. Im Gegenteil: Man sollte lieber die Probleme im Arbeitsalltag identifizieren und dann nach einer Lösung suchen. Ein Sicherheitsproblem kann durch Row Level Security, Always Encrypted und Dynamic Data Masking gelöst werden. Desweiteren lassen sich mithilfe dieser Funktionen auch Sicherheitsprobleme lösen, die eventuell im Nachhinein auftreten könnten. Auf jeden Fall hat man durch diese drei Features gute "Werkzeuge" an der Hand, die einem helfen können, sollte es einmal zu Schwierigkeiten kommen.

Im Anhang zu diesem Artikel sind Beispiele von Row Level Security und Dynamic Data Masking verfügbar. Ein Beispiel für Always Encrypted wird von Microsoft auf GitHub mit dem "Wide World Importers"-Projekt angeboten [8].

Anhang

Folgend finden Sie Beispiele/Demonstrationen für Row Level Security und Dynamic Data Masking:

SET NOCOUNT ON
GO

-- Wir arbeiten in tempdb, weil wir nur "spielen" :)
USE tempdb
GO

-- Erst aufräumen. Hier sehen wir den neuen Befehl "DROP IF EXISTS"
DROP TABLE IF EXISTS dbo.Orders, dbo.SalesPerson
DROP USER IF EXISTS SalesNorth
DROP USER IF EXISTS SalesSouth
GO

-- Nun bauen wir unsere Testtabelle frisch auf
-- Die Tabelle wird für Demozwecken einfach gehalten
CREATE TABLE dbo.Orders
(
CustomerID INT NOT NULL,
OrderId INT NOT NULL,
ProductId INT NOT NULL,
Quantity INT NOT NULL,
Price DECIMAL(18,3) NOT NULL,
OrderDate datetime NOT NULL DEFAULT GETUTCDATE(),
AreaId INT NOT NULL
)
GO

INSERT INTO dbo.Orders
        ( CustomerID , OrderId ,  ProductId , Quantity , Price , OrderDate , AreaId )
VALUES  ( 1, 1, 4711, 1, 100.0, GETUTCDATE(), 1 ),
    ( 2, 2, 4712, 1, 200.0, GETUTCDATE(), 1 ),
    ( 3, 3, 4713, 1, 500.0, GETUTCDATE(), 2 )
GO

-- Erstelle die Vertriebssteuerungstabelle
CREATE TABLE dbo.SalesPerson
(
SalesPersonLogin NVARCHAR(25) NOT NULL,
SalesAreaId INT NOT NULL
)
GO

INSERT INTO dbo.SalesPerson
        ( SalesPersonLogin, SalesAreaId )
VALUES  ( N'SalesNorth', 1 ),
    ( N'SalesSouth', 2 )
GO

-- Erstelle nun die 2 Verkäufer (ohne Login weil wir nur testen und keine Active Directory nutzen wollen)
CREATE USER SalesNorth WITHOUT LOGIN
CREATE USER SalesSouth WITHOUT LOGIN
GO

-- Select Rechte werden nun benötigt (beachte, dass wir hier für mehrere Benutzer Rechte gleichzeitig vergeben können)
GRANT SELECT ON dbo.SalesPerson TO SalesNorth, SalesSouth
GRANT SELECT ON dbo.Orders      TO SalesNorth, SalesSouth
GO

-- Jetzt fangen wir an unsere Filterfunktion zu bauen. Die Steuerungstabelle gibt schon die Möglichkeit zu filtern
-- Wie immer bei der Entwicklung, bauen wir Stück für Stück in die richtige Richtung

-- Als erstes, mit EXECUTE AS schlüpfen wir in die Rolle des Verkäufers um die Daten so zu filtern wie wir wollen
EXECUTE AS USER= 'SalesNorth'
SELECT USER_NAME() AS WhoAmI,o.* FROM dbo.Orders o  
INNER JOIN dbo.SalesPerson sp ON sp.SalesAreaId = o.AreaId WHERE sp.SalesPersonLogin = USER_NAME()

REVERT -- Revert springt zu unserem Sysadmin konto zurück
GO

-- Mit dem zweiten Verkäufer ebenfalls testen
EXECUTE AS USER= 'SalesSouth'
SELECT USER_NAME() AS WhoAmI,o.* FROM dbo.Orders o  
INNER JOIN dbo.SalesPerson sp ON sp.SalesAreaId = o.AreaId WHERE sp.SalesPersonLogin = USER_NAME()

REVERT
GO

-- Nun wissen wir, dass wir eine richtig funktionierende Filterung haben. 
-- Jetzt wollen wir die Daten permanent filtern, ohne ein JOIN nutzen zu müssen.
-- Dazu erstellen wir eine Funktion um die Filterlogik einzurichten.

CREATE FUNCTION dbo.SalesAreaFilter ( @AreaId AS INT )
RETURNS TABLE
    WITH SCHEMABINDING
AS
RETURN
    SELECT  1 AS rowLevelPredicateResult
    FROM    dbo.SalesPerson sp
    WHERE   sp.SalesAreaId = @AreaId
            AND sp.SalesPersonLogin = USER_NAME();
GO

-- Zum Abschluss muss ein Policy erstellt werden. 
-- Der Policy wendet die zuvor erstellte Funktion auf eine Tabelle an
CREATE SECURITY POLICY OrdersFilter
ADD FILTER PREDICATE dbo.SalesAreaFilter(AreaId)
ON dbo.Orders
WITH (STATE = ON);
GO

-- Nun schlüpfen wir wieder in die Rolle des Verkäufers um zu sehen 
-- ob die Daten nun auch beim einfachen SELECT gefiltert werden
EXECUTE AS USER= 'SalesNorth'
SELECT USER_NAME() AS WhoAmI,o.* FROM dbo.Orders o  

REVERT
GO

-- Mit dem zweiten Verkäufer ebenfalls testen
EXECUTE AS USER= 'SalesSouth'
SELECT USER_NAME() AS WhoAmI,o.* FROM dbo.Orders o  

REVERT
GO


-- ERFOLG!!

-- Allerdings müssen wir wieder aufpassen.
-- Als erste Nebeneffekt, werden Orders auch für uns als Sysadmin gefiltert
SELECT USER_NAME() AS WhoAmI  
SELECT USER_NAME() AS WhoAmI,o.* FROM dbo.Orders o  
GO

-- Das kann eine gewollte Situation sein. Als Sysadmin sind wir für den 
-- Datenbankserverbetrieb zuständig, nicht aber die Verkäufe
-- Falls wir dennoch Zugriff auf die Rohdaten benötigen, müssen wir die Filterfunktion 
-- anpassen um unser User immer Zugriff zu gewähren

-- Alles wegschmeißen und mit Sysadmin Ausnahme wieder aufbauen
DROP SECURITY POLICY IF EXISTS  dbo.OrdersFilter
DROP FUNCTION IF EXISTS dbo.SalesAreaFilter 
GO

CREATE FUNCTION dbo.SalesAreaFilter ( @AreaId AS INT )
RETURNS TABLE
    WITH SCHEMABINDING
AS
RETURN
    SELECT  1 AS rowLevelPredicateResult
    FROM    dbo.SalesPerson sp
    WHERE   USER_NAME() = 'dbo' -- GOD MODE
            OR ( sp.SalesAreaId = @AreaId
                 AND sp.SalesPersonLogin = USER_NAME()
               );
GO

CREATE SECURITY POLICY OrdersFilter
ADD FILTER PREDICATE dbo.SalesAreaFilter(AreaId)
ON dbo.Orders
WITH (STATE = ON);
GO

-- Ein letztes Mal alles testen
EXECUTE AS USER= 'SalesNorth'
SELECT USER_NAME() AS WhoAmI,o.* FROM dbo.Orders o  

REVERT
GO

-- Mit dem zweiten Verkäufer ebenfalls testen
EXECUTE AS USER= 'SalesSouth'
SELECT USER_NAME() AS WhoAmI,o.* FROM dbo.Orders o  

REVERT
GO

-- Nun sehen wir als Sysadmin wieder alles :)
SELECT USER_NAME() AS WhoAmI,o.* FROM dbo.Orders o  
GO
  

USE tempdb
GO

-- Aufräumen
DROP TABLE IF EXISTS dbo.MaskedTable;
DROP USER  IF EXISTS ZeroCool
GO

-- Man achte auf die zusätzlichen Angaben "MASKED WITH....."
-- So können die Verschleierungsoptionen gesteuert werden.
CREATE TABLE dbo.MaskedTable
       (
         Col1 INT NOT NULL PRIMARY KEY CLUSTERED,
         Col2 VARCHAR(255) MASKED WITH (FUNCTION = 'default()'),
     Col3 VARCHAR(255) MASKED WITH (FUNCTION = 'email()'),
     Col4 INT       MASKED WITH (FUNCTION = 'default()'),
     Col5 VARCHAR(255) MASKED WITH (FUNCTION = 'partial(5,"XXXXXXX",0)')
       );
GO
INSERT INTO dbo.MaskedTable
        ( Col1, Col2, Col3, Col4, Col5 )
VALUES  ( 1, 'Testdata for DDM', 'Test@Test.com', 100, 'More test data' ),
    ( 2, 'Mess with the best, die like the rest', 'zerocool@acidburn.com' , 200 , 'pool on the roof must have a leak' )

-- Als Sysadmin *und* Tabellenersteller, dürfen wir alle Daten sehen
SELECT  USER_NAME() AS WhoAmI,*
FROM    dbo.MaskedTable
GO

-- Testuser erstellen
CREATE USER ZeroCool WITHOUT LOGIN
GO
-- SELECT auf die Testtabelle zulassen
GRANT SELECT ON dbo.MaskedTable TO ZeroCool
GO

-- Tabelle als Testuser abfragen, wir sollten verschleierte Daten sehen
EXECUTE AS USER = 'ZeroCool'
SELECT USER_NAME() AS WhoAmI,
     Col1, -- int
     Col2, -- varchar + default()
     Col3, -- varchar + email()
     Col4, -- int     + default()
     Col5  -- varchar + partial(5,"XXXXXXX",0)
FROM dbo.MaskedTable
REVERT

-- Nun unser Testuser das Recht geben verschleierte Daten zu sehen
GRANT UNMASK TO ZeroCool  -- << UNMASK wird auf Datenbankebene gesetzt und (noch) nicht auf Tabelle oder Spaltenebene
GO

-- Jetzt sind die Daten sichtbar
EXECUTE AS USER = 'ZeroCool'
SELECT USER_NAME() AS WhoAmI,* FROM MaskedTable
REVERT
GO

-- Und jetzt nehmen wir das Recht wieder weg
REVOKE UNMASK TO ZeroCool
GO




-- Können wir die Daten auch ohne Rechte einsehen?
EXECUTE AS USER = 'ZeroCool'
SELECT  USER_NAME() AS WhoAmI,
        CAST(Col2 AS int) -- Col2 ist kein INT, ein CAST wird fehlschlagen. Beim Beta-Release wurden die Daten unverschleiert als Fehler ausgegeben
FROM    dbo.MaskedTable
REVERT

-- Wie ist es wenn wir die Daten in eine andere Tabelle "exportieren"?
EXECUTE AS USER = 'ZeroCool'
SELECT  USER_NAME() AS WhoAmI,
    Col1,
        Col2,
        Col3,
    Col4,
    Col5
INTO dbo.MaskedTableDump
FROM    dbo.MaskedTable


-- Hmmm, wir dürfen in ein Userdatenbank keine Tabelle anlegen :( 


SELECT  USER_NAME() AS WhoAmI,
    Col1,
        Col2,
        Col3,
    Col4,
    Col5
INTO #MaskedTableDump -- Aber Jeder darf Temp-Tabellen in tempdb erstellen!!! :)
FROM    dbo.MaskedTable

-- Jetzt die Temp-Tabelle auslesen. (Bei Release Candidate 2 wurde dieses Schlüpfloch geschlossen)
SELECT * FROM #MaskedTableDump 


-- Wenn wir wissen welche Datentypen die Tabelle hat, können wir aber mit Systemfunktionen teilweise
-- an die Daten kommen. Dynamic Data Masking ist also (noch) nicht perfekt!
-- Col4 
SELECT  USER_NAME() AS WhoAmI,
    SQRT(SQUARE(Col4)),    -- SQRT(SQUARE()) liefert die richtigen Daten
    EXP(LOG(Col4)),      -- EXP(LOG()) liefert (fast) die richtigen Daten
    Col4          -- Col4 wird noch als 0 (also maskiert) dargestellt
FROM    dbo.MaskedTable
REVERT
GO
  

Autor

Das könnte Sie auch interessieren