2005年03月16日(水)<< 前の日記 | 次の日記 >>
この日の詳細

■1靴にICタグでバラ色の未来[セキュリティ][ICタグ]次の記事 >> このエントリーをはてなブックマークに追加

昨夜のニュース番組で、 ICタグを靴に取り付けて在庫管理をする三越百貨店[http://bizns.nikkeibp.co.jp/cgi-bin/search/wcs-bun.cgi?ID=337271&FORM=biztechnews] のレポートを放送していた。
「便利だけどもプライバシー問題が」という切り口を期待していたけれども、ICタグのコストが問題で、それは 響プロジェクト[http://itpro.nikkeibp.co.jp/free/NBY/RFID/20031219/1/] で解決されるというバラ色の未来が描かれて終わっていた。
書籍にICタグを入れると、立ち読みする客の行動が追跡できて、マーケティングに威力を発揮するし、靴にICタグを入れると、販売機会を逸したとかこれまで取れなかったマーケティング情報が取れるようになるとか、素晴らしいことばかりだ。
幸い、録画できたのでいずれ続報を。

■ 関連記事

■2 続・UFJ銀行を偽装した電子メール詐欺が発生していますのでご注意ください[?200503b&to=200503151#200503151][セキュリティ][フィッシング詐欺]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

高木先生も 「銀行業界が自治体に苦情を申し立てても不思議でない」[http://takagi-hiromitsu.jp/diary/20050315.html#p01] と題して取り上げている。
警告が出たら「いいえ」を押すのが当然の常識として人々にもともと理解されているはずのところが、昨今では、その常識が崩れつつある。その原因は、自治体の電子申請システムだ。自治体の愚かな行いが、銀行に対するphishing攻撃の危険性を増大させている。
国や自治体がこの国のPKIをズタボロにしたというのは大げさではない。
インターネットはエンドユーザーがネットワークの一部を支えているという点で、旧来のクライアントサーバ型のシステムと非常に大きく異なる。
クライアントサーバ型システムでは、サービスの提供者側が利用端末までを管理して、閉じたシステムを構成していた。利用端末に至るまでがサービス提供者の責任範囲だから、どういう端末を使おうが、サービス提供者の責任に於いて自由に決定することができる。
イントラネットもこの形体に近い。閉じたシステムなのだから、社内サービスを提供する側が端末側も管理し、責任を負う格好で、オレオレ証明書を導入することも許されるだろう。
インターネットに公開するサービスは事情が違う。端末を運用して、責任を負うのは利用者の側なのだ。あるサービスを利用するために、あやしいルート証明書を導入してしまったら、その端末は信用できない端末になってしまう。これはその端末で利用する全てのサービスに影響を与える。
プラグインを導入するのも一緒だ。信用できないプラグインを導入してしまえば、その端末は信用できない端末になってしまう。これもその端末で利用する全てのサービスに影響を与える。
端末の利用者は、同じパソコンを様々なサービスの利用に使うのだから、信頼できるルールに則って提供される証明書しか受け入れてはいけない。これは安心してネットワークを利用するPKIを構築するために、端末運用者(=利用者)に科せられた責務だ。
一部の行政のサービス提供者は、利用者のパソコンを「ウチの自治体サービス端末」とでも思っているのではなかろうか。
そして、イントラネットを構築する積もりで、利用者に「これを導入しろ、信用して『はい』を押せ」とやっているのではないか。だとすると、これだけ、オレオレ証明書にもプラグインにも、無頓着な作りを看過していることが理解できる。
だとすると、端末で起こる問題にも責任を負う必要が生じるはずだが、一切責任を負わないと宣言しているのはどうしたことだろうか。

自治体が署名したActiveXのバグ:

自治体が署名したActiveXコントロールにバグがあって、情報を盗まれるとか、パソコンがおかしくなって業務に支障が出るとか、そういう形でユーザが被害にあったりすると、訴訟を起こされそうな気がする。
仮に「一切の責任を負いません」と表記したとしても、自治体が提供している行政サービスを受けるために不可欠のものであり、サービスを受けるためには導入が必要だと説明しているのだから、責任を免れない可能性は高い。
そう考えると、ActiveXコントロールが必要な電子自治体システムを構築している自治体は、相当に勇気があると思う。

■ 関連記事

■3 国際化ドメイン名(IDN)のフィッシング詐欺脆弱性についてCENTRが声明[http://日本語.jp/access/phishing_centr.html][セキュリティ]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

「paypаl.com」と「paypal.com」,違いが分かりますか?[http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20050311/157348/index.shtml] から。
これまでに何度か、「ソ二一.jp」問題と「養老乃瀧.jp」問題として、日本語におけるIDNの運用の問題について取り上げてきた。
日本語.jpのフィッシング詐欺対策に「ソ二一.jp」問題は含まれているのか, 2005年2月21日[?200502c&to=200502213#200502213]
続・日本語.jpのフィッシング詐欺対策に「ソ二一.jp」問題は含まれているのか, 2005年2月25日[?200502c&to=200502252#200502252]
IDN(多言語ドメイン・日本語ドメイン)での"見た目に似た文字列, 2005年3月8日[?200503a&to=200503081#200503081]
この声明が日本語独自の問題に触れていないのは仕方がないとしても、 ITProの記事[http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20050311/157348/index.shtml] が、
さらにJPRSによれば,IDNを導入した時点で今回のような事態は十分予想されていて,防ぐためのガイドライン――「JETガイドライン(RFC3743)」や「ICANNガイドライン」――を用意しているという。これらに基づいて,IDN登録を運用すれば,多くの場合,今回のような事態は避けられる。
(中略)
実際,JPRSではガイドラインに従った運用をしているので,「example.jp」(すべてASCII)は登録できるが,「exаmple.jp」(ASCIIにキリル文字аが混入)は登録できない。
と、日本語特有の問題に言及していないのは残念だ。

■ 関連記事

■4 市長メルマガにウイルス[http://www.tokyo-np.co.jp/00/sya/20050314/eve_____sya_____004.shtml][セキュリティ]<< 前の記事 このエントリーをはてなブックマークに追加

市広報課は「悪意のある者、あるいはウイルスに感染した方よりメールマガジン配信サーバーあてにメールを送付されたことが原因」と話している。通常、サーバーに外部から返信があっても登録者にメールは送られないが、送信者が市広報課に偽装されていたため、自動的に転送されてしまったという。
このシステム、「秘密の」アドレス宛に特定(市広報課)のFromを付けたメールを送ると、購読者宛に配信するという仕組みになっていた様だけれども、「秘密の」筈のアドレスが、Receivedのfor等の形でヘッダに付いたまま配信されていたか、あるいは全然秘密のアドレスになっていなかったのではないか。
この話、 Webアプリの欠陥が無くならない原因[?200503b&to=200503122#200503122] で触れた話と通じるものがある。
ある程度、メール配信の怖さを知っていれば、「メール配信システムの構築」と言う案件があって積算をする時に、
  • 外部から勝手に配信されることをどう防ぐか
  • いたずらによる登録にどう対応するか
  • エラーメールの処理をどうするか
  • ウイルスの誤送信をどう防ぐか
  • エラー時の特定の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]:

違う。
これは悪意のある者、あるいはウィルスに感染した方よりメールマガジン配信サーバあてにメールを送付されたことが原因です。
第三者から送信されたメールが、メールマガジン配信サーバから配信される仕組みだったことが原因ではないか。これは責任回避だろうか、それとも本当にそう考えているのだろうか。
本当にそう考えているのだとすると、再発防止策があさっての方向に行ってしまうような気がする。

ウイルスメールの配信の経過報告[http://www.city.musashino.tokyo.jp/section/01030kouhou/news/net-news/net-news17/0314mailmaga.html]:

非常に気になることがあって、
メールマガジンの配信(毎月5日、20日)については、個人情報の保護を考慮して受取人のアドレスが他の方には分からない方法で行います。
今までは分かったんじゃなかろうね。

■ 関連記事

詳細はこの日の詳細から

2001年03月16日(金)<< 前の日記 | 次の日記 >>
この日の詳細

■1 PacketShaper[http://www.metrosystems.co.jp/packetshaperhp/]次の記事 >> このエントリーをはてなブックマークに追加

うーん。コンテンツ依存の帯域制限を実現してるのか。 手ごわい。

■ 関連記事

■2 ipfw(8)[http://www02.so-net.ne.jp/~masuda/diary/?200103b&to=200103155#200103155][freebsd]<< 前の記事 このエントリーをはてなブックマークに追加

リンクさせていただきました:-)。
dummynetの解説[http://www.iet.unipi.it/~luigi/ip_dummynet/]ALTQ[http://www.csl.sony.co.jp/person/kjc/kjc/software.html] も参考になりました。TNXです。
キューイングによる帯域の制御って本当に効くのかなぁという疑問もありまして、 これは体感的な納得が必要なので、試してみるしかないですね。

■ 関連記事

詳細はこの日の詳細から

以上、9 日分です。

指定日の日記を表示

前月 2019年10月 翌月
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31

最近の日記

2019年04月01日

新元号「令和」について

2019年03月23日

DXアンテナ ワイヤレスチューナー メディアコンセント DMC10F1

2019年02月17日

#例のグラボを活用する

2019年01月03日

シリーズ5・myHomeAlexaで自分のCDをかける

2018年12月25日

シリーズ4・英語の楽曲・アルバム・アーティスト名をカタカナに直す

2018年12月23日

シリーズ3: Echo Dotがやってきた

2018年12月19日

続・Echo Dotがやってきた

分野別タイトル一覧


全て
CLIP
SYA!nikki
book
freebsd
hns
magic
おさけ
おしごと
お買いもの
ぐる
ごはん
アクセシビリティ
オープンソース
セキュリティ
音楽
地域情報化
電子自治体
日記

予定

    ToDo

      link

      keikuma on Twitter

      keikuma Name:前田勝之
      Location:長崎市
      Web:http://www.nantok...
      Bio:前田勝之(まえだかつゆき)。長崎在住。コンサル、SE、プログラマー、 なんとか株式会社代表、非常勤講師(情報セキュリティ)。 セキュアド、テクニカルエンジニア(SV,NW)。サーバ管理とWeb日記を10年ほど。 ネットとリアルの接点に関心あり。食べること・歌うこと・愛すること・作ること・飲むこと。おいしいものがぜんぶすき。

      サイト内検索

      Google AdSense

      Powered by hns-2.19.9, HyperNikkiSystem Project