Conséquences sur la sécurité et les performances de «Afficher l'état du serveur»

Cette question souligne que l'autorisation "Afficher l'état du serveur" est requise pour divers DMV (vues de gestion dynamique), mais je ne trouve rien sur qui vous faites et ne souhaitez pas accorder l'autorisation.

Maintenant, bien sûr, je comprends les "moindres autorisations" et pourquoi vous ne voudriez pas simplement les accorder à quiconque, mais je ne trouve aucune indication sur la façon d'évaluer si elles DEVRAIENT être accordées ou non.

Donc, ma question: quelles sont les implications en termes de sécurité et de performances de l'octroi à un utilisateur de l'autorisation "Afficher l'état du serveur". Que peuvent-ils faire qu'ils ne devraient peut-être pas être autorisés à faire ...

Mise à jour : une implication est que l'utilisateur pourra utiliser les DMV pour regarder les requêtes. Si les requêtes ou les paramètres de requête peuvent contenir des informations confidentielles que l'utilisateur ne pourrait pas voir autrement, autoriser VIEW SERVER STATE leur permettrait de le faire (c'est-à-dire dob = ou ssn =).

Il n'y a aucun problème de performance significatif auquel je peux penser en accordant cette autorisation. Du point de vue de la sécurité, vous courez le risque de laisser un utilisateur voir ce que vous avez le plus de détails sur vos points faibles.Par exemple, un utilisateur malveillant pourrait voir vos statistiques d'attente les plus courantes, ce qui pourrait les aider à cibler une attaque DoS contre votre serveur. .

Est-ce possible? Absolument. Est-ce probable? Je suis obligé de dire non, mais rappelez-vous que l'on estime que 90% des attaques contre les entreprises proviennent d'agresseurs internes.

En tant qu'administrateur, vous considéreriez ces informations comme faisant partie de votre domaine (performances / utilisation de l'index / etc.), mais il existe des raisons potentiellement convaincantes qu'une organisation de développement souhaiterait ces informations pour un grand système hérité qu'elles prennent en charge - identifier les tables zombies qui ne sont touchées que par des processus de maintenance par exemple.

En fin de compte, cela finit toujours par être une question de «chance et de générosité», car l'appel à savoir si une demande particulière est justifiée finit par être un choix doux et non une formule précise. L'utilisation de modèles de meilleures pratiques sans regarder le contexte est en soi un anti-modèle assez désagréable et la réalité est que beaucoup approchent leurs positions avec "parler à la main" comme point de départ.

En ce qui concerne les implications en termes de performances, je n'en ai connaissance d'aucune autorisation ni d'aucune autre.

En ce qui concerne:

Que peuvent-ils faire qu'ils ne devraient peut-être pas être autorisés à faire

Autrement dit, ils peuvent voir des choses qu'ils ne devraient peut-être pas voir. Et ne pensez pas à cela en termes de SQL Server. Cette autorisation particulière régit également les DMV tels que sys.dm_os_sys_info et plusieurs autres qui fournissent un aperçu de la machine hôte (matériel, services, etc.). Vous ne savez pas toujours quelles informations peuvent être utilisées contre vous. Et, même si vous êtes d'accord avec quelqu'un qui voit tout ce qui est autorisé par cette autorisation maintenant, parfois des DMV sont ajoutés dans les Service Packs / mises à jour cumulatives, et donc peut-être qu'une nouvelle information est exposée dont vous n'êtes pas au courant.

Je ne trouve aucune indication sur la façon d'évaluer si elle DEVRAIT être accordée ou non.

Puisque vous avez déjà mentionné de donner aux gens les autorisations minimales nécessaires, ce à quoi cela se résume vraiment: quelqu'un a-t-il besoin de cette autorisation pour une utilisation ad hoc ? Cela signifie-t-il que quelqu'un a besoin de la flexibilité nécessaire pour proposer ses propres requêtes? La création d'une ou plusieurs procédures stockées et / ou TVF multi-instructions fonctionnerait-elle? Si c'est le cas, vous n'avez pas besoin d'accorder d'autorisations à n'importe quel utilisateur (qui est alors libre de tout ce qui est autorisé par cette autorisation), et à la place, vous accordez les autorisations au code (qui ne fait que ce pour quoi il est codé). La signature du module est la façon dont vous y parvenez. Le concept général est le suivant:

1. Créez la ou les procédures stockées et / ou les TVF à instructions multiples pour effectuer l'action ou les actions souhaitées.
2. Accordez EXECUTEces modules à l'utilisateur et / ou aux rôles nécessaires pour effectuer ces actions
3. Créer un certificat
4. Signez le ou les modules à l'aide de ce certificat (à l'aide de ADD SIGNATURE)
5. Copiez le certificat dans la [master]base de données (c'est-à-dire créez un certificat en [master]utilisant la clé publique du certificat utilisé pour signer le (s) module (s)).
6. Créez une connexion à partir du certificat copié dans [master]
7. Accordez les autorisations au niveau de l'instance nécessaires à cette connexion basée sur un certificat (ce qui peut inclure son ajout aux rôles au niveau de l'instance).

Pour quelques exemples, veuillez consulter:

• Comment maintenir la restauration de la propriété de la base de données entre les domaines?

• Utilisez en toute sécurité et facilement des autorisations de haut niveau sans les accorder à quiconque: au niveau du serveur

C'est un problème de sécurité. Vous ne pouvez jamais vous tromper si vous suivez le principe des moins privilégiés . En d'autres termes, si un principal d'authentification n'a pas besoin d' une autorisation particulière, ne lui donnez pas cette autorisation. Donnez-vous des informations sur le type de serrures sur votre porte à d'autres personnes qui n'ont pas besoin de savoir cela sur votre maison? J'espère que non. Ils ne feraient probablement rien, mais ce n'est toujours pas prudent.

Si nous basions les principes de données sur la chance et la générosité, nous aurions beaucoup plus de problèmes plus souvent. La sécurité est un aspect où vous ne devez accorder que lorsque vous pouvez défendre la raison pour laquelle vous avez accordé. Vous donnez simplement à quelqu'un plus d'informations qu'il n'en a besoin . Ne le fais pas. L'état du serveur est toujours sensible.