データベース暗号化ガイドライン by DBSC

ここ数年はデータベースの暗号化に関する話題が（少しだけ）盛り上がりを見せているようです。某HSM屋さんの話によると、近年はDB暗号化の割合は着実に増えて来ているそうです。数年前と比べると、セキュリティに対する意識は変わってきたのでしょうね。

さて、11/1にデータベース・セキュリティ・コンソーシアム（DBSC）から「データベース暗号化ガイドライン 第1.0版」(PDFです）が公開されていました。35ページほどの文書ですが、データベース暗号化を行う際に考慮すべき事項がよく纏められています。暗号関連のお仕事をしている人は、ざっと目を通しておくとよいと思います。

読んでみた感想ですが、対象は何にせよ暗号を行う際に一番の問題となるのが、やっぱり暗号鍵の運用だなと思いました。暗号に詳しくない人は、一度データを暗号化すれば情報漏洩を防げると考えてしまいがちですが、実際は暗号鍵の危殆化や暗号アルゴリズムの脆弱性に対応しなければなりません。

それ以外にも、暗号鍵の安全な保管や、可監査性の担保と定期的な監査の実施などの暗号システムに特有なオペレーションが多く、意外と運用面での負担が大きかったりします。また、こういった暗号システム特有の運用に関する観点は、暗号分野が専門性の高い分野であることもあり、エンドユーザさんも正確に理解できていないことが多いと思います。

最近はPKI絡みのインシデントも多いですし、今後は暗号に対する基本知識が、構築側／運用側を問わずに必須になってくるのかもしれませんね。

今度はDigiCert Sdn社が不正な証明書を発行してしまった件

MicrosoftからSecurity Advisory 2641690が提供されています。先日のDiginotar社の騒動に続き、今度はDigiCert Sdn社の中間認証局が不正な証明書を発行してしまったそうです。どうやら弱い鍵アルゴリズムを使った証明書が発行されてしまったらしく、2つの中間認証局の証明書が失効されたそうです。

Micorosoftから提供されたパッチを適用する前と後でのWindows証明書ストアの変化を見てみましょう。パッチ適用前の証明書管理コンソール（certmgr.msc)の状態は以下のようになります。

パッチ適用後の証明書管理コンソールの状態は以下のようになります。2つの中間認証局が信頼されていない認証局に追加されているのが分かります。発行元はEntrustとCyber Trustですね。

しかし、最近は証明書関連のインシデントが多いですね。これが氷山の一角ではなければいいのですが。

今更ながらWindows 7のReadyBoostを使う

Pentium 4, メモリー1GBの遅いPCでWindows 7を使うことになったので、ReadyBoostで高速化できるかどうか試してみました。結果的に体感速度は良くなったのですが、原理が良くわからなかったのでちょっと調べてみました。

ReadyBoostは簡単に言うと、USBメモリーにHDDのキャッシュを作成することによって、アプリケーションの起動を高速に行う技術です。MicrosoftではReadyBoostに使用できるUSBメモリーの要件として、以下の項目を挙げています。

• 4KByteランダム読み込みが、2.5MB/sec
• 512KByteランダム書き込みが、1.75MB/sec

一般的なHDDと比較すると、ずいぶん低い要求に感じます。何故、遅いUSBメモリーにキャッシュを作ると、体感速度が向上するのでしょうか。で、色々ググってみると。ここら辺の話は、Mark Russinovich氏著のInside the Windows Vista kernel: Part 2に記述されていました。以下に引用します。

The speed of CPUs and memory are fast outpacing that of hard disks, so disks are a common system performance bottleneck. Random disk I/O is especially expensive because disk head seek times are on the order of 10 milliseconds-an eternity for today's 3GHz processors. While RAM is ideal for caching disk data, it is relatively expensive. Flash memory, however, is generally cheaper and can service random reads up to 10 times faster than a typical hard disk. 

つまり、 HDDの苦手なランダムアクセスを、ランダムアクセス（の読み込み）が得意なUSBメモリーに肩代わりしてもらうということですね。しかも10倍も違うそうです。

