Ist die Verwendung von Integrated Security (SSPI) für den Zugriff auf SQL Server für Webanwendungen besser?

Ist es beim Bereitstellen von Webanwendungen (.net) in einer Produktionsumgebung besser, integrierte Sicherheit zu verwenden, oder spielt dies überhaupt eine Rolle?

Es scheint mir, dass ein Hacker, der den Webserver beschädigt, keine Rolle spielt, da er sich leicht als Computer ausgeben kann.

Gedanken?

Ich würde sagen, es gibt nur zwei gültige Gründe für die Verwendung von SQL-Authentifizierung:

1. Sie verbinden sich von außerhalb der Domain, also integrierte Authentifizierung.
2. Sie führen einen TPC-C-Benchmark durch und jeder Zyklus zählt. SQL-Authentifizierung ist ein bisschen schneller.

In dem von Ihnen vorgeschlagenen Szenario (der Host des Webservers ist vollständig gefährdet) kann Sie nichts schützen. Der Hacker kann auf dem DB-Server mindestens alles tun, was der Webserver kann . Und ich würde sagen, dass eine gründliche Verteidigung Ihnen beibringen kann, den Verlust in einem solchen Fall zu minimieren: Reduzieren Sie die DB-Rechte des Kontos, das von Ihrem Webserver verwendet wird, auf das absolut erforderliche Minimum und nichts weiter. Stellen Sie zweitens sicher, dass der Webserver-Host, wenn er kompromittiert ist, nicht zum Erhöhen von Berechtigungen verwendet werden kann, die höher als das Webserver-Konto sind (dh es gibt keinen anderen Dienst auf dem WWW-Host, der Anmeldeinformationen mit höheren Berechtigungen für die Datenbank als das WWW-Konto verwendet). Dies sind grundlegende Sicherheitsprinzipien und haben nichts mit dem verwendeten Authentifizierungsschema zu tun.

Während die SQL-Authentifizierung im Vergleich zur Windows-Authentifizierung in Ihrem Szenario keinen klaren Vorteil bietet, gibt es andere zu berücksichtigende Punkte:

1. Durchsetzung zentraler Richtlinien: Sie haben einen Ort zum Einrichten Ihrer Kennwortrichtlinien, einschließlich Kennwortlebensdauer und -ablauf, Kontoauflösung usw.
2. Kontrolle über Identitätswechsel und Vertrauensdelegation. Sobald sql auth in einer Vertrauensdelegierungskette verwendet wird, sind alle Wetten deaktiviert, da dies keine echte "Delegierung" darstellt und daher nicht mehr den Einschränkungen unterliegt, die Ihre Richtlinien auferlegen
3. Auditing: SQL-Authentifizierung wird von Ihrem LSA nicht einmal gesehen, sodass Ihre gesamte Auditing-Infrastruktur einfach umgangen wird. Sie müssen die von SQL erzeugten Datensätze zu SQL-Authentifizierungsereignissen explizit hinzufügen, mischen jedoch Äpfel und Orangen, da diese Ereignisse unterschiedliche Quellen, Anbieter und Schemata im Ereignisprotokoll haben

Eine letzte Anmerkung: Das TDS-Protokoll legt das SQL-Authentifizierungskennwort im Klartext über dem Datenverkehr offen. Dies wird jedoch normalerweise durch die Anforderung einer SSL-Verschlüsselung des Datenverkehrs verringert.

Warum sehen Sie dann immer noch SQL-Authentifizierungs-WWW-Hosts, die das Kennwort in clear in der Datei web.config speichern? Das sind die schlechten Entwickler / Administratoren, sei keiner von ihnen.

msdn.microsoft.com/en-us/library/aa378326(VS.85).aspx

technet.microsoft.com/en-us/library/ms189067.aspx

Wenn Sie SSPI nicht verwenden, codieren Sie den Benutzernamen und das Kennwort fest in die Quelldateien.

Wenn Sie den Benutzernamen und das Kennwort fest in die Quelldateien schreiben, haben alle Ihre Mitarbeiter Zugriff darauf.

Das ist relativ unsicher. Ein verärgerter ehemaliger Mitarbeiter könnte die Informationen böswillig verwenden. Ein Besucher kann den Code irgendwo auf einem Bildschirm sehen. Oder der Quellcode könnte versehentlich in freier Wildbahn rauskommen.

Der Vorteil von SSPI ist, dass das Passwort niemals im Klartext gespeichert wird.

Die anderen Antworten waren bisher gut, aber ich werde eine andere einwerfen: Management.

Früher oder später werden Sie wahrscheinlich mit mehreren SQL-Servern enden. Das Verwalten der SQL-Authentifizierung zwischen Ihrer App und mehreren SQL-Servern ist etwas schmerzhaft, insbesondere wenn Sie auf Sicherheitsprobleme stoßen. Wenn Sie ein Windows-Authentifizierungskennwort einmal ändern, wird es sofort auf allen Servern geändert. Wenn Sie Ihre SQL-Authentifizierungskennwörter wechseln müssen, ist dies schmerzhafter - bis zu dem Punkt, an dem Sie dies wahrscheinlich gar nicht mehr tun werden. Das ist ein Sicherheitsrisiko.

Ich bin mir hier nicht zu 100% sicher, aber ich denke, der wichtigste Punkt ist, dass die SQL-Authentifizierung unsicher ist. Daher ist es besser, die Windows-Authentifizierung zu verwenden. Abhängig davon, wie Ihre App eingerichtet ist, können Sie die richtigen Anmeldeinformationen auch in verschlüsselter Form mit Windows-Authentifizierung auf dem Computer speichern. Ich denke nicht, dass das mit SQL-Authentifizierung wirklich möglich ist. Sie können es verschleiern, aber letztendlich muss es klar sein.

