Auswirkungen von "Serverstatus anzeigen" auf Sicherheit und Leistung

Diese Frage weist darauf hin, dass für verschiedene DMVs (Dynamic Management Views) die Berechtigung "Serverstatus anzeigen" erforderlich ist. Ich kann jedoch nichts darüber finden, wem Sie die Berechtigung erteilen und wem nicht.

Jetzt verstehe ich natürlich "geringste Berechtigungen" und warum Sie es nicht einfach irgendjemandem gewähren möchten, aber ich kann keine Anleitung finden, wie zu bewerten ist, ob es gewährt werden SOLLTE oder nicht.

Meine Frage: Welche Auswirkungen hat die Erteilung der Berechtigung "Serverstatus anzeigen" für einen Benutzer auf Sicherheit und Leistung? Was können sie tun, was sie vielleicht nicht tun dürfen ...

Update : Eine Implikation ist, dass der Benutzer DMVs zum Anzeigen von Abfragen verwenden kann. Wenn die Abfragen oder Abfrageparameter vertrauliche Informationen enthalten können, die der Benutzer sonst nicht sehen könnte, würde das Zulassen von VIEW SERVER STATE dies ermöglichen (dh dob = oder ssn =).

Es gibt keine wesentlichen Leistungsprobleme, die mir bei der Erteilung dieser Berechtigung einfallen. Unter Sicherheitsgesichtspunkten besteht die Gefahr, dass ein Benutzer sieht, was Sie am meisten über Ihre Schwachstellen wissen. So kann beispielsweise ein böswilliger Benutzer Ihre häufigsten Wartestatistiken anzeigen, um einen DoS-Angriff auf Ihren Server zu starten .

Ist das möglich? Bestimmt. Ist das wahrscheinlich? Ich muss Nein sagen, aber denken Sie daran, dass schätzungsweise 90 Prozent der Angriffe auf Unternehmen von internen Angreifern ausgehen.

Als Administrator würden Sie diese Informationen als in Ihrer Domäne befindlich ansehen (Leistung / Indexnutzung / usw.), aber es gibt möglicherweise zwingende Gründe, warum eine Entwicklungsorganisation diese Informationen für ein großes Legacy-System wünscht, das sie unterstützen - die Identifizierung von Zombietabellen, die nur berührt werden zum Beispiel durch Wartungsprozesse.

Am Ende ist es immer ein Thema von "Glück und Großzügigkeit", da die Frage, ob eine bestimmte Anfrage gerechtfertigt ist, eine weiche Wahl und keine klare Formel ist. Die Verwendung von Best-Practice-Mustern ohne Berücksichtigung des Kontexts ist selbst ein ziemlich unangenehmes Anti-Muster, und in Wirklichkeit nähern sich viele ihren Positionen mit "Talk to the Hand" als Ausgangspunkt.

In Bezug auf die Auswirkungen auf die Leistung sind mir keine für diese oder andere Genehmigungen bekannt.

Bezüglich:

Was können sie tun, was sie vielleicht nicht tun dürfen?

Einfach ausgedrückt, sie können Dinge sehen, die sie vielleicht nicht sehen sollten. Und denken Sie nicht nur an SQL Server. Diese spezielle Berechtigung gilt auch für DMVs wie sys.dm_os_sys_info und einige andere, die Einblicke in den (Hardware, Dienste usw.) bieten. Sie wissen nicht immer, welche Informationen gegen Sie verwendet werden können. Und selbst wenn Sie damit einverstanden sind, dass jemand jetzt alles sieht, was mit dieser Berechtigung zulässig ist, werden manchmal DMVs in Service Packs / kumulativen Updates hinzugefügt, sodass möglicherweise eine neue Information angezeigt wird, die Sie nicht kennen.

Ich kann keine Anleitung finden, wie zu bewerten ist, ob es gewährt werden SOLLTE oder nicht.

Da Sie bereits erwähnt haben, dass Personen die erforderlichen Mindestberechtigungen erteilen müssen, kommt es darauf an: Benötigt jemand diese Berechtigung für die Ad-hoc- Nutzung? Bedeutet das, dass jemand die Flexibilität benötigt, seine eigenen Fragen zu stellen? Würde das Erstellen einer oder mehrerer gespeicherter Prozeduren und / oder TVFs mit mehreren Anweisungen funktionieren? Wenn ja, müssen Sie keinem Benutzer Berechtigungen erteilen (der dann für alles, was durch diese Berechtigung zulässig ist, frei ist), und stattdessen erteilen Sie die Berechtigungen für den Code (der nur das tut, wofür er codiert ist). Mit der Modul-Signierung erreichen Sie dies. Das allgemeine Konzept lautet:

1. Erstellen Sie die gespeicherten Prozeduren und / oder TVFs mit mehreren Anweisungen, um die gewünschten Aktionen auszuführen.
2. Gewähren EXECUTE diese Module allen Benutzern und / oder Rollen, die zum Ausführen dieser Aktionen erforderlich sind
3. Erstellen Sie ein Zertifikat
4. Signieren Sie die Module mit diesem Zertifikat (mit ADD SIGNATURE)
5. Kopieren Sie das Zertifikat in die [master]Datenbank (dh erstellen Sie ein Zertifikat unter [master]Verwendung des öffentlichen Schlüssels des Zertifikats, mit dem die Module signiert wurden.
6. Erstellen Sie eine Anmeldung aus dem Zertifikat, in das kopiert wurde [master]
7. Gewähren Sie für diese zertifikatbasierte Anmeldung alle erforderlichen Berechtigungen auf Instanzebene (einschließlich des Hinzufügens zu Rollen auf Instanzebene).

Einige Beispiele finden Sie unter:

• Wie kann die Wiederherstellung des Datenbankbesitzes domänenübergreifend aufrechterhalten werden?

• Verwenden Sie Berechtigungen auf hoher Ebene sicher und einfach, ohne sie jemandem zu erteilen: auf Serverebene

Es ist ein Sicherheitsproblem. Sie können niemals etwas falsch machen, wenn Sie dem Prinzip der geringsten Privilegierung folgen . Mit anderen Worten, wenn ein Authentifizierungs - Haupt nicht benötigt eine besondere Genehmigung, geben Sie es dann nicht zu ihnen. Geben Sie Informationen über die Art der Schlösser an Ihrer Tür an andere Personen weiter, die das über Ihr Haus nicht wissen müssen? Ich würde nicht hoffen. Sie würden wahrscheinlich nichts tun, aber es ist immer noch nicht umsichtig.

Wenn wir Datenprinzipien auf Glück und Großzügigkeit gründen würden, wären wir viel häufiger in größeren Schwierigkeiten. Sicherheit ist ein Aspekt, den Sie nur gewähren sollten, wenn Sie verteidigen können, warum Sie gewährt haben. Sie geben einfach jemandem mehr Informationen, als er wissen muss . Tu es nicht. Der Serverstatus ist weiterhin vertraulich.