せっかくなので、対象となったマシンのHDDと手元にあるUSBメモリー（3本）の速度を計測してみました。ベンチマークはCrystal Mark 3.01を使用しています。USBメモリーのフォーマットはNTFSです。

たしかに、HDDは4KByteのランダムアクセスが極端に遅くなっています（水色の線です）。そして、USBメモリーの方は3本とも、そこそこの速度が出ています。このアクセス特性の差を使って、HDDの弱点を補完するんですね。

ちなみに、4GBのUSBメモリーを使ってReadyBoostの効き具合をパフォーマンスメーターで確認してみたところ、以下のようになりました。USBメモリーはBAFFALOのRFU3-K4Gです。

Bytes cachedとCache space usedを見ると、4.3GByteのデータが2.5GBに圧縮されてUSBメモリーに記憶されていることが分かります。

USBメモリーに保存されているデータはAESによって暗号化されています。データの圧縮と暗号化のオーバーヘッドを考慮しても、HDDからデータを読むよりかUSBメモリーから読み込んだほうが早くなるということなんですね。これほどまでにHDDのランダムアクセスが遅いのは意外でした。

1点だけ注意点。ReadyBoostはシステム起動時にキャッシュデータをHDDからUSBメモリーに転送します。このため、起動直後はしばらくはHDDへのアクセスが続きます。毎日電源を落とす運用をしている場合は要注意です。

CRYPTREC Report 2010が公開されていた

ちょっと古いネタですが、6月にCRYPTRECからCRYPTREC Report 2010が公開されていました。時間があったので、さらっと読んでみましたが、なかなか興味深いネタが多かったです。

CRYPTRECは独立行政法人 情報通信研究機構（NICT）の一部門として運営されており、日本国で使用する暗号アルゴリズムの一覧である「電子政府推奨暗号リスト」の作成など、重要な作業を担っています。公開されたCRYPTREC Report 2010はCRYPTRECの2010年の1年間の活動をまとめたものです。

内容は色々ありましたが、2013年に公開から10周年を迎える電子政府推奨暗号リストの更新作業や、暗号の脆弱性に対する手法の監視活動、サイドチャネル攻撃手法の研究、FIPS-140-3ドラフトに対するコメントやFIPS-140-3制定後々のISO/IEC, JIS化に関する作業など、中身の濃い話がたくさん書かれていました。

ちなみに、CRYPTRECは先日話題になったAESアルゴリズムに対するアタックについても「直ちに現実的な脅威につながることはない」というコメントを出しています。正直、暗号アルゴリズムについては、一般的な知識しかないので、この発表はとても安心できました。

PKI Day 2011に行ってきた（その2）

前回の続きで、PKI Day 2011の各セッションを見ていきたいと思います。

セッション4： 日本におけるRSA1024-SHA-1の移行に関する政策
暗号2010年問題に関して、日本国政府の取り組みが紹介されました。政府では新たな暗号方式への移行開始時期（通称：X-DAY）と、新たな方式への移行完了日（通称：Y-DAY）についての紹介でした。

現在の政府の方針では、X-DAYは2014年度開始、Y-DAYは未定（今後、X-DAYの様子をみて検討）となっています。なんだか微妙に先送りされちゃっただけのような気もしますが、無理のないスケジュールを考えると、これくらいが丁度よいのじゃないかと思えてきました。

セッション5： 最新の欧州PKI事情
AdES (Advanced Electronic Signature) 仕様関連を中心に、EUでの仕様策定の状況についてのお話がありました。

AdES関連の仕様はEUのESIが中心となって策定されました（日本もたくさん貢献しています！）が、EC指令460を受けて、仕様の軽量化と見直しが入るそうです。公演で面白かったのは、"should"とか"may"とかの「あやふやな記述はやめようよ」という点でした。これによって、今までオプション扱いだった（？）一部の規格が、必須扱いになるようなこともありそうです。国内の長期保存関連の実装も対応が必要になるかもしれません。

