Pourquoi est-ce une mauvaise pratique de permettre à tout le monde d'utiliser la connexion sa?

Même Microsoft décourage l'utilisation du mode d'authentification SQL Server , mais nos applications l'exigent.

J'ai lu qu'il est préférable de ne pas laisser les utilisateurs utiliser la saconnexion directement, plutôt d'utiliser l'authentification Windows et d'accorder à ces comptes (ou groupes de comptes) les privilèges sysadmin.

• N'est-ce pas essentiellement la même chose? Quels sont les avantages / inconvénients?
• Comment la meilleure pratique augmente-t-elle la sécurité de mes instances SQL Server?
• Cela s'applique-t-il uniquement aux instances de production, ou à nos instances de développement interne également?

Vous avez plusieurs questions différentes ici, donc je vais les assommer individuellement:

"J'ai lu qu'il est préférable de ne pas laisser les utilisateurs utiliser directement la connexion sa, plutôt d'utiliser l'authentification Windows"

Vous mélangez deux choses ici: le concept de SA et le concept d'authentification SQL et d'authentification Windows.

L'authentification SQL est une liste de noms d'utilisateur et de mots de passe qui sont stockés dans chaque serveur SQL. Le fait qu'il soit stocké en SQL est le premier problème. Si vous devez changer le mot de passe d'une connexion, vous devez le changer sur chaque serveur (ou conserver des mots de passe différents sur différents serveurs). Avec l'authentification Windows, vous pouvez désactiver de manière centralisée les connexions, modifier les mots de passe, définir des politiques, etc.

Si vous choisissez d'utiliser l'authentification SQL, SA n'est qu'une seule connexion d'authentification SQL. Il s'agit du nom d'utilisateur administrateur par défaut, tout comme l'administrateur est dans l'authentification Windows. Il a des super-pouvoirs locaux sur cette seule instance, mais pas de super-pouvoirs globaux sur toutes les instances.

"... et en accordant à ces comptes (ou groupes de comptes) les privilèges d'administrateur système."

Quelle que soit la méthode d'authentification que vous choisissez, idéalement, vous voulez suivre le principe du moindre privilège: accorder aux gens les droits minimaux dont ils ont besoin pour faire leur travail, et pas plus.

Ne les considérez pas comme de simples connexions - ce sont des gens qui peuvent vous faire virer. S'ils abandonnent la base de données ou désactivent accidentellement vos travaux de sauvegarde, ils ne seront pas renvoyés, car par défaut, SQL ne suit pas qui a fait quoi. C'est vous qui serez licencié parce que ça va arriver, et vous ne pourrez pas dire qui l'a fait.

"Comment la meilleure pratique augmente-t-elle la sécurité de mes instances SQL Server?"

Vous voulez faire deux choses:

1. Empêchez les gens de casser le serveur
2. Lorsqu'ils cassent le serveur, être en mesure d'identifier exactement qui l'a fait

Le premier est accompli avec le principe du moindre privilège: ne donner aux gens que les autorisations dont ils ont besoin, et rien de plus.

