Discussion :

[cdgidev]

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...

[cinemania]

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.

[cdgidev]

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?

[cinemania]

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)

[Piotrek]

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

[cdgidev]

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...