あと、個人的に気になったのは、現在策定中の書留電子メール (REM: Registerd e-mail)です。ちゃんと調べてないのですが、電子メールにエビデンス情報を付記することによって、メッセージの受理とか拒否とかを電子署名的に残せるようにする規格だそうです。最近のビジネスは電子メールに依存しているので、PKIが普及するためのキラーアプリになる可能性もあるような気がします。

セッション6： パネルディスカッション「番号制度とPKI」
今回のパネルディスカッションでは、企業における番号制度に着目してのセッションでした。国民番号制度を議論しようとすると、個人情報の保護の話が出てきてしまって、話がこじれてしまうことがあります。今回はそういった話をスルーするために、企業に番号を割振る「企業コード」にフォーカスしてのディスカッションでした。

社印の代わりとして電子署名を使う場合に、社長が毎回ICカードを持ちださなきゃならないのか？等、現行の法律面との関連を踏まえての議論がありました。その他にも、政府が管理する「企業ディレクトリ」みたいなものがあったら超便利だし、個人番号の方と連携すれば更に便利になるという話もありました。

ちなみに、9/25に民主党は「共通背番号制度」法案を臨時国会に提出しないことを決めました。たしか、いわゆるマイナンバー制度は2015年に稼働開始のスケジュールだったような気がしますが、スケジュールが遅延するかもしれません。

最後に
私が最初にPKI Dayに参加したのは4年前になります。4年前と比べると、PKIの技術自体はあまり変化はありませんが、PKIを取り巻く環境は大きく変わってきています。クラウド技術は普通に利用されるようになってきましたし、スマートフォンも一気に普及しました。

こういった変化は、インターネットが既にインフラとして我々の生活に完全に定着し、十分利用に耐えるものになってきたためだと思います。しかし、インターネットは情報漏えいや成りすましなど、インフラとしては信用に欠ける部分があるのも事実であり、現段階では我々利用者はインターネットを信頼できない（もしくは信頼性の低い）インフラとして扱わなければなりません。

今後はPKIを含む暗号技術の重要性は、インターネットが社会インフラとして利用されることが多くなるにつれ、増加していくのは確実です。4年間の変化を考えると、PKIが真の社会インフラとして必須とな日は、意外と近いのかもしれません。

PKI Day 2011に行ってきた（その1）

PKI Day 2011に参加してきました。今回は恒例の東京ウィメンズプラザではなく、トスラブ山王での開催となりました。開催地が変更になったのは、U-Stream配信を行うための回線を確保するためだそうです。資料と公演の内容はこちらから見ることができます。

今年もいい話が聞けました。簡単に各セッションのコメントです。

セッション1： Microsoft U-Prove
マイクロソフトのID連携 (Identity Federation)に関する公演でした。今までのID連携では、個人情報等を公開してしまう恐れがあり、プライバシー保護の観点から問題があるとのこと。マイクロソフトでは、新しいID連携サービスを模索しており、U-Proveという技術に着目している。

U-ProveではIdPが個人情報を含むトークンと含まないトークンを生成し、クライアントは個人情報を含まないトークンをSPに提供することによって、プライバシー保護を考慮した認証が可能となる点が新しいそうです。ちょっと面白そうでしたので、あとで実験でもしてみようと思います。

セッション2：　楕円曲線暗号におけるPKI
楕円曲線暗号 (ECDSA) の各プラットフォームにおけるサポート状況が報告されました。検証対象となっているプラットフォームは、OpenSSL, Windows Vista, Java SE 7です。

ECDSAには鍵長以外にもいくつかのパラメータがあり、それぞれのプラットフォームで使用できるパラメータが異なります。PKIを導入する際には、設計段階において、アルゴリズムの選定と相互運用性の確認が必要ですが、今回の検証は当たりをつけやすくなって助かりました。

検証結果では、Vistaのサポートするパラメーターが少ないのは意外でした。Suite B対応の最小限のパラメータだけを実装した感じです。あと、個人的には、Windows 7の検証もあったらうれしかったです（7では使えるパラメーターがの組み合わせが増えていたような？気がします）。

