Verweigern Sie den Zugriff auf das Informationsschema in SQL Server


13

Ich suche nach der besten Möglichkeit, den Zugriff auf sys.tables/ Information Schemafür einen Benutzer / eine Gruppe in SQL Server zu deaktivieren .

Ich habe diesen Thread von 2008 gefunden

Es zeigt einen Weg, wie man den Zugriff auf [sys].[something]so verweigert :

 DENY SELECT ON [sys].[columns] TO DenySystemTableSelectRole
 GO
 DENY SELECT ON [sys].[tables] TO DenySystemTableSelectRole
 GO
 DENY SELECT ON [sys].[syscolumns] TO DenySystemTableSelectRole
 GO
 DENY SELECT ON [sys].[sysobjects] TO DenySystemTableSelectRole
 GO

Aber keine Möglichkeit, den Zugriff auf die zu deaktivieren Information Schema:

DENY SELECT ON INFORMATION_SCHEMA.TABLES To DenySystemTableSelectRole

Das scheint nicht zu funktionieren.

Wie kann ich den Zugriff auf information_schema deaktivieren?

Und gibt es eine einfachere Möglichkeit, den Zugriff auf alle sys/ zu deaktivieren information_schema?

Update: Eigentlich kann ich nicht beide der folgenden Anweisungen ausführen:

DENY SELECT ON [sys] TO reducedDBO
GO
DENY SELECT ON INFORMATION_SCHEMA To reducedDBO
GO

Ich habe versucht, sie auf der spezifischen Datenbank auszuführen, auf der der Benutzer vorhanden ist, und ich habe auch versucht, sie auf dem "Master" auszuführen.

Ich kann immer noch rennen:

 SELECT * from
 INFORMATION_SCHEMA.TABLES 

-> liefert weiterhin Ergebnisse

 SELECT * from
 sys.TABLES 

-> keine Ergebnisse mehr

Das Einbeziehen SCHEMA::in die Abfrage ermöglichte das Erstellen der Sicherheitselemente

DENY SELECT ON SCHEMA::[sys] TO reducedDBO
GO
DENY SELECT ON SCHEMA::INFORMATION_SCHEMA To reducedDBO
GO

Aber jetzt kann ich noch alle Informationen aus der DB auswählen.

Ich habe mir die Registerkarte "Securables" im Eigenschaftsfenster des Benutzers in Management Studio 2008 angesehen. Sie sieht folgendermaßen aus:

Eintrag, der die Auswahl von sys.tables blockiert

Schema: sys, Name: tables, Typ: View

Berechtigungen für sys.tables: Berechtigung: Auswählen, Erteiler: dbo, Verweigern ist aktiviert

Eintrag, der keine Auswahl blockiert

Schema :, Name: INFORMATION_SCHEMA, Typ: Schema

Berechtigungen für INFORMATION_SCHEMA: Berechtigung: Auswählen, Erteiler: dbo, Verweigern ist NICHT aktiviert (Ich habe versucht, dies zu überprüfen, aber keine Chance.)

Berechtigung: Auswählen, Erteiler: INFORMATION_SCHEMA, Verweigern ist aktiviert


Ich habe versucht, die Berechtigungen über die GUI festzulegen, aber dann erhalte ich den gleichen Fehler, dass das Festlegen von Berechtigungen nur für die Master-DB möglich wäre. Ich habe jedoch nicht den Benutzer / Login zur Sicherheit der Master-DB hinzugefügt.

Lösung:

Die einzige Möglichkeit, die denyArbeit für die information_schemazu erledigen, bestand darin , den Benutzer zur master-db hinzuzufügen und die deny selectauf dem master auszuführen :

DENY SELECT ON [sys].[tables] TO reducedDBO
GO
DENY SELECT ON INFORMATION_SCHEMA.TABLES To reducedDBO
GO

Und wie in diesem Code kann es nur für einzelne Tabellen ausgeführt werden.



Ja Danke. Tatsächlich besteht der Unterschied zwischen dem Ablehnen der [Informationsschema] -Ansichten und der [Sys] -Ansichten darin, dass das [Informationsschema] auf dem Master deaktiviert werden muss (und es wirkt sich auf alle DBs aus), wohingegen die [Sys] -Ansicht deaktiviert werden muss jede db selbst, und selbst wenn sie auf dem master deaktiviert ist, kann der benutzer immer noch aus der ansicht auswählen, wenn sie nicht auch auf der aktuellen db deaktiviert ist.
SwissCoder

Antworten:


10

Sie sollten in der Lage sein, Berechtigungen für das gesamte Schema sysund das gesamte information_schemaSchema zu verweigern :

DENY SELECT On SCHEMA::sys To [user_name]
DENY SELECT On SCHEMA::INFORMATION_SCHEMA To [user_name]

Dies sollte im Grunde nur verhindern, dass der Benutzer in diesen beiden Schemata Auswahlen vornimmt.


als Antwort markiert, aber die Sache ist die SCHEMA :: hat nicht geholfen, besser wieder entfernen. Die Lösung besteht darin, den Benutzer zur Masterdatenbank hinzuzufügen und dann das Verweigerungsskript auf dem Master auszuführen. Danke für deine Hilfe!
SwissCoder

