Validation d'un modèle de travail

Bonjour, j'ai besoin de votre aide afin de valider les inconvénients et avantages d'un modèle de structure d'accès aux données en .Net.

Le modèle vise à régler un problème d'accès aux données afin de permettre à une application de vivre dans une DMZ ou un WAN et avoir accès aux données d'un LAN. (Pour ceux qui ne connaissent pas ces termes, c'est simple, permettre à un logiciel dans une zone publique d'accéder à un serveur SQL dans une zone privé comme un réseau local d'entreprise)

Afin de faire fonctionner mon modèle j'ai établi les étapes suivantes et j'aimerais que vous m'aidiez à le valider afin de donner un peu de poids à mon argumentation envers mes dirigeants intransigeants qui ne savent pas vraiment vers quoi aller comme solution :

Survol

Utilisation de webservice ou de couche physiques pour l'àccès aux données par exemple :

Application dans la DMZ -> API en mémoire -> Web Service dans le LAN -> Couche d'accès physique en mémoire -> SQL Server

Cette technique si bien implanté peu être horriblement versatile et proposer un accès à plusieurs web service en chaine, donc si un webservice est public, il pourrait utiliser le web service privé pour aller chercher ses données.
Vous voyez ou je veux en venir? J'espère...

Présentation du modèle par couche

Première couche : Visuel/Applicatif (Presentation layer)
Nous avons ici plusieurs logiciels qui ont tous une fonction particulière mais opérant sur les même données de façon différentes.

Deuxième couche : Logique d'entreprise (Business layer)
Ici je prévois faire un simple système de classe qui gère tous les éléments de la base de données comme les employés, les transactions, la facturation et autres. Ce layer est complètement intégré et contrôle les accès par login et logout ainsi que plusieurs autres méchanismes...

Troisième couche : Logique d'accès aux données (Data layer)

C'est ici que ca devient compliqué. Afin d'éviter de forcer une entreprise d'utiliser un WebService surtout si elle n'en à pas besoin, je veux faire en sorte que le layer devienne en fait une interface pour deux sous modules.

L'interface d'écrirait les méthodes d'accès aux données qu'elle que soit la vraie méthode d'accès. Ensuite, en suivant ce modèle d'interface, je créerais deux data layer, un pour accéder directement à la base de données et un pour accéder à un service web.

Résultat

Quelqu'onque application devrait donc utiliser l'api de la deuxième couche en tout temps afin de contrôller les accès aux données. Par la suite cet api utilise le iDataLayer (Interface) de son choix selon la config pour aller chercher l'information.

Dans le cas que le iDataLayer est le webservice, est bien, la chaine recommence et le WebService utilise un API business afin de se connecter à la prochaine source valable. Ce nouveau noeud dans l'api pourrait être a nouveau configuré pour utiliser un Web Service qui en retour créera un troisième noeud d'API business... Encore ici le troisième noeud pourrait être configuré pour l'accès à une quatrième noeud de web service si l'on veut, ou pourrait à ce point se connecter sur l'autre iDataLayer qui est celui d'accès à la base de données.

Ceci permettrait donc (avec un impact notable sur la vitesse de travail bien évidement) permettre à quiquonque d'installer une chaine de web service qui communiquent ensembles et se relais le travail pour aller chercher l'information. Donc, autant de pare-feu ou de phénomène d'intrusion qui seraient disponibles pourrait donc, de manière sécurisé sous SSL être contournées sécuritairement. Et si l'utilisateur ne désire pas utiliser les webservice, il pourrait configurer son API de son logiciel pour se connecter directement au iDataLayer de la base de données et voila donc le travail...

Qu'est-ce que vous en pensez? Donnez moi vos commentaires les plus pertinents ainsi que des expériences si possible car c'est présentement une crise solide ici...

Les dirigeants veulent absolument fermer les communications directes entre les logiciels publics et la base de données privé afin de rendre le tout sécuritaire. Pour se faire, la seule solution qu'ils croient enviables est la création d'un logiciel de synchronisation. Dans le département de programmation nous sommes tous contre cette idée qui ne nous ammeneras que du trouble constant...

Bon alors dejà la connexion de ta DMZ vers ton server SQL inLAN... c'est pas envisageable.

Plusieurs raisons, mais la plus courante, ce sont les règles de sécurité. Si le serveur SQL est bien configuré... seul des ordinateurs et des sessions (sur ces ordinateurs) du LAN doivent pouvoir y accèder et par définition, les machines de la DMZ ne sont pas sur le domaine du LAN, ce qui rend les connexions vers SQL un peu compliquées et capricieuses.
Si tes machines de la DMZ sont dans le domaine du LAN... ya comme qui dirais un problème, et ya plus aucun intérêt a avoir une DMZ.

Ensuite, le problème d'un webservice (architecture distribuée) c'est que dans tous les cas, une machine dans le LAN doit servir "d'Interface" entre le LAN et le DMZ... C'est pas mauvais en soit, mais là aussi ils peuvent te dire NON les messieux de la direction.

Cela dit la réplication n'est pas une solution viable. Meme par une application tiers qui fait la synchro, car tu permet à une application de ce connecter de part et d'autre du rideau de fer en donnant DIRECTEMENT access au serveur SQL vulnérable qui est dans le LAN.

L'architecture distribuée donc par webservice est intéressante, bien que je ne vois pas l'intéret de les chainer, meme pour passer outre les diverses niveaux de sécurité. J'ai bien compris le principe, mais disons que ca ne sert à rien de les chainer, car tu va te retrouver a empiler les couches 2 et 1 de ton modele et créer autant de latence que possible sachant que si tu peux te connecter par une application distribuée de A à B à C pour arriver à D... ya fort à parier que tu puisse passer de A à D directement... toujours par les webservices.

Ensuite j'ai un peu de mal a comprendre...
On ne doit pas manipuler de données "sensibles" sur des machines de la DMZ... sinon ca ne sert à rien d'avoir une DMZ. En dehors des aspects mots de passe et sessions, je parle en terme d'informations.
Je ne crois pas que les bilans comptables, par exemple, de l'entreprise aient quelque chose à foutre sur des machines de la DMZ.
Donc j'ai un peu de mal a comprendre l'intérêt stratégique d'un tel système.
A part ajouter des vulnérabilités au réseau.

Si le but c'est de permettre à des employés pas physiquement présent dans l'entreprise d'avoir accès à des données sensibles... pour ca on a inventer des trucs formidables comme Citrix Metaframe pour ne citer que celui-là...
Ou encore connexion au VPN par carte GPRS/EDGE/3G pour les utilisateurs mobiles dotés de portables.

Salut et merci pour ta réponse, ca me remonte le moral de voir que ma solution n'est pas totalement folle...

Voici en fait les détails du problème pour que tu comprenes au complet le problème :

Nous avons une application à l'interne qui sert de gestion de projet, facturation et gestion des feuilles de temps. Dans la DMZ, j'ai un logiciel pour les roaming users qui sert à entrer les feuilles de temps. La DG veulent fermer le port entre la DMZ et le LAN pour que la base de données ne soit plus exposé à partir du LAN. Elle ne l'est pas à partir du WAN pas à t'inquiéter.

À l'interne, le logiciel de gestion lui se connecte directement sur la bd et c'Est correct comme ca. Juste un hic, il ne passe par aucun layer, l'application intègre les trois tiers de façon spaghetti dans tout les modules... la vache, ca va être le fun de remonter ca en 3 tiers...

En tous cas, la raison pour chainer est simple je veux pouvoir éventuellement faire une technique semblable :

(WAN) Gestion de projets à l'extérieur du bureau -> (DMZ) WebServiceA
(DMZ) Serveur IIS Feuille temps -> (DMZ) WebServiceA
(DMZ) WebServiceA -> (LAN) WebServiceB
(LAN) WebServiceB -> (LAN) SQL Server

À la rigueur, je connecterais le webservice B et la feuille de temps directement ensemble afin de sauter un noeud inutile, mais si les techs veulent qu'une seule porte à travers le firewall, ca serait plus simple sur le "WSA" comme les client externes... Il pourrait configurer le firewall pour ne laisser que les communications entre "WSA" et "WSB" sur un port SSL seulement et bloquer le reste... Ca serait bon non?

Je vois un peu mieux le probleme...

Donc les feuilles de temps et le logiciel de gestion de projet accèdes direct à la base depuis la DMZ... sans SSL... et bien entendu sans connexion approuvées, impossibles à obtenir depuis l'extérieur du LAN depuis la DMZ.

Alors en fait, si les feuilles de temps et le soft de gestion de projets sont INTERNES et que vous les avez developpé vous même...
Un coup de dépoussièrage pourrait faire l'affaire, et les remodèliser sur plusieurs couches, en utilisant pourquoi pas une architecture distribuée pour bénéficier des SSL.

En fait, tu aurais donc le noyau dur du systeme installé dans la DMZ et sur le serveur de données (ou ailleurs) dans le LAN.

en clair tu veux que sur la dmz, la couche utilisateur utilise la couche métier qui va consommer des services de la meme application noyau dans le lan qui va les fournir.
Et du coté du lan, cette couche métier ce connecte à la couche 1 (plus bas niveau) qui sert d'interface aux données.

Contrairement à ce que tu pense ce genre d'architecture n'a rien d'anormal, c'est le systeme que j'utilise (même si ca demeure plus complexe dans mon cas) sauf que moi c'est pas pour franchir une DMZ vers un LAN.

Tu va juste t'amuser à faire une couche 2 générique qui permette en phase client de consommer des services et à la fois de les fournir puisque de l'autre coté, elle fonctionne en mode serveur :)
Mais si cela est bien fait, ce que tu va mettre au point ce n'est pas une application, c'est un Framework utilisé par les applications tiers de gestion de projet et autres.

