アクセス制御はきちんと考える

 手順書を考える際には,アクセス制御のことも併せて考える必要がある。このアクセス制御が,うまく実装されていないことがあまりにも多い。不備あり,抜けあり,バグありで,結果としてそのギャップにつけこんで漏洩やら暴露やら破壊が起こってしまうのだ。

 アクセス制御とは,簡単に言えば人と権限のひも付けである。部長以上は編集可,課長以上は閲覧可,平社員は見てもいけない,というルールを定め,そのルールに従って物理的にも電子的にもアクセスさせることだ。これが想像以上にうまくいかないことが多い。

 うまくいかない原因は,例えばアクセス権限の設定のメンテナンスが現実に追いつかない(運用体制のパワーが現実の作業量に追いつかない)とか,権限を持つ人のリテラシが低い(部下に見せてしまう),とかいったものだろう。ほかにも,アクセス制御の仕組みそのものの脆弱性(弱いパスワードも含む)などもあるだろう。

 こういうリスクに対しては,パスワードの代わりにUSBキーや指紋認証を採用するなどの対策がある。あるいは,退職処理休職処理を徹底するシステムとしてディレクトリ管理を導入する,などの手もある。しかし,管理に携わる人間や,アクセス権限を持つ人間自身の不注意や意図的な漏洩に対しては,そういう策も効力を持たない。

 であればいっそのこと,アクセシビリティを与えて管理するのではなく,最初からそういう書類やファイルが存在することを見せない,というリスク低減方針が必要だろう。ファイル・サーバーに置いたとしても,そもそも権限のない人間にはファイルの存在すら知られないようにしてしまうのだ。人間は目の前にあるからこそ,よこしまな気を起こしてしまう。目に入らなければ,そもそもそういう想像すらしないだろう。

 止むを得ずファイルの存在を見せなければならない場合であっても,文書ファイルそのものにパスワードやIDを埋め込んで管理し,どこから漏れたのかをファイルベースで追跡するという手も考えられる。

 要するに,「ファイルを手に入れたとしても,しっかり追跡されていますよ」あるいは「記録されていますよ」という無言の圧力を加ることで,心理的なハードルを高くするという考え方だ。

 ほかに,空き巣対策のように「手間や手数をかけさせてあきらめさせる」という手もある。空き巣は5分奮闘してダメならあきらめる,と言われている。アクセス制御の手順を何重かにしておき,簡単なパスワードを一つ破ればアクセスできるのではなく,サーバー・アクセスにもディレクトリ・アクセスにも,ファイル・アクセスにもそれぞれ別のパスワードが必要という手間にしておくのだ。

 となると,半面で管理が煩雑になるうえ,ユーザーの使い勝手も悪くなる。そこから別のリスクを生まないようにするために,例えばパスワードは半分手帳に書いておき,残りの半分はワンタイム・パスワードにするなどの工夫が必要となるだろう(それでもパスワード管理には限界があり,あらかじめリスクを減らす,という考え方からすると,システム上の面倒や作業は承知のうえでUSBキーや指紋認証,静脈認証を導入するほうが安全かもしれない)。

 今回話題にしているような情報は厳重に管理しなければならないが,厳重ということは煩雑でもあるのだ。リテラシー教育するとしたら逆にその点を強調し,下手に技術的知識などを覚えてもらわない方が互いのためではないだろうか。

手順書は手を抜かずに作成

 いささか脱線してしまったが,ここで手順書の話になる。

 必要な手順書は「管理手順書」と「ユーザーの利用手順書」である。管理手順書に入れるべき要件は,リスク分析のところで言及した国際標準から引っ張ってきてもよいだろう。バックアップを毎日取っているか(バックアップされている内容はきちんと確かめているか),アクセス制御のメンテナンスをメンバー変更の都度,1日以内に行っているか,パスワード変更履歴を3カ月に1回はチェックしているか(変更されていない場合は自ら出向いて変えさせているか),ウイルス・チェックは毎日かけているか,などの要件がISO/IEC17799に載っている。これをそのまま管理策に盛り込んで,導入したアクセス制御の仕組みがきちんと機能しているかどうかの監査について述べれば(これもISO/IEC17799に載っている),それで管理手順書はでき上がりだ。

 利用手順書の方は少し手間がかかる。相手はコンピュータについて何も知らない,ということを前提としなければならないからだ。一つひとつのオペレーションについて丁寧に書き,画面などのキャプチャも多用し,かつエラーが起こったときの対処を明示しておく必要があるだろう。このあたりはマニュアル作成のプロに頼んでもよいだろう。  管理手順書もそうだが,手順書に関しては手抜きをしない方がよい。手順書の手抜きは,すなわち管理者やユーザーにその都度判断させるなどの余計なリスクを背負い込むことになるからだ。手順書は,読めばそのまま実践できるような構成・内容にしておくのが理想だ。

園田 道夫 Michio Sonoda

筆者は情報処理推進機構(IPA)の脆弱性分析ラボ研究員,および日本ネットワークセキュリティ協会(JNSA)の研究員を務める。JNSAではハニーポットワーキンググループ,セキュリティスタジアム企画運営ワーキンググループのリーダーとして活動している。MicrosoftのSecurity MVP。現在セキュリティ夜話(http://www.asahi-net.or.jp/~vp5m-snd/sec/),極楽せきゅあ日記(http://d.hatena.ne.jp/sonodam/)にて連続的に読み物掲載中。