Ach ja und eigentlich ist es mir auch nicht möglich das ganze SCHEMA zu deaktivieren, nur der Zugriff auf einzelne Tabellen kann so deaktiviert werden.
SwissCoder

5

Erstens haben Sie insofern Recht, als die (leicht kontraintuitive) Möglichkeit, den Zugriff auf die Schemas [sys] und [INFORMATION_SCHEMA] zu verhindern, darin besteht, zunächst sicherzustellen, dass die Anmeldung (also Prinzipal auf Serverebene) als Benutzer (erm, Principal auf Datenbankebene) in der master-Datenbank.

Angenommen, Sie haben der Einfachheit halber eine SQL-Anmeldung:

CREATE LOGIN [testy] WITH PASSWORD=N'SCoBIqlJELGzrY9zYsKWC5z3kHtMsyCAP6yBHLUYQ0w='
go

Legen Sie nun einen entsprechenden Benutzer in der Master-Datenbank an:

use [master]
go
CREATE USER [testy] FOR LOGIN [testy]
go

Jetzt möchten Sie verhindern, dass diese Anmeldung auf eine der Tabellen in den vom System bereitgestellten Schemata zugreift - [sys] und [INFORMATION_SCHEMA].

Offenbar gab es eine Verhaltensänderung zwischen SQL Server 2008 R2 und SQL Server 2012:

In SQL Server 2012 (und vermutlich in späteren Versionen) funktioniert das Ausführen der folgenden Befehle in der [master] -Datenbank wie erwartet:

DENY SELECT, VIEW DEFINITION ON SCHEMA::[sys] to [testy];
GO
DENY SELECT, VIEW DEFINITION ON SCHEMA::[INFORMATION_SCHEMA] to [testy];
GO

In SQL Server 2008 R2 (und vermutlich in früheren Versionen) scheinen die Stock Grant-Anweisungen, die Mitgliedern von [public] Zugriff auf Objekte in diesen Schemata gewähren, die obigen DENY-Anweisungen zu überschreiben, was für mich wie ein riesiger Haufen von Fehlern erscheint. Folglich müssen Sie auf 2008 R2 [öffentlich] für jede GEWÄHRUNG ausdrücklich VERWEIGERN. Hier ist ein Skript, um das zu tun:

declare
    @database_principal sysname,
    @cur cursor,
    @sql nvarchar( 4000 );

set @database_principal = 'testy';

set @cur = cursor local forward_only static for
    select 
        'DENY ' +
        permission_name + ' on ' +
        case class 
            when 1 then
                case minor_id
                    when 0 then 'OBJECT'
                    else 'COLUMN'
                end
            else
                class_desc
        end + '::' +
        case class
            when 0 then db_name()
            when 1 then quotename( OBJECT_SCHEMA_NAME(major_id) ) + '.' + quotename( object_name( major_id ) ) + case minor_id when 0 then '' else ( select '.' + quotename( name ) collate database_default from sys.columns where column_id=minor_id) end
            when 3 then schema_name( major_id )
        end + ' to ' +
        quotename( @database_principal )
    from
        sys.database_permissions
    where
        [grantee_principal_id] = 0 -- public
        and
        [state_desc] = 'GRANT'
        and
        [permission_name] = 'SELECT'
;

open @cur;

while
    1 = 1
begin
    fetch @cur into @sql;
    if @@fetch_status <> 0 break;

    print @sql;
    exec sys.sp_executesql @sql;
end;

close @cur;

deallocate @cur;

Führen Sie das Obige in der master-Datenbank aus, und Sie haben den Zugriff auf den Inhalt dieser Schemas entfernt.

Anmerkungen:

  1. Da es sich um explizite DENY-Anweisungen handelt, sind sie zum Zeitpunkt der Ausführung des Skripts korrekt. Wenn später jemand die öffentlichen Berechtigungen ändert (z. B. wenn ein Service Pack eine neue Systemtabelle erstellt), wird dies dem verweigerten Benutzer angezeigt
  2. Es ist eine gute Idee, eine Datenbankrolle als Ziel der DENY-Anweisungen zu verwenden und die abgelehnten Benutzer in diese Rolle zu versetzen.
  3. Sie können dies rückgängig machen, indem Sie DENY in REVOKE ändern
  4. Wenn Sie im obigen Skript die folgenden zwei Zeilen auskommentieren:

        and
        [permission_name] = 'SELECT'

    Dies hat zur Folge, dass ALLE Standard-GRANTs für die Öffentlichkeit rückgängig gemacht werden. Dies verhindert den Zugriff auf z. B. sys.sp_tables und unterbricht so die Fähigkeit von z. B. Microsoft Access, die Tabellen überhaupt aufzulisten. In Szenarien mit hoher Sicherheit ist es jedoch nützlich, dies zu tun, damit die Benutzer nur Zugriff erhalten, wenn Sie dies ausdrücklich gewährt haben es.


3

Ich bin mir nicht sicher, wann dieser Trick verfügbar wurde - da niemand ihn erwähnt hat -, aber es scheint, dass er mindestens seit SQL Server 2008 funktioniert.

DENY VIEW DEFINITION to [database-role / database-user];

Das oben Genannte funktioniert, ohne dass der Benutzer der masterDatenbank hinzugefügt werden muss, wie in einigen anderen Antworten erwähnt.


Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.