V.S.A. III

2006年12月アーカイブ

みなさま良いお年を

こんにちは，五十嵐です．弊社は今日が仕事納め．私の Tyzoh ブログも今年(平成18年/2006年)はこれで最後です．みなさんは年末年始はどのようにお過ごしの予定ですか．．．と書いて簡単にお茶を濁してしまおうかとも思ったのですが，やっぱり私は情報セキュリティの人なので．．．

冬期の長期休暇を控えて (2006/12/22 JPCERT/CC)
年末年始における注意喚起 [メール編] (2006/12/20 IPA)
年末年始における注意喚起[Web編] (2006/12/20 IPA)
年末年始における注意喚起[システム管理者向け] (2006/12/20 IPA)
年末年始の情報セキュリティ対策のお願い(12/27) (2006/12/27 @Police)

個人向けに書かれているのは IPA の「メール編」くらいでしょうか．それ以外は休暇前後の企業の中での注意事項のようになっています．JPCERT/CC はそういうお仕事ですのでわかりますけれど，警察庁の @Police はもっと消費者向けにメッセージを出して欲しいところですね．

年末年始，情報セキュリティに限らず，みなさまが安全･安心に過ごせるようにお祈りいたします．
良い年をお迎えください．

いかちょー (2006-12-28 15:09) | コメント(0)| トラックバック(8)

こんにちは，五十嵐です．「SNS (Social Networking Service)」という個人同士のつながりを基本にしたサービスが流行っていますね．mixi （ミクシィ）が最も有名な SNS になっているようですが，ご他聞に漏れず，私も mixi で遊んだり，仕事のヒントにしたりしています．GREE にも登録していますが，こちらはさっぱり使っていません．一時期，仕事で SNS の現状を調べるために，他にもいろいろと登録しましたが，結局，私的に使うのは mixi だけになってしまいました．

その SNS を社内で使用すると情報共有が図れて，生産効率が上がるという話を時々聞きますが，本当なのでしょうか．どこそこの会社で社内 SNS を導入したという話は聞くのですが，その後の効果についてはあまり話を聞きません．

裏づけデータもなく，単に私の推測なのですが，社内 SNS というのはそれほど効果を上げないのではないでしょうか．「柔らかいコミュニティ」という考え方であれば，今でもメーリングリストなどで可能です．ほとんど廃れてしまったネットニュースなどでも，似たような文化はありました．しかし，そうしたところでの発言者と読み手の関係は，社内 SNS になっても変わらないのではないかと思うのです．(以前書いた「なんで閲覧数増えないかなぁ．．．(ちょっと愚痴)」を読んでみてください)

ほとんどの場合，発言者は常連と呼べるような人々が活発に行い，それを大多数の読み手(ROM: Read Only Member というのは死語でしょうか(笑い))が眺めているという構図．これは SNS になっても変わらないのではないかと思うのです．

私はこうして業務時間中にこのブログを書くことを許してもらっていますが，まず，そういう時間をとることを許してもらえる雰囲気があるかどうか．「この忙しいのにブログ(SNS)なんか書いてる暇があったら，他の仕事を進めろ」というような雰囲気，文化が根強いのではないでしょうか．他の会社を一緒にしてしまっては申し訳ないですが，少なくともうちの会社はそうなのではないかと思います．

外部で受けてきたセミナーやイベントの内容を個人レベルの視点で書いたものを全社員に見てもらおう，という気持ちがある人がどれだけいるか．入力が面倒なので読むだけ，という人ばかりでは SNS は廃れていきます．SNS である必要すらなく，ブログで発信してお互いにトラックバックしたりコメントつけたりしていれば済む話です．

まして，社内 SNS となれば，同じ部署の人たちとのつながりや，そうでない人たちとのネットワークが機能上分離できていなければならない場面も出てくるはずです．前者の方はコミュニティという手段で表現するのかもしれませんが．．．

既に社内 SNS を導入している会社の，効果のほどはどんな感じなのでしょうか．社内 SNS を売り込む側の声は聞こえてきますが，導入後の結果の声が聞こえてこないのは，やはりあまり効果がでていないのか．．．気になります．

社内 SNS を導入するかどうかを相談されたら，私としては「止めといたら．どうしてもやりたいなら，ブログから始めた方がいいよ」と助言すると思います．皆さんはどう思います？

いかちょー (2006-12-27 11:16) | コメント(0)| トラックバック(23)

Windows Vista に早速．．．

こんにちは，五十嵐です．日経新聞に「OS 『ビスタ』安全面に欠陥」という記事が載っていました．

一般販売前だというのに，早くもセキュリティ面の指摘があったというのはすごいと思います．詳細はマイクロソフト社が調査中ということですが，Bugtraq などでは少し前に情報が流れていました．ロシアのサイトはロシア語で書かれているので，何が書いてあるのかさっぱりわかりません．

「すごい」というのは，一般消費者の手に届く前に脆弱性を見つけてくれる人たちがいるということです．マスコミとしては「安全面を売りに出したビスタに早くも傷がついた」と報道したいのだと思いますが，私はむしろ，発売前に脆弱性が明らかになってよかったのではないかと思っています．

一月末の発売に向けて，生産ラインに乗ってしまっていれば，今から止めるのは難しいかもしれません．発売と同時にセキュリティパッチが公開されるということも考えられますね．PS3 では脆弱性ではありませんでしたが，発売日に機能の一部が間に合わず，インターネットからダウンロードというようなこともあったようです．ビスタも「脆弱性」という機微な面はありますが，同様のやり方もあるかと思います．

同じ日経新聞の一面に「ソフトウェアに独禁法規制」という記事も載っていますので，マイクロソフト社も苦難の道になりそうですが，がんばって欲しいものです．

ついでですが，CM で，Apple Mac と「ワーク」の比較宣伝をやっていますね．Mac ってシェアの問題で独禁法にひっかからないだけで，シェアが伸びたら自分の首を絞めることになる CM なのではないかと笑ってしまいました．

メディアの表現は非常に主観的で面白いです．新聞は公平さを出すべきなのに，明らかに何らかの意図が感じられます．テレビのニュースなども．

例えば，今朝の番組では，高速道路のサービスエリアで，一般道からも利用可能な場所の話があり，そこに車を止めて相乗りしていく話が取り上げられていました．SA の提供側としてはサービス妨害になるかもしれないので，駐車場が意図していない使われ方をしているのは確かです．しかし，米国のカープールなどの利用と同じと考えると，排気ガスも少なくなっているし，環境的には良い話ではないの？などと思いました．日本も高速道路の入り口の脇などに正式にでっかいカープールをつくるべきなのでは．．．

だいぶ話がそれてしまいましたが，ビスタも早速脆弱性か？！という情報に踊らされるよりも，発売前に見つかってよかったね，と思ったほうが良いのではないでしょうか．

いずれにしても，安全な OS が提供されるのは良いことです．かなり期待しております．

私が昔 UNIX OS 保守部隊にいたり，Linux 関連の仕事をしていたので Windows 嫌いだと思っている方がいるようですが，私は Windows が嫌いではありません．ここまで世の中に PC が広まったのは Windows のおかげだと思っています．その辺，勘違いしないでくださいね．

いかちょー (2006-12-26 23:22) | コメント(0)| トラックバック(1)

AED(自動体外式除細動器)と空間ドキュメント管理システム

こんにちは，五十嵐です．"AED" をご存知ですか？「自動体外式除細動器」といって，不整脈などの死亡から人命を救助するための装置だそうです．何かの TV ドラマで使用されてから有名になってきているようです．

