it-swarm.com.de

Warum sollte eine Anwendung das sa-Konto nicht verwenden?

Meine allererste Frage, bitte sei sanft. 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. Die Antworten auf Diese Frage enthalten viele meiner Argumente für eine IT-fokussierte Diskussion

Ich bin gezwungen, ein neues Service-Management-System zu akzeptieren, das nur funktioniert, wenn das sa-Passwort verwendet wird. Ich hatte nie Zeit herauszufinden, warum beim Einrichten einer Evaluierung, aber das Serverteam versuchte, sie zu installieren, um eine feste Rolle zu verwenden, die ich mit db_creater und anderen 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 seine Datenbank ausgeführt, aber das ist auch fehlgeschlagen. Mürrisch versuchte ich, es mit einem Konto in der Sysadmin-Rolle zum Laufen zu bringen, aber selbst das schlug fehl und nicht mit 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 es die besorgniserregende Antwort: "Was ist das Problem damit?" und dann "Nun, wir können uns ansehen, wie man das Passwort verschlüsselt"

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 Sicherheitslücke

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 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 verständlich zu machen, und letztendlich ohnehin überholt sein kann, aber ich muss es versuchen.

21

Es hängt von Ihrem Unternehmen ab, aber in den meisten Fällen müssen Sie sicherstellen, dass es nicht als IT-Problem angesehen wird. Es ist ein Sicherheit Problem, und während sich die beiden massiv überlappen, hören Geschäftsleute eher zu, wenn Sie "Sicherheit" sagen, als wenn Sie nur "über allgemeine IT-Dinge stöhnen".

Arbeiten Sie mit Clients zusammen, die Sicherheitsanforderungen haben? Das ist ein guter Anfang. Wenn wir eine App mit sa-Level-Zugriff ausgeführt haben oder nur eine App, die ihre Anmeldeinformationen nicht ordnungsgemäß gesichert hat, auch wenn sie keinen privilegierten Zugriff verwendet (wir bevorzugen nach Möglichkeit Windows Integrated anstelle von gespeicherten Benutzern/Pässen), und wir waren einer Sicherheit unterworfen Prüfung, diese Prüfung würde fehlschlagen und wir würden das Risiko eingehen, Kunden zu verlieren und/oder Geld für die Kunden unserer Gruppen zurückgeben zu müssen (Bankenorganisationen im Fall des Produkts, an dem ich hauptsächlich arbeite, andere Teile der Gruppe befassen sich mit Polizei und Gesundheit Behörden usw.) Sicherheit ist Teil unseres zweckmäßigen Angebots. Geschäftsleute werden verstehen die Schwere dieser potenziellen Bedrohung, auch wenn sie IT-Empfehlungen normalerweise nur Lippenbekenntnisse zollen.

Selbst wenn Sie die vom Kunden auferlegten Anforderungen ignorieren, werden Sie, wenn Sie sich bemühen, verschiedene Sicherheitsstandards nach Industriestandard zu erfüllen, diese Art der Anwendungsauthentifizierung angesichts eines Audits erneut scheitern lassen, da sie so weit von der Best Practice entfernt ist, dass sie allgemein als solche angesehen wird 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 dieser Anbieter sich dessen nicht bewusst zu sein scheint (oder zumindest angemessen besorgt ist), lässt Sie Zweifel daran haben, wozu sie sonst möglicherweise nicht in der Lage sind Umgang mit: Das Wissen über bewährte Verfahren für die DB-Sicherheit ist (sollte) ein Teil ihrer Arbeit, und die Implementierung ist nicht schwierig.

Weisen Sie auch darauf hin, dass Sie (der Käufer) dem Verkäufer angemessene Sicherheitsanforderungen diktieren sollte, nicht umgekehrt. Es sind Ihre Daten, daher sind sie nicht qualifiziert, anzugeben, was als sicher genug angesehen wird.

21
David Spillett

Keine Anwendung muss SA Zugriff - je. (Es sei denn, ihr einziger Zweck ist die Datenbankverwaltung irgendeiner Art.)