Nur weil ein Hacker in einen Server eindringen kann, ist das Spiel noch lange nicht vorbei. Ein Hacker erlangt möglicherweise die Kontrolle über einen nicht privilegierten Prozess, kann jedoch auf dem Server keine weiteren Aktionen ausführen. Aus diesem Grund ist es wichtig, nicht alles als Administrator oder System auszuführen, sondern Dienstkonten mit minimalen Rechten zu verwenden.

Das Beste, was zu tun ist, zu begrenzen, was sie tun können, wenn sie in den Webserver einbrechen. Dies bedeutet, dass nur die SQL-Rechte gewährt werden, die für die Funktion der Anwendung erforderlich sind. Es ist viel einfacher, der Anwendung DBO-Rechte zu erteilen, aber es macht die Datenbank im Falle eines erfolgreichen Angriffs auf den Webserver viel anfälliger.

Ich gehe vorab davon aus, dass es sich um einen internen Webserver im internen privaten Netzwerk handelt.

Beginnen wir mit dem Identitätswechsel der Maschine. Wenn die Identität des Anwendungspools Network Service ist und die .NET-Anwendung keinen Identitätswechsel aufweist, stellt die Webanwendung mithilfe des Computerkontos des Computers eine Verbindung zum Back-End-SQL-Server her. Und das würde bedeuten, dass Sie Zugriff auf dieses Computerkonto gewährt haben. Microsoft CRM funktioniert auf diese Weise.

Wenn Sie jedoch eine Identität angegeben haben, muss dieses Benutzerkonto auf den SQL Server zugreifen können. Sie haben zwar Recht, dass ein Angreifer, der den Webserver kompromittiert hat, tatsächlich denselben Zugriff wie das Identitätskonto hat, aber die Wahrheit ist, dass die Verwendung einer SQL Server-Anmeldung hier nichts ändert. Sobald ich Zugriff habe, kann ich die Webanwendung so ändern, dass sie das tut, was ich will, und zwar so weit, wie es Ihre Sicherheit auf dem Back-End-SQL-Server zulässt.

Jetzt erfahren Sie, warum Sie SSPI verwenden sollten. In erster Linie verwenden Sie keine SQL Server-basierte Anmeldung. Das heißt, Active Directory ist die einzige Quelle für Sicherheit. Das heißt, Sie haben die normalen Prüfmittel, um einen ungültigen Zugriff festzustellen. Zweitens bedeutet dies, dass Sie Ihren SQL Server nur im Windows-Authentifizierungsmodus lassen können, es sei denn, es gibt andere Apps, die dies erfordern. Das bedeutet, dass keine SQL Server-Anmeldungen zulässig sind. Das bedeutet, dass alle Angriffe gegen sa gestoppt werden, bevor sie überhaupt beginnen. Und schließlich erleichtert es die Genesung. Wenn Sie eine SQL Server-basierte Anmeldung verwenden, müssen Sie die Anmeldung mit SID und verschlüsseltem Kennwort extrahieren. Wenn Sie ein Windows-basiertes Benutzerkonto als "Dienstkonto" verwenden, erstellen Sie beim Wechseln zu einem neuen SQL Server die Anmeldung.

Die Frage ist, welche "besser" ist? Was schwer zu beantworten ist, da es sich auf den Kontext, die Werte und die Prioritäten des Fragestellers stützt.

Persönlich mag ich SQL auth.

• AD ist eine andere Sache, um Dienstkonten auszuführen und zu unterstützen und zu verwalten.
• AD muss in Ihrer Hosting-Umgebung verfügbar sein.
• AD würde es schwierig machen, in die Cloud oder Hybrid-Cloud zu wechseln.
• Mit AD können Sie Dienstkonten auf einfache Weise zu Gruppen hinzufügen, zu denen Administratoren in einem anderen Teil Ihrer Organisation keine Berechtigung haben sollten.
• SSPI umgeht das Problem der Verschlüsselung Ihrer Verbindungszeichenfolge nicht, da Sie Ihren SQL-Hostnamen in config verschlüsseln sollten.
• SQL-Authentifizierung ist einfach und nur Textkonfiguration, einfach bereitzustellen.
• Das Festlegen von App-Pool-Identitäten ist eine weitere Möglichkeit, den Benutzernamen und das Kennwort in diesen Automatisierungsskripten für jede Umgebung zu automatisieren und dann auszublenden.
• Durch die Verwendung von zwei Verbindungszeichenfolgen ist es einfach, fortlaufende Kennwörter zu verwenden, sodass Sie das Kennwort ohne Ausfallzeiten aktualisieren können.

Letzter Punkt: Sie codieren Ihre Verbindungsmanagerklasse, um jede Verbindungszeichenfolge zu testen. Auf diese Weise können Sie das Kennwort in der ersten in der Konfiguration ändern, die Änderung hinausschieben und ein Failover auf die zweite Verbindung durchführen. Anschließend aktualisieren Sie das Kennwort in MSQL und der erste wird wieder verwendet. Eine abschließende Konfigurationsänderung ist erforderlich, um das zweite Kennwort wie das erste festzulegen und für das nächste Mal vorzubereiten.

Wenn die Benutzer die Datenbank nicht direkt bearbeiten (über andere Client-Tools wie SQL Server Management Studio), erstelle ich in der Regel nur eine einzige SQL-Anmeldung für die Anwendung und erteile ihr den erforderlichen Zugriff. Zu diesem Zeitpunkt ist der Benutzer in seinen Handlungsmöglichkeiten auf der Web-App-Oberfläche eingeschränkt.