Bonsoir à tous, 

Voilà je développe une application en tier 3 et je ne veux absolument pas que les utilisateurs puissent faire des requêtes en db ou autre. Donc j'aurais besoin d'un core qui est le seul à avoir la permission d'interagir avec la db. Le hic c'est du coup le core dois pouvoir gérer l'accès de plusieurs personnes en même temps donc thread. Mais alors je voudrais savoir si il existe des librairies qui gère cela car c'est pas chose aisée 🤯. Le core sera en c++ sur un serveurbLinux avec postgresql comme db.

Merci et bonne soirée 

Pouvez-vous définir précisément ce qu'est un "core" pour vous ?

A quel type de menace est censé parer votre dispositif ?

Heu, tu as une appli qui se connecte directement à une base de données ?
Si tu veux une "parade" à cela, fait du client / serveur (ou une "passerelle") et configure ta base de donnée pour n'accepter que les connections en provenance du serveur.

PS: Ta question est plus une histoire d'architecture materiel et/ou logicielle que C++.

Merci de vos réponse.

bacelar a écrit:

Pouvez-vous définir précisément ce qu'est un "core" pour vous ?

A quel type de menace est censé parer votre dispositif ?

Le core pour moi c'est un programme programmé en C++ qui tourne en mode console sur un serveur distant. Le core est la seul entité qui communique avec la base de données. Insert select etc... Vus le nombre de personne qui vont faire des demande au core il faut être sur que personne ne fera d'injection sql de hacking etc... 

Deedolith a écrit:

Heu, tu as une appli qui se connecte directement à une base de données ?
Si tu veux une "parade" à cela, fait du client / serveur (ou une "passerelle") et configure ta base de donnée pour n'accepter que les connections en provenance du serveur.

PS: Ta question est plus une histoire d'architecture materiel et/ou logicielle que C++.

Non l'appli envoie une demande au core sur un serveur qui se connecte sur la base de données. 

Et c'est une bibliothèque C++ que je voudrais

Je ne comprends pas ce que votre "core" aura comme valeur ajoutée par rapport au simple gestionnaire de base de données "classique".

Moi, je vois surtout une surcouche qui augmente considérablement la surface d'attaque possible. (stack-overflow, buffer-overflow, faille de midleware/interconnexion, etc...)

Pourquoi l'utilisation de comptes (nominatifs si vous voulez de la non répudiation) ayant des droits adaptés ne ferait pas l'affaire ?

Les gestionnaires sont déjà multi-threadés et adaptés à de grosses montées en charge.

bacelar a écrit:

Je ne comprends pas ce que votre "core" aura comme valeur ajoutée par rapport au simple gestionnaire de base de données "classique".

Moi, je vois surtout une surcouche qui augmente considérablement la surface d'attaque possible. (stack-overflow, buffer-overflow, faille de midleware/interconnexion, etc...)

Pourquoi l'utilisation de comptes (nominatifs si vous voulez de la non répudiation) ayant des droits adaptés ne ferait pas l'affaire ?

Les gestionnaires sont déjà multi-threadés et adaptés à de grosses montées en charge.

Le fait d'avoir possibilité d'interagir avec le programme depuis smartphone et ordinateur avec un seul programme.

Pouvez vous me donné un exemple ou le core serait une valeur ajouté. C'est une architecture tier 3 et d'après ce que j'ai lu c'est assez bien, mais peut-être avez vous un meilleur exemple.

Quand vous parlé de gestionnaire vous parlé bien d'une base de données du style postgresql etc...?

Bon, "tier 3" à part pour des classements d'items dans des jeux en ligne, je connais pas.

"3-tier", c'est déjà plus connu.

Et, pour moi, "3-tiers" c'est comme du "3 couches" mais avec des technologies différentes pour des problématiques de sécurité et de fiabilité (indépendance).

Donc, dans une architecture "classique" "3-tiers", le 3ème tier est les données (les autres étant l'interface avec l'extérieur et les composants métier).

L'interfaçage entre le métier et la couche données est classiquement le gestionnaire de base de données (qui gère généralement bien plus qu'une base de données), un serveur Oracle, une instance SQL Serveur ou, dans votre cas le gestionnaire de base de données PostgreSQL, qui est en charge de plusieurs bases de données (je ne connais plus de gestionnaire monobase, depuis que MySQL a passé le cas il y a bien longtemps).