ふと気がついたら，うちの会社のエレベータホールに AED が設置されていました．すべてのフロアに設置されているわけではないようです．乗り換えの多い階に設置されていました．エレベータが低層階，中層階，高層階に分かれているので，1階とそれぞれの乗り換え階に設置されているようです．最上階にも設置されているのかも．．．他のフロアは未確認．

使い方は日本赤十字の「AED（自動体外式除細動器）の取扱い」のページに書かれています．しかし，素人がいざというときに使えるかというと，使っていいのかどうかの判断もなかなか難しいですね．素人判断で使って，かえって殺してしまったりしないかとか，不安になります．やはり専門家が使うもの，ということでしょうか．．．

AED をどこに設置するかという問題の一つに取り組んでいる例として，先日，東京大学空間情報科学研究センターの片岡先生から「地域健康危機管理における空間情報管理」という話を聞きました．主テーマは AED ではなかったのですが，「空間ドキュメント管理システム」という文書から位置情報を抽出して空間にマッピングするという面白い研究でした．この中で空間ドキュメントの地域分析の応用例として，AED の最適配置の例がとりあげられていました．

青森県弘前市の心停止発生地点を使用して，供給効果を最大化する AED の最適配置地点を割り出し，そのときの救命確率などの分布も計算されていました．

エレベータの乗り換え階に配置するのは，感覚的にはわかるのですが，本当に最適配置なのか？という答えは良くわかりませんね．むしろ各層のエレベータの真中の階に置くのがいいのではないかとも思います．うちの会社のビル内でそんなに頻繁に心停止事故が発生しているという話も聞きませんし．．．

それにしてもこの空間ドキュメント管理システム，tPod と連携すると面白うそうなんですが．

参考文献：[PDF] 「空間ドキュメント管理システムの設計と開発に関する研究」，東京大学空間情報科学研究センター，東京大学生産技術研究所

いかちょー (2006-12-25 14:28) | コメント(0)| トラックバック(107)

TGIF: プラットフォーム

こんにちは，五十嵐です．長年 SF 者をやってると，作家さんの知り合いも増えてくるし，仲間内からプロの作家や書評家，翻訳家などになる人も出てきます．そうした人たちは昔からの印刷システムとの関連で，Apple の Mac を使っている人が多いようです．時々この Mac の相談などを受けるのですが，私は Mac のことはさっぱりわかりません．Mandatory Access Control (強制アクセス制御) の MAC ならちょっとはわかりますけど．．．

mkamiya さんが「プラットフォームという言葉」というブログを書いていますが，Mac (Apple の方ね) という表現が「プラットフォーム」という言葉のイメージに一番近いのではないかと思っています．Windows といえば OS だし，DOS/V マシンといえばハードウェア．その点，Mac には OS X という OS があるにもかかわらず，全部まとめて "Mac" と呼んでいます．これが「プラットフォーム」なのではないかと思うのです．

IT の世界以外で「プラットフォーム」と言われて真っ先に思いつくのは駅のプラットフォームです．電車に人が乗り降りするあのプラットフォーム．銀河鉄道 999 で主人公鉄郎が泣きながらメーテルの乗る 999 を見送るあのプラットフォーム．

線路という基盤があって，電車というサービスがあり，そこを利用するためのプラットフォーム．線路が無ければ電車は来ないし，そういうところをプラットフォームとは呼ばないですよね．

では「『社会』プラットフォーム」という言葉で表現されるプラットフォームとは何か．線路に相当する基盤があって，社会に対するサービスが提供されているときに，そのサービスを利用するためのモノ全体が「社会プラットフォーム」なのだと思います．

月に一度の飲み会があるのですが，そうした中から生まれてきた作家や翻訳家さんたちにとっては，その飲み会がプラットフォームだったんだろうなと思ったりします．

今日はなんだか，情報セキュリティとは関係ない話になってしまいました．

"TGIF" とは，"Thank God, It's Friday!" の略．「花の金曜日」略して「花金」(笑) 毎週金曜恒例のお遊び/オタクモードです．

いかちょー (2006-12-22 09:00) | コメント(0)| トラックバック(40)

ファイルの削除 - tPod Security Policy Model #10

こんにちは，五十嵐です．「新感覚ファイルサーバ tPod」のセキュリティポリシーモデルの第十回．今回は「ファイルの削除」について書きます．

ファイルのライフサイクルにおいて不要になったファイルをどのように扱うかを検討しなければなりません．tPod に放り込んでおいたファイルをそのまま放置しておくのもひとつの方法ですし，明示的な削除を行うのもひとつの方法です．

tPod において難しいのは，複数のユーザがファイルを参照するため，ファイルの削除のタイミングがわからないということです．ファイルのオーナーが情報のオーナーだと考えれば，ファイルの存在を抹消する判断を行うのは，ファイルのオーナーです．しかし，それが他の人にとって有益な情報であった場合，削除することが他の人の不利益を及ぼす可能性も考慮しなければなりません．

逆に，不要な情報がいつまでも残っていることは，情報資産の管理という視点では，いつまでもリスクを抱えることにもなりかねません．したがって，リスクを軽減するために，管理するファイルを削除することが必要になります．

ファイルが知らないうちに消されてしまうかもしれないという危険性におびえながら tPod を使用するよりも，ファイルをコピーして自分で所有するという考えを思いつくかもしれません．これは情報の共有という点から考えると好ましくありません．オーナーの違う同じファイルのコピーがいくつも登録されているという状況になってしまいます．

この点についても残念ながら，良い解決方法は見つかっていません．登録されたファイルは永続的に存在すると考えるのが現時点では最も良い方法に思われます．ただし，上に書いたように不要な情報もいつまでも残るというリスクを受容するということになります．

情報を共有し，すべてのファイルがそこにあるということは tPod の最大の利点ですが，こうしたファイルの削除に関するリスクの問題を抱えていることも十分に念頭に入れて利用しなければなりませんし，今後の tPod の開発における検討課題になると思います．「ファイルの削除」という単純な問題のように見えることでも，複雑で様々な要因が隠れているのです．

今回は「ファイルの削除」について書きました．tPod のセキュリティポリシーモデルの説明は今回で終了です．思いつくままに並べてきましたが，今まで書いてきたことをまとめて，系統立てて脅威分析と評価，対策を考えていく必要があります．少し時間をいただいて，何らかの形で公開していきたいと思っています．

"tPod Security Policy Model #10" 了

いかちょー (2006-12-21 23:37) | コメント(0)| トラックバック(11)

ユーザ認証との分離 - tPod Security Policy Model #9

こんにちは，五十嵐です．「新感覚ファイルサーバ tPod」のセキュリティポリシーモデルの第九回．今回は「ユーザ認証との分離」について書きます．

tPod にとって，アクセス管理の必要上，ユーザ認証は不可欠なので，機能そのものを分離するわけにはいきません．ユーザ認証はしらないよ，というわけにもいかないので，現在は簡単な認証で行っています．

分離というのは，機能とポリシーの分離を指しています．例えば，企業内のたくさんあるシステムのログインを管理しようということで，Single Sign On(SSO) が注目されていますが，このようなものを用いた場合にも簡単に対応できるのが理想です．そのためには，ユーザ認証の部分を簡単に差し替えることが出来るようにする必要があります．「ユーザ認証の分離」とはこのことを指しています．

企業内のユーザ認証を一元的に管理するために SSO を使用するメリットは，ユーザがシステムごとにパスワードを変える必要が無く，そのために覚えておくパスワードが単一で済むということです．覚えておくパスワードが少ないということは，長いパスワード，いわゆるパスフレーズを利用できるというメリットがあります．単語などではなく，文章や長めのフレーズをパスワードとして利用することで，これが破られる可能性が少なくなりますし，ひとつだけ覚えておけばよいので，付箋紙に書いておいてモニターに貼り付けておくというような弊害も防げます．

