it-swarm.com.de

Verwendung von IMPERSONATE-Berechtigungen in SQL Server?

Während einiger Lektüre lernte ich die Berechtigungen zum Identitätswechsel kennen. Nach dem, was ich gelesen habe, ist es eher so, als würde man eine Kopie des Benutzers mit allen Berechtigungsstufen unter einem anderen Namen erstellen. Ich verstehe, dass dies zum Ausführen von Abfragen unter einem anderen Login verwendet werden kann, aber letztendlich welchen Zweck erfüllt es?

Warum wurde diese Funktion eingeführt?

5
karun_r

Persönlich verwende ich Identitätswechsel für drei Hauptkategorien von Aufgaben.

Testen Wenn ich testen muss, welchen Zugriff jemand hat, kann ich mich als dieser ausgeben, die Aufgabe ausprobieren und prüfen, ob sie funktioniert. Dies ist besonders nützlich, wenn ich Berechtigungen erteilt habe, der Benutzer mir jedoch weiterhin mitteilt, dass er eine bestimmte Aufgabe nicht ausführen kann.

Sammeln von Informationen Es gibt eine Reihe von Systemansichten/-funktionen, die Ihnen Informationen zu den Berechtigungen der Verbindungsprinzipien geben (sogar einige AD-Informationen). Wenn ich mich beispielsweise als Datenbankprinzipal (Benutzer) ausführe und sys.user_token abfrage, kann ich eine Liste aller AD-Gruppen abrufen, zu denen sie gehören, und welche ihnen Zugriff auf die aktuelle Datenbank gewähren.

Zugriff auf eine Aufgabe gewähren, ohne die Berechtigung zu erteilen Ein spezielles Beispiel hierfür ist die Möglichkeit, eine Tabelle abzuschneiden. Um eine Tabelle abzuschneiden, müssen Sie über die Berechtigung ALTER für die Tabelle verfügen. Ich möchte, dass einige diese Tabelle abschneiden, aber ich möchte nicht riskieren, dass sie Änderungen daran vornehmen.

  1. Erstellen Sie einen Datenbankprinzipal (Benutzer), der Änderungen an der Tabelle vorgenommen hat
  2. Erstellen Sie eine gespeicherte Prozedur, die TRUNCATE ausführt und EXECUTE AS Verwendet, um zu bewirken, dass SP] als der von mir erstellte Benutzer ausgeführt wird.
  3. Gewähren Sie Ausführungsberechtigungen für die gespeicherte Prozedur.

Sie können diese Technik sogar verwenden, um Berechtigungen auf Sysadmin-Ebene zu erteilen, obwohl sie ihre eigenen Schwierigkeiten und Risiken hat.

Bearbeiten:

Ich kann zwei mögliche Gründe sehen, warum Sie jemandem Identitätsrechte gewähren könnten.

Anwendungsberechtigungen von Direktzugriffsberechtigungen trennen

Für ApplicationA muss Benutzer Joe Zugriff haben, um aus einer beliebigen Tabelle lesen zu können. Im Rahmen von Joes Verantwortung muss er jedoch auch eine Statustabelle aktualisieren, falls etwas neu geschrieben werden muss. Durch Erteilen von Aktualisierungsberechtigungen für Benutzer UpdatePerms und Gewähren des Zugriffs von Joe auf ihn kann er sich bei SSMS anmelden, sich als dieser Benutzer ausgeben und die Tabelle aktualisieren. Dies bedeutet, dass er keinen Update-Zugriff über die Anwendung hat, diese gelegentliche Aufgabe jedoch ausführen kann.

Benötige zusätzliche Gedanken/Handlungen, bevor du eine Aufgabe ausführst

Ähnlich wie oben. Joe muss in der Lage sein, Zeilen aus einer Tabelle zu löschen, aber Sie möchten nicht, dass er dies versehentlich tut (oder es zumindest schwieriger macht). Da er sich vor dem Löschen als ein anderer Benutzer ausgeben muss, muss er zumindest etwas schwieriger darüber nachdenken, damit es weniger wahrscheinlich ist, dass es versehentlich passiert.

Hinweis: Ich musste in der Produktion noch nie eines davon machen. Es scheint nur logische Möglichkeiten.

