不正アクセス事件が後を絶たない。11月19日には，ワコールの電子商取引サイト「ワコールオンライン」が不正アクセスを受け，同サイトから商品を購入した顧客の情報（5124人分）が奪われていたことが明らかになった（関連記事［1］，［2］）。奪われた情報に顧客の氏名は含まれなかったものの，2016件の決済情報（クレジットカード番号と有効期限）は漏えいしており，一部がインターネット・ゲームの決済などに不正利用されたもようだ。

　ワコールはもちろん，同社からシステムの構築と運用を委託されているNECネクサソリューションズは，顧客から指摘を受けるまで不正アクセスの被害に気づいていなかった。同社では当初，「8月に実施したシステム改修でアプリケーション・レベルの脆弱（ぜいじゃく）性を混入させてしまい，そこを狙われた可能性が高い」（ワコール広報部）としていた（関連記事）が，その後の調査で2003年にも不正アクセスの痕跡が見つかったことから，脆弱性は改修前から含まれていたと見られる。

攻撃に気づかなくて“当たり前”

　ワコールのように不正アクセスに気づかないことは，必ずしも珍しいことではない。「愉快犯や政治犯ではなく，最近では明確に金銭目的の犯人が増えている。犯行が露見するまでの時間を稼ごうと，犯人は運営者や管理者に気づかれないように攻撃を仕掛けてくるようになった」（ラック セキュアネットサービス事業本部 取締役本部長 西本逸郎氏）からだ。現に，2005年春に不正な<iframe>タグを挿入されるという被害に遭ったあるコンテンツ業者は，こう証言する。「（その後の調査で）改ざんされる半年前に数万件の個人情報を奪われていたことが判明した。情報を抜かれたことにはまるで気づいていなかった」---。

　これらの事例から見えてくることは，不正アクセス事件とは無関係と思っている企業でも，「気づいていないだけで，実際には被害に遭っている可能性がある」（西本氏）ということだ。それゆえに，Webシステムに携わるすべての担当者は，（1）被害の有無，（2）既存システムに含まれる脆弱性の有無，（3）既存システムに含まれる対策の充実度，（4）新規システム構築時の対策の充実度---について，すぐにでも点検していただきたい。ユーザーの不完全な対策を逆手に取った攻撃手法も考案されているので，「うちは対策済みだ」と過信することは禁物である。1度点検したからといって安心せずに，繰り返し実施することが肝心だ。周囲にセキュリティの専門家がいなければ，経済産業省が公開する「情報セキュリティ監査企業台帳」（リンク）を参考に支援を求めてみてもよい。

ベンダー任せにしていないか

　点検すべき項目については「日経システム構築 2005年12月号」（今すぐ購入）の特集「緊急点検！ Webアプリ・セキュリティ〜多層の防御ラインでシステムを守る」に記述したので，ここではユーザーとSIベンダーの関係に言及しておきたい。既に個人情報保護法が全面施行され，ユーザーにはシステムを管理し，SIベンダーなどの業務委託先を監督する責任が生じている。にもかかわらず，現状では一部の例外的なユーザーを除き，セキュリティ対策をSIベンダー任せにしているところが大半なのではあるまいか。

　ワコールの場合で見てみよう。同社の場合，「(業務委託先の)個人情報の取り扱いが一定水準に達しているかどうかをプライバシーマークの取得状況でチェックするとともに，日々の運用に関しては適切に実施するよう求めてきた」（広報部）そうだ。ところがシステム面でどのような対策をとっていたかについては，「よく分からないのでNECネクサソリューションズに問い合わせてほしい」（広報部）と，当事者としてきっちり説明できる状態ではなかった。2005年春にカカクコムなど複数の企業で個人情報を奪われるなどの被害が発生したときも，「（ワコールからNECネクサソリューションズに）改まって対策状況を確認したり，注意喚起したりした事実はない」（広報部）という。これで果たして，管理・監督責任を十分に果たしていると言い切れるのか。

　もちろんワコールは，NECネクサソリューションズからシステム構成などを知らされていなかったかもしれないし，NECネクサソリューションズを信頼して業務を任せていたのだろう。ベンダーを疑えばきりがないのも事実だし，業務を委託した以上，責任を持ってもらいたいという話もよく分かる。既知の脆弱性を見逃したNECネクサソリューションズの責任は自明であるが，ユーザーであるワコールも，もっと主体的にセキュリティに関与することはできたはずだし，そうすべきであるように思えてならない。

ミスを考慮に入れよう

　現実を直視すれば，SIベンダーの手は脆弱性テストまで十分に行き届いてはいない。大手メーカー系SI技術者は，「1画面当たり約20万円を目指して開発しているのに，脆弱性テストにはほぼ同額が必要になる。（この金額ではユーザーの理解を得られないので，）改めて脆弱性テストを実施することはまずない」と証言する。

　代わりに開発の現場では，脆弱性が潜みづらいように，セキュリティを考慮したフレームワークを利用したり，コーディング規約などで縛りをかけたりしている。こうしたフレームワークや規約は，開発時点で脆弱性を排除する上ではかなり有効だが，保守フェーズに移行した後まで維持することが現実には難しい。人の入れ替わりなどに伴い，規約の伝承に失敗することがあるからだ。

　ユーザーはシステムに脆弱性が混入しやすい現実を直視し，SIベンダーに過剰な責任を押しつけたり，SIベンダーを過信したりすることなく，主体的にセキュリティ・リスクをコントロールすることに努めたい。現場では例えば，次のような方法が採用されている。

• 「概要設計書の段階でセキュリティ・ベンダーの監査を受けて脆弱性を叩き出す」（物質・材料研究機構 材料基盤情報ステーション 材料データベース研究グループリーダー 山崎政義氏）
• 「異なるSIベンダーが開発したセキュリティ対策ライブラリを併用し，一方で止められなくてももう片方で止められるようにする」（ウィルソン・ラーニング ワールドワイド ウェブコミュニケーションセンター長 葛野健司氏）
• 「Webアプリケーション・ファイアウォールを導入して万一に備える」（ライオン 統合システム部 椎名淳之氏）

　今後は，RFP（提案依頼書）にセキュリティへの要望を盛り込むなど，ベンダー選定にさかのぼってセキュリティ対策を始めるアプローチも出てくるだろう。ほかにも，読者独自の取り組みや個人的なアイデアなどがあれば，ぜひ記者に教えていただきたい。