一方で，ひとつのパスフレーズを知られてしまうと，すべてのシステムが利用可能になってしまうという欠点があります．この点は，執務室への入退室管理などの物理的セキュリティや，ネットワークへ接続できる機器の制限などの他の方面でのセキュリティを強化して，システムへの不正な侵入を防ぐ必要があります．このような面を考慮すれば，SSO は非常に便利なインターフェースとなるでしょう．

このようなことから，tPod でもユーザ認証を独立した仕組みとして考える必要があります．普通にログインして使用する場合以外に，第五回「直接リンクのファイル参照」で書いたようにファイルに外部から直接リンクするような参照方法に対してユーザ認証を行う必要があります．

そのためには，ユーザが認証されているかどうか，もう少し具体的にはユーザが使用しているブラウザが認証されているかどうかを確認し，必要があれば認証することになります．tPod でもこの点は考慮していますが，内部の構造としてはもう少し練る必要があるかなと思っています．

横道にそれつつ書きましたが，ユーザ認証の仕組みをファイル参照の認可の部分と独立させて分離することは，今後の拡張性のために重要な要素となります．セキュリティを低下させずに認証するよりよい方法を，今後も模索していく予定です．

今回は「ユーザ認証との分離」について書きました．次回は「ファイルの削除」の予定です．

"tPod Security Policy Model #9" 了

いかちょー (2006-12-20 22:47) | コメント(0)| トラックバック(7)

CCC - サイバークリーンセンター

こんにちは，五十嵐です．tPod のセキュリティポリシーモデルは都合によりお休み．本日は，"CCC" のお話．発表されたのが 12 月 12 日ですから，一週間前になります．

Cyber Clean Center サイバークリーンセンター

Telecom-ISAC Japan のページには特に何も公表されていませんが，Telecom-ISAC Japan を主導として，ISP 8 社が協力体制で運用するようです．IPA(独立行政法人情報処理推進機構)も関与しているはずですが，こちらも特に情報はありません．JPCERT/CC (有限責任中間法人 JPCERT コーディネーションセンター)は解析グループとしてボットの解析と情報提供，駆除ツールなどの提供を行っていくようです．

ボット対策の国家レベルは初の試みということで，総務省と経済産業省が連携して実施する事業になります．ただ，ここに NISC (内閣官房情報セキュリティセンター)の名前が無いと言うのは，どうなんだろうと私は思っています．本当に国家レベルで取り組むのであれば，NISC が全体統括で実働として総務省と経産省という組み合わせであるべきなのではないかと思うのですが．．．理想論と政治的な現実との乖離ということなんでしょうね．

"CCC" というゴロ合わせ的なところから名前がついているような気がします．「おっ，それいいじゃん」という感じで決まったのかもしれませんけれど，私のイメージだと，"Cyber Clean Center" ＝「サイバー空間のゴミ処理場」と思ってしまいます．それはある意味そうなのかもしれませんけど．．．実際には，ゴミ処理場というよりも「シュレッダーあります」的な情報発信だと思うので，ちょっと名前から想像するモノと違いますね．

今後のスケジュールでは，ボット対策の駆除ツールなども出し，なかなか難しいところにトライしていくようです．成果が出て，安心できるサイバースペースになっていくといいですね．

いかちょー (2006-12-19 16:59) | コメント(0)| トラックバック(4)

DoS 攻撃 - tPod Security Policy Model #8

こんにちは，五十嵐です．「新感覚ファイルサーバ tPod」のセキュリティポリシーモデルの第八回．今回は「DoS 攻撃」です．セキュリティポリシーモデルの話をしようとしているところに，突然「攻撃」の話とは，ちょっとずれている気もしますが，重要な点ですので触れておきます．

"DoS" とは "Denial of Service" の略で，サービス妨害を指します．ネットワークに負荷をかけたり，サーバーに負荷がかかるようなことをしてサービスを提供できなくなるようなものを DoS 攻撃と呼んでいます．tPod では加えて，ファイルの登録によって DoS 攻撃を加えることが出来ます．情報セキュリティの三要素で言えば「可用性」が損なわれます．

tPod では，ファイルの登録に際して，上書きを行いません．また，同一のファイル名での登録を許します．見かけ上のファイル名が同じでも，生成される URI が異なるので，別なファイルとして登録されるのです．しかし逆に言えば，同じファイル名でいくつものファイルが登録されると，どれがどれだかわからなくなるということになります．tPod ではそのようなことを避けるために，「ラベル」をつけてそれぞれを識別できるようにしていますが，必ずしもこれが有効なラベルかどうかはわかりません．また，ラベルをつけないことも可能です．

そうなると，どのファイルが自分の求めるファイルなのかがわからなくなってしまうことがあります．例えば，単に「12月度月報」と名づけられたファイルを，様々な部署がいっせいに登録してしまったとします．この場合，もちろん，オーナーやグループは分かれるかもしれませんが，仮に全体へ公開するような設定になっていた場合，ファイル名だけではどれがどれだかわからなくなってしまうという現象が発生します．

攻撃を意図したわけではありませんが，これはファイルの可用性を失うことになり，ユーザにとって不便を強いる事になってしまいます．また，意図的に同一ファイル名のファイルを大量に登録することは，明らかにサービス妨害です．同様に，関連性の無いファイルに無作為にラベルをつけると，ラベルの検索で，全く無意味なファイルが一覧されてしまいます．

このような状況に対して，tPod ではまだ有効な対策がありません．ユーザ認証の仕組みをしっかりと取り入れ，それぞれのオペレーションをすべて記録することで，事後の対策を行っていくということが重要になります．

本来は，脅威分析，リスク分析を行ったうえで，このような部分を考えていかなければなりませんが，tPod の利用面での重要なポイントになりますので，特にファイル登録における DoS 攻撃を取り上げました．

今回は「DoS 攻撃」について書きました．次回は「ユーザ認証との分離」について書きます．

"tPod Security Policy Model #8" 了

いかちょー (2006-12-18 21:12) | コメント(0)| トラックバック(6)

なんで閲覧数増えないかなぁ．．．(ちょっと愚痴)

こんにちは，五十嵐です．どのカテゴリに入れていいのかわからなかったので，とりあえず「アングラ」カテゴリに．ちょっとぶちぶちと愚痴．

一日外出だったので，朝一でブログ (「TGIF: ドクターレクター (「雪風帰還せず＜後編＞」)」) を投稿して家に帰ってから自分の記事の「閲覧数」を見たら約 90．

なんでこんなに少ないかなぁ．．．とがっくり．組織を背負って書いているわけじゃないから，個人ベースだとしても，それでも少ない．会社の人たちも見てくれてるなら，グループ従業員のせめて一割くらいの人が見てくれてもいいのになぁと思うわけです．Tyzoh 活動に参加している(と表明して下さっている)企業の方々も見てくれてないんだろうなぁ．

まぁ，内容に魅力がないんだと言われればそれまでだけれど，それでももうちょっと眺めてくれる人が増えないことには，モチベーションが下がってしょうがない．じゃぁ，もっと魅力的な内容を書けよ，と言われても，コメントもフィードバックもないんじゃ，何をどうすればいいのかもわからず．

せめて，RSS リーダに登録して形だけでも覗くくらいしてくれないものかな．

そう思って気がついたんだけど，RSS リーダに登録して，業務時間中にブログから情報収集している社員ってどのくらいいるんだろう．ブログを読んでると，一昔前の電子メールのように 「何でブログなんか読んで遊んでるんだ！」 とか上司に叱られるのだろうか． UUCP で電子メールをやり取りしていた頃は 「何でメールなんかで遊んでるんだ！」 だったもんなぁ．