La seconde consiste à donner à chaque personne sa propre connexion, à ne pas autoriser les connexions partagées (comme laisser tout le monde utiliser le même nom d'utilisateur / mot de passe) et, idéalement, à auditer les connexions. Vous ne ferez probablement pas cette dernière partie tout de suite, car c'est un peu douloureux, mais mettons les pièces en place en premier afin de pouvoir ajouter un audit plus tard après que quelqu'un ait déposé une base de données et que votre patron veuille savoir pourquoi.

Je sais ce que vous pensez: "Mais nous codons des applications, et l'application a besoin d'une connexion." Oui, donnez à l'application sa propre connexion, et les développeurs doivent connaître ce mot de passe, mais cette connexion doit être tellement privée d'autorisations que personne sensé ne voudrait l'utiliser. Par exemple, il peut être nécessaire qu'il soit uniquement dans les rôles db_datareader et db_datawriter, rien d'autre. De cette façon, il peut insérer, mettre à jour, supprimer et sélectionner des données, mais pas nécessairement modifier les schémas, ajouter des index, modifier les procédures stockées, etc.

"Est-ce que cela s'applique uniquement aux instances de production, ou à nos instances de développement internes?"

Je pense que cela s'applique tout autant aux instances de développement, car je m'inquiète généralement des gens qui cassent des choses. Les gens adorent casser les serveurs en cours de développement. Et bien sûr, quand il est temps de regrouper la liste des modifications pour migrer vers la production, j'ai besoin de savoir si un index particulier est vraiment vital pour l'application ou si certains bonehead viennent d'exécuter le Database Tuning Advisor et lui ont dit d'appliquer toutes les modifications . Des autorisations appropriées aident à atténuer cette douleur.

En fait, si vous lisez ce livre blanc: séparation des tâches SQL Server

Il vous indiquera que PERSONNE ne devrait utiliser les privilèges sysadmin sur son compte. Votre compte d'accès quotidien doit bénéficier d'un accès minimum, et non de droits administrateur explicites. Étant donné leur, CONTROL SERVER est en fait proche de ce qu'est sysadmin et vous permet ensuite de refuser l'accès DENY / REVOKE là où il n'en a pas besoin. L'octroi de droits d'administrateur système à quiconque devient un problème si vous devez respecter les normes de conformité informatique. La plupart des normes nécessitent une utilisation minimale du rôle sysadmin.

Je désactive et renomme le compte "sa", comme vous le feriez avec le compte administrateur intégré sur le système d'exploitation. À utiliser uniquement en cas d'urgence.

Les développeurs ont généralement un accès complet à leur environnement de développement. Ensuite, lorsque leur programme est déplacé vers une instance de pré-production, leur accès doit être minimal ou nul; tout comme ce serait en production. C'est un monde parfait. Si toutefois vous n'êtes pas là-dedans et que vos développeurs ont des privilèges plus élevés que vous ne croyez en avoir besoin, j'auditerais tous leurs comptes. Je capturerais tout et tout ce qu'ils font dans une certaine mesure. Donc, en cas de problème lors de leur présence sur votre serveur de production, vous pouvez revenir en arrière et savoir exactement ce qu'ils ont fait.

Si vous êtes soumis à des contrôles ou normes réglementaires externes (SOX, PCI, etc.), vous

• échouera à un audit
• échouent dans vos vérifications PCI mensuelles

Les développeurs doivent avoir db_owner sur un réseau SQL Server uniquement pour le développement.

Si vos serveurs SQL sont tous sur le réseau avec une version standard (c'est-à-dire le même compte de service), alors sa en un leur confère tous des droits.

Si le compte de service est administrateur local, vos développeurs ont également un contrôle total sur les serveurs.

Il n'y a aucun avantage.

sa = sysadmin

La connexion avec sa permet à l'utilisateur d'effectuer toutes les opérations suivantes: - supprimer et créer des bases de données - modifier des objets dans la base de données - supprimer et créer des connexions - changer les mots de passe - supprimer toutes les données

Accorder des privilèges sysadmin à un compte Windows accomplit la même chose.

La liste continue, mais cela devrait vous donner quelques bonnes raisons de ne JAMAIS JAMAIS laisser un non-administrateur utiliser sa.

Vous devez créer un compte Windows ou SQL avec les privilèges minimums nécessaires pour faire fonctionner les applications. (c.-à-d. connexion, accès aux procédures stockées et aux vues)

La meilleure pratique consiste à utiliser un mot de passe fort et à l'oublier.

J'ai deux options en tête en ce moment, pour lesquelles on ne devrait pas avoir un compte SA faible. Si vous avez un mot de passe faible / vide pour SA, une personne maléfique (traduisez-le en «collègue amical») pourrait:

• activer la procédure système xp_cmdshell et, en utilisant les privilèges du compte de service Sql Server, endommager votre boîte locale (créer / supprimer des fichiers ..). Le fait d'avoir une sécurité faible pour SA ne dit pas grand-chose sur les paramètres d'instance, mais pourrait impliquer que l'utilisateur du service pourrait suivre de mauvaises pratiques (comme être administrateur :-));

• activez le courrier sur votre instance et avancez rapidement un petit script amusant de spam (qui vous causera probablement des problèmes soit avec votre fournisseur d'accès Internet, soit avec vos collègues ... selon l'endroit où les courriers vont ;-));

Je ne soulignerai pas les faits évidents qu'il peut supprimer des bases de données, des connexions ... etc.

• N'est-ce pas essentiellement la même chose? Quels sont les avantages / inconvénients?

• Pas nécessairement: par exemple - sur l'instance SQL Server de votre ordinateur portable, la différence entre l'authentification Windows et l'authentification SQL signifie qu'en théorie, un attaquant externe ne pourrait utiliser qu'un compte SQL, car l'authentification Windows ne peut pas être utilisée en dehors de votre propre domaine Compte. Un utilisateur peut analyser les ordinateurs portables voisins du centre commercial où vous buvez votre café et peut voir que vous avez une instance SQL installée et démarrée et peut essayer de s'amuser gratuitement. Ce n'est pas que cela puisse arriver souvent ... mais c'est une possibilité :-).

• Comment la meilleure pratique augmente-t-elle la sécurité de mes instances SQL Server?

• Comme chaque meilleure pratique dans ce monde fait son travail ... diminue les chances d'un éventuel inconvénient (par exemple: la meilleure pratique de faire de l'activité physique diminuera les chances que vous soyez comme moi .. une pomme de terre de canapé) qui pourrait se produire autrement.

