2005年03月16日サーバ管理者日誌サーバ管理とそれ以外の日常を綴ります。メールはkei@nantoka.comまで。レポートを放送していた。解決されるというバラ色の未来が描かれて終わっていた。書籍にICタグを入れると、立ち読みする客の行動が追跡できて、マーケティングに威力を発揮するし、靴にICタグを入れると、販売機会を逸したとかこれまで取れなかったマーケティング情報が取れるようになるとか、素晴らしいことばかりだ。録画できたのでいずれ続報を。題して取り上げている。警告が出たら「いいえ」を押すのが当然の常識として人々にもともと理解されているはずのところが、昨今では、その常識が崩れつつある。その原因は、自治体の電子申請システムだ。自治体の愚かな行いが、銀行に対するphishing攻撃の危険性を増大させている。高木浩光@自宅の日記[http://takagi-hiromitsu.jp/diary/20050315.html#p01]国や自治体がこの国のPKIをズタボロにしたというのは大げさではない。インターネットはエンドユーザーがネットワークの一部を支えているという点で、旧来のクライアントサーバ型のシステムと非常に大きく異なる。クライアントサーバ型システムでは、サービスの提供者側が利用端末までを管理して、閉じたシステムを構成していた。利用端末に至るまでがサービス提供者の責任範囲だから、どういう端末を使おうが、サービス提供者の責任に於いて自由に決定することができる。イントラネットもこの形体に近い。閉じたシステムなのだから、社内サービスを提供する側が端末側も管理し、責任を負う格好で、オレオレ証明書を導入することも許されるだろう。インターネットに公開するサービスは事情が違う。端末を運用して、責任を負うのは利用者の側なのだ。あるサービスを利用するために、あやしいルート証明書を導入してしまったら、その端末は信用できない端末になってしまう。これはその端末で利用する全てのサービスに影響を与える。プラグインを導入するのも一緒だ。信用できないプラグインを導入してしまえば、その端末は信用できない端末になってしまう。これもその端末で利用する全てのサービスに影響を与える。端末の利用者は、同じパソコンを様々なサービスの利用に使うのだから、信頼できるルールに則って提供される証明書しか受け入れてはいけない。これは安心してネットワークを利用するPKIを構築するために、端末運用者(=利用者)に科せられた責務だ。一部の行政のサービス提供者は、利用者のパソコンを「ウチの自治体サービス端末」とでも思っているのではなかろうか。イントラネットを構築する積もりで、利用者に「これを導入しろ、信用して『はい』を押せ」とやっているのではないか。すると、これだけ、オレオレ証明書にもプラグインにも、無頓着な作りを看過していることが理解できる。すると、端末で起こる問題にも責任を負う必要が生じるはずだが、一切責任を負わないと宣言しているのはどうしたことだろうか。自治体が署名したActiveXのバグ:自治体が署名したActiveXコントロールにバグがあって、情報を盗まれるとか、パソコンがおかしくなって業務に支障が出るとか、そういう形でユーザが被害にあったりすると、訴訟を起こされそうな気がする。仮に「一切の責任を負いません」と表記したとしても、自治体が提供している行政サービスを受けるために不可欠のものであり、サービスを受けるためには導入が必要だと説明しているのだから、責任を免れない可能性は高い。考えると、ActiveXコントロールが必要な電子自治体システムを構築している自治体は、相当に勇気があると思う。これまでに何度か、「ソ二一.jp」問題と「養老乃瀧.jp」問題として、日本語におけるIDNの運用の問題について取り上げてきた。JPRSによれば,IDNを導入した時点で今回のような事態は十分予想されていて,防ぐためのガイドライン——「JETガイドライン(RFC3743)」や「ICANNガイドライン」——を用意しているという。これらに基づいて,IDN登録を運用すれば,多くの場合,今回のような事態は避けられる。(中略)実際,JPRSではガイドラインに従った運用をしているので,「example.jp」(すべてASCII)は登録できるが,「exаmple.jp」(ASCIIにキリル文字аが混入)は登録できない。2005/03/16[http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20050311/157348/index2.shtml]と、日本語特有の問題に言及していないのは残念だ。Tweet市広報課は「悪意のある者、あるいはウイルスに感染した方よりメールマガジン配信サーバーあてにメールを送付されたことが原因」と話している。通常、サーバーに外部から返信があっても登録者にメールは送られないが、送信者が市広報課に偽装されていたため、自動的に転送されてしまったという。2005/03/14[http://www.tokyo-np.co.jp/00/sya/20050314/eve_____sya_____004.shtml]このシステム、「秘密の」アドレス宛に特定(市広報課)のFromを付けたメールを送ると、購読者宛に配信するという仕組みになっていた様だけれども、「秘密の」筈のアドレスが、Receivedのfor等の形でヘッダに付いたまま配信されていたか、あるいは全然秘密のアドレスになっていなかったのではないか。触れた話と通じるものがある。外部から勝手に配信されることをどう防ぐかいたずらによる登録にどう対応するかエラーメールの処理をどうするかウイルスの誤送信をどう防ぐかエラー時の特定のMTAの困った挙動にどう対応するか隠れバウンスエラーにどう対応するかと言った様なことを最低限気に掛けるものだ。実際、安全なメール配信システムを構築するのは本当に難しい。いった中で、どこまでは許せるということを考えながら、例えば、ドメイン内部からであることを詐称されない方法で確実に判定する送信時に何らかの方法でパスワードを確認するフィルタリングして添付ファイル付きメールは配送しないようにするエラーメールを分析する方法を用意するということを盛り込んだ仕様を考えて、ある程度のスクリプトを開発することを前提にして積算することになる。ところが、蓋を開けてみると、Webで入力すると特定のaliasのincludeが書き換えられるだけの仕組みが構築されたりする。発注者が要求したことは確かにできるのだ。個人情報保護法でクライアントの意識は変わるのだろうか[http://slashdot.jp/article.pl?sid=05/03/14/0456231]。ウイルスメール配信のお詫びとご報告[http://www.city.musashino.tokyo.jp/section/01030kouhou/news/net-news/net-news17/0312mailmaga.html]:違う。これは悪意のある者、あるいはウィルスに感染した方よりメールマガジン配信サーバあてにメールを送付されたことが原因です。2005/3/12[http://www.city.musashino.tokyo.jp/section/01030kouhou/news/net-news/net-news17/0312mailmaga.html]第三者から送信されたメールが、メールマガジン配信サーバから配信される仕組みだったことが原因ではないか。これは責任回避だろうか、それとも本当にそう考えているのだろうか。本当にそう考えているのだとすると、再発防止策があさっての方向に行ってしまうような気がする。ウイルスメールの配信の経過報告[http://www.city.musashino.tokyo.jp/section/01030kouhou/news/net-news/net-news17/0314mailmaga.html]:非常に気になることがあって、メールマガジンの配信(毎月5日、20日)については、個人情報の保護を考慮して受取人のアドレスが他の方には分からない方法で行います。ウイルスメールの配信の経過報告[http://www.city.musashino.tokyo.jp/section/01030kouhou/news/net-news/net-news17/0314mailmaga.html]今までは分かったんじゃなかろうね。TwitterName:前田勝之Location:長崎市Web:http://www.nantok...Bio:前田勝之(まえだかつゆき)。(情報セキュリティ)。セキュアド、テクニカルエンジニア(SV,NW)。サーバ管理とWeb日記を10年ほど。ネットとリアルの接点に関心あり。食べること・歌うこと・愛すること・作ること・飲むこと。おいしいものがぜんぶすき。reserved.サイトポリシ。