it-swarm.com.de

Warum ist es eine schlechte Praxis, jedem zu erlauben, das sa-Login zu benutzen?

Sogar Microsoft rät von der Verwendung des SQL Server-Authentifizierungsmodus ab , aber unsere Anwendungen erfordern dies.

Ich habe gelesen, dass es eine bewährte Methode ist, Benutzer das sa -Login nicht direkt verwenden zu lassen, sondern stattdessen die Windows-Authentifizierung zu verwenden und diesen Konten (oder Kontogruppen) Sysadmin-Berechtigungen zu gewähren.

  • Ist das nicht im Wesentlichen dasselbe? Was sind die Vor- und Nachteile?
  • Wie erhöht die bewährte Methode die Sicherheit meiner SQL Server-Instanzen?
  • Gilt dies nur für Produktionsinstanzen oder auch für unsere internen Entwicklungsinstanzen?
25
Jon Seigel

Sie haben hier verschiedene Fragen, also werde ich sie einzeln ausschalten:

"Ich habe gelesen, dass es eine bewährte Methode ist, Benutzer das sa-Login nicht direkt verwenden zu lassen, sondern stattdessen die Windows-Authentifizierung zu verwenden"

Sie mischen hier zwei Dinge: das Konzept der SA und das Konzept der SQL-Authentifizierung und der Windows-Authentifizierung.

Die SQL-Authentifizierung ist eine Liste von Benutzernamen und Kennwörtern, die in jedem SQL Server gespeichert sind. Die Tatsache, dass es in SQL gespeichert ist, ist das erste Problem. Wenn Sie das Kennwort eines Logins ändern müssen, müssen Sie es auf jedem Server ändern (oder unterschiedliche Kennwörter auf verschiedenen Servern verwalten). Mit der Windows-Authentifizierung können Sie Anmeldungen zentral deaktivieren, Kennwörter ändern, Richtlinien festlegen usw.

Wenn Sie sich für die Verwendung der SQL-Authentifizierung entscheiden, ist SA ist nur eine SQL-Authentifizierungsanmeldung. Dies ist der Standardbenutzername des Administrators, genau wie der Administrator bei der Windows-Authentifizierung. Er verfügt jedoch über lokale Superkräfte in dieser einen Instanz, jedoch nicht globale Supermächte in allen Instanzen.

"... und Zulassen dieser Sysadmin-Berechtigungen für diese Konten (oder Kontogruppen)."

Unabhängig davon, für welche Authentifizierungsmethode Sie sich entscheiden, möchten Sie im Idealfall dem Prinzip der geringsten Privilegien folgen: Menschen die Mindestrechte gewähren, die sie für ihre Arbeit benötigen, und nicht mehr.

Betrachten Sie sie nicht nur als Logins - sie sind Leute, die Sie entlassen können. Wenn sie die Datenbank löschen oder Ihre Sicherungsjobs versehentlich deaktivieren, werden sie nicht ausgelöst, da SQL standardmäßig nicht nachverfolgt, wer was getan hat. Du bist derjenige, der gefeuert wird, weil es passieren wird, und du wirst nicht sagen können, welche Person es getan hat.

"Wie erhöht die bewährte Methode die Sicherheit meiner SQL Server-Instanzen?"

Sie möchten zwei Dinge tun:

  1. Verhindern Sie, dass Personen den Server beschädigen
  2. Wenn sie den Server beschädigen, können Sie genau identifizieren, wer es getan hat

Das erste wird mit dem Prinzip des geringsten Privilegs erreicht: den Leuten nur die Berechtigungen zu geben, die sie benötigen, und nicht mehr.

Die zweite Möglichkeit besteht darin, jeder Person ein eigenes Login zu geben, keine gemeinsamen Anmeldungen zuzulassen (z. B. alle Benutzer denselben Benutzernamen/dasselbe Passwort verwenden zu lassen) und im Idealfall die Anmeldungen zu überprüfen. Sie werden diesen letzten Teil wahrscheinlich nicht sofort erledigen, weil er schmerzhaft ist, aber lassen Sie uns die Teile zuerst anbringen, damit Sie später Audits hinzufügen können, nachdem jemand eine Datenbank gelöscht hat und Ihr Chef wissen möchte, warum.

Ich weiß, was Sie denken: "Aber wir codieren Apps, und die App benötigt ein Login." Ja, geben Sie der Anwendung ein eigenes Login, und die Entwickler müssen dieses Passwort kennen, aber dieses Login sollte so frei von Berechtigungen sein, dass niemand, der bei klarem Verstand ist, es verwenden möchte. Beispielsweise muss es möglicherweise nur in den Rollen db_datareader und db_datawriter vorhanden sein, sonst nichts. Auf diese Weise kann es Daten einfügen, aktualisieren, löschen und auswählen, aber nicht unbedingt Schemas ändern, Indizes hinzufügen, gespeicherte Prozeduren ändern usw.