「ブログなんか読んでる暇ない」

↓

「ブログも読まずに何やってんだ！」

という時代はまだまだ先ということか．．．

別にブログの王様になろうとは思わないけれど，閲覧数 500 / 日くらい欲しい．このブログの知名度をもっと上げるためには，キャンペーンでもやらんとだめってことでしょうか．もちろん，コンテンツも改善するとして．．．

業務中がだめでも，

昼休みの 5 分くらい Tyzoh ブログを覗いてくださいよ，みなさん！

特に OA 用 PC でソリティアなんかをしているそこのアナタ！！
(もちろん，帰宅後に自宅からでもオッケーです)
そして，「アイツがこんなこと書いてるぞ」って周りに宣伝してください！

でも，ロボットがアクセスしに来て，一気に 500 アクセスとか増えてもうれしくないぞ．

(コメントを書くにはユーザ登録が必要です．)
私の最新ブログは 「こちら」からどうぞ ．
Tyzoh ブログ全体の最新は「こちら」からどうぞ．

いかちょー (2006-12-16 02:09) | コメント(0)| トラックバック(3)

TGIF: ドクターレクター (「雪風帰還せず＜後編＞」)

こんにちは，鼻水ぢゅるぢゅるの五十嵐です．インフルエンザの予防注射を打ってからしばらくして風邪をひき，なんだかそのままインフルエンザが活性化したんでは？！という有様です．熱も40度近くまで．．．とりあえず熱は下がったものの，鼻水は出っ放しです．予防接種代金，返してくれ！

SF マガジン 2007 年 1 月号に神林長平さんの 戦闘妖精・雪風第三部「雪風帰還せず＜後編＞」 が掲載されました．「TGIF: ウィルスキラー帰還せず」(2006/10/20)で取り上げた前編の続きです．
引用：

「雪風帰還せず」の後編は SF マガジン 2007 年 1 月号の予定だそうです．どうやら，ハニーポットの話になりそう．期待大です．

という予想は当たったともいえるし，外れたともいえるし．．．まだ読んでいない方のためにもネタばれは書きませんけれど．

今回の＜後編＞には「ドクターレクター」というニックネームを持つコンピュータが出てきます．今で言う thin client です．いや，たぶん，そう．「戦隊区の外にでれば，たぶんフリーズするのだろう」という記述からもそう読めます．小説内では 「仮想コンピュータ」 と呼んでいますが，セキュア VM 環境上に構築されたパーソナルコンピュータ．内閣官房情報セキュリティセンター(NISC)が，もうすぐ現実に作り上げてくれますよ，きっと．

小説内では，セキュリティ上，私物の物理的にスタンドアロンのパーソナルコンピュータは許可されないという状況から一変．敵の侵入から隔離するためにスタンドアロンのコンピュータを使うようになるという話．ストーリーの大筋にはあまり影響のない部分だけど，この細かい設定がとてもいいです．

少し古い SF では 「マザーコンピュータ」 が良く出てきます．集中管理系スーパーコンピュータ．当時は汎用機ホストの延長上でメインフレームが肥大化するというイメージだったのでしょうけれど，今日のように一旦は分散化したシステムが，やはり情報セキュリティの意味合いで集中化傾向に戻ってくるとは予想しなかったでしょうね．

Thin Client が一昔前の X 端末とどこが違うのか．．．端末がサーバーであるとか，ややこしいのが X 端末で，サーバーはサーバーだというのが Thin Client なんでしょうか．誰か教えて＞＞えらい人

でも神林さん，OS がエミュレートされてても， 「仮想コンピュータ」 とは言わないんでは？いや待て，近未来だと，一回りしてそう呼ぶようになるのか？

じゃあ，「仮想コンピュータ」じゃなくてなんて呼ぶんだ，って言われると．．．
そのまんま「エミュレーテッド･コンピュータ」かなぁ．．．
OS なら「ゲスト OS」という呼び方があるけど．．．
なんか，「仮想コンピュータ」でいいような気もしてきた．．．

"TGIF" とは，"Thank God, It's Friday!" の略．「花の金曜日」略して「花金」(笑) 毎週金曜恒例のお遊び/オタクモードです．

いかちょー (2006-12-15 09:00) | コメント(0)| トラックバック(61)

マルチレベルセキュリティ - tPod Security Policy Model #7

こんにちは，五十嵐です．「新感覚ファイルサーバ tPod」のセキュリティポリシーモデルの第七回．今回は「マルチレベルセキュリティ」です．

第一回の時に，「tPod はマルチレベルセキュリティではない」と書きました．つまり，ユーザのクリアランスレベルやファイルの機密レベルなどの「レベル」を持っていません．一般に使用するにはこれで構わないのですが，企業などで使用する場合には，必要となるかもしれませんので検討が必要です．

今まで，情報セキュリティの三要素である可用性，完全性，機密性という観点からは特に説明を行いませんでした．可用性は必要な時にファイルに正しくアクセスできることです．可用性については次回触れる予定です．また，追記や上書きがないことから，tPod やそのバックエンドとなるデータベースが壊れない限り，常に完全性が保たれています．問題は機密性という点です．ここで取り上げる機密性は，ファイルが暗号化されているといったレベルではなく，「極秘」や「社外秘」といったファイルの取り扱いの話になります．

第一回，第二回で説明したように，ユーザがファイルにアクセスできるかどうかは，オーナーとグループ，それ以外の人の参照権がファイルにどのように設定されているかによります．

ここで，派遣会社の人がグループ A にいるときに，人事部が発行するファイルで，従業員には見せたいが，派遣会社の人には見せたくないファイルがあったとします．この場合，tPod ではどのようになるでしょうか．

ファイルのオーナーはすなわち情報のオーナーであるべきですので，この場合は人事部長になるのが正しい姿です．すべての人には見せてはいけないので，「その他」の参照権はありません．{user, group, other} で示すと，{r, ?, -} となります．"?"と書いたグループの部分で制御しなければなりません．つまり，設定は {r, r, -} となり，グループは「従業員」というグループで管理することになります．すべての従業員ユーザは「従業員」というグループに入ることを意味します．

それでは，同じ従業員でも部長などだけに見せたい場合にはどうでしょう．この場合も同様に，ファイルのグループを「部長」というグループにし，{r, r, -} という参照権を設定すればよいことがわかります．

軍隊などでは厳密に情報の流れや機密性，完全性を制御したいため，ファイルが下位のレベルに間違って流れたり，下位の不完全な情報が上位に流れたりしないような仕組みが必要でした．例えばある種のマルチレベルのセキュリティポリシーモデル (注) では，報告というものを重視して，下から上に対して追記のみ可能で上から下へは書き込みが出来ないというものがあります．部長の例では，部員が部長のレベルと同じレベルのファイルには追記が出来，部長以上の人が読むことはできるが，部長は下位のレベルに書き込みが出来ないというものです．

しかし，現実の民業の世界では，そこまで厳密な機密性や完全性を求める必要はありません．グループの管理が複雑になったり，様々な「グループ」が乱立したりする可能性はありますが，オーナーとグループの考え方で，十分にセキュリティ用途が果たせるため，マルチレベルのセキュリティは必要ありません．

ただし気をつけなければならないのは，権限のある人がファイルを取得し，権限のない人に対して間違って公開してしまう可能性があるということです．これを防ぐひとつの方法は，例えば衝突回避性の高いハッシュ関数など(MD5 など)を使って，同一ファイルを登録できないようにすることです．悪意ある人がファイルを少しだけ改変して登録しなおすことを防ぐことはできませんが，間違ったオペレーションを防止することは出来るはずです．(最初に登録した人のもの，ということになりますが，これも運用ルールでカバーすべき問題だと思います)