(Pour la gestion de projet tu peux de suite aller plus loin et la refaire avec les WF de dotnet3, mais ca une autre histoire.)

Ton architecture n'a rien de très esotérique, juste qu'il va falloir apporter un soin particulier à l'architecture distribuée de la couche exposée du framework.
(couche 2 : business layer)

Normalement tout ce qui se trouve en DMZ ne doit pas avoir d'acces possible vers le LAN, sinon il y a peu d'interet a la chose.

Personnellement j'utilise des VPN avec des logiciels clients pour les utilisateurs mobiles et d'autre routeurs pour les succursalles (cinemania en a parle un moment). Ce lien VPN se fait directement dans la zone du LAN
* Avantages
- Simple a mettre en oeuvre
- Niveau de securite satisfesant
- Choix des ressources & ports accessibles et innaccessibles

* Cependant
- Performances du VPN a tester en tout premier lieu
- Necessite un travail de fond rigoureux sur les droits d'acces
- Necessite un monitoring regulier
- Necessite une politique de mise a jour des cles reguliere pour une securite optimale

Merci les gars pour votre opinion, je prendrai cela en compte avec interet lors de mon exposé aux DG et j'espere qu'ils vont mieux comprendre l'importance de changer la manière d'opérer le logiciel. Depuis que je suis arrivé il y a deux ans, je n'ai cessé de voir des anormalités comme celles ci sous prétexte qu'ils ne connaissent pas le monde de la programmation.