セッション3： SSLにおける暗号危殆化サンプル調査の報告
毎年恒例のSSLサーバーの定点観測のお話でした。この調査報告は、金融系と政府系のSSLサーバーが使用している証明書のアルゴリズムとSSLの暗号設定について、3年間の追跡調査を行った結果を報告しています。ちょうど、2010年問題が話題になったこともあり、興味深いセッションでした。

SSL証明書では、RSA1024 / MD5がほとんど使われなくなったそうです。各SSL証明書屋さんは、数年前からMD5でハッシュした証明書の発行を止めていたので、想定通りの結果になっています。調査結果によると、95%以上のSSLサーバ証明書がハッシュアルゴリズムにSHA1を使っているとのことでした。

SSLサーバーの暗号設定は未だ改善されていませんね。共有鍵にRC4-MD5を受け付けるサーバーも多く、昨年からの変化もあまりありませんでした。おそらくSSLサーバーをデフォルトの状態で運用しているのではないかという指摘があり、まさにその通りな感じでした。

このセッションで感じたのは、暗号アルゴリズムに関する設定の難しさです。検証結果にもありましたが、ブラウザ側でも次世代のアルゴリズムをサポートしていますので、サーバー側では、そろそろ古いアルゴリズムは切り捨ててしまってもよいのではないかと思いました。

（次回に続く）

偽物のgoogle.comに対するMicrosoftの対応

DigiNotar社のSSL証明書偽装事件の続報が入りました。どうやら、*.*.comや*.windowsupdate.com等の証明書も発行されており、被害は相当なモノになっているようです（参照）。やばいことになってきましたね。

そんなさなかに、Microsoftがセキュリティアドバイザリーを改定しました（こちら）。今回の改定によると、MicrosoftはDigiNotar社の全認証局を信頼しないようにするためのパッチを公開したそうです（こちら）。

今回のパッチの影響をもう少し詳しく見てみましょう。Windowsでは、証明書を利用するためには、証明書を証明書ストアに登録しなければなりません。この証明書ストアには「信頼されていない認証局」というカテゴリーがあり、このカテゴリーに登録された証明書（と、その下位のCAが発行した証明書）は証明書の検証時に信頼されていない証明書として取り扱われます。

実際に証明書ストアを見てみましょう。Windowsの証明書ストアはcertmgr.mscを起動すると閲覧できます。パッチを当てる前の証明書ストアの「信頼されていない証明書」を見てみると、こんな感じです。（うっは、結構入ってるじゃんw）

パッチを適用後の「信頼されていない証明書」はこんな感じになります。ピンクで示した部分がパッチを適用することによって登録された証明書です。5つのCA証明書が「信頼されていない証明書」登録されました。

では、パッチを適用した状態で偽物のgoogle.comの証明書を検証したらどのようになるのでしょうか。実験してみました。（DigiNotar社のルート認証局証明書と中間認証局証明書を証明書ストアにインポートしています）。全般タブでは失効として扱われています。

パス検証のタブを見ると、本来CA証明書のCNが表示されるところに、「Untrusted」と表示されます。ちゃんと「信頼されていない認証局」として認識されるようです。

今回の事件の真相は未だ判明していませんが、PKI業界で仕事をしている身としては強い危機感を感じます。今後は認証局や登録局に対する攻撃が増えることも予想され、PKIという技術そのものに対する信頼が崩れてしまうことも考えられます。PKI業界は今回の教訓を生かしてより信頼できる体質になるべく努力を惜しむべきではありません。対策が後手になればなるほど傷は広がります。PKIが生まれて三十余年、今、PKI業界は信頼できるインフラとしての地位をかけた生存競争の時代に突入したのかもしれません。

偽物のgoogle.comのSSL証明書が発行された件

偽物のgoogle.comのSSL証明書が発行されたそうです。事の発端はこちらのメールだそうで、問題の証明書のダウンロード先も書かれています。

