Durchgreifen der SQL Server-Sicherheit

Ich arbeite jetzt seit 2 Jahren als SQL Server-DBA für eine Stadt.

Ich wurde hinzugezogen, um einen bestehenden DBA zu unterstützen, also habe ich langsam alles in mich aufgenommen und habe eine Weile gearbeitet, um Glaubwürdigkeit in der Organisation zu erlangen. Es ist Zeit, das schwierigste und wichtigste Problem anzugehen: Sicherheit.

Unser Hauptserver ist ein Failovercluster mit SQL 2005. Es enthält 166 Datenbanken. Es bedient ungefähr 550 Verbindungen mit App-Pooling für die meisten Anwendungen, sodass problemlos Tausende von Benutzern unterstützt werden. Wir bedienen auch eine öffentliche Website, auf der ziemlich viel Verkehr herrscht. Hersteller-Apps, Inhouse-Apps, Zugriff auf Back-Ends - eine große Auswahl mit einigen kritischen Anwendungen.

Viele Entwickler haben Produktionszugriff . Änderungen werden außerhalb des RFC-Prozesses vorgenommen, und wir haben keine Ahnung, welche Daten von Entwicklern geändert werden. Sie genießen auch den Zugriff auf die Produktion während der Implementierung von Systemen - was ich auch gerne stoppen würde.

Bei so vielen laufenden Anwendungen würde jeder vernünftige DBA den Server sperren .

Wie würden Sie ein Entwicklerteam von einer offenen Sicherheit zu einer restriktiveren Umgebung überführen?

Ich arbeite an einem Notfallanforderungssystem, das ihnen für eine begrenzte Zeit Zugriff auf ihre Datenbank (en) gewährt. Dies würde uns die Prüfung von Zugriffs- und DDL-Änderungen ermöglichen. Hoffentlich wird dies nicht verwendet, da wir nicht auf eine Seite geantwortet haben. Es wird HTTP, verschlüsselte Webkonfiguration, Login / Pwd auf dem Bildschirm (keine E-Mail) verwendet und eine Drosselung auf 3 pro 12 Stunden angefordert. Wir würden auch angerufen, wenn ein Login ausgestellt wird.

Irgendwelche Warnungen zu diesem Systemtyp?

Das größte Risiko, das ich sehen kann, besteht darin, dass wenn das ntlogin eines Benutzers kompromittiert würde - dies auch seine Datenbanken wären. Wir haben diese Sicherheitslücke im Moment, da sie immer Zugriff haben, aber nie wissen würden, ob es passiert ist.

Änderungen: Entwicklung und Staging sind robuste Systeme mit 8 Kernen und 8 GB Speicher. Planen Sie die Implementierung eines PRD-STG-Kopiermechanismus, den Entwickler verwenden können, wenn ihre Datenbank nicht umfangreich ist und keine vertraulichen Informationen enthält.

Das Management ist unterstützend. Wenn wir ihnen in Notfällen den Zugang garantieren können, ist ihre größte Sorge erledigt. Das andere Problem könnte sein, während der Implementierungen Zugriff auf die Produktion zu haben - was ich lieber nicht geben würde. Wir können den Übergang zum Staging zuerst üben und während des Go-Live dort testen und korrigieren - wobei DBAs auf prd migrieren.

Ich habe in meiner Firma mit der gleichen Sache gearbeitet. Ich fand tatsächlich, dass die meisten Menschen dafür empfänglicher waren als ich dachte, aber ein paar Dinge waren entscheidend:

• Erinnern Sie sie daran, dass der Hauptzweck darin besteht, Unfälle zu vermeiden. Unfälle sind etwas, mit dem sich jeder identifizieren kann. Fast niemand glaubt, dass sie jemals gehackt werden, und wenn man über interne Hacker spricht, werden sie sofort in die Defensive gedrängt ("Vertraust du mir nicht?").
• Reagieren Sie schnell auf Anfragen, wenn sie auf einen Block stoßen.
• Sei bereit, mit ihnen zu arbeiten. Wir stellten fest, dass einige der Dinge, die ich anfangs gesperrt hatte, für ihre Arbeit benötigt wurden und keine Probleme verursachten, wenn sie wieder ein wenig geöffnet würden.
• Seien Sie konsequent. Sie müssen diese Richtlinien universell anwenden. Wenn möglich, wenden Sie sie auch auf sich selbst an.

Ich habe auch versucht, dies in kleineren Schritten zu tun, um es weniger störend zu machen. Zum Beispiel:

