Implications sur la sécurité et les performances de “ Afficher létat du serveur ”

Il ny a pas de problèmes de performances importants auxquels je puisse 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 la plupart des détails sur vos points faibles, par exemple, un utilisateur malveillant pourrait consulter vos statistiques dattente les plus courantes, ce qui pourrait les aider à cibler une attaque DoS contre votre serveur.

Est-ce possible? Certainement. probable? Je suis obligé de dire non, mais rappelez-vous que 90% des attaques contre les entreprises sont le fait d’attaquants internes.

En tant quadministrateur, vous verriez ces informations comme appartenant à votre domaine (performances / utilisation de lindex / etc.), mais il existe des raisons potentiellement convaincantes pour Une organisation opérationnelle voudrait ces informations pour un grand système hérité quelle prend en charge, identifiant les tables zombies qui ne sont touchées que par les processus de maintenance par exemple.

En fin de compte, cela finit toujours par être un problème de « chance et de générosité » puisque lappel à savoir si une demande particulière est justifiée finit par être un choix souple et non une formule claire. Lutilisation de modèles de bonnes pratiques sans regarder le contexte est en soi un anti-modèle assez méchant et la réalité est que beaucoup abordent leurs positions avec « parler à la main » comme point de départ.

En ce qui concerne les implications sur les performances, je nen connais aucune pour cette autorisation ou toute autre autorisation.

Concernant:

Que peuvent-ils faire quils ne devraient peut-être pas faire?

En termes simples, ils peuvent voir des choses que peut-être quils ne devraient pas voir. Et ne pensez pas à cela uniquement en termes de SQL Server. Cette autorisation particulière régit également les DMV tels que sys.dm_os_sys_info et bien dautres qui fournissent des informations sur 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 daccord pour que quelquun voie maintenant tout ce qui est autorisé par cette autorisation, parfois des DMV sont ajoutés dans les Service Packs / Mises à jour cumulatives, et donc peut-être quune nouvelle information est exposée dont vous nêtes pas au courant.

Je ne trouve « aucune indication sur la manière dévaluer si elle DEVRAIT être accordée ou non.

Puisque vous avez déjà mentionné loctroi aux gens des autorisations minimales nécessaires, ce que cela revient en fait est: quelquun a-t-il besoin de cette autorisation pour une utilisation ad hoc ? Cela signifie que quelquun a-t-il besoin de la flexibilité de formuler ses propres requêtes? La création dune ou plusieurs procédures stockées et / ou TVF multi-instructions fonctionnerait-elle? Si tel est le cas, vous n’avez pas besoin d’accorder des autorisations à un 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é). Module Signing est la façon dont vous accomplissez cela. Le concept général est:

1. Créez la (les) procédure (s) stockée (s) et / ou les TVF multi-instructions pour effectuer les actions souhaitées.
2. Accorder EXECUTE sur ces modules à tous les utilisateurs et / ou rôles nécessaires pour effectuer ces actions
3. Créer un certificat
4. Signez le ou les modules en utilisant ce certificat (en utilisant ADD SIGNATURE)
5. Copiez le certificat dans la base de données [master] (cest-à-dire créez un certificat dans [master] à laide de 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 nimporte quelle instance- niveau permis ns sont nécessaires à cette connexion basée sur un certificat (ce qui peut inclure son ajout à des rôles au niveau de linstance).

Pour quelques exemples, veuillez consulter:

• Comment conserver la propriété de la base de données en restaurant sur domaines?

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

Cest « un problème de sécurité. Vous ne pouvez jamais vous tromper si vous suivez le Principe du moins privilégié . En dautres termes, si un mandant dauthentification na pas «  besoin dune autorisation particulière, alors ne le faites pas » Donnez-vous des informations sur le type de serrure de votre porte à dautres personnes qui nont pas besoin de savoir cela à propos de votre maison? Jespère que non. Ils ne feraient probablement rien, mais ce n’est toujours pas prudent.

Si nous fondions les principes de données sur la chance et la générosité, nous serions un peu plus souvent en difficulté. La sécurité est un problème aspect où vous ne devriez accorder que lorsque vous pouvez défendre pourquoi vous avez accordé. Vous « donnez simplement à quelquun plus dinformations quil nen a besoin de savoir . Ne le faites pas. Létat du serveur est toujours sensible.

Commentaires

• Qui a dit quil le distribuait inutilement? LOP pourrait avoir besoin daccorder à quelquun pour enquêter sur un problème spécifique (par exemple, regarder sys.dm_db_missing_index_details) et ils veulent savoir quels sont exactement les risques de le faire.
• Je suppose que je ‘ m manque la marque avec cette question, je ne ‘ rien voir dans la question qui indique la nécessité de lautorisation.
• @ThomasStringer: la question nest ‘ t sur la nécessité, elle ‘ sur risque . Pour le dire en termes monétaires, vous savez peut-être à quels risques supplémentaires cela exposerait vos serveurs, et vous pourrez ainsi dire non à un centime, et oui à un million de dollars. Je ne ‘ t, mais je veux.