Olaf Helper

Man hört und sieht es immer noch häufiger:

Auch heutzutage, wo jedem das Thema Sicherheit präsent sein sollte, gibt es weiterhin viele, kleine oder größere Applikationen, die auf einen MS SQL Server zugreifen und das mit dem SQL Account "sa", welcher nicht zu selten über kein strenges oder noch schlimmer, über gar kein Passwort verfügt; mal abgesehen davon, dass es eh jeder kennt. Dabei ist dieser Standard SysAdmin Account eigentlich sowieso auch nur für die Administration gedacht gewesen; wie es halt immer so ist.

Natürlich sollte sowas von Grund auf geändert werden, also das die Anmeldung über den Windows Account des aktuellen Benutzers erfolgt oder zumindest über einen für die jeweilige Applikation dediziert angelegten SQL Account, der über ein strenges Passwort verfügt.

Durch die Masse an Applikationen ist eine solche Änderung natürlich zeitaufwendig; und was ist in der Zwischenzeit, bis alle Zugriffe geändert sind? Weiterhin dieses Sicherheitsrisiko eingehen mit der Gefahr, dass jemand "ungewünschte Änderungen" vornimmt und Daten oder gar ganze Objekte löscht?

Dafür gäbe es eine Möglichkeit zur Lösung. Seit dem Microsoft SQL Server Version 2005 gibt es die Möglichkeit SQL Account‘s mittels eines einfach ALTER LOGIN umzubenennen, einschließlich dem "sa" Account.

Die Idee ist also folgende:

-       "sa" umbenennen, z.B. in "saRealAdmin"

-       Strenges Passwort für "saRealAdmin" vergeben

-       Neuen SQL Account "sa" mit dem ursprünglichen Passwort anlegen und ihm die minimalst benötigten Rechte geben.

Versuchen wir es mal (Empfehlung: Vorher die [master] Datenbank kopieren!):

USE [master] 

GO 

-- Original "sa" umbenennen 

ALTER LOGIN [sa] WITH NAME = [saRealAdmin] 

GO 

-- Neuen "sa" mit altem Pwd anlegen 

CREATE LOGIN [sa] WITH PASSWORD=N'altesPasswort' 

GO 

-- Kontrolle; beide da 

SELECT sid, name 

FROM [master].[sys].[syslogins] 

WHERE name LIKE 'sa%' 

GO 

-- In AdventureWorks als DB User anlegen 

-- und nur Lese-Rechte vergeben 

USE [AdventureWorks] 

GO 

CREATE USER [sa] FOR LOGIN [sa] 

GO 

EXEC sp_addrolemember N'db_datawriter', N'sa' 

GO 

-- Test neuer "sa" auf Rechte 

EXECUTE AS LOGIN = 'sa'; 

GO 

DROP TABLE Person.Address 

GO 

-- User Context wieder zurück schalten 

REVERT; 

Der Test hat geklappt, die Anmeldung mit dem neuen „sa“ funktioniert, die Rechte sind eingeschränkt und auch die Verwendung des vermeintlich alten „saRealAdmin“ funktioniert einwandfrei und hat natürlich weiterhin Admin-Rechte.

Auf die Art kann man die Zwischenzeit überbrücken und trotzdem arbeiten Applikationen, die „sa“ verwenden weiterhin.

Nach Umstellung aller Apps sollte man sich überlegen, die Umbenennung rückgängig zu machen, sonst denkt der Admin womöglich nicht mehr daran, einen andern Sql Account zu verwenden.