L'application Web est-elle connectée à une base de données via un serveur d'applications plus sécurisé?
Je l'ai entendu de mes collègues et d'autres personnes sur Internet suggèrent qu'il est plus sûr d'exécuter cette configuration:
Web server -> Application server -> Database, Que ceci:
Web server -> Database
Les raisons que si un adversaire prend le contrôle d'un serveur Web, puis il y a une couche supplémentaire à surmonter si vous avez besoin de la base de données.
Je pense que si un contrôle de l'adversaire le serveur web, ils sont alors aussi bon que d'avoir accès à la base de données, car ils seront en mesure d'effectuer des requêtes arbitraires sur le serveur d'applications qui leur confiance. Il va les ralentir, je suppose, mais l'effort supplémentaire pour mettre en œuvre un niveau intermédiaire + tous les trous possibles dans la requête introduite par qui semble ne pas être en vaut la peine pour moi.
P.s. Depuis, on m'a dit que ma question est générique, je vais ajouter plus d'informations sur la configuration que j'ai.
J'ai un client de SPA qui ne parle que de l'API et le jeton est utilisé comme système d'authentification. application Web fournit vraiment que la demande initiale de brancher l'application et il n'y a pas d'autres appels en dehors des fichiers statiques et API. L'application Web parle alors directement à la base de données dans la couche de données. Je viens d'un utilisateur dans la base de données et tous les accès est contrôlé par la logique métier et/ou la couche d'autorisation dans mon cadre (par exemple, des rôles dans un jeton peuvent être vérifiés avec des attributs avant qu'il ne passe à la couche d'affaires, sans un rôle nécessaire que vous ne sont pas autorisés à accéder à certaines API du tout). Donc, il n'y a pas de danger à quiconque d'appeler une de l'API (à moins que je ne en les protégeant de manière appropriée, mais c'est une autre histoire).
Donc, en prenant en compte cette configuration, y aurait-il un avantage du point de vue de la sécurité pour faire la couche de données de l'application Web pour communiquer avec le serveur d'application qui va gérer la logique métier au lieu de la base de données directement (et le serveur d'application parlera à la base de données ). Dans ce cas, l'application Web est généralement réduite au chargement initial du client + un proxy au service de l'application, ce qui semble tout à fait superflu pour moi.
"plus sécurisé" est inconstructif
Penser que quelque chose est "plus sûr" conduit souvent souvent à une mauvaise prise de décision. Toutes sortes de choses sont plus sûres tout en étant une mauvaise idée. Il est plus utile de demander "Cela ajoute-t-il une sécurité significative?" et "la sécurité a-t-elle gagné un compromis raisonnable entre le coût et la prestation?"
Tiers n'ajoute pas beaucoup de sécurité
La plupart des livres Infosec recommandent le modèle à trois niveaux. J'ai trouvé que le modèle à deux niveaux est tout aussi courant (peut-être plus commun) et cela inclut un grand nombre d'applications très critiques que j'ai auditées: la banque en ligne, etc.
La réalité est que deux niveaux n'est qu'un bénéfice de sécurité marginal sur un seul niveau. Les gens diront souvent "si le serveur Web est piraté, ils ne sont pas sur la base de données". Bien que techniquement vrai, c'est trompeur. Le serveur Web aura des informations d'identification pour se connecter à la base de données, ce qui permettra à un attaquant d'extraire toutes les données. Vous pouvez imaginer certains scénarios d'attaque où avoir deux niveaux bloque des vecteurs d'exploitation particuliers, mais ceux-ci sont rares.
L'avantage de sécurité de trois niveaux vs deux est encore inférieur à deux vs un. Et cela en est particulièrement donc avec les spas, où le niveau Web est sur le client.
EDIT Pour être clair, je veux dire des niveaux comme dans les niveaux sur des serveurs séparés (virtuels ou physiques) - plutôt qu'une séparation purement logique.
Si vous distinguez le serveur Web, le serveur d'applications et la base de données, vous entendez en réalité une extrémité frontale, une logique commerciale et un arrière-plan (stockage). Ceci est également appelé A architecture multi-niveaux avec niveau de présentation, niveau d'application et niveau de données. Dans ce cas, le serveur d'applications ne passera pas simplement des demandes du serveur Web, mais n'autorise que des actions qui correspondent à la logique commerciale. Cela signifie que tous les éléments de sécurité (c'est-à-dire qui peuvent accéder à quoi) est essentiellement fait dans le serveur d'applications et le serveur Web est juste là pour rendre ces informations accessibles via un navigateur Web.
Si vous ne disposez que de serveur Web et de base de données uniquement, la logique Business fait essentiellement partie du serveur Web. Bien que cela rend souvent plus facile de démarrer avec une certaine application Web, la distinction manquante entre la présentation et la logique d'entreprise conduira facilement dans un gâchis que personne ne peut plus comprendre et qui permet souvent de contourner la logique commerciale et d'obtenir ainsi un accès direct à la base de données pour un attaquant.
Notez que la séparation entre les couches ne doit pas nécessairement être effectuée avec un serveur ou une application distincte, mais elle peut également être une séparation en cours de traitement (I.e. API, classes ...). Mais il est important que cette séparation ne puisse être simplement contournée, ce qui peut souvent être traité de manière plus sécurisée avec un processus ou un serveur distinct. Une séparation manquante entre la présentation et l'application peut parfois être vue en ce que vous ne pouvez pas accéder à des informations spécifiques par HTML, mais elles sont toujours accessibles par une API JSON ou XML.
Vous avez besoin d'une couche d'application en tant que filtre car la plupart des systèmes de base de données ne permettent pas la manipulation des autorisations suffisamment graine de greil pour gérer plusieurs utilisateurs.
Habituellement * Vous pouvez créer des utilisateurs avec différentes autorisations de lecture et d'écriture, mais généralement * Celles-ci sont conçues pour quelques dizaines d'utilisateurs et ne pas bien échir pour des milliers ou même des millions d'utilisateurs. En outre, vous pouvez généralement définir des autorisations sur un niveau de table et non sur un niveau par rangée, mais seul un niveau de champ.
Cela signifie qu'il est difficile de contrôler les données que vos utilisateurs peuvent et ne peuvent pas afficher et quelles données elles peuvent et ne peuvent pas modifier. Pour donner un exemple, prenons une table des utilisateurs avec ces colonnes
userId
password
profilePicture
createdDate
lastLoggedInDate
Les gens devraient être autorisés à changer leur propre profilePicture, mais pas celle d'autres personnes. Personne ne devrait changer le champ createdAt et changer le userId pourrait causer toutes sortes de hijinks. Chaque utilisateur doit modifier le lastLoggedInDate lorsqu'ils se connectent et la définissent à la date actuelle, mais ne le définissez pas sur quelque chose de différent. Votre base de données peut-elle gérer cette complexité *? Oh, et nous n'avons même pas déjà parlé de références entre les tables.
Eh bien, mais si vous voulez simplement interdire cela sur la couche cliente en n'écrivant tout simplement pas le code d'interface graphique pour faire ce que l'utilisateur n'est pas censé faire? Le problème est que votre base de données n'a aucun moyen de vérifier que votre application client est vraiment le programme que vous avez écrit. Lorsqu'il parle SQL et envoie des informations d'identification valides de connexion, la base de données lui fera confiance. Un utilisateur malveillant pourrait écrire son propre client et envoyer des commandes SQL arbitraires à votre base de données.
* Je ne veux pas dire qu'il est impossible qu'une base de données soit impossible qui puisse faire tout cela, mais jusqu'à présent, je n'ai pas vu un. Lorsque vous en connaissez un, n'hésitez pas à commenter.