Warum sollte eine Anwendung das sa-Konto nicht verwenden?

21

Meine allererste Frage, bitte sei sanftmütig. Ich verstehe, dass das sa-Konto die vollständige Kontrolle über einen SQL Server und alle Datenbanken, Benutzer, Berechtigungen usw. ermöglicht.

Ich bin der festen Überzeugung, dass Anwendungen das sa-Passwort nicht ohne einen perfektionierten, auf Geschäftsleute ausgerichteten Grund verwenden sollten, warum. Die Antworten auf diese Frage enthalten viele meiner Argumente für eine IT-bezogene Diskussion

Ich werde gezwungen, ein neues Service-Management-System zu akzeptieren, das NICHT funktioniert, es sei denn, es verwendet das sa-Passwort. Ich hatte keine Zeit herauszufinden, warum eine Evaluierung eingerichtet wurde, aber das Serverteam versuchte, sie zu installieren, um eine feste Rolle zu verwenden, für die ich db_creater und andere Berechtigungen eingerichtet hatte, die ich für erforderlich hielt. was fehlgeschlagen ist. Ich habe dann das Serverteam mit dem sa-Konto installieren lassen, aber unter einem Konto in der dbo-Rolle für die Datenbank ausgeführt, aber das ist auch fehlgeschlagen. Mürrisch versuchte ich, es mit einem Konto in der Rolle des Systemadministrators zum Laufen zu bringen, aber auch das schlug fehl und es gab keine nützlichen Fehlermeldungen, die es mir ermöglichten, herauszufinden, was vor sich ging, ohne mehr Zeit als verfügbar aufzuwenden. Es funktioniert nur mit dem sa-Konto und dem Passwort, die im Klartext in der Konfigurationsdatei gespeichert sind.

Als ich dies abfragte und das Serverteam mit dem Anbieter sprach, erhielt er die besorgniserregende Antwort: "Was ist das Problem damit?" und dann: "Nun, wir können uns ansehen, wie das Passwort verschlüsselt wird."

Ich weiß, dass es Mittel und Wege gibt, um den Zugriff auf die Datei einzuschränken, aber meiner Meinung nach ist dies nur eine weitere Sicherheitsschwäche

Wie auch immer, meine Frage ist, könnte mich jemand auf eine Dokumentation hinweisen, mit der ich dem Unternehmen den Grund erklären kann, warum dies eine schlechte Sache ist und ein großes Nein sein sollte. Ich arbeite in einem Bereich, der bedeutet, dass ich die Sicherheit ernst nehmen muss und mich bemüht habe, das Geschäft zu verstehen. Letztendlich kann es sein, dass ich ohnehin in den Schatten gestellt werde, aber ich muss es versuchen.