Ces gestionnaires de données sont des technologies assez particulières pour rentrer dans la définition d'une frontière technologique au sens de l'architecture "3-tiers". (Sauf si vous avez succombé aux appels des sirènes d'Oracle pour tout foutre en JAVA dans leur serveur, ou de M$ avec du .NET embarqué dans du SQL Server)

>Le fait d'avoir possibilité d'interagir avec le programme depuis smartphone et ordinateur avec un seul programme.

C'est assez étrange, car, dans une architecture "3-tiers" classique, c'est la couche métier qui est en charge de gérer les interactions multiples synchrones car elle est la seule à avoir une vue d'ensemble et des données "pertinentes" et des règles business.

Donc, pourquoi c'est à votre interface avec les données de gérer ces trucs et pas à l'interface métier ? (Il ne faut pas confondre 3-tiers et client/serveur)

>Pouvez vous me donné un exemple ou le core serait une valeur ajouté.

Sauf cas particulier, et comme vous avez une définition très restrictive de "core", non.

Mais des middleware de worflow, d'orchestration, de résilience aux pannes, etc... peuvent facilement être des composants à mettre entre un tier "Business" et un tier "Données" et qui offrent de grosses valeurs ajoutées.

>Quand vous parlé de gestionnaire vous parlé bien d'une base de données du style postgresql etc...?

PostgreSQL est un gestionnaire de base de données, pas "une base de données", et il dispose de tout ce qu'il faut pour monter un système d'authentification et un système d'autorisation performants et flexibles (à mon avis).

-
Edité par bacelar 19 mai 2022 à 12:41:32

En gros dans mon projet toutes personnes peut se connecté via une application (Xamarin C#). La base de données est sur un serveur physique distant chez le client ou non. En plus de sa un ordinateur est chez le client(c++,java ou c#). Ce que je voyais c'est que les personnes concerné envoie leur demande au serveur (c++) qui lui traite la demande sur à la base de données(postgres), et renvoie les résutlats via socket. Vu que tout le monde peut s'y connecté je dois gèrer l'acces du message reçu si il est valable ou non etc... Je pense que la logique d'accès va être longue donc je ne peux pas la mettre dans l'app, car cela prendrais trop de place au niveaux mémoire sur le smartphone. Donc j'ai voulu avoir une communication avec un programme qui communique lui même avec la base de données (core) et qui gère tous cela car je ne veux pas que quelqu'un puissent se connecter sur la DB sans passer par le core il n'y aura donc qu'un accès à la DB

Je ne vois rien qui ressemble à du 3-tiers dans votre architecture, c'est du client/serveur, à première vue.

>sur un serveur physique distant chez le client

Qu'entendez-vous par client ?

>et renvoie les résutlats via socket.

A moins d'être dans un intranet, cette approche est très contrainte, au temps faire du HTTP "classique".

Pourquoi l'approche "standard" 'client/SeveurWeb/Gestionnaire de bases de données' ne convient pas à votre approche ???

Par client j'entends les personnes qui achèteront le service.

C'est dans un intranet (réseau local) du client(acheteur).

Je pense que cela ne convient pas car l'application(ui) devra contenir toutes une logique d'accès à la DB. Je regarde l'approche http mais je trouve que cela ressemble à ce que je veux faire. Le serveurWeb fera les accès à la DB aussi. Je n'ai jamais pratiqué ce genre de truc donc je dois me renseigner mieux. Mais je ne comrpends pas pour le moment ou est la différence.

>l'application(ui) devra contenir toutes une logique d'accès à la DB.

Cela contrevient frontalement au paradigme de base de l'architecture "3-tiers", où chaque couche doit être technologiquement différente.

C'est peut-être compatible avec une approche "3 couches" peu orthodoxe, mais c'est clairement une erreur/faiblesse dans le cadre de la sécurité informatique "en profondeur", comme vos remarques le suggère.

En plus, en terme de qualité logicielle, c'est clairement aussi une erreur car vous vous interdisez de faire évoluer une couche/tier indépendamment d'un re-déploiement complet de tous les clients(application) => bad design.

Donc, pour moi, cette contrainte "une logique d'accès à la DB dans l'UI" est une erreur et vos réflexions sur la sécurité n'ont fit que la révéler.

Dans des Model applicatifs type MVVM, il est tout à fait possible d'utiliser des "ViewModel" qui ne servent que pour l'IHM, si votre application demande beaucoup de données même pour un simple affichage.

>Je regarde l'approche http mais je trouve que cela ressemble à ce que je veux faire.

C'est bien pour cela que je vous l'ai mentionné. Mais dans une approche "standard" 3-tiers avec une couche Business hébergée dans un serveur HTTP, vous n'avez pas à réinventer une roue carrée et vous bénéficiez d'outils éprouvés, très simple d'accès et très très très populaires (si vous avez un stagiaire, il y a, je pense, près de 100% de chance pour qu'il l'ai déjà utilisée en école).

>Mais je ne comrpends pas pour le moment ou est la différence.

Pas de développement maison onéreux et spécifique, un mainteneur avec peu d'expérience pourra faire le job, pléthore d'outils d'aide au développement, à la sécurité à l'optimisation de l'architecture, etc...

Concrètement, je ne vois AUCUN avantage à votre approche. (à part vous prendre la tête sur des problèmes qui ont été résolus et les solutions partagées par des 10zaine d'équipes de développement depuis 30 ans et l'invention de Tim Berners-Lee.)