この証明書の発行元となっているのは、ノルウェーのDigiNotar社の"DigiNotar Public CA 2025"の認証局です。この認証局は"DigiNotar Root CA"の下位CAとして運営されています。どんな審査をしているのか気になったので、軽くCPSでも見てみようと思ったのですが、残念ながらノルウェー語なんでさっぱり理解できなかったです（CPSはここにあります）。

既にDigiNotar Public CA 2025は偽物のSSL証明書を失効したそうなので、念のためWindows 7のCertutil.exeで確認してみました。Certutil.exeはユーザーの中間証明機関ストアに2025の証明書をインポートしてから実行しています。以下は実行結果です。長いので途中は省略しています。

PS C:temp> Certutil -verify -user .\fake_certificate.cer

<<省略>>

------------------------------------

証明書が失効しています

Cert は End Entity 証明書です

リーフ証明書は失効されています (理由 =0)

CertUtil: -verify コマンドは正常に完了しました。

「リーフ証明書は失効されています (理由 =0)」と出ているので、たしかに失効されています。理由=0なので、失効理由の詳細は不明です。不正な証明書のシリアル番号を含むCRLを発行できていることから、何らかのミスによって登録局による審査をスルーして発行してしまったのではないかと思われます。（※多くのCA製品では、自分が発行した証明書以外のシリアル番号をCRLに記載できない実装が多いです）

さて、気になるベンダー各社の対応ですが、MozillaプロジェクトとMicrosoftの対応は素早かったです。Mozillaプロジェクトでは、こちらのページに詳細がまとめられています。アップデートで対応とのことですが、手動でトラストアンカーから不正なSSL証明書を発行してしまったルートCA証明書を削除する手順も公開しています（こちら）。

MicrosoftもSecurity Advisory (2607712)を公開しています。Microsoftは配布しているCTL (Certificate Trust List) からDigiNotar社のルート証明書を取り除いて対応したそうです。Windowsは証明書の有効性を検証する際に、Windows UpdateのサイトからCTLを自動的にダウンロードして検証するので、このような対応となっているのですね。

一見すると、トラストアンカーからルート証明書を削除するのは妥当な対処に思えますが、実はとても影響の大きい対処方法でもあります。なぜならば、ルート証明書をトラストアンカーから削除することによって、DigiNotar社が発行した全ての証明書が信頼されない事になり、既に大量に証明書を発行している場合は、それらが全て無効な証明書として取り扱われてしまうためです。いわゆる村八分のような状態です。

以前、Comodoが不正なSSL証明書を発行してしまったときは、偽物のSSL証明書を失効するという方法が取られました。今回は、偽物のSSL証明書の失効だけでは不十分と判断し、トラストアンカーからルート証明書を削除したことを考えると、CA鍵の漏洩のような重要な問題が発生しているのかもしれません。

また、今回のネタの提供者はイラン在住でイラン政府の関与を疑っているようです。なんだか物騒な話ですが、そういった背景を加味すると、今回の対応もありえるような気がします。しばらくは目を離せないネタになりそうです。

PKI Day 2011の申し込みが始まりました

PKI Day 2011の申し込みが始まりました。今年は9/26に山王健保会館での開催となります。開催の概要と申し込みはこちら。今年は去年の半分となる120名の定員です。参加を希望する人は早目に申し込んでおいたほうがいいと思います。もちろん私も参加するつもりです。

ちなみに、PKI Dayは去年からUstreamで配信を行っているようです。今は公演の一部分（15分程度）しか見れませんが、会場の雰囲気は伝わると思います。今年は定員が減ってしまったので、インターネットで公開してもらえると助かる人も多いのではないでしょうか。

Video streaming by Ustream

iOSの4.3.5で修正された脆弱性がちょっとおもしろい件（CVE-2011-0228）

AppleがiOSのセキュリティアップデートを公開しましたが、PKI的にちょっと面白げな内容でした。パブリックな信頼された認証局から発行されたSSL証明書の私有鍵を使って、別の任意のフィールドを含むSSL証明書を発行すると、その証明書が有効な（Validな）として判定されてしまうそうです。