今回は「マルチレベルセキュリティ」について書きました．次回は「DoS 攻撃」について書きます．(次回は 12 月 18 日の予定です．金曜日は TGIF ですので(笑))

[注] 「 Bell-LaPadula モデル」のことです．

"tPod Security Policy Model #7" 了

いかちょー (2006-12-14 09:00) | コメント(0)| トラックバック(74)

OS にアクセス管理を任せる弊害 - tPod Security Policy Model #6

こんにちは，五十嵐です．「新感覚ファイルサーバ tPod」のセキュリティポリシーモデルの第六回．今回は「OS にアクセス管理を任せる弊害」です．

単に「アクセス管理」という場合，二種類のアクセス管理を一言でまとめてあらわしています．ひとつは tPod そのものにアクセスするためのユーザ認証 (Authentication)，もうひとつは tPod に格納されたファイルにアクセスするためのユーザ認可 (Authorization) です．

アクセス管理を OS に任せてはどうかという声も聞こえますが，二種類のアクセス管理をどちらも任せてしまうのは無謀です．というよりも，ファイルの格納をデータベースで行っている以上，二つ目のアクセス管理「ユーザ認可」については OS では手が出せません．このことを踏まえて OS に任せるというのであれば，それは一つ目のアクセス管理「ユーザ認証」について言っていることになります．

ユーザ認証を OS に任せるのはひとつの手ではありますが，tPod がネットワークを介してファイルサーバとして機能する場合，そのために OS にログインさせるのは，サーバに触れることの出来るユーザを増やすことになりますので，好ましい結果ではありません．

以前，sugino さんが

昔、とあるセキュリティに詳しい人から「WindowsのNTFSの権限管理機構はとてもよく考えられている」と聞いたことがあります。
確かに、NTFSの権限管理の仕組みでいままで困ったことはありません。
NTFSに、乗っかってしまうのが楽かもしれません。http://www.tyzoh.jp/modules/weblog/details.php_blog_id=1119#comment7248

と書かれていましたが，データベースに格納されたファイルには NTFS の権限管理が届きませんので，ユーザ認可には使えませんし，ユーザの認証として使うにしても，そのために OS にユーザを作るのは得策とはいえません．サーバとなる OS のユーザ管理者と tPod というアプリケーションのユーザ管理者は完全に分離した方がセキュリティ上は強固になります．ネットワークを介さずに使用する，スタンドアロンのシステムではそれも可能/便利かもしれませんが．．．やはりここは Web2.0 を意識して作り上げた方が良いでしょう．エンジンの Web サービス部分とインターフェース(User Experience)部分を分けた方が使い勝手は良くなります．

また，OS に依存してしまった場合，その OS で固定になるというのが(これは多分に私の感情的な部分ですが)いやな感じです．マルチ OS 上で tPod が動くのが理想ではないかと思っています．いずれ，EAL5+ などの評価の高い OS が出てきたら，その上で動くようにするというのが理想です．

タイトルで「弊害」と書きましたので，いくつかの弊害を列挙しておきます．

セキュリティ強度が OS 依存になる．
データベースに格納されたファイルのアクセス管理が行えない．
監査ログが OS の管理者によって管理されなければならない．
サーバ側にユーザアカウントを作成する必要がある．
tPod セキュリティポリシーモデルに合致した細かい制御が出来ない．

という点です．

ユーザ認証を OS に任せるというのもひとつのてではありますが，企業内で使用することを考えると，むしろ最近流行の IDM と連携して利用できるようにした方がより使い勝手が良くなると思います．

今回は「OS にアクセス管理を任せる弊害」について書きました．次回は「マルチレベルセキュリティ」について書きます．

"tPod Security Policy Model #6" 了

いかちょー (2006-12-13 12:23) | コメント(0)| トラックバック(1)

直接リンクのファイル参照 - tPod Security Policy Model #5

こんにちは，五十嵐です．「新感覚ファイルサーバ tPod」のセキュリティポリシーモデルの第五回．今回は「直接リンクのファイル参照」です．

tPod を利用した方であれば「直接リンク」という言葉がどのようなものを指すのかお分かりかと思いますが，使ったことのない方にはイメージがわかないかもしれません．

tPod はブラウザベースでファイルの検索を行います．インターフェースを変更すれば(現在はまだ変更できませんが)ブラウザ以外のインターフェースも可能ですが，ファイルの参照は URL によって行います．ファイルが登録されると URL が生成されると言い換えても構いません．

通常の使い方は，ユーザ認証を通過した後，ファイル名やキーワードなどで検索を行い，ファイルを特定します．一覧は URL の列挙になりますが，見やすくするためにファイル名などでハイパーリンクの表示になっています．個々のファイルは URL を指定することで参照できます．

特定のファイルを他の人に知らせたい場合，二つの方法があります．ひとつは他人が絶対につけないような「タグ」をつけて，それを知らせて検索してもらう方法．もうひとつは URL を直接知らせる方法です．前者のメリットは，検索しても見つけられない人は，参照できないという点です．情報セキュリティ面から考えるとこれはひとつの方法として残しておく必要があります．後者は明確にファイルを指定できるという点です．しかし，参照権の問題をクリアしなければなりません．

tPod がファイルサーバであることを考えると，そこにファイルを集中させて管理し，外部から指定する場合には URL が指定できる方が良さそうに思えます．実体の置き場所(管理場所)と参照元のホームページなどを分離できるという点は tPod の使い方の一つのメリットです．ホームページを作る側はファイルのメンテナンスから開放され，tPod に管理をゆだねることでホームページサーバの容量などを気にせずにデザインに集中させることが出来ます．

ここで考えておかなければいけないことが最低三つあります．一つ目は，ホームページからリンクする場合，それが普遍でなければならないこと．二つ目は，ユーザが参照できるかどうかはアクセスしてみなければわからない点．三つ目はファイルがアップデートされたときのメンテナンス．

一つ目の URL の普遍性は重要です．例えば，ユーザがログインしている状態でのみ参照できるように，URL の中にセッションコードなどを含ませて，随時 URL が変わるようなセキュリティ手法があります．例えば，"https://some.domain.jp/abc/session-id-variable /filename.doc" というような URL で "session-id-variable" の部分をログインするたびに変わるようにするというものです．ログアウトするとセッションIDは消えますので，その後はこの URL では参照できません．このような方法は tPod では使用できないということになります．URL が普遍でありながら，ユーザの認証，認可を行う仕組みを採用する必要があります．

二つ目は「存在知」の観点からは，参照できないのに存在そのものは公になるという点で，問題になりますが，この場合には運用上の問題と考えるしかありません．外部から URL で指定できるものはすべての人に参照権があるように設定しておくというのが前提になります．ただし，IDM(ID Manager)などを導入して，その参照 URL のリストそのものが tPod と同様のレベルでユーザに対して見えなくするという方法が使えるかもしれません．

三つ目は tPod の特性で，上書きというものが存在しないため，アップデートされたファイルは，常に新しい URL になるという点です．したがって，最新のファイルを参照しようとする場合には常にメンテナンスを伴うことになります．この問題は tPod 側でも検討の余地があります．

最後に，外部からのリンクに対するユーザ認証について記述しておきます．監査ログのところでも述べたとおり，すべての行為はログされる必要があります．そのため，一般公開されているものであっても，ユーザ認証 (Authentication) を経て参照行為を認可 (Authorization) しなくてはなりません．ユーザ認証を受けていない状態で，固定の URL を参照する場合，ユーザ認証を受けた上で，その URL に該当するファイルを提示する，あるいは参照を却下するという動作が必要になります．その際，ユーザ認証を経て，トップページが表示されるような仕組みでは使い物にならないということです．

