Pourquoi une application ne devrait-elle pas utiliser le compte sa
Ma première question, veuillez être douce. Je comprends que le compte sa permet un contrôle complet sur un serveur SQL et toutes les bases de données, utilisateurs, autorisations, etc.
Je suis absolument convaincu que les applications ne devraient pas utiliser le mot de passe sa sans une raison perfectionnée et axée sur l'homme d'affaires. Les réponses à cette question incluent beaucoup de mon raisonnement pour une discussion axée sur l'informatique
Je suis obligé d'accepter un nouveau système de gestion de services qui ne fonctionnera PAS à moins qu'il n'utilise le mot de passe sa. Je n'ai jamais eu le temps de comprendre pourquoi lors de la configuration d'une évaluation, mais l'équipe du serveur a essayé de l'installer pour utiliser un rôle fixe que j'avais configuré en incorporant db_creater et d'autres autorisations que je pensais que cela nécessiterait. qui a échoué. J'ai ensuite laissé l'équipe du serveur s'installer avec le compte sa mais s'exécuter sous un compte dans le rôle dbo pour sa base de données mais cela a échoué aussi. Grincheusement, j'ai essayé de le faire fonctionner avec un compte dans le rôle sysadmin, mais même cela a échoué et pas avec des messages d'erreur utiles qui m'ont permis de comprendre ce qui se passait sans passer plus de temps que je n'en disposais. Il ne fonctionnera qu'avec le compte sa et le mot de passe stocké en texte clair dans le fichier de configuration.
Lorsque j'ai posé cette question et que l'équipe du serveur a parlé au fournisseur, elle a obtenu la réponse inquiétante "Quel est le problème avec ça? puis "eh bien, nous pouvons regarder brouiller le mot de passe" brouillage ffs
Je sais qu'il existe des moyens de restreindre l'accès au fichier mais ce n'est qu'une autre faiblesse de la sécurité à mon avis
Quoi qu'il en soit, ma question est, quelqu'un pourrait-il m'indiquer une documentation que je peux utiliser pour expliquer à l'entreprise la raison pour laquelle c'est une mauvaise chose et devrait être un gros non non. Je travaille dans un domaine qui signifie que j'ai besoin de prendre la sécurité au sérieux et que j'ai eu du mal à faire comprendre l'entreprise et peut finalement être surclassé, mais je dois essayer.
Cela dépend de votre entreprise, mais l'essentiel dans la plupart des cas est de s'assurer qu'il est pas considéré comme un problème informatique. C'est un problème de sécurité et bien que les deux personnes qui se chevauchent massivement soient plus susceptibles d'écouter si vous dites "sécurité" que si vous "gémissez à propos de choses informatiques générales".
Travaillez-vous avec des clients qui ont des exigences de sécurité? C'est un bon point de départ. Si nous exécutions une application avec un accès de niveau SA, ou simplement une application qui ne sécurisait pas correctement ses informations d'identification même si nous n'utilisions pas un accès privilégié (nous préférons fortement Windows Integrated plutôt que l'utilisateur/passe stocké si possible), et nous étions soumis à une sécurité audit, cet audit échouerait et nous risquerions de perdre des clients et/ou de devoir reverser de l'argent quant aux clients de nos groupes (organismes bancaires dans le cas du produit sur lequel je travaille principalement, d'autres parties du groupe s'occupent de la police et de la santé autorités et ainsi de suite) la sécurité fait partie de notre offre étant adaptée à l'objectif. Les gens d'affaires comprendront comprennent la gravité de cette menace potentielle même s'ils ne paient généralement pas plus que les lèvres des recommandations informatiques.
Même en ignorant les exigences imposées par le client, si vous vous efforcez de répondre à diverses normes de sécurité standard de l'industrie, ce type d'authentification d'application va vous échouer face à un audit, car il est si loin des meilleures pratiques qu'il est généralement considéré comme quelque chose sur la liste "ne devrait tout simplement pas être fait". Expliquez clairement à vos décideurs professionnels que la sécurité est une partie importante de l'application, et le fait que ce fournisseur ne semble pas être au courant (ou du moins de manière appropriée) vous fait douter de quoi d'autre ils pourraient ne pas être capables traiter: connaître les meilleures pratiques de sécurité DB fait (bien, devrait) faire partie de leur travail et les mettre en œuvre n'est pas difficile.
Soulignez également que vous (l'acheteur) doit dicter des exigences de sécurité raisonnables au fournisseur, et non l'inverse. Ce sont vos données, elles ne sont donc pas qualifiées pour déclarer ce qui est considéré comme suffisamment sécurisé.
Aucune application n'a besoin d'avoir SA - jamais. (À moins que son seul but soit l'administration d'une base de données quelconque).)
C'est une règle générale de ne jamais accorder plus de droits à une connexion (application ou personnelle) que ce que l'entreprise requiert pour cette connexion.
Aucune application n'est complètement sécurisée. La plupart ont une sorte de vulnérabilité d'injection SQL ou XSS. Si un intrus parvient à exécuter une déclaration de son choix et dispose d'un accès "SA", il peut y avoir beaucoup de choses qui peuvent arriver à vos données qui pourraient tuer l'entreprise immédiatement. (Surtout si les données doivent être fiables car elles sont utilisées par les forces de l'ordre.) Demandez aux parties prenantes ce qu'elles devraient faire, si quelqu'un était en mesure de modifier délibérément même un seul enregistrement et que ces informations avaient été divulguées.
Désormais, avec l'accès "SA", non seulement la base de données de l'application pouvait être modifiée, mais également toutes les autres bases de données du système. Alors, demandez à vos parties prenantes ce qu'elles feraient si vous vouliez faire une copie de TOUTES vos bases de données et l'envoyer au journal. Parce que cela pourrait arriver si un employé mécontent découvre l'existence de cette faille de sécurité.
Le vendeur a déclaré qu'il pouvait brouiller le mot de passe. C'est BS. L'application doit accéder au mot de passe en texte clair pour l'utiliser, de sorte que la clé pour déchiffrer le mot de passe serait stockée non chiffrée juste à côté. De plus, comme mentionné précédemment, le vrai problème n'est pas que quelqu'un trouve ce mot de passe; c'est que les personnes (mal) utilisant ce système à travers une vulnérabilité auront un accès complet à toutes vos bases de données sans jamais voir le mot de passe.
La cause la plus probable pour SA étant requise est que l'application doit interagir avec l'Agent SQL. Au moins c'est l'une des fonctions les plus difficiles à implémenter correctement et la plupart des gens prennent simplement "utiliser SA" Il est possible que le fournisseur lui-même ne sache pas comment vérifier les autorisations sysadmin.
Vous pouvez essayer deux solutions:
Renommez SA (une meilleure pratique de sécurité de toute façon) et créez un nouveau compte appelé 'SA' avec des droits restreints. (Jamais essayé, mais cela devrait fonctionner)
N'installez pas le logiciel. En tant que professionnel, vous ne pouvez pas assumer la responsabilité de cette action, vous ne devez donc pas l'installer. Pour vous donner une comparaison, demandez à un plombier de faire passer la conduite de gaz directement à travers le foyer au lieu de le contourner pour économiser du tuyau/de l'argent. Vous vous moquez peut-être de cette image, mais je pense que c'est une comparaison appropriée - Ce logiciel explosera tôt ou tard, probablement plus tôt. Et quand c'est le cas, cela pourrait aussi faire chuter l'entreprise.
Si tout cela n'empêche pas "eux" d'exiger ce logiciel, la dernière recommandation que je puisse vous donner est de courir. Si quelque chose arrive aux données, vous serez le premier responsable. Donc, avec cette application en place, vous n'avez probablement aucune sécurité d'emploi, alors trouvez un employeur qui vous en donne au moins.
Je vois deux lignes d'attaquer cela.
Conformité. Y a-t-il des critères de conformité obligatoires en vigueur dans votre boutique? Recherchez attentivement sa formulation et voyez si vous trouvez quelque chose qui serait incompatible avec la "condition" de l'application. Si vous trouvez quelque chose qui empêche l'utilisation de
sapar une application, vous avez un boîtier étanche à l'eau, car l'application rendrait votre entreprise responsable, etc.Accès administrateur utilisateur. Assurez-vous de présenter clairement le cas où une application qui nécessite
saun accès donne en faitsaun accès à tous les utilisateurs de l'entreprise qui ont des droits d'administrateur sur les postes de travail où l'application est installée. Il n'y a aucun moyen de cacher le mot de passesaaux administrateurs locaux où l'application s'exécute, c'est-à-dire fait et aucune quantité de "brouillage" ne peut empêcher cela. Il n'y a pas de racine de confiance locale à laquelle un administrateur local ne peut pas accéder s'il le souhaite. Indiquez clairement que le fait d'avoir une application qui nécessitesaéquivaut à donnersades privilèges à tous les utilisateurs exécutant l'application. Expliquez ce que cela signifie, ce que les utilisateurs peuvent faire efficacement:- possibilité de lire toutes les données du serveur, non seulement à partir de cette application mais à partir de toute autre base de données hébergée sur ce serveur
- possibilité de modifier toutes les données sur le serveur, à nouveau à partir de toute autre base de données sur le même serveur
- pouvoir effacer toute trace de ses actions après une modification
- pouvoir modifier tout audit et historique pour faire apparaître que certaines actions ont été effectuées par un utilisateur différent
- possibilité d'utiliser les informations d'identification SQL Server pour intensifier une attaque sur toute autre ressource qui fait confiance à ce serveur. Cela peut impliquer tout autre serveur SQL, mais également d'autres ressources, y compris, mais sans s'y limiter, les partages de fichiers, les serveurs d'échange, etc., car le serveur SQL peut être utilisé comme un tremplin.
Expliquez aux décideurs que l'acceptation de cette application implique de confier chaque employé qui a un accès administrateur aux postes de travail exécutant l'application avec tous les privilèges mentionnés ci-dessus. Le vendeur tentera de défendre sa position en invoquant une sorte ou une autre de "chiffrement" du mot de passe sa pour l'application. Cela ne retient pas l'eau. Aucun schéma de chiffrement ne peut résister à une attaque d'un administrateur. Et précisez que la quantité de compétences techniques requises pour trouver un mot de passe localement "caché" est complètement hors de propos. Les employés ne le feront pas eux-mêmes, l'un d'eux cherchera sur Google et découvrira le script facile à utiliser qui le fait.
Tout d'abord, le mot de passe sa stocké en clair? Vous devriez voter avec votre portefeuille. Quiconque pense que cela est acceptable doit être mis hors service.
Voici une anologie qui pourrait vous aider à expliquer le problème: l'employée Alice doit avoir accès au premier étage. Lui donnez-vous la clé principale de tout le bâtiment ou juste la clé du premier étage? Réponse: Vous lui donnez juste les clés du premier étage. Pourquoi? Parce qu'il réduit les risques de dommages accidentels ou délibérés. Si Alice ne peut pas accéder à la salle des serveurs du deuxième étage, elle ne fera jamais rien de mal là-dedans.
C'est le principe du moindre privilège.
Quant à savoir pourquoi l'application doit utiliser le compte sa, c'est une question à laquelle PerfMon ou Extended Events devrait pouvoir répondre. Créez une trace PerfMon à l'aide du modèle T-SQL, peut-être filtrée par nom d'application.
Sur le haut de ma tête, voici un autre argument contre l'utilisation de sa: L'utilisation du compte sa nécessite que le service SQL Server soit en mode d'authentification mixte. Seule l'authentification Windows est meilleure car nous pouvons tirer parti de toutes les fonctionnalités sécurisées de Kerberos.
D'un point de vue technique, il n'y a aucune raison pour qu'une application ait besoin d'autorisations SA. Ce qui s'est probablement passé, c'est que les développeurs de l'application vérifient probablement si leur connexion dispose d'autorisations sysadmin et sinon, il suffit renvoie un message d'erreur. De cette façon, ils peuvent prétendre que l'application requiert des droits SA.
Si vous devez avoir cette application, je l'exécuterai sur une instance distincte qui ne contient rien d'autre.
Peut-être que votre fournisseur demande/requiert "sa", car quelque part dans son application, il utilise XP_CMDSHELL. (Ne me lancez pas sur les dommages possibles avec un accès illimité à XP_CMDSHELL. Il suffit de dire que cela ouvre potentiellement non seulement vos données, mais la machine hôte et, peut-être, tout autre élément de votre réseau à un accès de type administrateur)
S'il y a un besoin légitime, vous pouvez accorder un accès restreint via un compte proxy. Voir, par exemple, BOL: http://msdn.Microsoft.com/en-us/library/ms175046.aspx
Aucune application ne devrait nécessiter le compte SA et le mot de passe pour fonctionner.
Cependant, j'ai installé un produit de gestion des services informatiques et, pendant le processus d'installation, vous avez la possibilité de fournir les informations d'identification du compte SA pour permettre au programme d'installation de créer la base de données et d'attacher un compte à la base de données. pour le logiciel à utiliser. Les informations d'identification du compte SA ne sont enregistrées nulle part dans les journaux de l'application ou du programme d'installation. Ce logiciel offre également la possibilité d'utiliser une base de données pré-créée lors de l'installation.
Je voudrais donc simplement confirmer si le compte SA est requis pour l'installation ou le fonctionnement de ce logiciel de gestion des services informatiques.
Si Installation: créez un compte 'sa' temporaire - faites l'installation - et supprimez le compte.
Si opération: évitez ce logiciel comme la peste. (ou configurez un serveur SQL autonome qui hébergera uniquement cette base de données.)
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
En revanche, 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