Gibt es eine Möglichkeit, CRUD-Vorgänge für Verbindungen vom Verbindungsserver abzulehnen?

Ich habe eine SQL Server-Instanz RPT1(2008 R2), die für "Hauptbenutzer" eingerichtet wurde, um ihre eigenen Abfragen auszuführen. Dieser Server ist mit unserem Produktionsberichtsserver PRD1(SQL Server 2008-Instanz) verbunden, mit Ansichten (on RPT1), die den Verbindungsserver ( PRD1) direkt abfragen .

Der Verbindungsserver wurde mit einem Konto erstellt, für das CRUD auf dem Server erforderlich ist (für die Berichtsüberwachung usw.).

Wenn die Benutzer an Raffinesse gewinnen, fordern sie auch größere Berechtigungen an (z. B. um ihre eigenen Ansichten zu erstellen). Ich möchte sicherstellen, dass sie keine CRUD-Operationen auf dem Verbindungsserver ausführen, aber das Konto, mit dem es verknüpft wurde, verfügt über diese Berechtigungen.

Der erste Auflösungspfad, den ich sehe, besteht darin, einen anderen Benutzer mit niedrigeren Berechtigungen zu erstellen und den Server erneut zu verbinden.

Mein zweiter Weg ist zu sehen, ob es eine Möglichkeit gibt, explizit DENYCRUD auf dem PRD1Server für Verbindungen zu erstellen, die von einem Verbindungsserver kommen.

Ist es möglich, CRUD nur über den Link explizit abzulehnen? Oder sollte ich einfach den Server mit einem anderen Konto neu verbinden? Gibt es eine andere offensichtliche Lösung, die ich übersehen habe?

Haben Sie sich die Einrichtung eines serverweiten DDL-Triggers angesehen? Ich habe dies erfolgreich auf mehreren Produktionsservern verwendet, um nicht autorisierte Änderungen von Entwicklern zu blockieren. Ich bin einer Firma beigetreten, in der ALLE Entwickler vollen SA-Zugriff hatten.

Als wir versuchten, ihre Rechte zu ändern, hatten wir eine vollständige Revolution, da die Entwickler plötzlich "ihre Arbeit nicht mehr erledigen konnten". Also habe ich einen serverweiten DDL-Trigger verwendet, um die Möglichkeiten einzuschränken. Es war sehr einfach.

Ich habe eine Tabelle namens AuthorizedDDLUser erstellt, die eine sehr einfache Struktur hat:

 CREATE TABLE [dbo].[AuthorizedDDLUser](
    [Username] [nvarchar](256) NOT NULL,
    CONSTRAINT [PK_AuthorizedDDLUser] PRIMARY KEY CLUSTERED 
    (
      [Username] ASC
     )
    WITH (
           PAD_INDEX  = OFF
           , STATISTICS_NORECOMPUTE  = OFF
           , IGNORE_DUP_KEY = OFF
           , ALLOW_ROW_LOCKS  = ON
           , ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
    ) ON [PRIMARY]

  GO

Ich habe dann die Anmeldenamen der Entwickler eingefügt, die ich ändern möchte (dh das DBA-Team und Senior SQL-Entwickler).

Ich habe dann einen serverweiten DDL-Trigger erstellt, der dem folgenden ähnelt:

CREATE TRIGGER [block_ddl]
ON SERVER
FOR CREATE_PROCEDURE,ALTER_PROCEDURE, DROP_PROCEDURE, 
    CREATE_TABLE,ALTER_TABLE, DROP_TABLE, 
    CREATE_FUNCTION,ALTER_FUNCTION, DROP_FUNCTION, 
    CREATE_INDEX,ALTER_INDEX, DROP_INDEX, 
    CREATE_VIEW,ALTER_VIEW, DROP_VIEW,
    CREATE_TRIGGER,ALTER_TRIGGER, DROP_TRIGGER
AS
    IF NOT EXISTS(SELECT UserName FROM AuthorizedDDLUser WHERE UserName=CURRENT_USER)
    BEGIN
            //RAISE CUSTOM ERROR MESSAGE HERE AND ROLLBACK THE TRANSACTION 
            // ROLLING BACK EFFECTIVELY CANCELS THE DDL STATEMENT
            ROLLBACK TRANSACTION --
    END

Meine Implementierung war etwas komplizierter, ebenso wie die Prüfung. Ich versuche es hier jedoch einfach zu halten.

Kurz gesagt, Sie können selektiv einschränken, was der verknüpfte Benutzer auf dem System tun kann. Um wirklich damit zu beginnen, würde ich vorschlagen, dass Sie die folgenden Artikel lesen.

1. Verwenden eines DDL-Triggers zum Blockieren von Schemaänderungen in SQL Server: http://www.mssqltips.com/sqlservertip/2646/using-a-ddl-trigger-to-block-schema-changes-in-sql-server/
2. Überwachen von DDL-Befehlen (Erstellen, Ändern, Löschen) in SQL Server 2005: http://www.mssqltips.com/sqlservertip/1006/auditing-ddl-create-alter-drop-commands-in-sql-server-2005/
3. DDL-Ereignisliste: http://msdn.microsoft.com/en-us/ms189540.aspx
4. DDL-Trigger: http://msdn.microsoft.com/en-us/library/ms175941.aspx
5. Verwenden der EventData () - Funktion mit DDL-Triggern in SQL Server 2005: http://www.mssqltips.com/sqlservertip/1571/using-the-eventdata-function-with-ddl-triggers-in-sql-server-2005/

In meinem Fall konnten die Entwickler also so ziemlich alles tun, außer mein System durcheinander zu bringen. Schließlich haben wir sie vom SA-Zugang entwöhnt und mein Leben wurde dank DDL-Triggern wieder normal.

Ich hoffe, das hilft!

AKTUALISIEREN:

Vielen Dank an Martin Smith für den Hinweis, dass es sich um Auslöser handelt. Etwas, das ich bis jetzt nicht realisiert habe (du lernst jeden Tag). Der MSDN-Artikel ist insofern sehr verwirrend, als er angibt, dass es sich sowohl um einen Vorher- als auch einen Nachher-Trigger handelt. Ja, dies könnte ein gewisses Potenzial für Leistungsprobleme eröffnen, wenn Sie, wie Martin sagte, einen Index zurücksetzen, der auf einer ziemlich großen Tabelle basiert. Wenn Sie jedoch nur die Erstellung von Ansichten und Tabellen blockieren möchten, sollte dies in Ordnung sein.

Also mit Bedacht einsetzen.

Sie müssen dies wirklich beheben, da dies die Benutzerfreundlichkeit dieser Funktion einschränkt.