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,'abc@foo.com','12346789');

Irgendwann wird ein ETL-Prozess geschrieben, der einige Aktivitäten in der testDatenbank 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 CustomerTabelle (und schon gar nicht für die SensitiveDataSpalte) haben, daher werden diese oben ausdrücklich verweigert.

Der ETL-Prozess wird abgeschnitten, dbo.StagingTablesodass ALTERTabellenberechtigungen dafür erteilt werden.

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

Ziemlich gefährlich ...

Zusätzlich zu der offensichtlichen Berechtigung, die Struktur von sich StagingTableselbst zu ändern, ALTER TABLEkönnen sie mit der Berechtigung Trigger für die Tabelle erstellen. In diesem Fall können sie durch Verkettung der Eigentumsverhältnisse sowohl sensible Kundendaten (trotz der ausdrücklichen DENYBerechtigungen) anzeigen als auch Vandalismus an 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

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, noch ist es erforderlich, sie in eine gespeicherte Prozedur zu verpacken, die die EXECUTE ASKlausel verwendet (normalerweise gefolgt von 'dbo'oder OWNER). Die Modulsignierung 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:

• SQL-Berechtigung zum Abschneiden von Tabellen
• SQL Server TRUNCATE TABLE-Berechtigungen

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 nurALTER 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 EXECUTE ASKlausel, 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 diesen Vorgang nur über diesen Code und nur für diejenigen, denen die EXECUTEBerechtigung für diesen Code erteilt wurde. Als Schemabesitzer sind bestimmte implizite Berechtigungen zulässig, die nicht erforderlich sind. Wenn Sie EXECUTE AS 'dbo'oder verwenden EXECUTE AS OWNER(vorausgesetzt, der Eigentümer ist dbo) , erhalten Sie von diesem Zeitpunkt an den gesamten Prozessdbo Berechtigungen, nicht nur die gespeicherte Prozedur / den Trigger / die Funktion, mit der Sie gearbeitet haben EXECUTE AS. Die Modulsignatur beschränkt die Berechtigungen nur auf den von Ihnen signierten Code und nicht auf den vom signierten Code aufgerufenen Code.

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