Nous étudions actuellement une archi de VPN dans le cas d'un Disaster
Recovery Plan bien spécifique. Plus particulierement on etudie ce qui
peut se faire pour authentifier les users se connectant a cet acces VPN
de chez eux. On souhaiterais avoir quelque chose de mieux qu ele
login/pass, mais on aimerait eviter la PKI qui serait extrememenbt
lourde à gerer en permanence compte tenu de la proba faible que ce DRP
soit un jour employé.
Ca doit marcher avec un client SecuRemote de CP.
Dans notre reflexion on a les SecurID, les token USB (type alladin), les
authents par certif, et je me demandais si un éditeur avait pondu une
solution à base de SMS, ie le user recevrait un one time pass par son
tel gsm via SMS qu'il pourrait ensuite utiliser en conjonction avec un
code fixe pour s'authentifier sur le firewall (via j'imagine un serveur
Radius custom).
OoO En cette matinée ensoleillée du vendredi 17 février 2006, vers 09:24, DarkSboub disait:
Dans notre reflexion on a les SecurID, les token USB (type alladin),
Ca coûte combien environ ces tokens USB ? -- BOFH excuse #278: The Dilithium Cyrstals need to be rotated.
Eric Razny
Le Fri, 17 Feb 2006 08:24:25 +0000, DarkSboub a écrit :
Nous étudions actuellement une archi de VPN dans le cas d'un Disaster Recovery Plan bien spécifique. Plus particulierement on etudie ce qui peut se faire pour authentifier les users se connectant a cet acces VPN de chez eux. On souhaiterais avoir quelque chose de mieux qu ele login/pass, mais on aimerait eviter la PKI qui serait extrememenbt lourde à gerer en permanence compte tenu de la proba faible que ce DRP soit un jour employé.
Bonjour. J'ai bien peur que la direction envisagée ne soit pas très probante. Eviter une PKI parce que c'est lourd à gérer je peux comprendre (encore que pour un VPN c'est finalement ce qui me semble le plus simple, avec ou sans tokens physiques :) ).
Par contre "éviter ... faible proba que" j'ai peur, amha, que vous vous dirigiez directement vers une catastrophe si le "disaster occurs". Si on met en place un DRP c'est qu'on a des services critiques à maintenir. Si on a à l'esprit que le DRP ne sera jamais utilisé c'est la porte ouverte à un manque progressif de vigilance et lors du désastre un employé viré aura accès au système parce qu'on n'aura pas géré correctement le tout[1]. Même avec les clefs physiques il faut gérer les pertes, les vols, les "non rendu" (l'ancien employé qui a effectué son départ alors que le gus du service info était absent quelques jours[2]).
Que ce soit une PKI avec une crl ou une autre façon pour un serveur radius d'autentifier le personnel authorisé ce ne change pas grand chose : ça doit être à jour.
Si le DRP est mis en branle suite à une attaque, le système de secours a au moins intérêt à filtrer les entrées! (et à être mis en service quand on pense avoir patché la faille initiale :) )
Un DRP est quelque chose d'assez complexe à gérer et je doute que le contrôle d'accès, fusse par PKI, soit la chose la plus problèmatique.
Eric
[1] en restant dans le cadre de l'accès. Parce que si vous partez sur cette façon de gérer le DRP, quid dans 5 ans des services qui auront étés ajoutés entre temps, et qui n'auront pas été intégrés au DRP alors qui finalement ils sont devenus "vitaux".
[2] ben oui. Il faut partir quand même avec l'idée que le service info peut merder, même si ça ne devrait pas :)
Le Fri, 17 Feb 2006 08:24:25 +0000, DarkSboub a écrit :
Nous étudions actuellement une archi de VPN dans le cas d'un Disaster
Recovery Plan bien spécifique. Plus particulierement on etudie ce qui
peut se faire pour authentifier les users se connectant a cet acces VPN de
chez eux. On souhaiterais avoir quelque chose de mieux qu ele login/pass,
mais on aimerait eviter la PKI qui serait extrememenbt lourde à gerer en
permanence compte tenu de la proba faible que ce DRP soit un jour
employé.
Bonjour.
J'ai bien peur que la direction envisagée ne soit pas très probante.
Eviter une PKI parce que c'est lourd à gérer je peux comprendre (encore
que pour un VPN c'est finalement ce qui me semble le plus simple, avec ou
sans tokens physiques :) ).
Par contre "éviter ... faible proba que" j'ai peur, amha, que vous vous
dirigiez directement vers une catastrophe si le "disaster occurs".
Si on met en place un DRP c'est qu'on a des services critiques à
maintenir. Si on a à l'esprit que le DRP ne sera jamais utilisé c'est la
porte ouverte à un manque progressif de vigilance et lors du désastre un
employé viré aura accès au système parce qu'on n'aura pas géré
correctement le tout[1]. Même avec les clefs physiques il faut gérer les
pertes, les vols, les "non rendu" (l'ancien employé qui a effectué son
départ alors que le gus du service info était absent quelques jours[2]).
Que ce soit une PKI avec une crl ou une autre façon pour un serveur
radius d'autentifier le personnel authorisé ce ne change pas grand chose
: ça doit être à jour.
Si le DRP est mis en branle suite à une attaque, le système de secours a
au moins intérêt à filtrer les entrées! (et à être mis en service
quand on pense avoir patché la faille initiale :) )
Un DRP est quelque chose d'assez complexe à gérer et je doute que le
contrôle d'accès, fusse par PKI, soit la chose la plus problèmatique.
Eric
[1] en restant dans le cadre de l'accès. Parce que si vous partez sur
cette façon de gérer le DRP, quid dans 5 ans des services qui auront
étés ajoutés entre temps, et qui n'auront pas été intégrés au DRP
alors qui finalement ils sont devenus "vitaux".
[2] ben oui.
Il faut partir quand même avec l'idée que le service info peut merder,
même si ça ne devrait pas :)
Le Fri, 17 Feb 2006 08:24:25 +0000, DarkSboub a écrit :
Nous étudions actuellement une archi de VPN dans le cas d'un Disaster Recovery Plan bien spécifique. Plus particulierement on etudie ce qui peut se faire pour authentifier les users se connectant a cet acces VPN de chez eux. On souhaiterais avoir quelque chose de mieux qu ele login/pass, mais on aimerait eviter la PKI qui serait extrememenbt lourde à gerer en permanence compte tenu de la proba faible que ce DRP soit un jour employé.
Bonjour. J'ai bien peur que la direction envisagée ne soit pas très probante. Eviter une PKI parce que c'est lourd à gérer je peux comprendre (encore que pour un VPN c'est finalement ce qui me semble le plus simple, avec ou sans tokens physiques :) ).
Par contre "éviter ... faible proba que" j'ai peur, amha, que vous vous dirigiez directement vers une catastrophe si le "disaster occurs". Si on met en place un DRP c'est qu'on a des services critiques à maintenir. Si on a à l'esprit que le DRP ne sera jamais utilisé c'est la porte ouverte à un manque progressif de vigilance et lors du désastre un employé viré aura accès au système parce qu'on n'aura pas géré correctement le tout[1]. Même avec les clefs physiques il faut gérer les pertes, les vols, les "non rendu" (l'ancien employé qui a effectué son départ alors que le gus du service info était absent quelques jours[2]).
Que ce soit une PKI avec une crl ou une autre façon pour un serveur radius d'autentifier le personnel authorisé ce ne change pas grand chose : ça doit être à jour.
Si le DRP est mis en branle suite à une attaque, le système de secours a au moins intérêt à filtrer les entrées! (et à être mis en service quand on pense avoir patché la faille initiale :) )
Un DRP est quelque chose d'assez complexe à gérer et je doute que le contrôle d'accès, fusse par PKI, soit la chose la plus problèmatique.
Eric
[1] en restant dans le cadre de l'accès. Parce que si vous partez sur cette façon de gérer le DRP, quid dans 5 ans des services qui auront étés ajoutés entre temps, et qui n'auront pas été intégrés au DRP alors qui finalement ils sont devenus "vitaux".
[2] ben oui. Il faut partir quand même avec l'idée que le service info peut merder, même si ça ne devrait pas :)
Sieg
Hello :)
Je ne sais pas si l'authentification SMS est une bonne chose. En effet, apparemment l'entete serait falsifiable.
:)
http://www.waste.org/~terje/palm/SMSspoof/
Hello :)
Je ne sais pas si l'authentification SMS est une bonne chose. En effet,
apparemment l'entete serait falsifiable.