例として、VerisignからSSL証明書を1通購入するものとします。この証明書は、iPhoneがデフォルトで信頼する認証局から発行されているため、ウェブサーバーにインストールすれば正しいSSL証明書として認識されます。

次に、このSSL証明書を発行する際に生成した私有鍵を使って詐称用の証明書に署名します。このときに、詐称用の証明書には任意のSubject DNやSubjectAltName:DNS等を指定できます。例えば、www.microsoft.comで使用するSSL証明書も発行できます。ここまでは、別に難しいことではなく、OpenSSLを使えば誰でもできてしまいますし、特に不正な行動ではありません。

問題はiPhoneで詐称用の証明書の検証する際に発生します。本来ならば、信頼された認証局（上記ではVerisign）から発行されたSSL証明書のBasicConstraintsフィールドのSubject TypeにはEnd Entityが指定されているはずなので、このSSL証明書の私有鍵で署名した証明書のパス検証を行うと、詐称用の証明書は無効な（invalidな）証明書として取り扱われなくてはなりません。

今回の問題は、詐称用の証明書のパス検証の際に、SSL証明書（上記ではVerisignから発行されたも）のBasicConstrainsフィールドの値を正しく確認しないために、詐称用のSSL証明書が有効な認証局から発行されたとして扱われてしまいます。つまり、第三者が勝手に発行したSSL証明書が有効な証明書として判定されてしまうのです。

これは結構大きな穴だと思います。7/15にiOS 4.3.4が出て、すぐに今回のアップデートが出たことを考えると、Appleもこの問題の危険性を認識しているのでしょうね。

PKI day 2011は9月に開催するんだそうな

ここ数年はPKI Dayは今頃の時期に開催することが多かったのですが、今年は9月26日（月）に開催するそうです。開催場所も変わり、トスラブ山王（山王健保会館）になるそうです。

トスラブ山王は会社の健康診断でお世話になったりしています。建物の感じからすると、会場はあまり広くはなさそうな感じなので、参加人数が制限されてしまうかもしれませんね。

オフィスで熱中症になった件

先日、会社で節電のために冷房を入れないで頑張っていたら熱中症になりました。症状としては以下のような感じでした。

• 頭が痛い。
• 強烈な睡魔に襲われた感じがして頭が働かない
• 突然意識が無くなる
  
• 顔が赤くなる

過去にも熱中症になったことは何度かあり、そのときの症状に酷似していたので、すぐに水を飲んで冷房を入れました。しばらくすると動けるようになったので、その日は代休を使って午後から帰りました。正直、意識が飛んだのにはビビりました。

何でこんなことになったのかというと、節電の為に空調の設定温度を高め（29度）にしていたことと、私の席の空気の対流が悪かったたこと、そして、熱源が多いことです。私の席は胸ぐらいの高さのパーティションに囲まれていて、PCが3台（タワーが2台、ノートが1台）と液晶モニターが3台（マルチモニター構成）稼働しています。空調の風も来ないし、発熱も十分です。

節電も重要かもしれませんが、健康を削ってまでやる必要は無いと思います。節電もほどほどにするのがよいのでしょうね。

ソニーがAESに対応したFeliCaをチップを発表

ソニーがAESに対応したFeliCaチップを発表しました。サヨナラ3DES。以下、日経BPの記事より引用です。

ソニーは2011年6月10日、暗号方式としてAESを採用し、メモリ・サイズを6Kバイトに拡張した次世代FeliCa用のICを開発したと発表した。現行品は暗号方式がトリプルDES、メモリ・サイズが4Kバイトだった。2011年冬にサンプル・チップの出荷を開始し、2012年春から量産出荷する予定。

暗号の業界で良く言われる言葉に、「弱い暗号を使うならば、暗合化しない方がよい」というものがあります。これは、暗号化したことによって、セキュリティが高くなったと思い込み、逆に秘密データの管理を疎かにしてしまうことを意味しています。

で、「そろそろヤバそうな暗号アルゴリズムを使うの止めようよ」というのが、俗にいう暗号2010年問題です（2010年は過ぎちゃったけど）。今回FeliCaが採用するAESは2010年問題の言い出しっぺのNISTが推奨する共通鍵暗号アルゴリズムに含まれています。今後はFeliCa以外の暗号アプリケーションも徐々にAESに移行して行くのでしょうね。