• Cela s'applique-t-il uniquement aux instances de production, ou à nos instances de développement interne également?

• Supposons que je suggère d'implémenter les meilleures pratiques de sécurité (testées et modifiées en fonction des besoins de votre environnement) au moins en production. Mais si dans le développement, vous utilisez également des données de production (sensitive..etc), c'est une forte indication que vous devez également modifier vos pratiques de développement.

Pour répondre à votre dernière question, nous utilisons des comptes SA sur toutes nos bases de données de développement (avec le mot de passe "sa", à ça!)

Cependant, il est essentiel de noter que nous ne stockons pas les données et que nous ne générons pas les données. Nos bases de données sont uniquement utilisées pour un magasin de données pour une application C / C ++. Ces bases de données de développement contiennent uniquement des données de test et sont fréquemment créées, supprimées, modifiées, etc. \

De plus, tout aussi critique, toutes les bases de données de développement sont installées sur des machines de développement. (Une copie par développeur, au moins!) Donc, si quelqu'un gâche une installation entière, il n'a fait que gâcher lui-même, et personne d'autre.

Lorsqu'il s'agit d'un environnement dans lequel vous voulez vous assurer que votre base de données, vos tables et vos données sont réellement cohérentes et sûres, vous voulez un bon mot de passe SA solide. Si vous laissez cela faible, n'importe qui et tout le monde ont un accès complet à vos données et peuvent complètement détruire votre base de données.

Pour un groupe de développeurs avec leurs propres copies de la base de données qui contiennent uniquement des données de test, je toujours ai encore trouvé un argument solide pour le maintien d' un solide compte SA.

Tout paramètre de sécurité système SQL Server par défaut fourni doit être modifié. Il est recommandé de ne pas utiliser le mode mixte (active à la fois l'authentification Windows et SQL Server) pour l'authentification. Au lieu de cela, passez à l'authentification Windows uniquement - qui appliquera la stratégie de mot de passe Windows - vérification de la longueur, de la durée de vie et de l'historique du mot de passe. La fonctionnalité de la stratégie de mot de passe Windows qui la différencie de l'authentification SQL Server est le verrouillage de la connexion - après plusieurs tentatives de connexion infructueuses, la connexion devient verrouillée et inutilisable pour une utilisation ultérieure

D'un autre côté, l'authentification SQL Server ne fournit aucune méthode pour détecter les tentatives d'attaque par force brute, et pire encore, SQL Server est même optimisé pour gérer un grand nombre de tentatives de connexion rapide. Donc, si l'authentification SQL Server est indispensable dans un système SQL Server particulier, il est fortement recommandé de désactiver la connexion SA