je suis en train de peaufiner une petite autorite de certification, de
quoi gerer quelques certificats serveurs et autant utilisateurs (une
20aine a tout casser dans chaque cas).
Il me reste un dernier probleme : rediger (ou ne pas le faire) une
politique de certification et une declaration des pratiques de
certification.
Bon, je sais bien que c'est mieux avec mais ca m'a l'air lourdingue...
Des commentaires, moqueries, insultes, menaces de mort ?
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
T0t0
"Pascal Cabaud" wrote in message news:ci7lhe$pt7$
je suis en train de peaufiner une petite autorite de certification, de quoi gerer quelques certificats serveurs et autant utilisateurs (une 20aine a tout casser dans chaque cas).
Il me reste un dernier probleme : rediger (ou ne pas le faire) une politique de certification et une declaration des pratiques de certification.
Bon, je sais bien que c'est mieux avec mais ca m'a l'air lourdingue...
Arf, heu... c'est sur que quand on aime bien la technique, ca va souvent de paire avec j'aime pas faire de la doc :-) Concernant la PKI, le problème est le même que beaucoup de solutions de sécurité. Si tu ne documentes pas correctement et que tu n'a pas des procédures claires et précises, il y a de chances pour que ca devienne vite le bordel, et donc peu efficace. En plus, dans le cas d'une PKI, tu es censé authentifier des utilisateurs ou serveurs, ce qui fait qu'il y a une dimension juridique par dessus (selon tes besoins) Enfin, c'est un domaine souvent obscure pour le commun des mortels, et les quelques docs qui peuvent permettre de mieux comprendre le bouzin sont toujours les bienvenues !
Donc le risque si tu documentes mal ou pas du tout est de te retrouver avec de certificats dans la nature, de CRLs pas à jour, des gens pas contents pasqu'ils attendent ou que ca marche pas, enfin bref, que des emmerdes. C'est vrai que pour 20 personnes ca semble pas le Pérou, mais si tu es le seul admin, que se passera-t-il quand tu seras absent ? etc. D'autant plus si ton autorité de certification est différente de ton autorité de distribution, etc. Les documents doivent prendre tous ces paramètres en compte.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Pascal Cabaud" <pcNO@SPAMeila.jussieu.fr> wrote in message
news:ci7lhe$pt7$1@news-reader2.wanadoo.fr
je suis en train de peaufiner une petite autorite de certification, de
quoi gerer quelques certificats serveurs et autant utilisateurs (une
20aine a tout casser dans chaque cas).
Il me reste un dernier probleme : rediger (ou ne pas le faire) une
politique de certification et une declaration des pratiques de
certification.
Bon, je sais bien que c'est mieux avec mais ca m'a l'air lourdingue...
Arf, heu... c'est sur que quand on aime bien la technique, ca va souvent
de paire avec j'aime pas faire de la doc :-)
Concernant la PKI, le problème est le même que beaucoup de solutions
de sécurité. Si tu ne documentes pas correctement et que tu n'a pas des
procédures claires et précises, il y a de chances pour que ca devienne
vite le bordel, et donc peu efficace.
En plus, dans le cas d'une PKI, tu es censé authentifier des
utilisateurs
ou serveurs, ce qui fait qu'il y a une dimension juridique par dessus
(selon tes besoins)
Enfin, c'est un domaine souvent obscure pour le commun des mortels, et
les quelques docs qui peuvent permettre de mieux comprendre le bouzin
sont toujours les bienvenues !
Donc le risque si tu documentes mal ou pas du tout est de te retrouver
avec de certificats dans la nature, de CRLs pas à jour, des gens pas
contents pasqu'ils attendent ou que ca marche pas, enfin bref, que
des emmerdes.
C'est vrai que pour 20 personnes ca semble pas le Pérou, mais si tu es
le seul admin, que se passera-t-il quand tu seras absent ? etc.
D'autant plus si ton autorité de certification est différente de ton
autorité de distribution, etc.
Les documents doivent prendre tous ces paramètres en compte.
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
je suis en train de peaufiner une petite autorite de certification, de quoi gerer quelques certificats serveurs et autant utilisateurs (une 20aine a tout casser dans chaque cas).
Il me reste un dernier probleme : rediger (ou ne pas le faire) une politique de certification et une declaration des pratiques de certification.
Bon, je sais bien que c'est mieux avec mais ca m'a l'air lourdingue...
Arf, heu... c'est sur que quand on aime bien la technique, ca va souvent de paire avec j'aime pas faire de la doc :-) Concernant la PKI, le problème est le même que beaucoup de solutions de sécurité. Si tu ne documentes pas correctement et que tu n'a pas des procédures claires et précises, il y a de chances pour que ca devienne vite le bordel, et donc peu efficace. En plus, dans le cas d'une PKI, tu es censé authentifier des utilisateurs ou serveurs, ce qui fait qu'il y a une dimension juridique par dessus (selon tes besoins) Enfin, c'est un domaine souvent obscure pour le commun des mortels, et les quelques docs qui peuvent permettre de mieux comprendre le bouzin sont toujours les bienvenues !
Donc le risque si tu documentes mal ou pas du tout est de te retrouver avec de certificats dans la nature, de CRLs pas à jour, des gens pas contents pasqu'ils attendent ou que ca marche pas, enfin bref, que des emmerdes. C'est vrai que pour 20 personnes ca semble pas le Pérou, mais si tu es le seul admin, que se passera-t-il quand tu seras absent ? etc. D'autant plus si ton autorité de certification est différente de ton autorité de distribution, etc. Les documents doivent prendre tous ces paramètres en compte.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Benoit
Le 15 Sep 2004 12:57:21 GMT, Pascal Cabaud :
je suis en train de peaufiner une petite autorite de certification, de quoi gerer quelques certificats serveurs et autant utilisateurs (une 20aine a tout casser dans chaque cas).
Il me reste un dernier probleme : rediger (ou ne pas le faire) une politique de certification et une declaration des pratiques de certification.
Tout dépend de ton organisatoin et de tes objectifs: - est-ce que tu es le seul à tout faire (i.e. installation technique administration et enrôlement des agents --officier d'AE--) ou est-ce que d'autres personnes, peu conscientes de leur rôle, vont être impliquées dans la délivrance (DRH ? directeur de compte, de projet ?) - est-ce que tu vas entrer en relation avec des tiers (partenaires clients) qui, pour «croire» ta CA, vont te demander les niveaux d'exigence de ton autorité (et, donc ces docs) ? - est-ce que les choses que tu mets en place sont d'un «temporaire» certain (i.e. pour une mission ou un projet) ou est-ce que cela durera ? -- pour info, les bonnes pratiques en matière d'IGC prévoient souvent une durée de vie de la RootCA de *trente* ans, il faut donc avoir des docs bien propres pour assurer un service raisonnable pour ce type de durée). - donc, surtout, la question à savoir est: est-ce que tu fais cette PKI pour un service qui pourrait être extensible et devenir, au fil du temps, important ?
Si ce n'est pas le cas, pour aucune question, effectivement, tu peux dormir tranquille sans doc: tu es le seul responsable du truc et c'est très bien comme cela.
Si tu réponds «oui» à une ou plusieurs de ces questions (et not. la dernière), fais avec soin (1) la création des clefs racine (2) la protection de la clef de la CA (3) les procédures d'enrôlemement et de révocation des agents et serveurs.
Voici quelques pistes personnelles pour faire cela très bien sans avoir trop de sous ou de temps, mais assurer quand même les bases d'un service fiable qui pourra grossir au fil du temps.
-1- faire une key ceremony avec quelques responsables de la boutique, ca dure une heure, on peut prendre un pot en meme temps, et puis ca implique les autres resp. («rappelle-toi tu étais au courant de cette PKI, tu étais présent !»)
variante: couper les clefs de l'AC Racine en N parmi M (exemple: en 3 sur 7) et filer un morceau du secret à chacun des responsables («tu es au courant de la PKI, tu as même un morceau du secret dans ton coffre !») --
Avantage: si l'IGC sert à d'autres trucs, les gens le sauront et cela ne sera pas une clef faite sur un coin de table: elle «appartiendra» à la structure.
-2- protection des clefs de l'AC en production. un truc bien sympa est de tirer une clef d'ac soft, sur une machine hors-ligne, la copier sur CD, la coller au coffre, et puis copier cette clef sur une carte à puce et mettre l'AC en ligne avec la carte comme HSM pas cher. C'est vraiment sympa parce que * les cartes à puce ont un excellent niveau d'habilitation (EAL4+, FIPS et compagnie) -> ce n'est pas un HSM au rabais mais juste un HSM *pas cher*; * une carte, ça rame, d'accord, mais la CA n'est jamais (enfin très rarement!) le goulot d'entranglement (on fait rarement whatzillion de cert par jour); * si la carte grille (ca peut arriver) tu n'as qu'a sortir le cd du coffre et en faire une autre parce que tu as une copie sûre de la clef -> tu assures donc une continuité de service.
-3- les procédures agents et serveurs Il faut toujours rédiger un minimum de choses, quitte à les corriger / étoffer un peu par la suite; il faut au moins . la PC (pourquoi on fait le service) . la DPC (comment on opère le service)
mets des révisions, comme cela, tu auras l'occasion de les faire évoluer en douceur si cela devient opportun.
en espérant avoir un peu aidé,
amicalement,
-- Benoit
-- adresse anti spam: beurk le spam est en trop.
Le 15 Sep 2004 12:57:21 GMT, Pascal Cabaud pcNO@SPAMeila.jussieu.fr:
je suis en train de peaufiner une petite autorite de certification, de
quoi gerer quelques certificats serveurs et autant utilisateurs (une
20aine a tout casser dans chaque cas).
Il me reste un dernier probleme : rediger (ou ne pas le faire) une
politique de certification et une declaration des pratiques de
certification.
Tout dépend de ton organisatoin et de tes objectifs:
- est-ce que tu es le seul à tout faire (i.e. installation technique
administration et enrôlement des agents --officier d'AE--) ou
est-ce que d'autres personnes, peu conscientes de leur rôle,
vont être impliquées dans la délivrance (DRH ? directeur de
compte, de projet ?)
- est-ce que tu vas entrer en relation avec des tiers (partenaires
clients) qui, pour «croire» ta CA, vont te demander les niveaux
d'exigence de ton autorité (et, donc ces docs) ?
- est-ce que les choses que tu mets en place sont d'un «temporaire»
certain (i.e. pour une mission ou un projet) ou est-ce que cela
durera ? -- pour info, les bonnes pratiques en matière d'IGC
prévoient souvent une durée de vie de la RootCA de *trente*
ans, il faut donc avoir des docs bien propres pour assurer un
service raisonnable pour ce type de durée).
- donc, surtout, la question à savoir est: est-ce que tu fais cette
PKI pour un service qui pourrait être extensible et devenir, au
fil du temps, important ?
Si ce n'est pas le cas, pour aucune question, effectivement, tu
peux dormir tranquille sans doc: tu es le seul responsable du
truc et c'est très bien comme cela.
Si tu réponds «oui» à une ou plusieurs de ces questions (et not. la
dernière), fais avec soin (1) la création des clefs racine (2) la
protection de la clef de la CA (3) les procédures d'enrôlemement
et de révocation des agents et serveurs.
Voici quelques pistes personnelles pour faire cela très bien sans
avoir trop de sous ou de temps, mais assurer quand même les bases
d'un service fiable qui pourra grossir au fil du temps.
-1- faire une key ceremony avec quelques responsables de
la boutique, ca dure une heure, on peut prendre un pot en
meme temps, et puis ca implique les autres resp. («rappelle-toi tu
étais au courant de cette PKI, tu étais présent !»)
variante: couper les clefs de l'AC Racine en N parmi M (exemple: en
3 sur 7) et filer un morceau du secret à chacun des responsables
(«tu es au courant de la PKI, tu as même un morceau du secret dans
ton coffre !») --
Avantage: si l'IGC sert à d'autres trucs, les gens le sauront et
cela ne sera pas une clef faite sur un coin de table: elle
«appartiendra» à la structure.
-2- protection des clefs de l'AC en production. un truc bien sympa est
de tirer une clef d'ac soft, sur une machine hors-ligne, la
copier sur CD, la coller au coffre, et puis copier cette clef sur
une carte à puce et mettre l'AC en ligne avec la carte comme HSM
pas cher. C'est vraiment sympa parce que
* les cartes à puce ont un excellent niveau d'habilitation
(EAL4+, FIPS et compagnie) -> ce n'est pas un HSM au rabais
mais juste un HSM *pas cher*;
* une carte, ça rame, d'accord, mais la CA n'est jamais (enfin
très rarement!) le goulot d'entranglement (on fait rarement
whatzillion de cert par jour);
* si la carte grille (ca peut arriver) tu n'as qu'a sortir
le cd du coffre et en faire une autre parce que tu as une copie
sûre de la clef -> tu assures donc une continuité de service.
-3- les procédures agents et serveurs
Il faut toujours rédiger un minimum de choses, quitte à les
corriger / étoffer un peu par la suite; il faut au moins
. la PC (pourquoi on fait le service)
. la DPC (comment on opère le service)
mets des révisions, comme cela, tu auras l'occasion de les faire
évoluer en douceur si cela devient opportun.
je suis en train de peaufiner une petite autorite de certification, de quoi gerer quelques certificats serveurs et autant utilisateurs (une 20aine a tout casser dans chaque cas).
Il me reste un dernier probleme : rediger (ou ne pas le faire) une politique de certification et une declaration des pratiques de certification.
Tout dépend de ton organisatoin et de tes objectifs: - est-ce que tu es le seul à tout faire (i.e. installation technique administration et enrôlement des agents --officier d'AE--) ou est-ce que d'autres personnes, peu conscientes de leur rôle, vont être impliquées dans la délivrance (DRH ? directeur de compte, de projet ?) - est-ce que tu vas entrer en relation avec des tiers (partenaires clients) qui, pour «croire» ta CA, vont te demander les niveaux d'exigence de ton autorité (et, donc ces docs) ? - est-ce que les choses que tu mets en place sont d'un «temporaire» certain (i.e. pour une mission ou un projet) ou est-ce que cela durera ? -- pour info, les bonnes pratiques en matière d'IGC prévoient souvent une durée de vie de la RootCA de *trente* ans, il faut donc avoir des docs bien propres pour assurer un service raisonnable pour ce type de durée). - donc, surtout, la question à savoir est: est-ce que tu fais cette PKI pour un service qui pourrait être extensible et devenir, au fil du temps, important ?
Si ce n'est pas le cas, pour aucune question, effectivement, tu peux dormir tranquille sans doc: tu es le seul responsable du truc et c'est très bien comme cela.
Si tu réponds «oui» à une ou plusieurs de ces questions (et not. la dernière), fais avec soin (1) la création des clefs racine (2) la protection de la clef de la CA (3) les procédures d'enrôlemement et de révocation des agents et serveurs.
Voici quelques pistes personnelles pour faire cela très bien sans avoir trop de sous ou de temps, mais assurer quand même les bases d'un service fiable qui pourra grossir au fil du temps.
-1- faire une key ceremony avec quelques responsables de la boutique, ca dure une heure, on peut prendre un pot en meme temps, et puis ca implique les autres resp. («rappelle-toi tu étais au courant de cette PKI, tu étais présent !»)
variante: couper les clefs de l'AC Racine en N parmi M (exemple: en 3 sur 7) et filer un morceau du secret à chacun des responsables («tu es au courant de la PKI, tu as même un morceau du secret dans ton coffre !») --
Avantage: si l'IGC sert à d'autres trucs, les gens le sauront et cela ne sera pas une clef faite sur un coin de table: elle «appartiendra» à la structure.
-2- protection des clefs de l'AC en production. un truc bien sympa est de tirer une clef d'ac soft, sur une machine hors-ligne, la copier sur CD, la coller au coffre, et puis copier cette clef sur une carte à puce et mettre l'AC en ligne avec la carte comme HSM pas cher. C'est vraiment sympa parce que * les cartes à puce ont un excellent niveau d'habilitation (EAL4+, FIPS et compagnie) -> ce n'est pas un HSM au rabais mais juste un HSM *pas cher*; * une carte, ça rame, d'accord, mais la CA n'est jamais (enfin très rarement!) le goulot d'entranglement (on fait rarement whatzillion de cert par jour); * si la carte grille (ca peut arriver) tu n'as qu'a sortir le cd du coffre et en faire une autre parce que tu as une copie sûre de la clef -> tu assures donc une continuité de service.
-3- les procédures agents et serveurs Il faut toujours rédiger un minimum de choses, quitte à les corriger / étoffer un peu par la suite; il faut au moins . la PC (pourquoi on fait le service) . la DPC (comment on opère le service)
mets des révisions, comme cela, tu auras l'occasion de les faire évoluer en douceur si cela devient opportun.