"Gilt dies nur für Produktionsinstanzen oder auch für unsere internen Entwicklungsinstanzen?"

Ich denke, das gilt genauso für Entwicklungsinstanzen, weil ich mir normalerweise Sorgen mache, dass Leute Dinge kaputt machen. Die Leute lieben es einfach, Server in der Entwicklung zu brechen. Und wenn es Zeit ist, die Liste der Änderungen für die Migration in die Produktion zu bündeln, muss ich natürlich wissen, ob ein bestimmter Index für die App wirklich wichtig ist oder ob ein Bonehead gerade den Database Tuning Advisor ausgeführt und ihm gesagt hat, dass er alle Änderungen anwenden soll . Die richtigen Berechtigungen helfen, diesen Schmerz zu lindern.

52
Brent Ozar

Wenn Sie dieses Whitepaper lesen: SQL Server-Whitepaper zur Aufgabentrennung

Es wird Ihnen sagen, dass NIEMAND Sysadmin-Berechtigungen für sein Konto verwenden sollte. Ihr tägliches Zugriffskonto sollte über einen Mindestzugriff verfügen, nicht über explizite Systemadministratorrechte. Angesichts dessen ist CONTROL SERVER tatsächlich in der Nähe von sysadmin und ermöglicht es Ihnen dann, den Zugriff dort zu verweigern/zu widerrufen, wo sie ihn nicht benötigen. Das Zulassen von Sysadmin-Rechten für jedermann wird zu einem Problem, wenn Sie IT-Compliance-Standards erfüllen müssen. Die meisten Standards erfordern eine minimale Verwendung der Sysadmin-Rolle.

Ich deaktiviere und benenne das "sa" -Konto um, genau wie Sie es mit dem integrierten Administratorkonto auf dem Betriebssystem tun würden. Nur zur Verwendung im Notfall.

Entwickler erhalten normalerweise vollen Zugriff auf ihre Entwicklungsumgebung. Wenn ihr Programm dann in die Vorproduktionsinstanz verschoben wird, sollte ihr Zugriff minimal oder gar nicht sein. so wie es in der Produktion wäre. Das ist eine perfekte Welt. Wenn Sie sich jedoch nicht darin befinden und Ihre Entwickler über höhere Berechtigungen verfügen, als Sie für erforderlich halten, würde ich ihre Konten überprüfen. Ich würde alles und jedes erfassen, was sie bis zu einem gewissen Grad tun. Falls also auf Ihrem Produktionsserver etwas schief geht, können Sie zurückgehen und genau herausfinden, was sie getan haben.

15
user507

Wenn Sie externen behördlichen Kontrollen oder Standards (SOX, PCI usw.) unterliegen, dann Sie

  • wird ein Audit nicht bestehen
  • schlagen bei Ihren monatlichen PCI-Prüfungen fehl

Entwickler sollten db_owner in einem SQL Server-Netzwerk nur für die Entwicklung haben.

Wenn sich Ihre SQL Server alle im Netzwerk mit einem Standard-Build befinden (d. H. Dasselbe Dienstkonto), überträgt sa in one allen Rechte.

Wenn das Dienstkonto ein lokaler Administrator ist, haben Ihre Entwickler auch die volle Kontrolle über die Server.

Es gibt keine Vorteile.

8
gbn

sa = sysadmin

Wenn Sie sich mit sa anmelden, kann der Benutzer alle folgenden Aktionen ausführen: - Datenbanken löschen und erstellen - Objekte in der Datenbank ändern - Anmeldungen löschen und erstellen - Kennwörter ändern - alle Daten löschen

Das Gewähren von Sysadmin-Berechtigungen für ein Windows-Konto führt dasselbe aus.

Die Liste geht weiter, aber dies sollte Ihnen ein paar gute Gründe geben, NIEMALS NIEMALS einen Nicht-Administrator sa verwenden zu lassen.

Sie sollten ein Windows- oder SQL-Konto mit den Mindestberechtigungen erstellen, die erforderlich sind, damit die Apps funktionieren. (d. h. Anmelden, Zugriff auf gespeicherte Prozeduren und Ansichten)

6
datagod

Die beste Vorgehensweise besteht darin, ein sicheres Passwort einzugeben und es zu vergessen.

5
garik