Ils laissaient le soins au directeur de programmation d'établir les architectures, hors le gars en question à 65 ans et n'avais jamais touché au .net ou au web avant.... vous voyez donc dans quoi je suis embourbé maintenant qu'il est parti....

Merci encore et bonne chance dans vos projets...

ba la politike du vpn va juste prendre un peu de temps à la mise en place mais c'est assez facile à faire.

ca peut couter un peu cher car faut envisager des pc portables mais ca coutera certainement moins cher qu'un développement supplémentaire qui sera assez long, les archi distribuées ne sont pas rapides à faire car faut les soigner.
D'autant que là tu devrais tout redévelopper.

Je pense qu'il vaut mieux investir dans des portables avec cartes GPRS pour vos utilisateurs nomades, qu'un développement. C'est moins long, moins cher, et plus rentable car ya pas de probleme de sécurité puisqu'il suffit de réellement isoler la DMZ du reste du réseau, par le firewall.
Plus rien d'ouvert, et pu besoin de données annexes ni rien.

Et si vraiment les mobiles vous emmerde... ba un serveur avec Citrix Metaframe mais le probleme c ke les licences de Citrix sontpas données et faut des tokens pour chaque utilisateur (ce sont des générateurs d'identifiants RSA) et c ca qui n'est pas donné.

Minute, j'ai p-e pas dit le bon mot par roaming, ont a des employés à l'externe dans des cliniques médicales, des hopitaux et autres entreprise... les gars sont pas sur des portables, ils travaillent la à 100% du temps mais doivent quand même faire une feuille de temps. Il n'ont donc pas de portable ou de poste mobile...

Soit vous isolez une machine à eux sur le vpn... soit vous utilisez une architecture avec Citrix Metaframe ou un concurrent...

Disons que Citrix c'est comme un Terminal Service/Bureau a distance, mais concut spécialement pour les besoins des entreprises
pour avoir de l'extérieur (et meme de l'intérieur) accès à des serveurs en mode bureau à distance ou RAdmin (c'est le meme principe mais au lieu d'etre sur le serveur citrix, c sur un autre serveur du vpn... générallement réservé aux administrateurs en passant par ce serveur citrix qui fait passerelle) au sein du VPN.

Mon applicatif actuel semidistribué concerne justement une multinationale qui utilise cette stratégie. Leurs utilisateurs qui sont hors de l'enceinte de l'entreprise, donc leur vendeurs, recoive un Token RSA et par le biais de la passerelle Metaframe de la boite en fonction du login, ils arrivent sur un serveur "de présentation" ou serveur d'application.
C'est une méthode qui a fait ses preuves et ne constitue pas une violation des règles de sécurité du groupe... et tu peux du coup
déplacer toutes les fichers vers ce serveur applicatif, dans le LAN.
meme moi je déploie le produit dans leur agence francaise par le meme principe sauf que moi je peux accèder au RAdmin à l'inverse de leurs employés.