偽装請負と偽装委任

今回はちょっと固い話です。以前、PM関連（を含む）の仕事をしたときに労働関連の法律について勉強しました。このとき、「委任契約だろうが請負契約だろうが、客先に常駐している作業担当者が顧客から直接指示を受けてはいけない」というものがありました。当時は、単純にそういうモノだと思って深く追求はしませんでしたが、IT Proの記事に分かりやすい説明がありましたので引用して紹介します。

引用元：偽装「請負」の請負には「委任」も含まれる

最初に触れたように，「偽装請負」に「委任」は含まれないのではないか，という疑問はもっともなのですが，結論的には厚生労働省の「労働者派遣事業と請負により行われる事業との区分に関する基準」にいう「請負」には「委任（委託）」も含まれます。

業務委任契約で客先に常駐するSEについても，この区分基準に基づいて事業の独立性が求められ，独立性がなければ偽装請負（偽装委任？）であるということになります。従って，この連載の2回目，3回目で説明したことは，委任契約という形を取ったとしてもそのまま妥当します。委任契約であっても，偽装請負にならないためには独立性を確保する，あるいは実態に合わせて派遣法上の派遣として扱う等の対応が必要なのです。

つまり、民法では請負契約と委任契約は別々の概念ですが、労働者派遣法や職業安定法上の「請負」には民法の「委任」が含まれると言う事らしいです。つまり、請負契約だろうが委任契約だろうが関係ないということですね。

そこで、疑問に思ったのですが、請負（もしくは委任）作業場所に作業者が1名しかいない場合は、作業者が管理責任者を兼任することができるかどうかという事です。本来ならば、顧客 -> 管理責任者 -> 作業者と言う指示パスが存在するはずですが、作業者が管理責任者を兼任する場合は、「人」という単位に着目すると、顧客 -> 作業者という指示パスが存在する事になり、微妙にグレーゾーンになりそうです。

実際に軽くググって見ると、厚生労働省より「労働者派遣事業と請負により行われる事業との区分に. 関する基準」 37号告示)に関する疑義応答集」（PDFです）というFAQが公開されており、質問4にその答えが出ていました。以下に引用します。

Q:
請負事業主の管理責任者が作業者を兼任する場合、管理責任者が不在になる場合も発生しますが、請負業務として問題がありますか。

A:
請負事業主の管理責任者は、請負事業主に代わって、請負作業場での作業の遂行に関する指示、請負労働者の管理、発注者との注文に関する交渉等の権限 を有しているものですが、仮に作業者を兼任して、通常は作業をしていたとしても、これらの責任も果たせるのであれば、特に問題はありません。
また、管理責任者が休暇等で不在にすることがある場合には、代理の者を選任しておき、管理責任者の代わりに権限を行使できるようにしておけば、特に問題はありません。
ただし、管理責任者が作業者を兼任しているために、当該作業の都合で、事実上は請負労働者の管理等ができないのであれば、管理責任者とはいえず、偽装請負と判断されることになります。
さらに、請負作業場に、作業者が1 人しかいない場合で当該作業者が管理責任者を兼任している場合、実態的には発注者から管理責任者への注文が、発注者から請負労働者への指揮命令となることから、偽装請負と判断されることになります。

ということで、一人で客先に常駐する場合は管理責任者を兼任すると、偽装請負として扱われてしまうことになります。請負契約で客先で仕事をする場合は、最低、2名は必要になるということですね。

実際に現場で働くSE達はあまりこういった教育を受けていないような気がします。もちろん私も受けていませんでした。労働関連の法規は結構難しいですが、指揮命令に関する事はPMだけではなく末端のSEにもリテラシーとして教育しておく必要があると思いました。

プロジェクト炎上、復活、そして10連休へ...

ブログ放置しすぎてすんません。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の設計の際に何を考慮するかわからない場合には、参考になると思います。