Diese Frage weist darauf hin, dass für verschiedene DMVs (dynamische Verwaltungsansichten) die Berechtigung „Serverstatus anzeigen“ erforderlich ist, ich jedoch nichts über Sie finden kann tun und wollen nicht die Erlaubnis erteilen.

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 verwenden kann, um Abfragen zu betrachten. Wenn die Abfragen oder Abfrageparameter vertrauliche Informationen enthalten können, die der Benutzer sonst nicht sehen würde, würde das Zulassen von VIEW SERVER STATE dies ermöglichen (dh dob = oder ssn =).

Antwort

Es gibt keine wesentlichen Leistungsprobleme, die mir bei der Erteilung dieser Berechtigung einfallen. Aus Sicherheitsgründen besteht die Gefahr, dass ein Benutzer sieht, was Sie sind Die meisten Details zu Ihren Schwachstellen, z. B. könnte ein böswilliger Benutzer Ihre häufigsten Wartestatistiken anzeigen, die ihm dabei helfen könnten, einen DoS-Angriff auf Ihren Server zu starten.

Ist dies möglich? Auf jeden Fall. Ist dies der Fall wahrscheinlich? Ich bin gezwungen, Nein zu sagen, aber denken Sie daran, dass schätzungsweise 90 Prozent der Angriffe gegen Unternehmen von internen Angreifern ausgehen.

Antwort

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 für die Entwicklung Die Entwicklungsorganisation möchte diese Informationen für ein großes Legacy-System, das sie unterstützen, indem sie Zombietabellen identifiziert, die beispielsweise nur von Wartungsprozessen berührt werden.

Am Ende geht es immer um „Glück und Großzügigkeit“. da die Aufforderung, ob eine bestimmte Anfrage gerechtfertigt ist, eine weiche Wahl und keine klare Formel ist. Die Verwendung von Best-Practice-Mustern ohne Betrachtung 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.

Antwort

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

In Bezug auf:

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

Einfach ausgedrückt, sie können Dinge sehen das sollten sie vielleicht nicht sehen. 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 gewähren der Host-Computer (Hardware, Dienste usw.). 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 soll oder nicht.

Da Sie bereits erwähnt haben, dass Personen die erforderlichen Mindestberechtigungen erteilt werden, 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 (was nur das tut, wofür es codiert ist). 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 Sie EXECUTE für diese Module an alle Benutzer und / oder Rollen, die diese Aktionen ausführen müssen
  3. Zertifikat erstellen
  4. Signieren Sie die Module mit diesem Zertifikat (mit ADD SIGNATURE)
  5. Kopieren Sie das Zertifikat in die Datenbank [master] (dh erstellen Sie mit dem öffentlichen Schlüssel ein Zertifikat in [master] des Zertifikats, mit dem die Module signiert wurden.
  6. Erstellen Sie eine Anmeldung aus dem Zertifikat, das nach [master]
  7. kopiert wurde. Level permissio Für diese zertifikatbasierte Anmeldung sind ns erforderlich (einschließlich des Hinzufügens zu Rollen auf Instanzebene).

Einige Beispiele finden Sie unter:

Antwort

Es ist ein Sicherheitsproblem. Sie können niemals etwas falsch machen, wenn Sie folgen dem Prinzip der geringsten Privilegierung . Mit anderen Worten, wenn ein authentifizierender Prinzipal keine bestimmte Berechtigung benötigt, dann don “ Geben Sie es ihnen nicht. 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 basieren würden, wären wir viel häufiger in größeren Schwierigkeiten. Sicherheit ist ein Problem Aspekt, bei dem 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. . Tun Sie es nicht. Der Serverstatus ist immer noch vertraulich.

Kommentare

  • Wer sagt, dass sie es unnötig weitergeben? Das OP muss möglicherweise gewähren Es liegt an jemandem, ein bestimmtes Problem zu untersuchen (z. B. sys.dm_db_missing_index_details) und er möchte wissen, welche Risiken genau damit verbunden sind.
  • Ich denke, ich ' Fehlt die Markierung mit dieser Frage, ' sehe in der Frage nichts, was auf die Notwendigkeit der Erlaubnis hinweist.
  • @ThomasStringer: Die Frage ist nicht ' t über Notwendigkeit, es ' geht es um Risiko Um es monetär auszudrücken, wissen Sie möglicherweise, welchen zusätzlichen Risiken dies Ihre Server aussetzen würde, und können daher Nein zu einem Penny und Ja zu einer Million Dollar sagen. Ich don ' t, aber ich möchte.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.