6
Kenneth Fisher

Möglicherweise möchten Sie einem Benutzer erlauben, einen erweiterten gespeicherten Prozess oder eine andere privilegierte Operation auszuführen, jedoch nur unter bestimmten Umständen.

Schreiben Sie eine gespeicherte Prozedur, die EXECUTE AS enthält, die die privilegierte Operation ausführt, und erteilen Sie dem Benutzer dann Berechtigungen für diese gespeicherte Prozedur. Auf diese Weise können sie diese privilegierte Operation nur im Kontext dieser gespeicherten Prozedur ausführen, die Sie geschrieben haben, um eine streng eingeschränkte Operation auszuführen.

3
R Evans

Zusätzlich zu dem, was bereits in den beiden anderen Antworten (von @KennethFisher und @REvans) gesagt wurde, erlaubt die Berechtigung IMPERSONATE auch einem Benutzer, der sich weder in der Datenbankrolle dbo noch in der Datenbankrolle sysadmin Serverrolle Die Möglichkeit, die Eigenschaft AUTHORIZATION eines Objekts (eines, das diese Eigenschaft hat, nicht alle) für einen anderen Benutzer als sich selbst festzulegen. Zum Beispiel:

CREATE Assembly [AnnoyTsqlPurists]
  AUTHORIZATION [SomeoneElse]
  FROM 0x4D59.........................;

Um zu klären/zu ändern, was die anderen bezüglich der eingeschränkten Erhöhung von Berechtigungen über EXECUTE AS Gesagt haben, sollte beachtet werden, dass EXECUTE AS Nicht erforderlich ist, solche Dinge zu tun, zumindest nicht mehr. Während die Verwendung von EXECUTE AS Der einfachere Weg ist, kann ein Benutzer oder Login nicht als anderer Benutzer oder Login fungieren, sondern nicht den Kontext steuern, in dem EXECUTE AS Ausgegeben werden kann. Nehmen Sie das Beispiel, dass User_AIMPERSONATE User_B Gewährt wird, um so etwas wie TRUNCATE TABLE Ausführen zu können, und dann EXECUTE für eine gespeicherte Prozedur gewährt wird das enthält sowohl die Anweisungen EXECUTE AS User = 'User_B'; als auch TRUNCATE TABLE. Das funktioniert. Es verhindert jedoch nicht, dass User_AEXECUTE AS User = 'User_B'; Ausführt, wann immer sie möchten, auch außerhalb dieser bestimmten gespeicherten Prozedur. Und wenn Sie jemandem eine allgemeinere Erlaubnis geben müssen, wie z. B. VIEW SERVER STATE, Kann er sich als dieser "erhöhte" Benutzer ausgeben, um diese erhöhte Erlaubnis außerhalb der wahrscheinlich beabsichtigten viel engeren gewünschten Anwendung dieser Erlaubnis zu verwenden B. Daten von einer bestimmten DMV abrufen, nicht alle DMVs, für die diese Berechtigung erforderlich ist.

Glücklicherweise gibt es einen Mechanismus, der es ermöglicht, sehr granular und explizit zu sein, wenn nicht privilegierten Benutzern erlaubt/benötigt wird, "Sachen" auf höherer Ebene zu machen: Modul Unterzeichnung. Mit diesem Ansatz richten Sie einen Login und/oder Benutzer (Asymmetric Key-based oder Certificate-based) ein, der die gewünschten Berechtigungen enthält , aber Dieser Login und/oder Benutzer kann nicht verkörpert werden, da er sich nicht anmelden kann. Anschließend ordnen Sie den Login und/oder Benutzer über ADD SIGNATURE Einem oder mehreren Modulen (gespeicherte Prozedur, Funktion (außer Inline-TVF), Trigger oder Assembly) zu. Gewähren Sie den nicht privilegierten Benutzern schließlich EXECUTE für die Module. Jetzt haben die nicht privilegierten Benutzer keinen Zugriff auf die Quelle der erhöhten Berechtigungen.

Weitere Details finden Sie in meinen folgenden zwei Antworten (und deren Links zu noch mehr Antworten), ebenfalls hier auf DBA.SE:

2
Solomon Rutzky