Es ist eine allgemeine Regel, niemals mehr Rechte für eine Anmeldung (anwendungs- oder persönlich) zu gewähren, als das Unternehmen für diese Anmeldung benötigt.

Keine Anwendung ist vollständig sicher. Die meisten haben eine Art SQL Injection- oder XSS-Sicherheitslücke. Wenn ein Eindringling eine Anweisung seiner Wahl ausführen kann und über SA-Zugriff verfügt, können Ihren Daten viele Dinge passieren, 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, auch nur einen einzigen Datensatz absichtlich zu ändern, und diese Informationen durchgesickert wären.

Mit dem SA-Zugriff kann jetzt nicht nur die Datenbank der Anwendung geändert werden, sondern auch jede andere Datenbank im System. Fragen Sie Ihre Stakeholder, was sie tun würden, wenn Sie eine Kopie ALLER Ihrer Datenbanken erstellen und an die Zeitung senden würden. Denn das kann passieren, wenn ein verärgerter Mitarbeiter herausfindet, dass diese Sicherheitslücke besteht.

Der Anbieter 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. Der Schlüssel zum Entschlüsseln des Kennworts wird also unverschlüsselt direkt daneben gespeichert. Wie bereits erwähnt, besteht das eigentliche Problem nicht darin, dass jemand dieses Passwort findet. Es ist so, dass Personen, die dieses System aufgrund einer Sicherheitsanfälligkeit (falsch) verwenden, vollen Zugriff auf alle Ihre Datenbanken erhalten, ohne jemals das Kennwort zu sehen.

