ブログ放置しすぎてすんません。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の設計の際に何を考慮するかわからない場合には、参考になると思います。
2011年4月28日木曜日
2010年12月28日火曜日
2010年のまとめのまとめ
もうすぐ正月だ。来年を気持ちよく迎えるために、今年一年をさらっと振り返ってみますかね。
新バイクの導入
まずは、プライベートから。今年1年の一番のイベントは、新バイクの入手だな。これのせいでライフスタイルが思いっきり変化した。シングルスピードいいけど、やっぱマルチはいいね。
バイクは8月に納品だった。その後、12月末までに8回くらいは山に行った。9〜10月中までは資格の受験対策(ちなみに、合格した)のせいで乗れなかったので、4ヶ月で8回くらいか。駄目だね。全然乗り足りないね。自転車成分が足りなくて脚気になりそう...
反省点は怪我。切り傷と打ち身は数知れず・・・
- 脛を強打してアザで足が真っ青になる
- 股間を強打して顔が真っ青になる
- 前転して頭部を打ってヘルメットが凹む
- 谷にバイクを落としそうになって自分が落ちて切り傷
- 日焼けしすぎて皮膚科に行く
あと、前半は機材の故障も多かったな。ということで、来年は少し大人しく乗ります。でもって乗る回数を増やします。
それ以外は?
次に仕事面。前半はCA(公開鍵認証局)の移行作業だった。はじめてRSA製品 + nCipherのHSMの構成を使ったけど、自分でも満足する品質の仕事ができたと思う。慣れない営業仕事もやったから、そっちの方で精神的な負担が大きかったけど、技術面では問題はなかった。自分の適性を実感できた前半でした。
後半も同じような認証局(AD DSとかAD CSとかnCipher HSMとか)の移行作業だったけど、こちらはトラブル続きでした。上司との連携が最悪で思うように仕事が進まなく、「コレが噂の『ピーターの法則』ってやつか!はじめて見たぜ。」とか思ってました。こういう典型的な苦労も自分が人を使う立場になったときに役に立つんだろうと思うと微笑ましい限り。
ということで、来年は仕事のストレスを許容できる範囲で適当に頑張ります。もちろん溜まったストレスは山に捨ててきます。捨てる量がクソ多いので山に行く回数も自然と増えますが、捨てられる分だけマシです。でも捨てられなくなったらどうすっかなぁ。山に籠るか。
2010年、他にもいろいろあったけど、
本当は暗号2010年問題でモメた話とか、i386アセンブラでプチOSを作る話とか、女性に間違われてナンパされた話とかもあるんだけど、たぶん年内の更新は(面倒なので)コレでおしまい。皆様、よいお年を。
2010年9月1日水曜日
RSA Confarence 2010に行きたい!(たぶん無理)
今年も、RSA Confarenceの次期になった。昨年はNETWORK INTEROPと同時開催だったため、会場の隅の方でひっそりとやっていて、RSA社(とPKI業界)の将来に不安を抱いたもんだが、今年はグランドプリンスホテル赤坂で開催するそうな。
どうせ行けないけど、気になるセッションは...
どうせ行けないけど、気になるセッションは...
- CR-001 ブロック暗号・軽量暗号の最新動向
- CR-002 量子暗号の現状と展望~ セキュアフォトニックネットワークの実現に向けて ~
- WH-004 高信頼・高安全ソフトウェアのための数理的検証手法:最新の研究と応用の現状
- CR-003 ハッシュ関数の現状と今後の動向
- CR-004 クラウド時代の新しい暗号技術~ 関数型暗号 ~
- CR-005 素因数分解実装実験の最新状況報告
実は、暗号よりも「WH-004 高信頼・高安全ソフトウェアのための数理的検証手法」のセッションに興味がある。私は学生のころ(ずいぶん前だが...)、Fomal Velification Methodのうち、並行モデルのモデルチェックの研究をしていた。当時は論理回路のチェックがCADに実装されたころで、ソフトウェアのチェックは組み込み用途などの非常に限定された分野にしか適用できず、しかも大して役に立たなかったのだ。
並行モデルにおける組み合わせ状態の爆発的な増加の問題が解決されたのか、ブレイクスルーが起こって全数探索以外の動向が出てきたのか。そこら辺が気になるところ。
まぁ、今のスケジュールでは参加できないだろうがね... USTREAMで中継してくれないかなあ。5000円で全セッションが見れるとかだと、すごい助かるんだけど。
2010年6月18日金曜日
今年もPKI Day 2010が開催されるぞ!
6月29日に毎年恒例のJNSA主催のPKI Day 2010が開催される。申し込みはコチラ。まだ申し込んでないから、急がないと。でも、最近は微妙に忙しくなってしまって、行けないかもしれない。29日か....何かリリースがあったような気がするし。
個人的には、こういうセミナーってのは凄く重要だと思う。PKI関連は専門性が高い分、市場が狭い。だから他人の意見を聞く機会が少なくて、どうしても独りよがりになりがち。こういったセミナーで色々な人の意見が聞けるってのは、すごいありがたい事だ。
あぁー。どうすっかな。行きたいな。休日出勤して進捗を稼いでおくか…うーん。今、担当してる案件は絶賛炎上中だし、無理だよなぁ。
個人的には、こういうセミナーってのは凄く重要だと思う。PKI関連は専門性が高い分、市場が狭い。だから他人の意見を聞く機会が少なくて、どうしても独りよがりになりがち。こういったセミナーで色々な人の意見が聞けるってのは、すごいありがたい事だ。
あぁー。どうすっかな。行きたいな。休日出勤して進捗を稼いでおくか…うーん。今、担当してる案件は絶賛炎上中だし、無理だよなぁ。
2010年6月4日金曜日
近況報告(死んでませんよ)
実は死んでいました
前回の投降からずいぶんと日が開いてしまった。ブログから離れていたのは、仕事の量が(無駄に)多かったのと、その所為で精神的にダウンしたこと。「PCなんて触りたくもねぇ」って感じになっていました。いや、実際に家では全く触らなかったんだけどね。今は仕事も一段落しています。
ちなみに体重は10キログラムも増えました。元に戻には1年くらいかかりそう。BMIは25を超えたので、「準肥満」って奴に分類されてしまった!
死んでいた理由
この3ヶ月を振り返ってみると、実際の業務量はそこまで多くないのに、異様に体力と精神力を消耗していたことに気付いた。体力的にも精神的にも落ち着いてきた今では、苦労した理由が明確になってきた様に思える。思いつく限りに並べてみると、
死んでみて学んだ事
会社の業務が個人に依存することの危険性を、身を以て体験した。技術系のネタなら技術書を読めば習得できるが、会社特有の仕事のやり方は市販の本では習得できない。こういったものはフロー化して情報システムとして作り込むなり、マニュアル化して研修するなりして、効率よく新人に伝授する方法が必要だと思う。(というより、やって当然だと思う。それが無い状態で前線に投入するのがおかしいだろ)
また、個人の中にあるノウハウを適切に伝授することの重要性を実感した。個人の中のノウハウは、ある結果を得るための過程で蓄積される。ある仕事の結果をナレッジベースで管理する事は多々あるが、その結果を得るまでの道筋が残っていない事が多い。そういったノウハウを集約・整理して共有することが、後に続く者の能力を高め、ひいては長期的な視点で見た場合の会社の能力を上げる事に繋がると思う。しかし、個人の中のノウハウは、文書化できないことも多いので、とても難しい課題だと思う。(他の会社はどうやっているんだろう)
今回の苦労は色々と考えさせられた。私は個人依存を極力減らし、情報の見通しを良くするように努力したいと思う。
前回の投降からずいぶんと日が開いてしまった。ブログから離れていたのは、仕事の量が(無駄に)多かったのと、その所為で精神的にダウンしたこと。「PCなんて触りたくもねぇ」って感じになっていました。いや、実際に家では全く触らなかったんだけどね。今は仕事も一段落しています。
ちなみに体重は10キログラムも増えました。元に戻には1年くらいかかりそう。BMIは25を超えたので、「準肥満」って奴に分類されてしまった!
死んでいた理由
この3ヶ月を振り返ってみると、実際の業務量はそこまで多くないのに、異様に体力と精神力を消耗していたことに気付いた。体力的にも精神的にも落ち着いてきた今では、苦労した理由が明確になってきた様に思える。思いつく限りに並べてみると、
- 兼任が多すぎること
プロジェクトマネージャーとソリューション営業と開発者を全て兼任した。 - 初めての職種が多かった
プロジェクトマネージャーとソリューション営業は初めての経験だった。
開発よりもPMと営業の負荷が高かった。実際、これらの負荷が減った時期は順調でした。 - 初めての作業に対するフォローアップ体制の欠如
初めて行なう職種なのに、適切な教育が行なわれなかった。請負契約?それっておいしいの?って状態からのスタートでした。見積作成なんか、社内で何度もやってるだろうに、業務のフロー化がされていないので、何をしていいかサッパリ解らない。完全にゼロからのスタートでした。 - 納期がクソ短い
見積作成に4日とか。ダイナミックなスケジュールでした。
死んでみて学んだ事
会社の業務が個人に依存することの危険性を、身を以て体験した。技術系のネタなら技術書を読めば習得できるが、会社特有の仕事のやり方は市販の本では習得できない。こういったものはフロー化して情報システムとして作り込むなり、マニュアル化して研修するなりして、効率よく新人に伝授する方法が必要だと思う。(というより、やって当然だと思う。それが無い状態で前線に投入するのがおかしいだろ)
また、個人の中にあるノウハウを適切に伝授することの重要性を実感した。個人の中のノウハウは、ある結果を得るための過程で蓄積される。ある仕事の結果をナレッジベースで管理する事は多々あるが、その結果を得るまでの道筋が残っていない事が多い。そういったノウハウを集約・整理して共有することが、後に続く者の能力を高め、ひいては長期的な視点で見た場合の会社の能力を上げる事に繋がると思う。しかし、個人の中のノウハウは、文書化できないことも多いので、とても難しい課題だと思う。(他の会社はどうやっているんだろう)
今回の苦労は色々と考えさせられた。私は個人依存を極力減らし、情報の見通しを良くするように努力したいと思う。
登録:
コメント (Atom)