今回は「直接リンクのファイル参照」について記述しました．次回は「OS にアクセス管理を任せる弊害」について記述します．

"tPod Security Policy Model #5" 了

いかちょー (2006-12-12 23:01) | コメント(0)| トラックバック(7)

監査ログ - tPod Security Policy Model #4

こんにちは，五十嵐です．「新感覚ファイルサーバ tPod」のセキュリティポリシーモデルの第四回．今回は「監査ログ」です．

tPod では現在，ログの仕組みを装備していません．しかし，今後はログが重要な要素になることは間違いありません．単に「ログ」と言った場合，いくつかの種類が考えられます．

ユーザの認証ログ
検索のログ
ユーザのファイルに対する操作ログ

などです．1 番はユーザが正しい認証を行ったかどうか，あるいは不正な認証が試みられていないかなどの観点から，ログをとる必要があります．今までこの部分のセキュリティについては何も記述してきませんでした．これは，tPod の外部で認証を行う場合があることを想定しています．現在の tPod 自身でも簡単な認証の仕組みを用意していますが，IDM(ID Manager)などの利用を考えると，tPod 自身がユーザ認証の仕組みを用意するよりも，分離してそれらの外部の仕組みを利用する方法が望ましい場合もあります．そこで，ユーザ認証についてはセキュリティポリシモデルの検討からは少し距離を置くことにしました．この点については，回を改めて説明します．

2番はどのような検索が行われたのかというログですが，これはセキュリティの面よりもむしろデータマイニングや tPod 自身の改善に役立つものと考えられます．ここでは取り上げません．

3 番がここで取り上げようとする「監査ログ」になります．すなわち，ユーザがファイルを登録したことや，参照したこと，参照権限の設定の変更などを記録します．また，参照権限のない人がファイルを参照しようとしたなどの記録になります．前回の「存在知」の考え方から言えば，参照権限のない人がファイルを参照しようとすることはありえないように思えますが，参照を URL で行う場合，この URL を直接参照することが可能になります．この直接参照については次回書きますが，このような参照について，拒否したことを明確にするようなログが必要になります．

認証(Authentication)と認可(Authorization)とを明確に区別して考える場合，上で記述した 1 番は認証，3 番が認可になります．認可のログを採ることをここでは「監査ログを採る」と呼んでいます．

監査ログをとる上で必要になることは，ユーザとその行為です．どのユーザがどのような行為を行ったのか．そしてそれは許可されたのか拒否されたのかということです．さらに，付随的な情報として，許可されたのはどのような情報に基づいたものなのか，拒否されたのであれば，どのような情報に基づいて拒否されたのかなどの情報が必要になります．

また，私の保守の経験からすると，単に許可された情報，拒否された情報ばかりでなく，その時にユーザがどのような状態であったか，ファイルがどのような設定になっていたのかなどが必要になるとおもいます．ファイルのグループとユーザのグループなどは変更される可能性があり，参照権限設定がどのようであったかということ自体が重要になる可能性もあります．

そして，時刻も重要です．いつ行われたものなのかを明確にしなければなりません．

まとめると，次のような項目が監査ログには必要になります．

ユーザ名(主体)
ファイル名(客体)
行為(登録，参照，参照権限変更，グループ変更，オーナ変更など)
行為の可否(許可，拒否)
時刻
許可/拒否された前提条件
ユーザ(主体)の状態(所属グループなど)
ファイル(客体)の状態(オーナー，グループ，参照権限など)

これらをログとして残すことで，監査証跡としての「監査ログ」をつくりあげることができます．

前回の「存在知」の原則に従えば，参照の「拒否」というのはないのではないかと思ったあなた．大正解です．しかしここにひとつの落とし穴があります．それが「直接リンクによるファイル参照」です．これについては次回記述します．

監査ログの参照は，管理者とは分離すべきだと思っています．管理者の行ったオペレーションも監査ログに登録し，監査ログは，専用のユーザによってのみ参照できるようにします．運用上は同じ人が管理するとしても，システム上の権限の分離は明確にしておいたほうがよいでしょう．

今回は「監査ログ」について書きました．次回は「直接リンクのファイル参照」です．

"tPod Security Policy Model #4" 了

いかちょー (2006-12-11 13:53) | コメント(0)| トラックバック(4)

TGIF: tPod セキュリティポリシーモデル番外編

こんにちは，五十嵐です．金曜日です．「新感覚ファイルサーバ tPod」のセキュリティポリシーモデルですが今回は

番外編

です．

ウルトラマンメビウスとともに日々地球．．．というか日本を守っている Crew GUYS Japan．情報を共有するために tPod を導入することになった．

Crew GUYS Japan のメンバーは「SSSP」「UG」「MAT」といった過去のアーカイブドキュメントを使って，出現怪獣の検索などを行っている．これを tPod に入れ替えて使用する．

怪獣博士のテッペイ隊員が怪獣の特徴などをどんどんラベル付けする一方で，コノミ隊員が「かわいい」とか「キラキラ」とか「ビュンビュン」とか，相変わらずわけのわからないラベル付けをしている．

その脇でコーヒー豆の種類を分類して紐付けしているサコミズ隊長．
せっせと報告書をまとめて登録するミサキ総監代行．
いつものように何もせずに雑談をするトリヤマ補佐官とマル補佐官秘書．

そこへ，tPod に新しいドキュメントが登録された．どうやら謎の総監からのメッセージらしい．ミサキ女史がそれを見つける．たまたま総監の名前で検索したら出てきたのだ．しかし，参照権限は自分のグループにしかない．ファイルのオーナーは総監なので，参照設定を変更する権限はミサキ女史にはない．ここにいる GUYS メンバー全員に見えるようにするためにはどうすればいいのか．．．

簡単なこと．一旦ダウンロードして登録しなおせばいいのだ．登録しなおして，自分がオーナーになって，みんなに見えるようにすればいい．

こうして，総監からのメッセージは無事，メンバー全員が参照できたのだった．だが，なぜか，トリヤマ補佐官だけ参照権限が無かった．．．

これって，いわゆる隠れチャネルというやつでは．．．運用上の問題だって片付けていいんだろうか．．．機密情報は個人が勝手に登録しなおさないこと，とかルールが必要かも．

"tPod Security Policy Model 番外編" 了

"TGIF" とは，"Thank God, It's Friday!" の略．「花の金曜日」略して「花金」(笑) 毎週金曜恒例のお遊び/オタクモードです．

いかちょー (2006-12-08 09:00) | コメント(0)| トラックバック(66)

存在知 - tPod Security Policy Model #3

こんにちは，五十嵐です．「新感覚ファイルサーバ tPod」のセキュリティポリシーモデルの第三回．今回は「存在知」です．

「存在知」という言葉は聴き慣れないかもしれません．簡単に一言で言ってしまえば，存在そのものを知る必要性を指します．つまり，秘密にしたい資料や，個人の作成途中のファイルなど，存在することすら知られたくない情報というものがあるときに，どのように取り扱うかということです．

tPod は，何でもかんでもファイルを放り込んでしまえ，というのがコンセプトです．すべてのファイルを同等に扱えるというのが特徴です．一方で，隠しておきたいファイルが登録できないとなると，未完成のファイルなどは登録できないということになってしまいます．

このようなことを避けるために，前々回，前回と紹介した，「グループ」や「オーナー」の考え方を導入し，それぞれの参照権限を管理することで，ファイルのアクセスを制御しています．

