2005年03月12日() << 前の日記 | 次の日記 >>
これまでの03月12日 編集

■1 ICカードと電子ポスターを利用したマーケティング技術を開発〜産総研発ベンチャーを設立し実用化[http://www.aist.go.jp/aist_j/press_release/pr2005/pr20050310/pr20050310.html][セキュリティ]次の記事 >> このエントリーをはてなブックマークに追加

ICカードやモバイルデバイスを利用し、ユニークIDとそのIDを取得した場所および時間を手がかりとしてユーザの要求を特定し、適切なサービスを起動するもので、本技術を使用することにより、Suicaに利用されているFeliCa仕様のICカードをはじめ、Bluetooth規格の端末機器や各種ICカード、その他ユニークIDを持つモバイルデバイスを統一的に扱うことができる。

本技術の特長は、個人情報の提供や事前登録などを必要とせずに匿名で利用でき、また既に流通し所有している非接触ICカードを利用可能としたことである。
の話は、 3月11日の日経産業新聞の記事[http://it.nikkei.co.jp/it/newssp/iccard.cfm?i=2005031008205uh] で知った。
ちょうど、 「Suica番号がメールアドレスと結び付けられ始めた」[http://takagi-hiromitsu.jp/diary/20050305.html#p01] の記事を読んだ後だったので、どういう立場で書かれているのか深読みをしていたのだけれども、 深読みに過ぎなかった[http://takagi-hiromitsu.jp/diary/20050311.html#p02] らしい。組織が大きくなると、色々と難しい問題が出てくる様です。
直接関係ないけれども、思いつくヒトは「実施時のセキュリティ問題は置いておいて」システムを提案して、設計するヒトは「問題は運用でカバーすればいいや」と思って設計して、実装するヒトは「問題は設計レベルでカバーされている筈」と思って実装して、営業するヒトは「とにかく安全ですから」と言って売り込んで、運用するヒトは「大丈夫って言ってるんだから大丈夫」と思いこんで運用して、利用者は大丈夫でないものを大丈夫と信じ込まされて使っているという、どこかで聞いた様な話を思い出した。

■ 関連記事

■2 プライバシー問題の解決が難しいのはなぜか〜第8回 コンピュータ犯罪に関する白浜シンポジウム REPORT[http://www.jstage.jst.go.jp/article/shirahama/8/0/8_54/_article/-char/ja/][セキュリティ]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

高木浩光@自宅の日記[http://takagi-hiromitsu.jp/diary/20050311.html#p03] から。
Webアプリの欠陥が無くならない原因として、
この種のものが適正な費用をかけずに構築されているのではないでしょうか。即ち、安い構築事業者を使う、安いサービスにアウトソースする、あるいは入札して安いところが落札するとか、これをどう防ぐのかが難しいのです。
という問題を指摘している。これは常々感じるところで、受注者からすると、セキュリティはバグの有無という品質管理の観点と比べてもさらに見えにくい品質なので、ここを落とせば、顧客に見えないところで相当なコストを削減できる性質がある。
ことに入札ということになると、設計上明に要求されていないけれども、実装者の良心として対策すべきことを盛り込んで価格を出せば、必ず負けるという残念な状況がある *1
知らなければ大穴を空けたまま納品してしまえば良いことなので、良心の呵責も少ないけれども、知っていると技術者の良心を取るかお金を取るかという、困った状況に追い込まれる。
入札の場合、お金を掛ければ、つまり最低制限価格を上げれば、極端な安値で落札されることは無くなるけれども、これがセキュリティ面を含めた品質の向上に繋がるかというとそうはならないという問題がある。受注者からすると、同じものを高い金額で納めるだけのことになってしまう可能性が高い。
結局、あくまで入札を使いつつ、この問題を解決するためには、仕様書を作成する段階でセキュリティに関して十分な要件を定義する必要があるし、その通りに実装されたかどうかを第三者が確認する必要が出てくる。
ただ、この場合、設計者は実装者以上に実装に関する知識と考察を要求されることになるので、そこまでやって設計と実装を分離して割が合うのかどうかが新たな問題となるだろう。
もう一つ指摘しておくと、セキュリティは各工程で作り込むものであって、システムができあがってから、何らかの対策をしてセキュリティを確保するということは、大抵の場合、不可能である。
ところが、
「SSLを使っているのでセキュリティは万全です」という認識であったりする
という状況は、冗談でなく往々にして起こる。類似の例に、
「ベリサイン社の証明書を取得しており、セキュリティは万全です」
というものもあるし、
「ファイヤーウォールを導入したのでセキュリティは万全です」
や、
「IDSを設置したのでハッカー対策は万全です」
というものもある。セキュリティを確保してくれる魔法の箱はない *2
*1: 金額の乖離は、設計者が仕様書に盛り込まなかったセキュリティ上の要件と、実装者が意識している潜在的なリスクに比例する。
*2: 良く知られた攻撃に対して、アプリケーションレベルで対策してくれる箱を作ったら売れるだろうと夢想したことはあるが、なかなか難しそうだ。

■ 関連記事

■3 続・「はかる」って「量る」?「計る」?[?200503b&to=200503112#200503112]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

■ 関連記事

■4 IRCnet #組み込み 誕生[http://slashdot.jp/journal.pl?op=display&uid=4374&id=234635][IRC]<< 前の記事 このエントリーをはてなブックマークに追加

kei6氏(nantoka.comのひと)も組み込みをやってるそうな。
FreeBSDサーバ管理者だとばかり思ってたので、意外ですた。
私の中では、セキュアプログラミングと組み込みとUNIXは、より低いレイヤのことを考えてないといけないという線で繋がっています。
最近のプログラマは、即戦力に育たないといけませんから、PHPならPHP、JavaならJava、CならCの言語だけの教育を受けて、実戦配備されちゃうことが多いので、パケットやメモリを意識しないプログラマが増えている気がします。
セキュアなコードを書こうと思うと、例えば、「?ID=abc%d」を受け取って、「'abc-31491'は無効なIDです。」と表示されるのはとてつもなくマズイだろうということにピンと来ないといけないのですが、上のレイヤだけの教育では、この辺りが身に付いて来ない気がします。
日本の将来を考えると、この辺りの問題はとても深刻だと思うのですが。

■ 関連記事

以上、1 日分です。

指定日の日記を表示

前月 2005年03月 翌月
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
おさけ
おしごと
お買いもの
ぐる
ごはん
アクセシビリティ
オープンソース
セキュリティ
音楽
地域情報化
電子自治体
日記

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