it-swarm.com.de

Wie gefährlich ist die Erteilung der ALTER TABLE-Berechtigung?

Stellen Sie sich das folgende Szenario vor

CREATE DATABASE test

GO

USE test;    

CREATE TABLE dbo.Customer
  (
     CustomerId   INT,
     Email        VARCHAR(100),
     SensitiveData VARCHAR(20)
  );

INSERT INTO dbo.Customer
VALUES     (1,'[email protected]','12346789');

Irgendwann wird ein ETL-Prozess geschrieben, der einige Aktivitäten in der Datenbank test ausführt.

CREATE USER etlUser WITHOUT LOGIN; /*For demo purposes*/

CREATE TABLE dbo.StagingTable
  (
     StagingTableId INT,
     SomeData       VARCHAR(100),
  )

GRANT UPDATE,INSERT,DELETE,SELECT,ALTER ON dbo.StagingTable TO etlUser;

DENY SELECT ON dbo.Customer TO etlUser;
DENY SELECT ON dbo.Customer (SensitiveData) TO etlUser; /*For good measure*/

Der etlUser sollte keine Berechtigungen für die Tabelle Customer haben (und schon gar nicht für die Spalte SensitiveData), daher werden diese oben explizit verweigert.

Der ETL-Prozess schneidet dbo.StagingTable so werden ALTER Tabellenberechtigungen dazu gegeben.

Dies wird während einer Sicherheitsüberprüfung markiert. Wie gefährlich ist dieses Szenario?

11
Martin Smith

Ziemlich gefährlich ...

Zusätzlich zu der offensichtlichen Berechtigung, die Struktur von StagingTable selbst zu ändern, können sie mit der Berechtigung ALTER TABLE Trigger für die Tabelle erstellen. In diesem Fall können sie durch Verkettung von Eigentumsrechten sowohl vertrauliche Kundendaten anzeigen (trotz der expliziten Berechtigungen DENY) als auch Vandalismus in dieser zweiten Tabelle ausführen.

EXECUTE AS user='etlUser'

GO

CREATE OR ALTER TRIGGER TR ON dbo.StagingTable AFTER UPDATE AS 
/*Exposure of sensitive data*/
SELECT * FROM dbo.Customer;

/*Vandalism*/
DELETE FROM dbo.Customer;

go

--Fire the trigger
UPDATE dbo.StagingTable SET SomeData = SomeData WHERE 1=0;

REVERT
16
Martin Smith

Die Berechtigung ALTER TABLE ermöglicht nicht nur das Hinzufügen von Triggern, sondern auch Folgendes:

  1. Trigger deaktivieren (Audit Trail vermeiden)
  2. Deaktivieren Sie Einschränkungen (unter Berücksichtigung fehlerhafter Daten).
  3. Ändern von Einschränkungen (unter Berücksichtigung schlechter Daten)
  4. Ändern der Spaltendefinitionen (Ändern des Datentyps, der maximalen Größe, der NULL-Fähigkeit)
  5. Fügen Sie eine berechnete Spalte hinzu, die eine T-SQL-UDF aufruft (was es sehr schwierig macht, einen parallelen Plan zu erhalten, was die Leistung leicht beeinträchtigen könnte).

Es ermöglicht auch das Entfernen von Spalten, aber das wird wahrscheinlich nicht unbemerkt bleiben (da wir hier anscheinend nach potenziellen Aktionen suchen, die eher täuschen als böswillig sind).

Glücklicherweise ist es niemals erforderlich, diese Berechtigung jemandem zu erteilen oder sie in eine gespeicherte Prozedur zu verpacken, die die Klausel EXECUTE AS Verwendet (normalerweise gefolgt von 'dbo' Oder OWNER). Module Signing ermöglicht die einfache Abstraktion privilegierter Aktionen hinter signiertem Code (gespeicherte Prozeduren, Trigger, skalare UDFs und TVFs mit mehreren Anweisungen). Ich habe Beispielcode, der zeigt, wie dies in den folgenden Antworten hier auf DBA.SE erreicht werden kann:

Der Unterschied zwischen diesen beiden Antworten besteht in der Berechtigung, die dem signaturbasierten Benutzer erteilt wurde. Die zu erteilende Berechtigung (oder die hinzuzufügende DB-Rolle) hängt vom Umfang der erforderlichen Aufgaben ab. Wenn Sie nur die Berechtigung für eine einzelne Tabelle benötigen, gewähren Sie nur ALTER für diese Tabelle. Wenn für alle Tabellen in einem bestimmten Schema eine Berechtigung erforderlich ist, erteilen Sie einzelnen Tabellen keine Berechtigung, sondern erteilen Sie dem Schema selbst die Berechtigung. Und so weiter.

Das Signieren von Modulen ist ein paar zusätzliche Schritte im Vergleich zum Erstellen eines Schemas speziell für den ETL-Benutzer oder zum Verwenden der Klausel EXECUTE AS, Aber:

  1. es ist wirklich nur ein einfaches Kopieren und Einfügen, da der Code in beiden oben verlinkten Antworten und verfügbar ist
  2. es ist sicherlich die sicherste verfügbare Option. Es erlaubt diese Operation nur über diesen Code und nur für diejenigen, denen die Berechtigung EXECUTE für diesen Code erteilt wurde. Als Schemabesitzer sind bestimmte implizite Berechtigungen zulässig, die nicht erforderlich sind. Wenn Sie EXECUTE AS 'dbo' Oder EXECUTE AS OWNER Verwenden (vorausgesetzt, der Eigentümer ist dbo), erhalten Sie den gesamten Prozess , ab diesem Zeitpunkt dbo Berechtigungen, nicht nur die gespeicherte Prozedur/Trigger/Funktion, mit der Sie EXECUTE AS verwendet haben. Die Modulsignatur beschränkt die Berechtigungen nur auf den von Ihnen signierten Code und nicht auf den vom signierten Code aufgerufenen Code.
8
Solomon Rutzky

Eine bessere Vorgehensweise wäre, ein Staging-Schema zu erstellen, das dem ETL-Benutzer gehört. Anschließend kann der ETL-Prozess Tabellen abschneiden, Einschränkungen deaktivieren, Partitionswechsel durchführen usw. innerhalb des Staging-Schemas. Der ETL-Benutzer würde nur eine eingeschränkte Berechtigung für die anderen Schemas benötigen.

Sie können auch eine Datenbankrolle anstelle eines einzelnen Benutzers verwenden.

Natürlich können Sie Ihrem eingeschränkten Benutzer auch ermöglichen, Tabellenkürzungen mit einer im Besitz von dbo befindlichen gespeicherten Prozedur wie folgt durchzuführen:

create procedure truncate_t 
with execute as owner
as
begin
  truncate table t;
end