Pour une base de données d'applications Web, à partir d'un point de vue de sécurité Si quelqu'un intercepte le compte d'application DB, la surface exposée à une attaque est beaucoup moins importante puis lorsque des tables et des vues ne sont pas exposées. Quels avantages de sécurité une offre de solution non SP (ou non)? Je vois de nombreux avantages à utiliser une solution non SP, mais l'exposition de toutes les tables me laisse un peu inquiet.
La question concerne les principaux produits de base de données de base de données en général, mais plus précisément, SQL Server 2008.
9 Réponses :
Eh bien, je suppose que vous avez vraiment capturé le cœur du problème vous-même: si vous n'utilisez pas de procédures stockées pour toutes les opérations de CRUD, vous devez accorder au moins un compte d'utilisateur DB spécifique à une application au moins sélectionner des droits sur toutes les tables. .
Si vous souhaitez autoriser le compte db à faire encore plus de travail, ce compte pourrait également avoir besoin d'une autre autorisation, comme la mise à jour et éventuellement supprimer sur certaines tables.
Je ne vois pas comment une approche de procédure non stockée aurait des avantages de sécurité - il ouvre la porte un peu plus, la question est vraiment la suivante: pouvez-vous vous permettre? Pouvez-vous sécuriser suffisamment de compte DB spécifique de l'application afin qu'il ne compromettrait pas la sécurité globale de votre système?
Un compromis possible peut être d'utiliser des vues ou un accès à la table pour autoriser sélectionner, mais gérer tout le reste (mises à jour, suppressions, inserts) à l'aide de Procs stockés - Half Secure, à moitié pratique ...
Comme cela est souvent - il s'agit d'un compromis classique entre commodité (approche non-SP; utiliser une ormission éventuellement) et la sécurité (toute approche Sprat; probablement plus encombrante, mais un peu plus sûre).
marc
Merci. J'ai pensé à votre solution partielle - sélectionnez les tables, mises à jour de SPS. Avez-vous essayé cette approche? Quoi que ce soit imprévu et qui a causé des problèmes?
@Steve: Non, je n'ai jamais fait cette approche hybride. Mon emploi précédent était tout-Sprat - sûr, mais une douleur à travailler contre. Mon actuel est tout accès à la table directe - pratique mais pas terriblement sûr ....
C'est l'une de ces zones où la sagesse conventionnelle est correcte: Exposer uniquement les procédures stockées vous donne plus de contrôle sur la sécurité. Donner un accès direct aux tables et à des vues est plus facile et il y a des moments où vous devez le faire, mais cela va être moins sûr.
D'un point de vue de sécurité uniquement, je ne peux voir aucun avantage d'une approche non-SP aurait sur une approche SP car:
Le plus grand avantage de sécurité à n'utiliser pas de procédures stockées est la clarté. Vous savez exactement quel compte peut faire, en voyant quel accès aux tables qu'il a. Avec des procédures stockées, ce n'est pas nécessairement le cas. Si un compte a la possibilité d'exécuter la procédure X, cela limite le compte à l'exécution et ne pas frapper une table sous-jacente, mais X peut faire n'importe quoi. Il pourrait supprimer des tables, modifier des données, supprimer des données, etc.
Pour savoir quel compte peut faire avec des procédures stockées, vous devez examiner la procédure stockée. Chaque fois qu'une SPTP est mise à jour, quelqu'un devra examiner ce qu'il fait pour s'assurer que quelque chose ne s'est pas passé "accidentellement" placé dedans. Le vrai problème avec la sécurité des Sprates vient de l'intérieur de l'organisation, pas d'attaquants voyous.
Voici un exemple:
Disons que vous essayez de restreindre l'accès à la table des employés. Sans procédures stockées, vous venez de refuser l'accès à la table. Pour avoir accès à une personne à peu près à vous demander de manière flagrante d'accorder des autorisations. Bien sûr, ils pourraient vous amener à exécuter un script pour accorder un accès, mais la plupart des gens essaient au moins d'examiner un script qui modifie le schéma de base de données (en supposant que le script ne mettra pas à jour une SPTP, que je vais parler ci-dessous).
Il existe potentiellement des centaines de procédures stockées pour une application. D'après mon expérience, ils sont mis à jour assez fréquemment, ajoutez un champ ici, en supprimez celui-ci. Pour que quelqu'un examine le nombre de scripts de procédure de mise à jour, tout le temps devient décourageant et, dans la plupart des organisations, l'équipe de base de données commence à examiner rapidement la procédure (ou ne pas le regarder tout) et le déplacer). C'est là que se trouve le vrai problème. À présent, dans cet exemple, si une personne sur le personnel informatique souhaite permettre un accès à une table, cette personne doit simplement glisser dans une ligne de code accordant un accès ou de faire autre chose. Dans un monde parfait, cela se ferait attrapé. La plupart d'entre nous ne travaillent pas dans un monde parfait.
Le vrai problème avec les procédures stockées est qu'ils ajoutent un niveau d'obfuscation au système. Avec Obfuscation, il vient de complexité et la complexité vient finalement plus de travail pour comprendre un système sous-jacent administratif. La plupart des gens de celui-ci sont surchargés et les choses glissent. Dans ce cas, vous n'essayez pas d'attaquer le système pour avoir accès, vous utilisez la personne responsable du système pour obtenir ce que vous voulez. Mitnick avait raison, dans la sécurité, les gens sont le problème.
Les attaques majoritaires contre une organisation viennent de l'intérieur. Chaque fois que vous introduisez la complexité dans n'importe quel système, les trous apparaissent, les choses peuvent être négligées. Ne croyez pas cela, pensez à votre travail. Parcourez les étapes sur qui vous demanderiez d'avoir accès à un système. Très bientôt, vous réalisez que vous pouvez amener les gens à oublier les choses au bon moment. La clé pour pénétrer avec succès un système avec des personnes impliquées est de faire quelque chose qui semble inoffensif, mais est vraiment subversive.
N'oubliez pas que si j'essaie d'attaquer un système: je ne suis pas votre ami; Je n'ai aucun intérêt pour vos enfants ou vos passe-temps; Je vais vous utiliser de quelque manière que ce soit nécessaire pour obtenir ce que je veux; Je m'en fiche si je te trahis. L'idée de "mais il était mon ami et c'est pourquoi je lui fais confiance de croire ce qu'il faisait était correct" n'est pas un réconfort après le fait.
Clarté pour qui? Si l'équipe DB est responsable de l'accès à la DB, les Devs ne doivent même jamais connaître le nom des objets de base de données (tables). Je ne sais pas pourquoi avoir Devs voir le code DB est un avantage de sécurité.
Obfuscation n'est pas une sécurité. C'est comme dire que dire que les voleurs ne trouveront pas les bijoux, parce que je l'ai caché dans le placard. Si je veux vraiment briser quelque chose de ne pas savoir que le schéma est une contrariété mineure, pas un obstacle. Mon point est que n'utiliser pas Sprates conserve la sécurité simple, ce qui est le plus gros facteur dans la sécurisation d'un système. Moins de modifications apportées au système de DB rendent le système plus sûr du présent point de vue, car la possibilité de quelque chose d'être négligé est moins. Changer la fonctionnalité des Sprates Chaque version augmente les chances que quelque chose va manquer.
Si vous avez Inline SQL, vous êtes plus sensible à l'injection SQL, mais avec Sprates, il est simplement stocké dans une variable et n'affecte pas la structure de l'appel.
Vrai, mais c'est une faiblesse de l'application d'appel, non pas avec la base de données elle-même. Si vous utilisez Dynamic SQL dans Sprates, vous pouvez être aussi susceptible d'injection SQL avec une SPTP.
@Kevin: Vous ne voyez toujours pas comment n'utiliser pas Sprats le rend "plus" plus sûr ou de sécurité "plus" simple. Si le seul accès autorisé est l'exécution de SP, je peux vérifier tout mon code SQL au même endroit et déterminer ce que les procs accédent quels objets - je ne peux pas faire cela si j'ai permis de sélectionner la permission sur une table à un utilisateur - qui sait quelles requêtes ils écrivent.
@Kev tu penses à petite. Ne pensez pas à l'audit de votre code pense à l'audit de l'audit de 30 personnes. Déterminer ce que chaque SproC fait et quelles tables il accède. Sur des systèmes compliqués, j'ai vu des Sprates facilement plus de 100 lignes de code. Avec l'accès à la table, vous pouvez distinguer rapidement si quelqu'un peut voir certaines informations: Steve n'a pas accès à la table des employés, Steve ne peut pas obtenir ces données. Avec SproCs: Steve ne peut pas accéder à la table des employés, mais Steve a accès à l'exécution de ces 25 SproCs. Maintenant, vous devez parcourir 25 procédures différentes pour voir s'il a accidentellement eu accès.
@Kevin: Et vous pensez trop étroit :) Steve n'a peut-être pas accès à la table mais SUE fait, et Steve a blagué le mot de passe de Sue d'elle. Je suppose que nous devrons accepter de ne pas être en désaccord - je n'appliquerai jamais les autorisations de niveau de table sur mes bases de données, et vous écrirez toujours SQL dans le code - espérons que nous ne finirons jamais de travailler pour la même entreprise :) (Bien que le DBA I gagner)
@Kev en fait, je joue à l'avocat du diable sur celui-ci. :) La collusion est une tâche difficile à battre. J'écris beaucoup de procédures stockées, mais l'un de mes emplois est également de pirater des systèmes. Je suis très bien sûr à savoir comment glisser des choses anciennes Qa et les équipes de DB et montrer des faiblesses dans les processus.
En plus de la séparation de sécurité traditionnelle avec des procédures stockées (autorisation d'exécution sur les procédures, repose sur la chaînage de propriété pour l'accès aux données) Les procédures stockées peuvent être Code signé , entraînant un contrôle d'accès très granulaire et spécifique à toutes les fonctionnalités de serveur tels que serveurs liés, Vues de gestion SPOPED Server , accès contrôlé à Procédures stockées et même des données dans d'autres bases de données en dehors de l'accès ordinaire de l'utilisateur.
Demandes ordinaires effectuées dans des lots T-SQL, quelle que soit la qualité de la fantaisie et le nombre de couches sur des couches de génération de code et orm, il ne peut tout simplement pas être signé et ne peut donc pas utiliser l'un des et Mécanismes de contrôle d'accès puissant disponibles.
Prenons un système qui doit être vraiment sécurisé, disons le système de comptabilité de votre entreprise. Si vous utilisez des PROC et accordez un accès uniquement aux PROC, les utilisateurs ne peuvent rien faire autre que ce que le processus fait, jamais. Il s'agit d'un contrôle interne conçu pour s'assurer que les règles commerciales du système ne peuvent être obtenues par un utilisateur du système. C'est ce qui empêche les gens de faire de l'achat d'une entreprise, puis de l'approbation des fonds eux-mêmes ouvrant la porte à la fraude. Cela empêche également de nombreuses personnes de l'organisation de supprimer tous les enregistrements de la table des comptes car ils n'ont pas de droits supprimés, à l'exception de ceux accordés à partir du proc, qui ne permettront qu'une suppression à la fois.
Les développeurs doivent maintenant avoir plus de droits afin de développer, mais ils ne devraient pas avoir plus de droits sur une machine de production, si vous souhaitez envisager la sécurité. True Un développeur pourrait écrire un SP malicieux qui fait quelque chose de mauvais lorsqu'il est mis à pousser. Ce même développeur pourrait bien placer le même code dans la version de l'application et être aussi susceptible d'être attrapé ou non causght comme s'il modifie malicieusement un proc. Personnellement, je pense que le PROC pourrait être plus facile à attraper car il pourrait être repéré séparément du code par le DBAS qui pourrait signifier que le gestionnaire ou la gestion de la configuration et que les DBA avaient une chance de regarder la personne de gestion du gestionnaire ou de la configuration. Nous savons tous que la réalité est que personne ne pousse à un code à prodon a le temps de passer en revue personnellement chaque pièce de celui-ci, alors recruter des développeurs dignes de confiance est essentiel. L'examen de code et le contrôle de la source en place peuvent aider à trouver un changement malveillant ou de le renvoyer à une version précédente, mais l'utilisation du code d'application SPS Vice-Device est à risque des développeurs, quoi qu'il arrive.
La même chose est vraie pour les administrateurs du système. Le doit avoir des droits complets sur le système afin de faire leur emploi. Ils peuvent potentiellement faire beaucoup de dégâts sans être pris. Le mieux que vous puissiez faire dans ce cas est limiter cet accès au moins de personnes que possible et faire de votre mieux pour recruter des personnes de confiance. Au moins si vous avez peu de personnes avec cet accès, il est plus facile de trouver la source du problème s'il se produit. Vous pouvez minimiser les risques en ayant des sauvegardes hors site (au moins au moins ce que l'administrateur se casse si elle peut être corrigée dans une certaine mesure) mais vous ne pouvez jamais vous débarrasser complètement de ce risque. Encore une fois, cela est vrai, peu importe quelle manière vous autorisez les applications à accéder aux données.
L'utilisation réelle de SPS n'est donc pas d'éliminer tous les risques possibles, mais de le faire si moins de personnes peuvent nuire au système. L'utilisation du code d'application pour affecter les informations de base de données est intrinsèquement non sécurisée et ne doit être autorisée dans aucun système stockant des informations financières ni des informations personnelles.
C'est une analogie imparfaite, mais j'aime comparer les tableaux du schéma "DBO" de la DB aux données "privées" dans la terminologie OO, ainsi que des points de vue et des PROC stockés à "public". On peut même faire un schéma "public" distinct du schéma DBO pour faire la distinction explicite. Si vous suivez cette idée, vous obtenez un avantage de sécurité ainsi qu'un avantage d'extensibilité.
Un compte (non du compte de l'application Web) a DBO Access et possède la base de données, et l'application Web connecte à l'aide d'un autre compte restreint aux structures en fonction du public.
Le seul argument possible contre est que j'ai rencontré des cas dans les cas où certaines déclarations ne peuvent pas être efficacement paramétralisées dans un SP (et une SQL dynamique est requise) et cela vous donne la possibilité d'injection SQL SQL. C'est vraiment une considération très étroite cependant et c'est un cas rare. Au moins dans PostgreSQL, j'ai une fois de temps en temps vu quelques cas où cela devait être soumis à un examen supplémentaire.
Dans l'ensemble, même dans ces cas, je pense que les approches de type SP vous donnent une sécurité de sécurité, car elles signifient que l'application peut utiliser des mécanismes génériques d'injection anti-SQL de manière générique où il pourrait autrement être possible et votre SP peut être utilisé par de nombreuses applications. En outre, si toutes les activités doivent passer par SP, vous pouvez réduire votre exposition à l'injection SQL et centraliser les audits des problèmes.
En général, moins un utilisateur peut faire moins d'exposition de la sécurité en général. Cela signifie que moins un utilisateur peut faire avec une attaque d'injection SQL.
Les procédures stockées donnent généralement une sécurité meilleure et plus granulaire que vous ne pouvez faire sans.
La plupart des réponses ici spécifient les avantages de sécurité de l'utilisation de procédures stockées. Sans ignorer ces avantages, il y a quelques grands inconvénients qui n'ont pas été mentionnés:
Les modèles d'accès aux données sont parfois beaucoup plus importants qu'une procédure spécifique qui est effectuée . Nous voulons vous connecter / surveiller / analyser / augmenter des alertes / blocs qui accèdent aux données, quand et comment. Nous ne pouvons pas toujours obtenir ces informations lors de l'utilisation de procédures stockées.
Certaines organisations peuvent avoir des tonnes de procédures stockées . Il est impossible de les examiner tous, et il peut être plus logique de se concentrer sur les tableaux (en particulier lorsqu'on considère que les procédures stockées peuvent être très complexes, ont des bugs et d'introduire d'autres problèmes de sécurité).
Certaines organisations peuvent nécessiter une séparation des préoccupations . Les administrateurs de base de données (ou toute personne qui écrit des procédures stockées) ne font pas toujours partie du personnel de sécurité. Il est parfois nécessaire que la sécurité personnelle ne se concentre que sur les données simplement parce qu'elles ne sont pas responsables de la logique commerciale et des gars qui écrivent la logique commerciale, ne sont pas complètement de confiance.