Ich hatte gerade ein Interview in Redmond, wo sie mir eine Menge sicherheitsbezogener Fragen zu asp.net stellten. Eine der Fragen, die sie stellten, bestand darin, eine sichere Intranetanwendung so zu konfigurieren, dass eingeschränkte Delegierung für den Zugriff auf SQL Server verwendet wurde. In diesem Szenario ist ein AD-Benutzerkonto delegierter Zugriff auf den SQL Server. Der ganze Zweck besteht natürlich darin, a) keinen Benutzernamen / Passwort irgendwo auf dem Webserver (web.config) zu speichern, und b) ein abstrahiertes Sicherheitsmodell bereitzustellen, das in Active Directory verwaltet werden kann.
Das hat mich dazu gebracht darüber nachzudenken, wie ich meine Seiten all die Jahre für den anonymen Zugang konfiguriert habe. Normalerweise werde ich meine IIS-Websites unter Verwendung des standardmäßigen anonymen Kontos ausführen und die Verbindungszeichenfolge in web.config speichern (verschlüsselt und manchmal im Klartext). Dies erfordert natürlich, dass Ihr SQL Server im gemischten Modus ausgeführt wird. Meine Frage ist also, ob wir die Verbindungszeichenfolge überhaupt in web.config gespeichert haben und nur ein eindeutiges anonymes Domänenkonto für die bestimmte Website erstellt haben, auf die db_datareader in SQL Server zugreifen würde. Gibt es einen Grund, warum es eine schlechte Idee wäre, dies zu tun?
Ich habe versucht, an all die Szenarien zu denken, wo dies eine schlechte Idee wäre, und die einzige, die mir einfällt, ist, wo ein "Hacker" den Code auf dem Webserver kompromittiert hat und dann irgendwie Zugriff auf Ihr SQL hat Server ... aber das könnte in beiden Szenarien passieren.
Kennt jemand die beste Praxis hier?
Wo ich arbeite, haben wir einen Windows-Dienst, der unter einem bestimmten Domänenkonto läuft. Dieses Konto wird in SQL Server als Anmeldung eingerichtet und hat einen übereinstimmenden Benutzer in der Datenbank, auf die es zugreifen muss. Wir hatten damit nie Probleme.
Ich denke, das Wichtigste ist, Ihren Datenbankbenutzer (oder seine Rolle) richtig zu konfigurieren, damit er nur auf das zugreifen kann, was er benötigt.
Ich habe die Verwendung von AD in Betracht gezogen, um den SQL-Zugriff auf ähnliche Weise zu verwalten, die Sie in Ihrem ersten Absatz beschrieben haben. (AD-Gruppe - & gt; SQL Server-Anmeldung - & gt; DB-Benutzer - & gt; DB-Objekte) Der einzige Nachteil, den ich bisher sehen kann, ist, wenn ein Benutzer direkt mit der Datenbank verbunden ist, würden sie jede Logik umgehen, die Sie in Ihrer App haben. Ein Vorteil ist, dass Sie wissen, welche Domänenbenutzer auf Ihre Datenbank zugreifen.
Vielleicht könnten Sie ODBC verwenden, um einen DSN für die SQL Server-Verbindung zu erstellen. Dann muss Ihre web.config nur den DSN kennen. Dies erfordert möglicherweise, dass Sie System.Data.OleDb verwenden. Ich habe noch nie gesehen, DSN in ASP.NET verwendet, aber es war ziemlich Standard für Classic ASP. Und ich habe noch nie gehört, dass Active Directory zur Verwaltung von ODBC verwendet wird.