Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
jean lavenant
cdt_sylvestre wrote:
une entreprise qui fait de la consultation d information à travers un serveur web les infos sont contenus dans un serveur oracle
dois je mettre: -le serveur web et le serveur oracle dans la DMZ -le serveur web dans la DMZ, oracle dans le reseau local de l entreprise
Tu dois réfléchir en terme de risque et non pas en terme technique au début de ton projet. Les questions doivent être:
Qu'est ce qui est le plus critique si on devait perdre quelquechose lors d'une attaque ?
Les informations sont elles réservées à un usage interne ou à un usage externe ou les deux ? Si cela est a un usage interne, est ce definitif, ou dans le futur cela sera t'il ouvert à l'exterieur ? Si cela est à usage interne uniquement, qu'elle est la criticité de ces données vis a vis de ces personnes (salaires du personnel ou simple bulletin d'info ??) ....
Bref, c'est important de se poser ces questions, car c'est à partir de cela que tu vas définir ton architecture.
Juste pour te donner une vision technique "générale". Les données sont généralement le plus critique donc elle doivent être le mieux protégé.
Mon avis est qu'elles doivent être placé dans un sous réseaux spécifiques et unique, différent du LAN et de la DMZ. Pourquoi ? Disons que si tu te fais pirater ton applicatif, il est facile de le restaurer à partir de sauvegarde, ca ne change pas bcp d'une sauvegarde à l'autre. En revanche, pour les bases que dire d'une transaction qui a été passé et qui ensuite a été corrompue par une attaque. Ta derniere sauvegarde sera surement de la veille !!
Les mettre sur le LAN les expose à des attaques par rebond avec des postes de travail peux sécuriser. En général, j'ai tendance à considérer le LAN comme une zone brumeuse qu'il est difficile à controler, bref ne mets rien d'important sur le LAN...
pour moi la DMZ ne doit pas communiquer avec le reseau local, mais cela doit etre le reseau local qui doit communiquer avec les serveur dans la DMZ
Concernant ta DMZ: elle doit être entièrement blindé vis à vis de tes autres sous réseaux: tu dois pouvoir être capable de contrôler tous les flux sortants de la DMZ. Et concernant ce qu'il y rentre, de l'exterieur, uniquement les protocoles liés à tes services que tu considère comme publique (DNS, HTTP, SMTP). Et du LAN, pour les utilisateurs normaux, la même politique que pour l'exterieur avec en plus des services spécifiques s'il y a lieu, et pour les admins un controle, par IP, en veillant à crypter les connections d'administration vers les machines de la DMZ.
C'est une vision générale, mais que tu retrouves dans la plupart des entreprises.
Jean LAVENANT
cdt_sylvestre wrote:
une entreprise qui fait de la consultation d information à travers un
serveur web
les infos sont contenus dans un serveur oracle
dois je mettre:
-le serveur web et le serveur oracle dans la DMZ
-le serveur web dans la DMZ, oracle dans le reseau local de l entreprise
Tu dois réfléchir en terme de risque et non pas en terme technique au
début de ton projet.
Les questions doivent être:
Qu'est ce qui est le plus critique si on devait perdre quelquechose lors
d'une attaque ?
Les informations sont elles réservées à un usage interne ou à un usage
externe ou les deux ?
Si cela est a un usage interne, est ce definitif, ou dans le futur cela
sera t'il ouvert à l'exterieur ? Si cela est à usage interne uniquement,
qu'elle est la criticité de ces données vis a vis de ces personnes
(salaires du personnel ou simple bulletin d'info ??) ....
Bref, c'est important de se poser ces questions, car c'est à partir de
cela que tu vas définir ton architecture.
Juste pour te donner une vision technique "générale".
Les données sont généralement le plus critique donc elle doivent être le
mieux protégé.
Mon avis est qu'elles doivent être placé dans un sous réseaux
spécifiques et unique, différent du LAN et de la DMZ. Pourquoi ? Disons
que si tu te fais pirater ton applicatif, il est facile de le restaurer
à partir de sauvegarde, ca ne change pas bcp d'une sauvegarde à l'autre.
En revanche, pour les bases que dire d'une transaction qui a été passé
et qui ensuite a été corrompue par une attaque. Ta derniere sauvegarde
sera surement de la veille !!
Les mettre sur le LAN les expose à des attaques par rebond avec des
postes de travail peux sécuriser. En général, j'ai tendance à considérer
le LAN comme une zone brumeuse qu'il est difficile à controler, bref
ne mets rien d'important sur le LAN...
pour moi la DMZ ne doit pas communiquer avec le reseau local, mais cela doit
etre le reseau local qui doit communiquer avec les serveur dans la DMZ
Concernant ta DMZ: elle doit être entièrement blindé vis à vis de tes
autres sous réseaux: tu dois pouvoir être capable de contrôler tous les
flux sortants de la DMZ. Et concernant ce qu'il y rentre, de
l'exterieur, uniquement les protocoles liés à tes services que tu
considère comme publique (DNS, HTTP, SMTP). Et du LAN, pour les
utilisateurs normaux, la même politique que pour l'exterieur avec en
plus des services spécifiques s'il y a lieu, et pour les admins un
controle, par IP, en veillant à crypter les connections d'administration
vers les machines de la DMZ.
C'est une vision générale, mais que tu retrouves dans la plupart des
entreprises.
une entreprise qui fait de la consultation d information à travers un serveur web les infos sont contenus dans un serveur oracle
dois je mettre: -le serveur web et le serveur oracle dans la DMZ -le serveur web dans la DMZ, oracle dans le reseau local de l entreprise
Tu dois réfléchir en terme de risque et non pas en terme technique au début de ton projet. Les questions doivent être:
Qu'est ce qui est le plus critique si on devait perdre quelquechose lors d'une attaque ?
Les informations sont elles réservées à un usage interne ou à un usage externe ou les deux ? Si cela est a un usage interne, est ce definitif, ou dans le futur cela sera t'il ouvert à l'exterieur ? Si cela est à usage interne uniquement, qu'elle est la criticité de ces données vis a vis de ces personnes (salaires du personnel ou simple bulletin d'info ??) ....
Bref, c'est important de se poser ces questions, car c'est à partir de cela que tu vas définir ton architecture.
Juste pour te donner une vision technique "générale". Les données sont généralement le plus critique donc elle doivent être le mieux protégé.
Mon avis est qu'elles doivent être placé dans un sous réseaux spécifiques et unique, différent du LAN et de la DMZ. Pourquoi ? Disons que si tu te fais pirater ton applicatif, il est facile de le restaurer à partir de sauvegarde, ca ne change pas bcp d'une sauvegarde à l'autre. En revanche, pour les bases que dire d'une transaction qui a été passé et qui ensuite a été corrompue par une attaque. Ta derniere sauvegarde sera surement de la veille !!
Les mettre sur le LAN les expose à des attaques par rebond avec des postes de travail peux sécuriser. En général, j'ai tendance à considérer le LAN comme une zone brumeuse qu'il est difficile à controler, bref ne mets rien d'important sur le LAN...
pour moi la DMZ ne doit pas communiquer avec le reseau local, mais cela doit etre le reseau local qui doit communiquer avec les serveur dans la DMZ
Concernant ta DMZ: elle doit être entièrement blindé vis à vis de tes autres sous réseaux: tu dois pouvoir être capable de contrôler tous les flux sortants de la DMZ. Et concernant ce qu'il y rentre, de l'exterieur, uniquement les protocoles liés à tes services que tu considère comme publique (DNS, HTTP, SMTP). Et du LAN, pour les utilisateurs normaux, la même politique que pour l'exterieur avec en plus des services spécifiques s'il y a lieu, et pour les admins un controle, par IP, en veillant à crypter les connections d'administration vers les machines de la DMZ.
C'est une vision générale, mais que tu retrouves dans la plupart des entreprises.
Jean LAVENANT
cdt_sylvestre
pour moi, aucune connection ne devait sortir de la DMZ, ainsi le backup d un serveur http devait non plus faire: tar, puis envoie par ftp mais tar puis un client ftp du serveur de bakup (ailleurs que dans la DMZ) 'vient' chercher le fichier compressé
donc si je comprends bien: dans une premiere DMZ le serveur http, dans une deuxieme DMZ le serveur oracle la dmz1 ne communique que par des requetes oracle vers la dmz2
si la dmz1 est corrompu, on aura le risque donc incontournable que le gars fasse des requetes 'malsaines' sur la BD (il aura récupéré le login/password d'ériture)
merci
"jean lavenant" a écrit dans le message de news: brpab3$72q$
cdt_sylvestre wrote:
une entreprise qui fait de la consultation d information à travers un serveur web les infos sont contenus dans un serveur oracle
dois je mettre: -le serveur web et le serveur oracle dans la DMZ -le serveur web dans la DMZ, oracle dans le reseau local de l entreprise
Tu dois réfléchir en terme de risque et non pas en terme technique au début de ton projet. Les questions doivent être:
Qu'est ce qui est le plus critique si on devait perdre quelquechose lors d'une attaque ?
Les informations sont elles réservées à un usage interne ou à un usage externe ou les deux ? Si cela est a un usage interne, est ce definitif, ou dans le futur cela sera t'il ouvert à l'exterieur ? Si cela est à usage interne uniquement, qu'elle est la criticité de ces données vis a vis de ces personnes (salaires du personnel ou simple bulletin d'info ??) ....
Bref, c'est important de se poser ces questions, car c'est à partir de cela que tu vas définir ton architecture.
Juste pour te donner une vision technique "générale". Les données sont généralement le plus critique donc elle doivent être le mieux protégé.
Mon avis est qu'elles doivent être placé dans un sous réseaux spécifiques et unique, différent du LAN et de la DMZ. Pourquoi ? Disons que si tu te fais pirater ton applicatif, il est facile de le restaurer à partir de sauvegarde, ca ne change pas bcp d'une sauvegarde à l'autre. En revanche, pour les bases que dire d'une transaction qui a été passé et qui ensuite a été corrompue par une attaque. Ta derniere sauvegarde sera surement de la veille !!
Les mettre sur le LAN les expose à des attaques par rebond avec des postes de travail peux sécuriser. En général, j'ai tendance à considérer le LAN comme une zone brumeuse qu'il est difficile à controler, bref ne mets rien d'important sur le LAN...
pour moi la DMZ ne doit pas communiquer avec le reseau local, mais cela doit
etre le reseau local qui doit communiquer avec les serveur dans la DMZ
Concernant ta DMZ: elle doit être entièrement blindé vis à vis de tes autres sous réseaux: tu dois pouvoir être capable de contrôler tous les flux sortants de la DMZ. Et concernant ce qu'il y rentre, de l'exterieur, uniquement les protocoles liés à tes services que tu considère comme publique (DNS, HTTP, SMTP). Et du LAN, pour les utilisateurs normaux, la même politique que pour l'exterieur avec en plus des services spécifiques s'il y a lieu, et pour les admins un controle, par IP, en veillant à crypter les connections d'administration vers les machines de la DMZ.
C'est une vision générale, mais que tu retrouves dans la plupart des entreprises.
Jean LAVENANT
pour moi, aucune connection ne devait sortir de la DMZ, ainsi le backup d un
serveur http devait non plus faire:
tar, puis envoie par ftp
mais tar puis un client ftp du serveur de bakup (ailleurs que dans la DMZ)
'vient' chercher le fichier compressé
donc si je comprends bien:
dans une premiere DMZ le serveur http,
dans une deuxieme DMZ le serveur oracle
la dmz1 ne communique que par des requetes oracle vers la dmz2
si la dmz1 est corrompu, on aura le risque donc incontournable que le gars
fasse des requetes 'malsaines' sur la BD (il aura récupéré le login/password
d'ériture)
merci
"jean lavenant" <jean.lavenant@equipement.gouv.fr> a écrit dans le message
de news: brpab3$72q$1@setranews.setra.fr...
cdt_sylvestre wrote:
une entreprise qui fait de la consultation d information à travers un
serveur web
les infos sont contenus dans un serveur oracle
dois je mettre:
-le serveur web et le serveur oracle dans la DMZ
-le serveur web dans la DMZ, oracle dans le reseau local de l entreprise
Tu dois réfléchir en terme de risque et non pas en terme technique au
début de ton projet.
Les questions doivent être:
Qu'est ce qui est le plus critique si on devait perdre quelquechose lors
d'une attaque ?
Les informations sont elles réservées à un usage interne ou à un usage
externe ou les deux ?
Si cela est a un usage interne, est ce definitif, ou dans le futur cela
sera t'il ouvert à l'exterieur ? Si cela est à usage interne uniquement,
qu'elle est la criticité de ces données vis a vis de ces personnes
(salaires du personnel ou simple bulletin d'info ??) ....
Bref, c'est important de se poser ces questions, car c'est à partir de
cela que tu vas définir ton architecture.
Juste pour te donner une vision technique "générale".
Les données sont généralement le plus critique donc elle doivent être le
mieux protégé.
Mon avis est qu'elles doivent être placé dans un sous réseaux
spécifiques et unique, différent du LAN et de la DMZ. Pourquoi ? Disons
que si tu te fais pirater ton applicatif, il est facile de le restaurer
à partir de sauvegarde, ca ne change pas bcp d'une sauvegarde à l'autre.
En revanche, pour les bases que dire d'une transaction qui a été passé
et qui ensuite a été corrompue par une attaque. Ta derniere sauvegarde
sera surement de la veille !!
Les mettre sur le LAN les expose à des attaques par rebond avec des
postes de travail peux sécuriser. En général, j'ai tendance à considérer
le LAN comme une zone brumeuse qu'il est difficile à controler, bref
ne mets rien d'important sur le LAN...
pour moi la DMZ ne doit pas communiquer avec le reseau local, mais cela
doit
etre le reseau local qui doit communiquer avec les serveur dans la DMZ
Concernant ta DMZ: elle doit être entièrement blindé vis à vis de tes
autres sous réseaux: tu dois pouvoir être capable de contrôler tous les
flux sortants de la DMZ. Et concernant ce qu'il y rentre, de
l'exterieur, uniquement les protocoles liés à tes services que tu
considère comme publique (DNS, HTTP, SMTP). Et du LAN, pour les
utilisateurs normaux, la même politique que pour l'exterieur avec en
plus des services spécifiques s'il y a lieu, et pour les admins un
controle, par IP, en veillant à crypter les connections d'administration
vers les machines de la DMZ.
C'est une vision générale, mais que tu retrouves dans la plupart des
entreprises.
pour moi, aucune connection ne devait sortir de la DMZ, ainsi le backup d un serveur http devait non plus faire: tar, puis envoie par ftp mais tar puis un client ftp du serveur de bakup (ailleurs que dans la DMZ) 'vient' chercher le fichier compressé
donc si je comprends bien: dans une premiere DMZ le serveur http, dans une deuxieme DMZ le serveur oracle la dmz1 ne communique que par des requetes oracle vers la dmz2
si la dmz1 est corrompu, on aura le risque donc incontournable que le gars fasse des requetes 'malsaines' sur la BD (il aura récupéré le login/password d'ériture)
merci
"jean lavenant" a écrit dans le message de news: brpab3$72q$
cdt_sylvestre wrote:
une entreprise qui fait de la consultation d information à travers un serveur web les infos sont contenus dans un serveur oracle
dois je mettre: -le serveur web et le serveur oracle dans la DMZ -le serveur web dans la DMZ, oracle dans le reseau local de l entreprise
Tu dois réfléchir en terme de risque et non pas en terme technique au début de ton projet. Les questions doivent être:
Qu'est ce qui est le plus critique si on devait perdre quelquechose lors d'une attaque ?
Les informations sont elles réservées à un usage interne ou à un usage externe ou les deux ? Si cela est a un usage interne, est ce definitif, ou dans le futur cela sera t'il ouvert à l'exterieur ? Si cela est à usage interne uniquement, qu'elle est la criticité de ces données vis a vis de ces personnes (salaires du personnel ou simple bulletin d'info ??) ....
Bref, c'est important de se poser ces questions, car c'est à partir de cela que tu vas définir ton architecture.
Juste pour te donner une vision technique "générale". Les données sont généralement le plus critique donc elle doivent être le mieux protégé.
Mon avis est qu'elles doivent être placé dans un sous réseaux spécifiques et unique, différent du LAN et de la DMZ. Pourquoi ? Disons que si tu te fais pirater ton applicatif, il est facile de le restaurer à partir de sauvegarde, ca ne change pas bcp d'une sauvegarde à l'autre. En revanche, pour les bases que dire d'une transaction qui a été passé et qui ensuite a été corrompue par une attaque. Ta derniere sauvegarde sera surement de la veille !!
Les mettre sur le LAN les expose à des attaques par rebond avec des postes de travail peux sécuriser. En général, j'ai tendance à considérer le LAN comme une zone brumeuse qu'il est difficile à controler, bref ne mets rien d'important sur le LAN...
pour moi la DMZ ne doit pas communiquer avec le reseau local, mais cela doit
etre le reseau local qui doit communiquer avec les serveur dans la DMZ
Concernant ta DMZ: elle doit être entièrement blindé vis à vis de tes autres sous réseaux: tu dois pouvoir être capable de contrôler tous les flux sortants de la DMZ. Et concernant ce qu'il y rentre, de l'exterieur, uniquement les protocoles liés à tes services que tu considère comme publique (DNS, HTTP, SMTP). Et du LAN, pour les utilisateurs normaux, la même politique que pour l'exterieur avec en plus des services spécifiques s'il y a lieu, et pour les admins un controle, par IP, en veillant à crypter les connections d'administration vers les machines de la DMZ.
C'est une vision générale, mais que tu retrouves dans la plupart des entreprises.
Jean LAVENANT
jean lavenant
cdt_sylvestre wrote:
pour moi, aucune connection ne devait sortir de la DMZ, ainsi le backup d un serveur http devait non plus faire: tar, puis envoie par ftp mais tar puis un client ftp du serveur de bakup (ailleurs que dans la DMZ) 'vient' chercher le fichier compressé
la deuxième solution est celle qu'il faut choisir, car cela évite le rebond vers le serveur de backup !
donc si je comprends bien: dans une premiere DMZ le serveur http, dans une deuxieme DMZ le serveur oracle la dmz1 ne communique que par des requetes oracle vers la dmz2 Exacte !
si la dmz1 est corrompu, on aura le risque donc incontournable que le gars fasse des requetes 'malsaines' sur la BD (il aura récupéré le login/password d'ériture)
Tu ne pas arrêter une attaque, tu peux juste la compliqué.
Par exemple en mettant une autre couche, en mettant un premier serveur web en front end qui relaiera les requêtes au moteur ( ds une architecture J2EE tomcat, ou architecture LAMP avec PHP). Comme cela s'il pirate le serveur web, il devra attaquer le serveur applicatif ensuite. Et de là, modifiable les bases: faisable, mais bcp plus compliqué...
Jean LAVENANT
cdt_sylvestre wrote:
pour moi, aucune connection ne devait sortir de la DMZ, ainsi le backup d un
serveur http devait non plus faire:
tar, puis envoie par ftp
mais tar puis un client ftp du serveur de bakup (ailleurs que dans la DMZ)
'vient' chercher le fichier compressé
la deuxième solution est celle qu'il faut choisir, car cela évite le
rebond vers le serveur de backup !
donc si je comprends bien:
dans une premiere DMZ le serveur http,
dans une deuxieme DMZ le serveur oracle
la dmz1 ne communique que par des requetes oracle vers la dmz2
Exacte !
si la dmz1 est corrompu, on aura le risque donc incontournable que le gars
fasse des requetes 'malsaines' sur la BD (il aura récupéré le login/password
d'ériture)
Tu ne pas arrêter une attaque, tu peux juste la compliqué.
Par exemple en mettant une autre couche, en mettant un premier serveur
web en front end qui relaiera les requêtes au moteur ( ds une
architecture J2EE tomcat, ou architecture LAMP avec PHP).
Comme cela s'il pirate le serveur web, il devra attaquer le serveur
applicatif ensuite.
Et de là, modifiable les bases: faisable, mais bcp plus compliqué...
pour moi, aucune connection ne devait sortir de la DMZ, ainsi le backup d un serveur http devait non plus faire: tar, puis envoie par ftp mais tar puis un client ftp du serveur de bakup (ailleurs que dans la DMZ) 'vient' chercher le fichier compressé
la deuxième solution est celle qu'il faut choisir, car cela évite le rebond vers le serveur de backup !
donc si je comprends bien: dans une premiere DMZ le serveur http, dans une deuxieme DMZ le serveur oracle la dmz1 ne communique que par des requetes oracle vers la dmz2 Exacte !
si la dmz1 est corrompu, on aura le risque donc incontournable que le gars fasse des requetes 'malsaines' sur la BD (il aura récupéré le login/password d'ériture)
Tu ne pas arrêter une attaque, tu peux juste la compliqué.
Par exemple en mettant une autre couche, en mettant un premier serveur web en front end qui relaiera les requêtes au moteur ( ds une architecture J2EE tomcat, ou architecture LAMP avec PHP). Comme cela s'il pirate le serveur web, il devra attaquer le serveur applicatif ensuite. Et de là, modifiable les bases: faisable, mais bcp plus compliqué...
Jean LAVENANT
T0t0
"cdt_sylvestre" wrote in message news:3fe01bb0$0$28678$
dois je mettre: -le serveur web et le serveur oracle dans la DMZ -le serveur web dans la DMZ, oracle dans le reseau local de l entreprise
pour moi la DMZ ne doit pas communiquer avec le reseau local, mais cela doit etre le reseau local qui doit communiquer avec les serveur dans la DMZ
Tu peux faire une recherche sur les principes d'architecture n-tiers. Ca devrait répondre à tes interrogations.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"cdt_sylvestre" <cdtEffacercAsly@relayeur.com> wrote in message
news:3fe01bb0$0$28678$626a54ce@news.free.fr
dois je mettre:
-le serveur web et le serveur oracle dans la DMZ
-le serveur web dans la DMZ, oracle dans le reseau local de l entreprise
pour moi la DMZ ne doit pas communiquer avec le reseau local, mais cela doit
etre le reseau local qui doit communiquer avec les serveur dans la DMZ
Tu peux faire une recherche sur les principes d'architecture n-tiers.
Ca devrait répondre à tes interrogations.
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