「存在知」の制御は，ファイルの参照権限そのものに加えて，存在そのものを秘匿することを可能にします．

ディレクトリ階層構造のファイル管理システムでは，ディレクトリの参照権限を管理することによって，そのディレクトリ下に含まれるファイルの存在を隠蔽できるものもありますが，この場合でもディレクトリの存在そのものを隠蔽できるわけではありません．ディレクトリやファイルの存在を知った上で，アクセス権限によって，参照可能かどうかを判断できることになります．

検索に用いられたキーワードによってファイルの有無がわかるということは，ファイルがそのキーワードに何らかの関連があることを示しています．極端に言えば，「極秘計画」などのキーワードによってファイルの存在が明らかになると，そのファイルの名前などで内容が推測されるケースもありますし，さらには，ファイル名を特定しておいていくつものキーワードで検索することで，極秘ファイルの内容が推測されてしまう可能性を秘めています．

もう少し具体的に例を挙げてみます．「Project または買収」でファイルを検索したとします．この時，検索結果一覧の中に「ProjectZ」というファイルが出てきました．しかし，参照しようとしたところ，権限がないことがわかりました．このとき，あなたはどうしますか？

素直な人は参照権限がないのでファイルに触れずにそのままにするでしょう．しかし，好奇心旺盛な人は，このファイルにはどんなことが書かれているのか気になるかもしれません．「Project または買収」と指定したということは，ファイル名の「ProjectZ」で結果が出てきただけなのか，「買収」も関係して出てきたのかわかりません．そこで，「ProjectZ かつ買収」として検索してみたところ，やはり同じファイルが出てきました．こうなると「ProjectZ かつ会社名」でいろいろ探りたくなるかもしれません．噂のあるあの企業の買収か？はたまた，うちが買収されるのか？などと考えながら．．．

ファイルの存在そのものを秘匿する重要性がここにあります．難しい言葉を使えば，このような内容の参照，ファイルの存在を知るということを「隠れチャネル(Covert Channel)がある」といい，情報セキュリティとしては脆弱性が存在することになります．参照権限のないファイルはそもそも検索の対象からはずすというのが一番かもしれません．検索し終わった後に参照権限のないファイルをリストしないという方法もあります．いずれも内部の実装の話になるので，どちらで実装しても構いませんが，権限のあるユーザ以外には存在が知られてはいけないファイルの隠蔽を，可能にすることが大切なのです．

難しそうに長々と書いてしまいましたが，単純に「見えていけないものはファイル名も含めて検索できてはいけない」ということです．当たり前のようですが，きちんと定義しておかないといけない項目の一つです．

一方で，ファイル名は見せてもよく，パスワードなどを知っているユーザのみが中身を参照したいという要望もあるでしょう．このようなケースにどのように対応していくのかというのが今後の課題ですが，ひとまず今回は棚に上げておきます．

今回は「存在知」について書きました．次回は「監査ログ」について記述する予定です．

"tPod Security Policy Model #3" 了

蛇足：
「クリアデスク」を実施するときに，「市販書は一般に公開されているものだから机の上に置いて帰宅していいんだ」という解釈をする方がいます．しかし，「存在知」の考え方からすると，市販書の存在そのものによって，その部署がどのようなことをする部署かという推測が可能になり，ソーシャル・エンジニアリング的に「脆弱である」ということになります．

一般の市販書であっても机の上には放置して帰らない．これが「クリアデスク」の本来の考え方です．

いかちょー (2006-12-07 09:00) | コメント(0)| トラックバック(8)

情報のオーナー - tPod Security Policy Model #2

こんにちは，五十嵐です．「新感覚ファイルサーバ tPod」のセキュリティポリシーモデルの第二回．今回は「オーナー」です．

前回のグループの説明では，ファイルの「オーナー」を正確に定義せずに，漠然と用語を使用しました．現在の tPod はユーザがファイルを登録すると，「登録者」＝「オーナー」となります．しかし，企業などの組織で使用する場合，内部統制などの情報セキュリティの観点から考えると，「『ファイル＝情報（資産）』の登録者」と「情報（資産）のオーナー」は区別して考える必要があります．

IPA（情報処理推進機構）の「電子政府システムにおけるアクセス制御要件に関する調査」によれば，文書のライフサイクルは

個人作業フェーズ → 共有フェーズ → 決裁フェーズ → 利用フェーズ → 破棄フェーズ

となり，「個人文書」「確定前行政文書」「確定済行政文書」があるとしています．

民間でも使うことを考えると，これを単純に tPod の利用方法として限定するわけには行きません．とはいえ，出来上がった文書を登録する場合，それを本来の情報のオーナーに送って，そのオーナーが文書を tPod に登録するというのがあるべき姿としての情報の流れになります．しかし，これは現実的ではありません．というのも，「ファイルを渡す」という行為そのものを tPod を用いて行いたいからです．つまり，情報オーナーに「ファイルを渡す」ということは，「オーナーの切り替え」に他なりません．ただし，承認/決裁のプロセスは情報セキュリティというよりも，業務プロセスとなるので，セキュリティポリシモデルからは除外して考えます．

登録者から情報オーナーへの切り替えのタイミングで問題になるのは，グループとの関係です．登録者 a が所属するグループが A であり，情報オーナー b の所属するグループが B であった場合に，情報資産＝ファイルのグループとアクセス権限をどのように考えるかが問題になります．

オーナーの切り替えに伴ってファイルのグループを A → B に変更するのか，あるいはオーナーの切り替えとグループの切り替えを分離して考えるか，という点を考えなければいけません．tPod ではこの点を後者で考え，A → B が必要であれば，オーナーの切り替え前に a が，あるいは切り替え後に b がそれぞれファイルのグループを必要に応じて A → B あるいは，変更しないことを選択するようにします．

登録者 a がファイルを登録した際にグループ A のメンバーがファイルを参照してよいかどうかは，登録時のファイルの参照許可状態に依存します．逆に言えば，ファイル登録時にグループとその参照権限の設定が出来ることが望ましいと言えます．望ましいというのは，ファイル登録時に参照権限が設定できなくても，基本的に初期状態ではファイル登録者のみが参照できるようにすることで，運用でカバーできるためです．前回のグループで記述した方式 {owner, group, other} を使用すると，{r, -, -} を初期状態とすればよい，ということです．

これによって，登録者と情報のオーナーとの間での受け渡しが可能になります．ファイルのオーナーが登録者から情報オーナーへ切り替わることで，管理権限が情報オーナーに移り，情報オーナーがファイルの参照権などを設定できるようになります．

冒頭では「ファイルの登録者」と「情報のオーナー」は異なる，と書きましたが，以上のように，tPod では「ファイルのオーナー」＝「情報のオーナー」とすることで，登録者と情報のオーナーの区別をつけ，管理の権限の移動が可能になることがわかりました．

書き忘れていましたが，ここまでの議論でお分かりのように，tPod のアクセス制御は，システムが強制的に参照権限を設定する「強制アクセス制御 (Mandatory Access Control: MAC)」ではなく，ファイルのオーナーが参照権限を設定できる「任意アクセス制御 (Discretionary Access Control: DAC)」になります．

「登録者」の情報などは，ラベルなどの運用面からどのように紐づけていくかを考える必要がありますので，これはセキュリティポリシーモデルの面からは除外して考えます．ただし，監査の面からは履歴をどのように残していくかを議論しなければなりません．これについては，改めて考えることにします．

今回はファイルの「オーナー」について記述しました．次回は tPod では特に重要となる「存在知」について記述します．

"tPod Security Policy Model #2" 了

いかちょー (2006-12-06 12:11) | コメント(0)| トラックバック(8)

