2009-01-30 11 views
9

Ich hatte gerade ein Interview in Redmond, wo sie mich eine Tonne Fragen zu Sicherheit Fragen rund um asp.net fragte. 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 ist natürlich, a) keinen Benutzernamen/Passwort irgendwo auf dem Webserver zu speichern (web.config) und b) ein abstrahiertes Sicherheitsmodell bereitzustellen, das in Active Directory verwaltet werden kann.Anonymer Zugriff (IIS) und SQL Server

Das brachte mich dazu, 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 alle Szenarien zu denken, wo dies eine schlechte Idee wäre, und die einzige, die ich denke, ist, wo ein "Hacker" den Code auf dem Webserver kompromittiert hat, und irgendwie Zugriff auf Ihre SQL Server ... aber das könnte in beiden Szenarien passieren.

Kennt jemand die beste Praxis hier?

Antwort

1

Wo ich arbeite, haben wir einen Windows-Dienst, der unter einem bestimmten Domänenkonto ausgeführt wird. 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 die Rolle) richtig zu konfigurieren, damit er nur auf das zugreifen kann, was er benötigt.

Ich habe überlegt, AD zu verwenden, um SQL-Zugriff auf ähnliche Weise zu verwalten, die Sie in Ihrem ersten Absatz beschreiben. (AD-Gruppe -> SQL Server-Anmeldung -> DB-Benutzer -> DB-Objekte) Der einzige Nachteil, den ich bisher sehen kann, ist, dass ein Benutzer, der direkt mit der Datenbank verbunden ist, jede Logik Ihrer App umgehen würde. Ein Vorteil ist, dass Sie wissen, welche Domänenbenutzer auf Ihre Datenbank zugreifen.

+0

Im ersten Absatz erwähne ich eingeschränkte Delegation. Dies erfordert ein Domänenkonto und nimmt die Identität eines Benutzers an, dessen Zugriff auf den SQL Server "beschränkt" ist, nichts anderes in der Farm. In diesem Szenario ist Ihr Benutzer nicht in der Lage, direkt über die App auf SQL zuzugreifen. –

2

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.

Verwandte Themen