Die wahrscheinlichste Ursache dafür, dass SA erforderlich ist) ist, dass die Anwendung mit SQL Agent interagieren muss. Zumindest ist dies eine der schwierigeren Funktionen, die richtig implementiert werden müssen, und die meisten Benutzer verwenden einfach die Option "SA verwenden". Die Anforderung, 'SA' selbst zu benötigen, kann daran liegen, dass der Anbieter nicht weiß, wie er nach Sysadmin-Berechtigungen suchen soll.

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

  1. Benennen Sie SA (ohnehin eine bewährte Sicherheitsmethode) um und erstellen Sie ein neues Konto mit dem Namen 'SA' mit eingeschränkten Rechten. (Ich habe dies nie versucht, 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. Um Ihnen einen Vergleich zu geben, bitten Sie einen Klempner, die Gasleitung direkt durch den Kamin zu führen, anstatt um ihn herum, um etwas Rohr/Geld zu sparen. Sie werden vielleicht ü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 jagen. Und wenn dies der Fall ist, könnte dies auch das Geschäft beeinträchtigen.

Wenn dies nicht "sie" 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, werden Sie als erster dafür verantwortlich gemacht. Wenn diese Anwendung vorhanden ist, haben Sie wahrscheinlich keine Arbeitsplatzsicherheit. Suchen Sie sich also einen Arbeitgeber, der Ihnen zumindest einige bietet.

20
Sebastian Meine

Ich sehe zwei Angriffslinien.

  • Konformität. 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 Anforderung der Anwendung nicht kompatibel ist. Wenn Sie etwas finden, das die Verwendung von sa durch eine Anwendung verhindert, haben Sie einen kugelsicheren wasserdichten Fall, da die Anwendung Ihr Unternehmen haftbar machen würde usw. usw.

  • ser Admin Access. Stellen Sie sicher, dass Sie den Fall klar darstellen, dass eine Anwendung, für die tatsächlich sa Zugriff erforderlich ist, sa Zugriff auf alle Unternehmensbenutzer gewährt, die über Administratorrechte auf den Arbeitsstationen verfügen, auf denen die Anwendung installiert ist. Es gibt keine Möglichkeit, das Kennwort sa vor lokalen Administratoren zu verbergen, auf denen die Anwendung ausgeführt wird. Dies ist ein fact, und dies kann durch kein "Scrambling" verhindert werden. Es gibt keine lokale Vertrauensbasis, zu der ein lokaler Administrator nicht gelangen kann, wenn er möchte. Stellen Sie klar, dass eine Anwendung, für die sa erforderlich ist, bedeutet, dass allen Benutzern, die die Anwendung ausführen, sa die Berechtigung erteilt wird. Erklären Sie, was dies bedeutet und was die Benutzer effektiv tun können:

    • möglichkeit zum Lesen aller Daten auf dem Server, nicht nur von dieser Anwendung, sondern auch von jeder anderen auf diesem Server gehosteten Datenbank
    • möglichkeit, alle Daten auf dem Server zu ändern, wiederum aus jeder anderen Datenbank auf demselben Server
    • fähigkeit, jede Spur seiner Handlungen zu löschen, nachdem eine Änderung vorgenommen wurde
    • möglichkeit, Audits und 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 jede 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, Austauschserver usw., da der SQL Server nur als Sprungbrett verwendet werden kann.

Machen Sie den Entscheidungsträgern klar, dass das Akzeptieren dieser Anwendung bedeutet, jedem Mitarbeiter, der Administratorzugriff auf Arbeitsstationen hat, auf denen die Anwendung ausgeführt wird alle oben genannten Berechtigungen anzuvertrauen. Der Anbieter wird versuchen, seinen Stand zu verteidigen, indem er auf die eine oder andere Weise das Kennwort sa für die Anwendung "verschlüsselt". Dies hält kein Wasser. Es gibt kein Verschlüsselungsschema, das einem Angriff eines Administrators standhalten kann. Und 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 es googeln und das benutzerfreundliche Skript entdecken, das es tut.

12
Remus Rusanu

Erstens, das sa Passwort im 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 helfen könnte, das Problem zu erklären: Mitarbeiter Alice benötigt Zugriff auf den 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 für den ersten Stock. Warum? Weil es die Wahrscheinlichkeit von versehentlichen oder absichtlichen Schäden verringert. Wenn Alice überhaupt nicht in den Serverraum im zweiten Stock gelangen kann, wird sie dort niemals etwas Schlimmes tun.

Es ist das Prinzip des geringsten Privilegs.

Dies ist eine Frage, die PerfMon oder Extended Events beantworten sollten, warum die Anwendung das sa-Konto verwenden muss. Erstellen Sie eine PerfMon-Ablaufverfolgung mithilfe der T-SQL-Vorlage, die möglicherweise nach dem Anwendungsnamen gefiltert wird.

Auf den ersten Blick ist hier 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. Nur Windows-Authentifizierung ist besser, da wir alle sicheren Funktionen von Kerberos nutzen können.

7

Aus technischer Sicht gibt es keinen Grund, warum eine Anwendung SA Berechtigungen) benötigen würde. Was wahrscheinlich passiert ist, ist, dass die Entwickler der Anwendung wahrscheinlich prüfen, ob ihre Anmeldung über Sysadmin-Berechtigungen verfügt, und wenn nicht, einfach löst eine Fehlermeldung aus. Auf diese Weise können sie behaupten, dass die Anwendung SA Rechte) benötigt.

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

4
mrdenny

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

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

4
TheDataBeagle

Für keine Anwendung sollten das Konto SA Konto und das Kennwort) erforderlich sein.

Ich habe jedoch ein IT Service Management-Produkt installiert, und während des Installationsvorgangs haben Sie die Möglichkeit, die Kontoanmeldeinformationen SA) anzugeben, damit das Installationsprogramm die Datenbank erstellen und ein Konto an die Datenbank anhängen kann Für die zu verwendende Software. Die Anmeldeinformationen des Kontos SA) 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.

Ich würde also nur bestätigen, ob das Konto SA 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 Betrieb: Vermeiden Sie diese Software wie die Pest. (Oder richten Sie einen eigenständigen SQL Server ein, auf dem nur diese eine Datenbank gespeichert ist.)

4
Brent

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

Andererseits bietet die SQL Server-Authentifizierung keine Methoden zum Erkennen von Brute-Force-Angriffsversuchen. Schlimmer noch, SQL Server ist sogar für die Verarbeitung 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 Anmeldung SA) zu deaktivieren

0
Ivan Stankovic