tPod セキュリティポリシーモデル #1

こんにちは，五十嵐です．「新感覚ファイルサーバ tPod」のセキュリティポリシーモデルについて数回に分けて考えてみます．(違う部分があったら，コメントお願いします＞＞sato さん)

今回は tPod のグループの考え方について書きます．

今のところ tPod では機密レベル(Classification)という概念を持っていません．登録されたデータ(文書，ファイル)には「極秘」「社外秘」「一般公開」といったタグ＝ラベル付けは自由にできますが，そのラベルが機密のレベルをあらわすわけではありません．

アクセスの主体となるユーザにもセキュリティ上の階層レベル(Clearance)という概念はありませんが，ユーザが属する「グループ」という概念があります．UNIX のオペレーティングシステムのファイルアクセス権限，ユーザのグループと同じものです．

すなわち，ファイルやユーザのセキュリティレベルには上下関係がありません．このようなセキュリティモデルを「シングルレベルセキュリティモデル」と呼びます．蛇足ですが，セキュリティのレベルに上下関係があり，ユーザ(主体)からファイル(客体)へのアクセスがその上下関係で制限されるものを「マルチレベルセキュリティモデル」と呼びます．

tPod のアクセス制御の考え方は従来の UNIX とほぼ同じと言えば，UNIX をご存知の方ならお分かりかと思います．すなわち，ファイルは，ファイルの所有者＝オーナーとひとつのグループに属します．ユーザはひとつ以上のグループに属します．ファイルには所有者，グループ，一般についてのアクセス権限が設定され，ユーザとユーザのグループによってアクセスが可能かどうかが決まります．

ここで，「アクセス」という言葉を漠然と使っていますが，tPod では登録されたファイルを上書きするということがありませんので，登録された後には「読める／読めない」のいずれかしかありません．UNIX ならば {User, Group, Other} の読み書き実行権限を {rwx, r-x, r--} のように(二次元のマトリックスで)あらわすところが，tPod では {r, r, -} という一次元の表になります．この点は非常に簡単になっているので，{r-x, -wx, --x} といったような面倒な組み合わせを考えずに済みます．単純に 8 通りの組み合わせしかありません．ここではすべては列挙しませんが，{-, -, r} といった無意味な組み合わせをはじめから排除することにすれば，単純なアクセス制御が可能になります．

sato さんが「やっぱりグループは階層...」で書いていた「階層」という言葉は，内部的な処理の考え方です．アクセス権の判定を階層的な考え方で参照していけば，処理が出来るという話です．

内部処理の話の前に，そもそもどのような参照の仕方をモデルとして考えているかを例を挙げて説明します．

ある組織を考えます．A 部には，B 課と C 課の二つの課があり，A には a1 という部長さんと a2 という部員がいます．B 課には b1, b2,...,bn という課員が，C 課には c1, c2,...,cm という課員がいます．ここで， c1 さんがファイル f を tPod に登録した場合を考えます．単純にするために，f のオーナーは c1, グループを C とします．f には {user, group, other} = {r, r, -} というアクセス権限が設定されました．つまり，c1 自身がこのファイルを見れるとともに，C 課の課員もこのファイルを見ることが出来ます．C 課に属さない B 課の課員はファイルを読めません．

このとき，A 部の a1 さんがファイル f を読めるようにしたいのですが，グループやアクセス権限の考え方をどのようにするかということが課題です．さらなる条件として，a1 さんは，B 課や C 課のファイルをすべて読めるようにし，a2 さんは A 部のファイルしか読めないようにします．

UNIX ではこれを group に誰が属するかという設定を行うことで可能にします．すなわち，

A: a1, a2
B: a1, b1, b2,...,bn
C: a1, c1, c2,...,cm

という具合です．これは単純ですので，すっきりしますが，課が増えた場合や a1 相当の a3 という人が増えた場合には，すべてのグループに a3 を書き加えてやる必要が出てきます．これを，

G1: a1
G2: a2
G3: G1, b1, b2,...,bn
G4: G1, c1, c2,...,cm

という管理のしかたをしようというのが sato さんの考えです．この場合には，a1 と同等権限の a3 という人が追加された場合には，G1 に a3 を追加するだけで済みます．これを処理するための仕組みを sato さんは「階層」という言葉であらわしていたわけです．より「階層」というイメージに合うように書くと，次のようになります．

a1 : G1 ⇒ G3, G4 と同等のアクセス権．
a2 : G2 ⇒ G2 のみ．
b1, b2,...,bn : G3 ⇒ G3 のみ．
c1, c2,...,cm : G4 ⇒ G4 のみ．

一方，

G5: G6, d1, d2
G6: G5, e1, e2

というような状況も出てきます(このような設定を許すか許さないかということは別にして)．これは G5 = G6 でそれぞれ {d1, d2, e1, e2} が G5 にも G6 にも含まれるというだけの話ですが，もっと複雑になると，人間の目では確認できなくなる可能性があります．この点を管理面でどのように簡単にするか，あるいはどのようにして許さないか，ということが課題になります．

今回は tPod のグループの考え方について書きました．次回は「オーナー」の部分に焦点を当てて解説を試み課題を明確にします．その後，「存在知」について考えていきます．

"tPod Security Policy Model #1" 了

いかちょー (2006-12-04 15:07) | コメント(0)| トラックバック(94)

TGIF: 悲しみのウルトラマン

こんにちは，五十嵐です．今日は情報セキュリティとも技術開発とも全く関係ない話です．立て続けに悲しい知らせ - 訃報が入ってきました．特撮系のブログではどこでもこの話題で持ちきりでしょうけれど，私も書かずにはいられません．

作曲家の宮内国郎さん死去 (2006/11/30 asahi.com)

「ウルトラマン」「帝都物語」の実相寺昭雄さん死去 (2006/11/30 asahi.com)
「ウルトラマン」など演出、映画監督の実相寺昭雄氏が死去 (2006/11/30 NIKKEI NET)
「ウルトラマン」演出、実相寺昭雄さん死去 (2006/11/30 YOMIURI ONLINE)
故実相寺昭雄さんの葬儀 (2006/11/30 asahi.com)

宮内国郎さんは「ウルトラQ」や「ウルトラマン」「快獣ブースカ」などの音楽を手がけ，誰もが一度は聴いたことがあると思います．昭和 30 年代や 40 年代前半生まれの方は，おそらく宮内さんの音楽で育ったと言っても過言ではないでしょう．

実相寺さんも言わずもがな．「ウルトラマン」がおそらく最も有名でしょうけれど，「怪奇大作戦」の奇抜なアングルや「ウルトラセブン」の「狙われた街」での独特の雰囲気．どれをとっても秀逸です．まもなく公開される「シルバー假面(かめん)」では総監修を務め，その発表会では元気な姿を見せていたといいます．

私の思い出の大きな比重を占めるお二人がお亡くなりになったことはとても残念です．
心よりご冥福をお祈りいたします．

"TGIF" とは，"Thank God, It's Friday!" の略．「花の金曜日」略して「花金」(笑) 毎週金曜恒例のお遊び/オタクモードです．
しかし，今回は神様をちょっとうらみますよ．．．Think ill of God, It's Frightened... という感じ．

いかちょー (2006-12-01 15:59) | コメント(0)| トラックバック(2)

« 2006年11月 | メインページ | 2007年1月 »

プロフィール

いかちょー

いかちょーこと五十嵐智です。
情報セキュリティ分野に興味があります。
一応、CISSP ホルダー。

SF者です。どうぞよろしく。

プロフィール詳細 (Google プロフィール)

カテゴリ

月別アーカイブ

RSSフィード