• Alle neuen Datenbanken haben jetzt von Anfang an restriktive Berechtigungen. Sie vermissen nicht, was Sie noch nie hatten.
• Entfernen Sie zunächst sysadmin und andere Rechte auf Serverebene, sofern diese derzeit vorhanden sind. Die meisten Leute werden zustimmen, dass sie den Server nicht neu konfigurieren müssen, und es werden viele Sicherheitslücken beseitigt. Sobald sie gesehen haben, dass sie damit leben können, schafft es die Voraussetzungen für eine schrittweise Verschärfung.
• Verschärfen Sie jeweils die Datenbanken einer Anwendung. Dies macht es für Sie übersichtlicher und ermöglicht es Ihnen, im Laufe der Zeit zu erfahren, welche Rechte sie benötigen, damit die zukünftige Straffung reibungsloser verläuft.

Viel Glück!

Setzen Sie zunächst einen DDL-Trigger ein, um alle auftretenden Schemaänderungen zu erfassen. Protokollieren Sie einfach jeden DDL-Befehl, der ausgeführt wird, und schauen Sie sich an, wer und wann.

Sie werden vielleicht feststellen, dass die Dinge nicht ganz so schlimm sind, wie es scheint. Finden Sie heraus, wer die meisten Änderungen vorantreibt, und holen Sie sie an Bord. Danach sollten Sie in der Lage sein, die Dinge besser zu binden.

Legen Sie außerdem eine Ablaufverfolgung an, um festzustellen, was von Anwendungen ausgeführt wird, die nicht Ihre richtigen Apps sind. Sehen Sie sich die Felder ApplicationName und / oder HostName im Trace an. Auf diese Weise erhalten Sie ein Feld für Ad-hoc-Abfragen. Dann sollten Sie in der Lage sein herauszufinden, wer häufig einspringt, um Daten zu hacken.

Ich würde immer zuerst damit beginnen, diese Art von Situation zu überwachen. Sperren Sie es bald, aber beginnen Sie jetzt mit der Überwachung, um ein Bild davon zu erhalten, wie groß das Problem ist.

Das ist ein ernstes Unterfangen. Diese Leute sind wahrscheinlich sehr, sehr engagiert und es wird viel Unterstützung von ihren Vorgesetzten erfordern, um dies zu ändern. Haben sie bereits eine Testumgebung? Ich gehe davon aus, dass sie es tun, aber wenn sie es nicht tun, sollte dies der erste Schritt sein. Stellen Sie außerdem sicher, dass es an Schnupftabak liegt. Wenn es alt und langsam ist, werden sie zusammenzucken, wenn sie gezwungen werden, es zu benutzen. Sie müssen bereit sein, ihnen in anderen Bereichen wie dem Test einen Knochen zuzuwerfen, um sie diplomatisch aus dem Weg zu räumen.

Treffen Sie sich mit den Hauptentwicklern und erfahren Sie, warum Sie Zugang zur Produktion haben. Die meisten kennen Sie wahrscheinlich schon. Dann entfernen / adressieren Sie ihre Gründe. Ich gehöre zu einem Entwicklerteam, das über vollständigen Produktionszugriff auf Server verfügt, und ich weiß, dass ich ihn nicht haben sollte. Ich habe bisher gesehen, dass drei meiner Kollegen aufgrund von überstürztem SQL oder Selbstgefälligkeit erhebliche Störungen verursachen. "Wir müssen Änderungen sofort implementieren" - "Schreiben Sie ein Skript, ich werde es überprüfen und ausführen, wenn es in Ordnung ist." "Wir brauchen Live-Daten" - "Ernsthaft? Oder reicht das Backup der letzten Nacht?" "Ich muss das testen, um zu sehen, ob es funktioniert" - "Begrüßen Sie Ihren neuen virtuellen Testserver."

Wir hatten bisher drei Unfälle, und ich bin sicher, wir werden mehr haben, da unsere Sicherheitsverriegelung noch weit entfernt ist.

Sie sagen, Sie arbeiten für eine Stadt, aber ich kann mir nicht sicher sein, ob Sie ein Regierungsangestellter, eine Vertragsfirma oder sogar ein Land sind, in dem Sie sich befinden.

