Active Directory Admins Zugriff verweigern

[McKloony 10]

Bei einem SQL 2012 habe ich ein Script geschrieben, welches einer Datenbank einen Admin User und einen Standard User hinzufügt. Dem Admin User werden alle Rollen entzogen, die ihm ermöglichen, eine SELECT Anweisung auf Datensätze auszuführen. Er soll diese ja nicht sehen, sondern nur arbeiten am Sever und der Struktur der Datenbank durchführen. Der Standard User soll dagegen mit den Daten arbeiten können, also Lesen und Schreiben aber selber keine administrativen Änderungen durchführen können.

USER MASTER
GO


DROP PROCEDURE USP_CREATE_LOGIN_STANDARD
GO


DROP PROCEDURE USP_CREATE_LOGIN_ADMIN
GO



CREATE PROCEDURE USP_CREATE_LOGIN_STANDARD (
	@DefaultDatabase nvarchar(50),
	@LoginName nvarchar(50),
	@LoginPassword nvarchar(50),
	@DefaultSchema nvarchar(50),
	@User nvarchar(50)) AS
BEGIN
	SET NOCOUNT ON

	DECLARE @SQL nvarchar(max)

	SET @SQL =  
		'IF NOT EXISTS (SELECT name FROM sys.syslogins WHERE name = ''' + @LoginName + ''')' +
		'BEGIN ' +
			'USE master; ' + 
			'CREATE LOGIN ' + @LoginName + ' WITH PASSWORD = ''' + @LoginPassword + ''', DEFAULT_DATABASE = ' + @DefaultDatabase + ', CHECK_EXPIRATION = OFF, CHECK_POLICY = OFF; ' +
			'PRINT(''New login ''''' + @LoginName + ''''' has been successfully created.'')' +
		'END ' +
		'ELSE ' +
		'BEGIN ' +
			'PRINT(''Login ''''' + @LoginName + ''''' already exists!!!'')' +
		'END'

	EXECUTE (@SQL)

	SET @SQL =  
		'USE ' + @DefaultDatabase + '; ' + 
		'IF NOT EXISTS (SELECT name FROM sys.sysusers WHERE name = ''' + @User + ''')' +
		'BEGIN ' +			
			'CREATE USER ' + @User + ' FOR LOGIN ' + @LoginName + '; ' +	
			'PRINT(''New user ''''' + @User + ''''' has been successfully created.'')' +
		'END ' + 		
		'ALTER USER ' + @User + ' WITH DEFAULT_SCHEMA = ' + @DefaultSchema + '; ' +
		
		'EXEC sp_droprolemember  ''db_accessadmin'', ' + @User + '; ' +
		'EXEC sp_droprolemember  ''db_backupoperator'', ' + @User + '; ' +
		'EXEC sp_droprolemember  ''db_datareader'', ' + @User + '; ' +
		'EXEC sp_droprolemember  ''db_datawriter'', ' + @User + '; ' +
		'EXEC sp_droprolemember  ''db_ddladmin'', ' + @User + '; ' +
		'EXEC sp_droprolemember  ''db_denydatareader'', ' + @User + '; ' +
		'EXEC sp_droprolemember  ''db_denydatawriter'', ' + @User + '; ' +
		'EXEC sp_droprolemember  ''db_owner'', ' + @User + '; ' +
		'EXEC sp_droprolemember  ''db_securityadmin'', ' + @User + '; ' +

		'EXEC sp_addrolemember  ''db_owner'', ' + @User + '; ' +
		'EXEC sp_addrolemember  ''db_datareader'', ' + @User + '; ' +
		'EXEC sp_addrolemember  ''db_datawriter'', ' + @User + '; ' +

		'PRINT(''Privileges for user ''''' + @User + ''''' altered!!!'')' 
	
	EXECUTE (@SQL)
END
GO



CREATE PROCEDURE USP_CREATE_LOGIN_ADMIN (
	@DefaultDatabase nvarchar(50), 
	@LoginName nvarchar(50), 
	@LoginPassword nvarchar(50),
	@DefaultSchema nvarchar(50),
	@User nvarchar(50)) AS
BEGIN
	SET NOCOUNT ON;
 
	DECLARE @SQL nvarchar(max)

	SET @SQL =  
		'IF NOT EXISTS (SELECT name FROM sys.syslogins WHERE name = ''' + @LoginName + ''')' +
		'BEGIN ' +
			'USE master; ' + 
			'CREATE LOGIN ' + @LoginName + ' WITH PASSWORD = ''' + @LoginPassword + ''', DEFAULT_DATABASE = ' + @DefaultDatabase + ', CHECK_EXPIRATION = OFF, CHECK_POLICY = OFF; ' +
			'PRINT(''New login ''''' + @LoginName + ''''' has been successfully created.'')' +
		'END ' +
		'ELSE ' +
		'BEGIN ' +
			'PRINT(''Login ''''' + @LoginName + ''''' already exists!!!'')' +
		'END'

	EXECUTE (@SQL)

	SET @SQL = 
		'USE ' + @DefaultDatabase + '; ' + 
		'IF NOT EXISTS (SELECT name FROM sys.sysusers WHERE name = ''' + @User + ''')' +
		'BEGIN ' +			
			'CREATE USER ' + @User + ' FOR LOGIN ' + @LoginName + '; ' +		
			'PRINT(''New user ''''' + @User + ''''' has been successfully created.'')' +	
		'END ' + 
		'ALTER USER ' + @User + ' WITH DEFAULT_SCHEMA = ' + @DefaultSchema + '; ' +			

		'EXEC sp_droprolemember  ''db_accessadmin'', ' + @User + '; ' +
		'EXEC sp_droprolemember  ''db_backupoperator'', ' + @User + '; ' +
		'EXEC sp_droprolemember  ''db_datareader'', ' + @User + '; ' +
		'EXEC sp_droprolemember  ''db_datawriter'', ' + @User + '; ' +
		'EXEC sp_droprolemember  ''db_ddladmin'', ' + @User + '; ' +
		'EXEC sp_droprolemember  ''db_denydatareader'', ' + @User + '; ' +
		'EXEC sp_droprolemember  ''db_denydatawriter'', ' + @User + '; ' +
		'EXEC sp_droprolemember  ''db_owner'', ' + @User + '; ' +
		'EXEC sp_droprolemember  ''db_securityadmin'', ' + @User + '; ' +
		'EXEC sp_addrolemember  ''db_backupoperator'', ' + @User + '; ' +
		'EXEC sp_addrolemember  ''db_ddladmin'', ' + @User + '; ' +
		
		'PRINT(''Privileges for user ''''' + @User + ''''' altered!!!'')' 

	EXECUTE (@SQL)
END
GO




EXECUTE USP_CREATE_LOGIN_STANDARD 
	@DefaultDatabase = 'Dummy',
	@LoginName = 'login_standard',
	@LoginPassword = 'login_standard',
	@DefaultSchema = 'dbo',
	@User = 'login_standard_user'


EXECUTE USP_CREATE_LOGIN_ADMIN 
	@DefaultDatabase = 'Dummy',
	@LoginName = 'login_admin',
	@LoginPassword = 'login_admin',
	@DefaultSchema = 'dbo',
	@User = 'login_admin_user'
	
	

Jetzt habe ich aber das Problem, dass sich ein Admin immer noch mit Windows Authentifizierung anmelden kann und somit wieder Zugriff auf die Daten hat, sprich eine SELECT Anweisung ausführen kann. Welche Rollen muss man dem Active Directory Admin entziehen, damit das nicht mehr möglich ist? Es bringt ja auch nichts, beim SQL Server einen Login für den AD Admin zu generieren und ihm die Rechte dort zu entziehen. Der AD Admin kann ja wiederum einen weiteren AD Admin anlegen, für den im SQL Server kein Login existiert und hat somit wieder Zugriff. Ich finde eine Sicherheitslücke im SQL Server.

 

[zahni 521]

Du kannst einem Domain-Admin keine Rechte entziehen wenn er auch Wartungstasks auf der DB ausführen soll.

Ansonsten mal hier lesen https://support.microsoft.com/en-us/kb/2184138

[McKloony 10]

Ich habe mich mit sa als sysadmin im SQL Server angemeldet und einfach den Server Login für den dort vorhandenen Windows Admin User entfernt. Jetzt sollte es eigentlich nur noch möglich sein, sich mit sa anzumelden, wenn man sysadmin Rechte haben möchte.

 

Allerdings ist es für einen echten Windows Admin möglich, über das Commandfenster und der Anweisung "sqlservr.exe -m" den SQL Server im administrativen Modus zu starten und sich dann insgeheim ein neues Login mit allen Rollen zu erstellen, aber das werde ich auch noch irgendwie absichern.

 

Das Beste wäre natürlich, dass man im Active Directory einen Windows Admin anlegen könnte, dem die Möglichkeiten fehlen, selber weitere Windows User anzulegen. Dann könnte man diesem Admin versuchen die Rollen zu entziehen, auf den SQL Server zuzugreifen.

[zahni 521]

Wenn ein Domain-Admin einen Server nicht anfassen sollen, darf er nicht direkt oder indirekt Member der lokalen Gruppe "Administratoren" sein und sonst auch keine Konten kennen, die das sind.

Allerdings kann dann ein Domain-Admin  dem SQL-Server und dessen Konto den Zugriff auf das AD entziehen.

 

Dann muss sich aber auch der DBA um alle Belange des Server selbst kümmern.

 

1x Admin, immer Admin. 

 

Ihr solltest das wohl ein wenig anders regeln. 

[Nobbyaushb 1.363]

Und wenn man dem Admin nicht vertrauen kann, wem dann?

 

Wenn ich als Admin sowas lesen würde wäre es höchste Zeit den Arbeitgeber zu wechseln.

 

Just my 2 Cents

[MrCocktail 191]

Moin.

 

da muss ich nobbyaushb Recht geben, einem Domain Admin musst du vertrauen können, oder er hat kein Domain Admin zu sein ...

 

Ich kann mir als Domain Admin immer die Möglichkeit verschaffen, auf einen Server zuzugreifen...

 

Gruss
J

[McKloony 10]

Der Admin soll ja alles können, aber eben nicht die Datensätze lesen. Das Problem hatte wohl auch die NSA mit Edward Snowdan :-)

[DocData 85]

Es ist absolut nichts ungewöhnliches. Mit genügen krimineller Energie geht viel, deswegen muss es ein entsprechendes Logging geben. Der Rest ist Konfigurationsaufwand. Im Vorfeld sollte aber klar abgesteckt werden wer was können muss. Abschließend ist ein Berechtigungssystem im Sinne eines RBAC aufzubauen.

[NilsK 2.790]

Moin,

 

wenn der Domain-Admin "nicht können darf", dann darf der Rechner nicht in die Domäne. Oder es muss eine Verschlüsselung eingesetzt werden, zu der der DA keinen Zugang hat. Ob das mit SQL Server bzw. mit der Applikation geht, steht auf einem anderen Blatt.

 

Wenn ich den Komfort einer Domänen-Integration will, dann muss ich auch die Folgen der Domänen-Integration in Kauf nehmen.

 

Gruß, Nils

[McKloony 10]

Das ist ja das Dilemma, beim SQL Server hat man ja nur die Wahl zwischen Windows Authentifizierung und dem gemischten Modus. Eine "pure" SQL Server Anmeldung gibt es nicht. Eventuell wird es von Microsoft mal eine Windows Server Rolle geben, die man einem technischem Admin Entziehgen kann, der den Zugriff auf den SQL Server Dienst regelt.

[zahni 521]

Die  "pure" SQL-Anmeldung gibt es  eh nur  noch aus Kompatibilitätsgründen. Hauptsächlich  für Fremdanwendung, die irgendwelche uralten Treiber mitbringen.