ブログ放置しすぎてすんません。3月は案件が炎上＆大震災で完全に疲れ切ってました。4月も反動で低調な感じで、やっと連休前になって落ち着いてきたところです。このゴールデンウィークで遊びまくって気分をリフレッシュしたいところですね。
私は、ここしばらくは公開鍵認証局（CA）のCA鍵更新案件に付きっきりでした。CA鍵の更新はどんなCA製品でも大して難しくはありませんが、下手にCA鍵を更新を実行してしまうと、証明書の利用者が証明書を検証できなくなったりして、たいへんなことになってしまいます。今回はユーザーが数万単位と多く、ミスがユーザーの業務継続性に直結するので、より精度の高い仕事が求められていました。
そんな理由もあって、今回は模擬環境を使って更新手順を作成し、十分に検証してから本番で作業をしましたが、既存のドキュメントをベースにした検証用の環境と実際に稼働している本番環境に差が生じてしまい、本番の作業時に様々なトラブルが発生してしまいました。詳細は書く事はでいませんが、初期構築時のドキュメントの記述ミスが数年後になって発覚したことになります。
CAは通常のシステムに比べて運用期間が長くなる傾向があります。特にCA鍵更新等のオペレーションは数年に1度しか行ないません。このため、今回のように初期構築時の不手際が実際に表面化するのが、数年後になるというはありがちなパターンです。初期導入時のドキュメントの作成や、その後のドキュメントのメンテナンスは往々にして軽視しがちではありますが、CAのように長期に渡って運用するシステムについては、多少コストがかかったとしてもしっかりと行なっておく必要があると思います。
また、初期構築時にCA鍵更新や危殆化への対応などの、運用中に発生するイベントを見越してシステムの設計/構築を行なう必要もあると思います。事前に設計しろって言われてもPKIなんぞよくわからん！って人は、RFC 3647が参考になると思います。RFC 3647は証明書ポリシー/認証局運用既定 (CP/CPS) の雛形を提供しています。CP/CPSはCAが発行する証明書の種類や運用方針を記述する文書です。この文書はパブリックなCA（GPKIやSSL証明書販売ベンダーなど）は、インターネットで公開するのが普通です。例えば、SSL証明書の販売で有名なベリサインのCP/CPSはこちらで公開されています。
社内だけで使用するプライベートなCAならば、厳密なCP/CPSの作成は必要ないとは思いますが、CAの設計の際に何を考慮するかわからない場合には、参考になると思います。