Ich habe momentan zwei Möglichkeiten im Kopf, warum man kein schwaches SA Konto haben sollte. Wenn Sie ein schwaches/leeres Passwort für SA) haben = eine böse Person (übersetze das zu 'freundlicher Kollege') könnte:

  • aktivieren Sie die Systemprozedur xp_cmdshell und richten Sie mithilfe der Berechtigungen des SQL Server-Dienstkontos Schäden an Ihrer lokalen Box an (Erstellen/Entfernen von Dateien ..). Geringe Sicherheit für SA sagt eigentlich nicht viel über die Instanzeinstellungen aus, könnte aber bedeuten, dass der Dienstbenutzer schlechte Praktiken befolgen könnte (wie ein Administrator zu sein :-));

  • aktivieren Sie E-Mails auf Ihrer Instanz und spulen Sie schnell ein kleines Spam-Fun-Skript vor (das wird Ihnen wahrscheinlich Probleme mit Ihrem Internetprovider oder Ihren Kollegen bereiten. Je nachdem, wohin die E-Mails gehen ;-));

Ich werde nicht auf die offensichtlichen Tatsachen hinweisen, dass es Datenbanken, Anmeldungen usw. löschen kann.

  • Ist das nicht im Wesentlichen dasselbe? Was sind die Vor- und Nachteile?
  • Nicht unbedingt: zB - Auf der SQL Server-Instanz Ihres Laptops bedeutet der Unterschied zwischen Windows-Authentifizierung und SQL-Authentifizierung, dass ein externer Angreifer theoretisch nur ein SQL-Konto verwenden kann, da die Windows-Authentifizierung nicht außerhalb Ihrer eigenen Domäne verwendet werden kann Konto. Ein Benutzer könnte benachbarte Laptops aus dem Einkaufszentrum scannen, in dem Sie Ihren Kaffee trinken, und möglicherweise feststellen, dass eine SQL-Instanz installiert und gestartet wurde, und versuchen, kostenlos Spaß zu haben. Es ist nicht so, dass es oft passieren könnte ... aber es ist eine Möglichkeit :-).

  • Wie erhöht die bewährte Methode die Sicherheit meiner SQL Server-Instanzen?

  • Da jede bewährte Praxis auf dieser Welt ihren Job macht, verringert sich die Wahrscheinlichkeit eines möglichen Nachteils (z. B. die beste Vorgehensweise bei körperlicher Aktivität verringert die Wahrscheinlichkeit, dass Sie wie ich sind ... eine Stubenhocker), die sonst auftreten könnte.

  • Gilt dies nur für Produktionsinstanzen oder auch für unsere internen Entwicklungsinstanzen?

  • Angenommen, ich würde vorschlagen, zumindest in der Produktion bewährte Sicherheitsmethoden (getestet und an die Anforderungen Ihrer Umgebung angepasst) zu implementieren. Wenn Sie jedoch in der Entwicklung auch Produktionsdaten (vertraulich usw.) verwenden, ist dies ein starkes Indiz dafür, dass Sie auch Ihre Entwicklungspraktiken ändern müssen.
1
Marian

Für Ihre letzte Frage verwenden wir SA Konten in allen unseren Entwicklungsdatenbanken (mit dem Passwort "sa"!).

Es ist jedoch wichtig zu beachten, dass wir die Daten nicht speichern und nicht generieren. Unsere Datenbanken werden ausschließlich für einen Datenspeicher für eine C/C++ - Anwendung verwendet. Diese Entwicklungsdatenbanken enthalten lediglich Testdaten und werden häufig erstellt, gelöscht, geändert usw. \

Ebenso wichtig ist, dass alle Entwicklungsdatenbanken auf Entwicklungsmaschinen installiert sind. (Mindestens eine Kopie pro Entwickler!) Wenn also jemand eine gesamte Installation durcheinander bringt, hat er nur sich selbst und sonst niemanden durcheinander gebracht.

Wenn es um eine Umgebung geht, in der Sie sicherstellen möchten, dass Ihre Datenbank, Tabellen und Daten tatsächlich konsistent und sicher sind, dann möchten Sie ein schönes, solides SA Passwort). Wenn Sie dieses schwach lassen, Dann hat jeder und jede uneingeschränkten Zugriff auf Ihre Daten und kann Ihre Datenbank vollständig zerstören.

Für eine Reihe von Entwicklern mit eigenen Kopien der Datenbank, die lediglich Testdaten enthalten, muss ich noch noch ein solides Argument für die Aufrechterhaltung eines starken Kontos SA) finden.

0
Richard

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, und was noch schlimmer ist, 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