Sérieusement, c'est pas mal comme système, et franchement... ca peut vous économiser des dixaine de milliers d'euros.
Je veux dire, meme si tu n'est éventuellement pas cadre, ou un maillon "important" de la chaine, au sens, ou ton temps n'est pas extremement précieux, une journée de développement coute en moyenne 250€ pour un développeur tout en bas de l'échelle à une société. (Charge, salaire ...compris)
Certains développeurs peuvent couter plus de 1400€ par jours.
Calcul en supposant que le prix que tucoute à développer à ta société, tout un systeme qui au final ne sera pas déployé avant plusieurs mois, dans les environs de 450€. Ensuite il faut compter facilement deux mois pour que la nouvelle architecture soit prete et encore autant pour tout refaire pour l'utiliser, soit environ 4 mois donc 4 * 24 * 450€ = 172800€
et ca c'est en calculant à la louche car en fait tu coute plus cher... et oui car tu as d'autres taches et ces taches tu ne peux plus les accomplir...$

Je sais que pour toute journée de monopolisée je coute entre 900 et 1100€ a ma société, si on tient compte de tout. Actuellement c'est ce que je coute à developper pour que le nouveau projet intègre tout ce que l'ancien intégrait et bien mieux, avec une architecture qui m'aura au final fallut plus de 6 mois à finir. Car pendant que je fait ca... devine... je fait rien d'autre... et il est là le probleme.

Actuellement en supposant que vous achetiez une machine pour l'applicatif et le serveur citrix metaframe, plus les licences citrix, plus les tokens, on serait très très loin des 172000 énoncés tout à l'heure et au lieu d'attendre 4 mois, il faudrait compter environ 1 semaine pour tout déployer...
Personnellement je suis employeur... cette solution qui allie tous vos besoins de sécurité me semble une bonne alternative.

Citation:

---

Envoyé par cinemania

...soit environ 4 mois donc 4 * 24 * 450€ = 172800€

---

Heu ... chez moi ça fait 43200€ (y a pas un x4 en trop pour les 172800 ? :D )

Sinon je suis tout à fait d'accord sur le fait qu'on estime pas assez souvant le cout du temps passé par rapport à l'investissement dans de l'existant (matériel + licences). C'est un très bon réflèxe à prendre.

C'est certain qu'une solution de ce genre les gars est bien, mais faut pas oublier que notre logiciel est fait pour etre vendu. Je me vois mal vendre notre logiciel pour quelques milliers mais forcer des licenses de différents logiciels:

Dans le cas #1 (Synchro): 2 licences de SQL Server + 1 licence de server 2003 pour hoster la feuille de temps

Dans le cas #2 (WebService): 1 licence de SQL Server + 2 licence de serveur 2003 pour hoster la feuille de temps et les webservice (Celui qui revient le moins cher c'est certain)

Dans le cas #3 (MetaFrame): 1 licence de SQL Server + 1 licence de serveur 2003 au minimum + 1 metaframe citrix a 40 000$

Ouch, ca coute cher pour déployer une feuille de temps chez un client vous trouvez pas?

=)

Mon point est fait je crois, de toute facon, avec l'architecture que je veux implanter (Interface variable d'accès aux données) je pourrai installer le serveur en local dans un LAN qui détient un metaframe s'il veulent bien utiliser cette solution. Dans l'autre cas, j'aurai la possibilité aussi de l'installer à distance de manière sécuritaire vu qu'un webservice fait un genre de coupe-hacker si la sécurité est bien monté, comme il ne voit pas le serveur SQL il ne peut pas hacker les données directement...

Je pense que mon idée est faite, Je vous remercis tous pour vos commentaire. @ la prochaine

CrazyOne

oui mais ca change la donne...

tu ne nous à pas non plus dit que l'application était dédiée à la vente.
forcément ca change le contexte, mais dit toi, que les clients disposant d'une architecture réseau avec un serveur lan SQL et des machines dans la DMZ... ont deja une infrastructure réseau complexe... et il est probable qu'ils aient des utilisateurs mobiles avec connexions GRPS/EDGE/3G.

Tout est question de connaitre les cibles auxquels vous souhaitez vendre l'applicatif.

Le projet que je gere est destiné entierement à des PME/Grande Entreprises. J'ai fait une série de choix stratégiques en terme de développement et d'orientations. Maintenant ce produit compte tenu des "requis" ne convient pas à une TPE, ou une toute petite PME, mais cela dit... je vois pas trop à quoi il pourrait servir dans une TPE mais bon c'est un autre probleme.

Tout est question de ciblage.
Mais cela aurait été exclusivement pour un déploiement interne, le développement n'aurait pas du tout était rentable...

Oui pour le 172000€ ya eu un *4 en trop :) mea culpa.