Muss das SA-Konto "SA" heißen oder kann ich es sicher umbenennen?

Wir haben einige Anwendungen in unserem Netzwerk (vor meiner Zeit), die ein SA-Konto in ihrer SQL Server-Verbindungszeichenfolge verwenden. Es ist im Quellcode fest codiert, und aus irgendeinem Grund können wir es nicht ändern - meine Frage ist nicht, warum wir es ändern sollten, sondern darum, es zu umgehen.

Ich denke darüber nach, das SA-Konto in etwas anderes umzubenennen (wie "SysAccount" oder ähnliches und ihm ein neues Passwort zu geben) und dann ein neues Konto mit dem Namen "SA" mit dem alten Passwort zu erstellen und ihm die für die Anwendung geeigneten Rechte zu gewähren (offensichtlich keine Mitgliedschaft in der Sysadmin-Rolle). Gibt es irgendwelche Fallstricke dabei? Gibt es bekannte Probleme, die SQL Server haben wird, wenn das Konto mit dem Namen SA kein Systemadministrator ist?

Ich gehe davon aus, dass ich, da ich das Konto gerade umbenenne, sicher bin - es wird immer noch eine UID von 0x01 haben, und ich habe dies getestet und es ist physikalisch möglich und scheint beim Testen richtig zu funktionieren, aber ich möchte sichergehen Ich übersehen nichts, was dadurch eindeutig kaputt geht. Wenn es kaputt geht, kann ich jederzeit die neue SA löschen und die alte wieder umbenennen, um den Schaden rückgängig zu machen, aber ich hoffe, dass ich es nicht versuche und versage.

Ich verwende SQL Server 2012, obwohl ich vermute, dass die gleiche Antwort für jede moderne Version gilt. Ich habe den Fehler gesehen, bei dem das Upgrade von 2005 auf 2008 brechen kann, wenn Sie dies getan haben , aber ich kann mir vorstellen, dass dies längst behoben ist.

Es kann umbenannt werden. Es wird oft als Best Practice für die Sicherheit angesehen, aber es kann zu SQL Agent-Ausfällen kommen, wenn Sie den Agent-Dienst nicht bouncen oder den Jobbesitzer wechseln. Außerdem kann ich Berichte darüber finden, die Server 2008-Upgrades beeinträchtigen .

Das reicht aus, damit ich mich nicht darum kümmern möchte, es umzubenennen. Ich sage, es reicht aus, ein komplexes Passwort zuzuweisen und die Anmeldung zu deaktivieren, und es ist im Allgemeinen eine bessere Option, da es die Sicherheitsanfälligkeit tatsächlich schließt, anstatt sie nur zu verschleiern. Durch die Verschleierung erhalten Sie nur sehr wenig Sicherheit. Wenn Sie in Zukunft wirklich einen SQL-Autorisierungssystemadministrator benötigen, erstellen Sie ein neues Konto dafür. Das ist nicht besonders schwierig. Sie haben dieselbe Angriffsfläche wie das Umbenennen, ohne sich daran erinnern zu müssen, dass SID 0x01 nicht mehr sa ist (obwohl es immer noch sa ist). Und da sich die SID nie wirklich ändert, ist es natürlich nicht schwierig zu finden, welches Konto die SID 0x01 ist (oder ein Mitglied der Sysadmin-Rolle). Verwenden Sie nach Möglichkeit nicht einmal den gemischten Modus.

Ja, das Problem von 2005 bis 2008 ist behoben. Jetzt können Sie das SA-Konto deaktivieren, es in SomethingElse umbenennen, ihm ein chinesisches Passwort geben oder es mischen und abgleichen.

Siehe: http://www.mssqltips.com/sqlservertip/2221/different-ways-to-secure-the-sql-server-sa-login/

Beachten Sie, dass der neue Name wie folgt ermittelt werden kann, da die SID von SA (unabhängig davon, wie Sie sie umbenennen) weiterhin besteht:

SELECT * FROM sys.syslogins WHERE sid = 0x01

Natürlich können Sie das integrierte Administrator-Login natürlich nicht loswerden. Sie müssen sich also nur entscheiden, ob die geringfügigen Nebenwirkungen für Sie ein Problem darstellen.

Ich verwende niemals "SA" für meine Arbeit, sondern mein eigenes spezielles Domain-Konto mit Sysadmin-Berechtigungen.

Ich kann mir eine Sache vorstellen, die Probleme verursachen kann: Wird die Anwendung aufgerufen IS_SRVROLEMEMBER('sysadmin'), um zu überprüfen, ob das Konto Mitglied der festen Serverrolle "sysadmin" ist? Wenn ja, funktioniert dies nicht, wenn 'sa' ein anderes Konto wird.