Wenn Sie diese Änderung vornehmen möchten (und wirklich, sollten Entwickler nicht nie haben alle Zugriff auf die Live - Umgebung [Ich bin ein Senior - Entwickler BTW]) , dann müssen Sie die Sicherung von Management zu Ihrem Amateur - Entwickler in Linie zu erhalten (nämlich die Die Produktions-DB ist für die Produktion bestimmt, nicht für Sie, um herauszufinden, warum Ihr halbherziger Code nicht funktioniert, indem Sie zufällige Abfragen ausführen, um zu sehen, was passiert.

Ich würde Ihnen wärmstens empfehlen, zu prüfen, ob eines davon für Ihre Organisation gilt:

SOX (Sarbanes-Oxley Act, gilt für börsennotierte Unternehmen in den USA)
Bill 198 (Provinz Ontario und indirekt der Rest Kanadas über CSA-Regeln)
CLERP-9 (Australien)
J-SOX (Japan)

All dies tun dasselbe, um sicherzustellen, dass die den Aktionären gemeldeten Finanzdaten so frei von Betrug wie möglich sind. Ein Element ist die Trennung von Verantwortlichkeiten - in der IT bedeutet dies, dass Entwickler niemals direkten Zugriff auf das Lesen oder Schreiben von Produktionsdaten haben sollten. Alle Aktionen müssen von den Serveradministratoren ausgeführt werden, einschließlich schriftlicher und signierter Anforderungen (Implementierungsformulare), die zu Überwachungszwecken aufbewahrt werden müssen.

In allen Fällen wird das Management sehr schnell an Ihre Seite kommen - unter SOX wird das Management zur Rechenschaft gezogen (Gefängniszeit!), Wenn keine geeigneten "Kontrollen" vorhanden sind.

Ihre größte Sorge wird sein, dass sich Anwendungen mit unangemessenen Konten anmelden, z. B. dba. Sie müssen Ihre Verbindungen überprüfen, bevor Sie die Tür zuschlagen.

Es ist sehr schwierig, Entwickler vom SQL-Zugriff in der Produktion abzuhalten, also machen Sie den Zugriff so plötzlich und scharf wie möglich. Wenn Sie die Unterstützung des Managements haben, ist Diplomatie nicht das Hauptproblem. Sicherheit und Zuverlässigkeit sind wichtiger als alles andere.

Wenn Sie nett sein müssen, setzen Sie sich mit allen Entwicklern zusammen und sagen Sie ihnen, was passieren wird und wie die Prozesse im Notfall ablaufen werden. Stellen Sie regelmäßige Sicherungen der Produktionsdaten für das Staging bereit. Sie können dort sicher mit den Daten spielen.

Im Notfall können Sie jederzeit ein Backup für das Staging wiederherstellen. Sie können die erforderlichen Änderungen skripten, testen und Ihnen das Skript senden.

Ich bin ein Entwickler, der Produktionszugriff auf eine Datenbank hatte. Das Ausführen einer Update-Anweisung und das Vergessen der where-Klausel ist sooo einfach.

Wenn Sie nicht so hart sein möchten, sollten schreibgeschützte Rechte an der Datenbank ein guter Zwischenschritt sein.

Ich muss es als Entwickler da rauswerfen.

Ich hasse dich.

Die Tatsache, dass DBAs uns daran hindern wollen, Arbeit zu leisten, ist idiotisch. Wir haben freie Hand über das System. Also sperrst du mein Konto? Alles, was ich tun muss, ist, die Produktionsverbindungszeichenfolge in meinem Debug-Code von Visual Studio abzulegen, und los geht's und ich kann alles steuern, was die Anwendung tun kann.

Diese Idee, dass das Beschränken von Entwicklern auf die Produktionsdatenbank jegliche Sicherheit bietet, ist eine dumme Überzeugung.

Als Entwickler würde ich empfehlen, anstatt zu versuchen, sie vollständig aus der Datenbank zu entfernen (insbesondere für die Kosten für das Unternehmen während der Bereitstellung), stattdessen eine Richtlinie zu übernehmen, nach der alle Skripts erforderlich sind, die große Aktualisierungen / Löschungen / Einfügungen verursachen müssen vom db-Team überprüft werden.

Wie Rob sagte, protokollieren Sie die gesamte DDL in der Datenbank. Sollten Entwickler gegen diese Regel verstoßen, melden Sie dies dem Management und lassen Sie sie mit der Situation umgehen.

Das einzige, wovor Sie die Datenbank vor Entwicklern schützen müssen, ist eine schlecht geschriebene Join-Anweisung, die eine ganze Tabelle anstelle der 100 Datensätze aktualisiert, die sie eigentlich haben sollte, weil wir beim Schreiben von SQL scheiße sind, weil wir nicht auf den Tag warten können, an dem Datenbanken nicht warten. gibt es nicht mehr in unserem Leben.