SQLDBAWithABeard
quelle
1
saoder ein Mitglied von sysadmin, einschließlich Windows-Logins?
Remus Rusanu
Sa und Sa nur :-(
SQLDBAWithABeard
1
Sie benötigen weitere Informationen vom Anbieter. Speziell, welche Dinge tun sie, die saexplizit erfordern .
Aaron Bertrand
11
Wenn ein Anbieter angibt, dass er sich explizit als sa anmelden muss, bedeutet dies, dass er seine App einfach nicht auf andere Weise getestet hat (oder dies einmal getan hat und ein Fehler aufgetreten ist, den er nicht untersucht hat, bevor er entschieden hat, dass wir einfach bleiben mit sa "), was mich nicht mit Zuversicht erfüllen würde. Nehmen Sie dieses Vorgehen jedoch nicht direkt mit dem Anbieter in Verbindung. Wenn Sie diplomatischer nachfragen, erhalten Sie bessere Ergebnisse!
David Spillett
David hat es richtig, glaube ich aus meinem kurzen Umgang mit dem Anbieter
SQLDBAWithABeard

Antworten:

21

Dies hängt von Ihrem Unternehmen ab. In den meisten Fällen müssen Sie jedoch sicherstellen, dass es sich nicht um ein IT-Problem handelt. Es ist ein Sicherheitsproblem , und während sich die beiden Bereiche massiv überschneiden, ist es wahrscheinlicher, dass Geschäftsleute zuhören, wenn Sie "Sicherheit" sagen, als wenn Sie nur "über allgemeine IT-Angelegenheiten jammern".

Arbeiten Sie mit Kunden zusammen, die Sicherheitsanforderungen haben? Das ist ein guter Anfang. Wenn wir eine App mit Zugriff auf Sa-Ebene ausgeführt haben oder nur eine App, deren Anmeldeinformationen nicht ordnungsgemäß gesichert wurden, auch wenn kein privilegierter Zugriff verwendet wurde (wir bevorzugen Windows Integrated nach Möglichkeit gegenüber gespeicherten Benutzern / Pass), und wir waren einer Sicherheitsanforderung unterworfen prüfung, diese prüfung würde fehlschlagen und wir würden riskieren, kunden zu verlieren und / oder geld an die kunden unserer gruppe zurückgeben zu müssen (bankorganisationen bei dem produkt, an dem ich hauptsächlich arbeite, befassen sich andere teile der gruppe mit polizei und gesundheit behörden und so weiter) sicherheit ist teil unseres zweckgebundenen angebots. Geschäftsleute werden die Schwere dieser potenziellen Bedrohung verstehen, auch wenn sie IT-Empfehlungen in der Regel nur als Lippenbekenntnis ausgeben.

Selbst wenn Sie die vom Kunden auferlegten Anforderungen ignorieren und verschiedene Sicherheitsstandards erfüllen möchten, wird diese Art der Anwendungsauthentifizierung Sie angesichts eines Audits erneut scheitern lassen, da sie so weit von den bewährten Methoden entfernt ist, dass sie allgemein als solche angesehen werden auf der Liste "sollte einfach nicht gemacht werden". Machen Sie Ihren Entscheidungsträgern klar, dass Sicherheit ein wichtiger Bestandteil der Anwendung ist, und die Tatsache, dass sich dieser Anbieter nicht bewusst zu sein scheint (oder zumindest in angemessener Weise darüber besorgt zu sein scheint), lässt Sie Zweifel daran aufkommen, wozu er sonst möglicherweise nicht in der Lage ist Der Umgang mit: Best Practices für die Sicherheit von Datenbanken zu kennen, ist (nun ja, sollte) Teil ihrer Aufgabe, und ihre Implementierung ist nicht schwierig.

Weisen Sie auch darauf hin, dass Sie (der Käufer) dem Verkäufer angemessene Sicherheitsanforderungen vorschreiben sollten, nicht umgekehrt. Da es sich um Ihre Daten handelt, können diese nicht angeben, was als sicher genug angesehen wird.

David Spillett
quelle
Ha. Wusste nicht, dass enter den Kommentar hinzugefügt hat. Man kann mit Sicherheit sagen, dass bei meiner Arbeit die Sicherheit aller Art ein wichtiges Anliegen ist. Betrachten Sie es als das Gleiche wie die Polizei, wenn Sie möchten. Die Entscheidungsträger sehen die sa jedoch nicht als bedenklich an. Das Audit ist ein guter Anfang, und ich werde das weiter untersuchen.
SQLDBAWithABeard
+1 Besonders gut hat mir der Kommentar gefallen, dass es sich um ein Sicherheitsproblem handelt , nicht um ein IT- Problem.
Kenneth Fisher
2
Ich würde zögern, etwas von einer Gruppe von Leuten zu kaufen, die denken, dass es in Ordnung ist, die Schlüssel für das Königreich in einer Konfigurationsdatei im Klartext zu belassen. Ich weiß, es ist nicht Ihr Anruf, aber wenn Sie The Deciders dazu bringen können, zu sehen, was für eine schreckliche Idee das ist und was über den Anbieter gesagt wird, könnte dies Ihrem Fall helfen.
Mdoyle
Mdoyle - Das Problem ist, wie ich mehr darüber erfahre, dass die Entscheider die Dinge in £ -Zeichen sehen und da dies ein Upgrade von einer alten Version ist, wird es billig. Ich glaube, ich gewinne den Kampf ein wenig dank der guten Leute hier. Ich habe den Test des Webserver-Teils davon zumindest für den
Moment verschoben
20

Es muss keine Anwendung über SA-Zugriff verfügen. (Es sei denn, der einzige Zweck ist die Datenbankverwaltung.)

Es ist eine allgemeine Regel, niemals mehr Rechte für eine Anmeldung (eine Anwendung oder eine persönliche Anmeldung) zu gewähren, als das Unternehmen für diese Anmeldung vorschreibt.

Keine Anwendung ist vollständig sicher. Die meisten haben eine SQL Injection- oder XSS-Schwachstelle. Wenn ein Angreifer eine Anweisung seiner Wahl ausführen kann und über SA-Zugriff verfügt, kann eine Reihe von Situationen mit Ihren Daten eintreten, die das Geschäft sofort zum Erliegen bringen können. (Insbesondere, wenn den Daten vertraut werden muss, weil sie von den Strafverfolgungsbehörden verwendet werden.) Fragen Sie die Beteiligten, was sie tun müssten, wenn jemand in der Lage wäre, absichtlich auch nur einen einzelnen Datensatz zu ändern, und diese Informationen durchgesickert sind.

Mit dem SA-Zugriff kann nun nicht nur die Datenbank der Anwendung geändert werden, sondern auch jede andere Datenbank auf dem System. Fragen Sie also Ihre Stakeholder, was sie tun würden, wenn Sie ALLE Ihre Datenbanken kopieren und an die Zeitung senden würden. Denn dies kann passieren, wenn ein verärgerter Mitarbeiter feststellt, dass diese Sicherheitslücke besteht.

Der Verkäufer sagte, sie könnten das Passwort verschlüsseln. Das ist BS. Die Anwendung muss auf das Kennwort im Klartext zugreifen, um es verwenden zu können. Daher wird der Schlüssel zum Entschlüsseln des Kennworts unverschlüsselt neben dem Kennwort gespeichert. Wie bereits erwähnt, besteht das eigentliche Problem nicht darin, dass jemand dieses Passwort findet. Personen, die dieses System aufgrund einer Sicherheitsanfälligkeit (falsch) verwenden, erhalten uneingeschränkten Zugriff auf alle Ihre Datenbanken, ohne jemals das Kennwort zu sehen.

Die wahrscheinlichste Ursache für die Anforderung von Sicherheitszuordnungen ist, dass die Anwendung mit SQL Agent interagieren muss. Zumindest ist das eine der schwierigeren Funktionen, die es zu implementieren gilt, und die meisten Leute gehen einfach den Weg, um es zu umgehen. Das Erfordernis von "SA" kann darauf zurückzuführen sein, dass der Anbieter nicht weiß, wie er nach Sysadmin-Berechtigungen sucht.

Es gibt zwei Lösungen, die Sie ausprobieren können:

  1. Benennen Sie SA um (eine bewährte Sicherheitsmethode), und erstellen Sie ein neues Konto mit dem Namen "SA" und eingeschränkten Rechten. (Noch nie ausprobiert, aber es sollte funktionieren)

  2. Installieren Sie die Software nicht. Sie als Fachmann können die Verantwortung für diese Aktion nicht tragen, daher sollten Sie sie nicht installieren. Bitten Sie zum Vergleich einen Klempner, die Gasleitung direkt durch den Kamin anstatt um den Kamin herum zu verlegen, um etwas Rohr / Geld zu sparen. Sie könnten über dieses Bild lachen, aber ich glaube, es ist ein angemessener Vergleich - Diese Software wird früher oder später, wahrscheinlich früher, in die Luft gehen. Und wenn dies der Fall ist, könnte dies auch das Geschäft beeinträchtigen.

Wenn dies "sie" nicht davon abhält, diese Software zu benötigen, ist die letzte Empfehlung, die ich Ihnen geben kann, die Ausführung. Wenn etwas mit den Daten passiert, sind Sie der Erste, der dafür verantwortlich gemacht wird. Mit dieser Anwendung haben Sie wahrscheinlich keine Arbeitsplatzsicherheit. Suchen Sie sich also einen Arbeitgeber, der Ihnen zumindest einige bietet.

Sebastian Meine
quelle
4
+1 nur für das Gleichnis "die Gasleitung direkt durch den Kamin" .
Ypercubeᵀᴹ
In SQL Server kann das sa-Konto nicht umbenannt werden. Es kann jedoch deaktiviert werden.
Greenstone Walker
1
@GreenstoneWalker: sicher , dass es folgende Möglichkeiten: alter login sa with name = [as];.
Remus Rusanu
Remus, das wird mir zu Recht dazu dienen, mich auf SSMS und auch auf altes Wissen zu verlassen. Vor SQL Server 2005 konnte es nicht umbenannt werden. SSMS scheint nicht in der Lage zu sein, die sa-Anmeldung umzubenennen, aber die von Ihnen bereitgestellte T-SQL ist genau richtig.
Greenstone Walker
12

Ich sehe zwei Angriffslinien.

  • Compliance . Gibt es in Ihrem Shop vorgeschriebene Compliance-Kriterien? Durchsuchen Sie den Wortlaut sorgfältig und prüfen Sie, ob Sie etwas finden, das mit der Anwendung "Anforderung" nicht kompatibel ist. Wenn Sie etwas finden, das die saVerwendung durch eine Anwendung verhindert, haben Sie ein kugelsicheres wasserdichtes Gehäuse, da die Anwendung Ihr Unternehmen haftbar machen würde usw. usw.

  • Benutzeradministratorzugriff . Stellen Sie sicher, dass Sie den Fall klar darstellen, dass eine Anwendung, für die tatsächlich saZugriff erforderlich ist sa, allen Unternehmensbenutzern Zugriff gewährt , die über Administratorrechte auf den Arbeitsstationen verfügen, auf denen die Anwendung installiert ist. Es gibt keine Möglichkeit, das saKennwort vor lokalen Administratoren zu verbergen, auf denen die Anwendung ausgeführt wird. Das ist eine Tatsache, und keine Menge an "Scrambling" kann dies verhindern. Es gibt keinen lokalen Vertrauensstamm, auf den ein lokaler Administrator nicht zugreifen kann, wenn er möchte. Stellen Sie klar, dass eine Anwendung, die dies erfordert , allen Benutzern, die die Anwendung saausführen, saBerechtigungen gewährt. Erklären Sie, was dies bedeutet und was die Benutzer effektiv tun können:

    • Fähigkeit, alle Daten auf dem Server zu lesen , nicht nur von dieser Anwendung, sondern von jeder anderen Datenbank, die auf diesem Server gehostet wird
    • Möglichkeit zum Ändern von Daten auf dem Server, erneut von einer anderen Datenbank auf demselben Server
    • Möglichkeit, jede Spur seiner Handlungen zu löschen, nachdem eine Änderung vorgenommen wurde
    • Möglichkeit, die Prüfung und den Verlauf zu ändern, um den Eindruck zu erwecken, dass bestimmte Aktionen von einem anderen Benutzer ausgeführt wurden
    • Möglichkeit, die SQL Server-Anmeldeinformationen zu verwenden, um einen Angriff auf eine andere Ressource zu eskalieren , die diesem Server vertraut. Dies kann jeden anderen SQL Server implizieren, aber auch andere Ressourcen, einschließlich, aber nicht beschränkt auf Dateifreigaben, Exchange-Server usw., da der SQL Server nur als Sprungbrett verwendet werden kann.

Machen Sie den Entscheidungsträgern klar, dass das Akzeptieren dieser Anwendung bedeutet, dass jedem Mitarbeiter, der über Administratorzugriff auf Arbeitsstationen verfügt, auf denen die Anwendung ausgeführt wird, alle oben genannten Berechtigungen übertragen werden. Der Anbieter wird versuchen, seine Position zu verteidigen, indem er das saKennwort für die Anwendung auf die eine oder andere Weise verschlüsselt . Dies hält kein Wasser. Es gibt kein Verschlüsselungsschema, das einem Angriff eines Administrators standhält. Machen Sie deutlich, dass die technischen Fähigkeiten, die erforderlich sind, um ein lokal 'verstecktes' Passwort zu finden, völlig irrelevant sind. Die Mitarbeiter werden es nicht selbst tun, einer von ihnen wird danach googeln und das benutzerfreundliche Skript entdecken, das es macht.

Remus Rusanu
quelle
Vielen Dank Remus. Das ist genau die Antwort, die ich benötigt habe. Ich
gewinne
7

Erstens ist das sa Passwort Klartext gespeichert? Sie sollten mit Ihrer Brieftasche abstimmen. Wer das für akzeptabel hält, muss aus dem Geschäft genommen werden.

Hier ist eine Anologie, die Ihnen bei der Erklärung des Problems helfen könnte: Mitarbeiterin Alice benötigt Zugang zum ersten Stock. Geben Sie ihr den Hauptschlüssel für das gesamte Gebäude oder nur den Schlüssel für den ersten Stock? Antwort: Sie geben ihr nur die Schlüssel zum ersten Stock. Warum? Weil es die Wahrscheinlichkeit eines versehentlichen oder absichtlichen Schadens verringert. Wenn Alice überhaupt nicht in den Serverraum im zweiten Stock gelangen kann, wird sie dort nie etwas Schlimmes tun.

Es ist das Prinzip des geringsten Privilegs.

Warum die Anwendung das sa-Konto verwenden muss, ist eine Frage, die PerfMon oder Extended Events beantworten können sollten. Erstellen Sie einen PerfMon-Trace mit der T-SQL-Vorlage, möglicherweise gefiltert nach dem Anwendungsnamen.

Ich habe ein weiteres Argument gegen die Verwendung von sa: Für die Verwendung des sa-Kontos muss sich der SQL Server-Dienst im gemischten Authentifizierungsmodus befinden. Windows-Authentifizierung ist besser, da wir alle sicheren Funktionen von Kerberos nutzen können.

Greenstone Walker
quelle
4

Aus technischer Sicht gibt es keinen Grund, warum eine Anwendung SA-Berechtigungen benötigt. Was wahrscheinlich passiert ist, ist, dass die Entwickler der Anwendung wahrscheinlich überprüfen, ob ihre Anmeldung Sysadmin-Berechtigungen hat, und wenn nicht, wird einfach eine Fehlermeldung ausgegeben. Auf diese Weise können sie behaupten, dass die Anwendung SA-Rechte erfordert.

Wenn Sie diese Anwendung benötigen, würde ich sie auf einer separaten Instanz ausführen, auf der sich nichts anderes befindet.

mrdenny
quelle
Ich denke , es ist wahrscheinlich überprüft , ob es als sa läuft und schlägt dann fehl , da es bei einem Konto mit Sysadmin nicht ausgeführt werden
SQLDBAWithABeard
1
Dann muss die spezifische Benutzer-ID überprüft werden. Vermutlich tut der Entwickler dies, weil es mit sa funktioniert und er sich nicht die Mühe machen wollte, die tatsächlich benötigten Berechtigungen zu ermitteln. Dies ist der einfachste Weg, um andere Fehler zu vermeiden. Es ist eine total beschissene Herangehensweise und der Verkäufer sollte dafür verprügelt werden.
Mrdenny
4

Möglicherweise fordert Ihr Anbieter "sa" an, weil er irgendwo in seiner Anwendung XP_CMDSHELL verwendet. (Machen Sie mich nicht mit dem Schaden vertraut, der durch den uneingeschränkten Zugriff auf XP_CMDSHELL möglich ist. Es reicht aus, zu sagen, dass dies möglicherweise nicht nur Ihre Daten, sondern auch den Host-Computer und möglicherweise alles andere in Ihrem Netzwerk für den Zugriff durch Administratoren öffnet.)

Wenn ein berechtigter Bedarf besteht, können Sie den eingeschränkten Zugriff über ein Proxy-Konto gewähren. Siehe beispielsweise BOL: http://msdn.microsoft.com/en-us/library/ms175046.aspx

TheDataBeagle
quelle
4

Für die Ausführung einer Anwendung sollten das SA-Konto und das Kennwort nicht erforderlich sein.

Ich habe jedoch ein IT Service Management-Produkt installiert. Während des Installationsvorgangs haben Sie die Möglichkeit, die Anmeldeinformationen für das SA-Konto anzugeben, damit das Installationsprogramm die Datenbank erstellen und der Datenbank ein Konto hinzufügen kann, das von der Software verwendet werden kann. Die Anmeldeinformationen für das SA-Konto werden nirgendwo in den Anwendungs- oder Installationsprotokollen gespeichert. Diese Software bietet auch die Möglichkeit, während der Installation eine vorab erstellte Datenbank zu verwenden.

Daher würde ich nur bestätigen, ob das SA-Konto für die Installation oder den Betrieb dieser IT Service Management-Software erforderlich ist.

Bei Installation: Erstellen Sie ein temporäres 'sa'-Konto - führen Sie die Installation durch - und entfernen Sie das Konto.

Wenn Operation: Vermeiden Sie diese Software wie die Pest. (Oder richten Sie einen eigenständigen SQL-Server ein, der nur diese eine Datenbank enthält.)

Brent
quelle
+1 für dedizierte SQL Server-Instanz. Das wäre eine gute Alternative zum Gewähren von Sicherheit auf dem realen Server.
Dan,
0

Alle angegebenen Standard-SQL Server-Systemsicherheitsparameter sollten geändert werden. Es wird empfohlen, für die Authentifizierung nicht den gemischten Modus zu verwenden (aktiviert sowohl die Windows- als auch die SQL Server-Authentifizierung). Wechseln Sie stattdessen nur zur Windows-Authentifizierung, um die Windows-Kennwortrichtlinie zu erzwingen, und überprüfen Sie die Kennwortlänge, die Lebensdauer und den Verlauf. Die Windows-Kennwortrichtlinie unterscheidet sich von der SQL Server-Authentifizierung durch die Anmeldesperre. Nach mehreren fehlgeschlagenen Anmeldeversuchen wird die Anmeldung gesperrt und kann nicht mehr verwendet werden

Andererseits bietet die SQL Server-Authentifizierung keine Methoden zum Erkennen von Brute-Force-Angriffsversuchen, und was noch schlimmer ist, SQL Server ist sogar für die Behandlung einer großen Anzahl schneller Anmeldeversuche optimiert. Wenn die SQL Server-Authentifizierung in einem bestimmten SQL Server-System ein Muss ist, wird dringend empfohlen, die SA-Anmeldung zu deaktivieren

Ivan Stankovic
quelle
1
War es ein Unfall oder eine Absicht, zwei Fragen mit der gleichen exakten Antwort zu beantworten?
ypercubeᵀᴹ
Danke für den Kommentar. Dachte nur, dass die Erklärung in beiden Fällen helfen kann.
Ivan Stankovic
Interessant, aber nicht besonders hilfreich für das OP.
Dan,