• 安全なサーバの数?

    総務省の日本のICTインフラに関する国際比較評価レポートによると日本は他の国に比べて「安全なサーバの数」が少ない(!?)らしい。日本は14位だそうです。これを読んで何故14位なのか非常に気になり更にPDFを読むと定義がありました。

    しかし、安全なサーバとは

    安全なサーバ数
    (出典)WORLD ECONOMIC FORUM「The Global Information Technology Report 2004-2005」
    Secure Internet servers, 2003
    (説明)
    100 万人当たりの安全なインターネットサーバ数※。
    ※ 暗号化通信をブラウザとの間で行えるサーバのことを指す。

    だそうです。

    SSL通信ができないサーバより、基本的なセキュリティ対策が取られていないサーバの方が危険です。「SSL通信 != 安全なサーバ」であることは広く知られていると思います。

    正しくは「SSLをサポートしたサーバの数」と表記しないと、日本には安全ではないサーバが多くある、と勘違いしてしまいますね。

    追記:「SSL」は専門用語なので報告書では使えないのでしょうね。「暗号化した通信が可能なサーバの数」で良いのかな? ところで「SSL」の安全性を素人向けに表現した文面で気に入っているのはDELLの表現です。

    暗号化は、どの位安全なのか?

    オンライン上で暗号化された情報を提示いただく事は、電話で情報をお伝えいただくのと同じ位安全です。

    詳しく書きませんがこの表現が非常に優れていると思える理由はいくつもあります。素人向けにはこれ以上優れた表現はないように思えます。

  • サイボーズがMySQLを選択した理由

    サイボーズは独自システムからオープンソースシステムを活用する方向に移行をするようですね。

    Berkeley DBも候補に挙がっていた、とこの事ですからトランザクションが必要ないことは明らかですね。現時点で選定したらSQLiteという選択肢もあったのかも知れませんね。

    決定した時点での状況、Windowsサポート等を考えるとMySQLと言う選択も株主としても納得できる選択と思います。

    新しいフレームワークではアプリケーションをPHPで記述しています。これもMySQLの採用と同じくらい大きな選択で、この部分をJavaにするかでも悩みました。

    この選択もDBの選択と同様に微妙ですが、コードの一部を公開してカスタマイズを可能にするにはPHPの方が有利だと思います。新しく作るならPHP5が良いかと思いますが、もう作ってあるようですね。

    このブログ、サイボーズの方もご覧になっているようなので営業を一つ。
    セキュリティの監査など必要でしたら是非どうぞ。
    # 本当に引合がきたりして(笑

  • だからSUNは衰退する

    3月、本誌のインタビューでサンのマクネリー会長は、IBMがコンピューター業界で再び独占的な地位に立とうとしている現状を、こう皮肉った。人類にとって、恐竜の復活は悪夢に違いない。

    メインフレームが復活するのは悪夢、と皮肉っているだけではSUNの将来も危ういでしょう。分散システムを広めるために大々的にTCO削減キャンペーンを行っていた事を忘れてしまったのでしょうか?

    現在ではネットワークの単価はムーアの法則を遥かに上回るペースで下落した結果、集中システムを維持するために必要な広域ネットワークも無料同然で手に入るようになってきています。今やファイルサーバでさえ集中させてしまっても問題が無くなってきています。実際に広域LANを利用している企業も多数です。

    たとえシステムが一箇所に集中していても、多数のサーバをメンテナンスするのは非常に手間がかかります。だからこそPC系のサーバでさえバーチャルサーバ技術への対応が急速に進んでいます。SUN自身もSunFireの仮想システムでメインフレームの様な機能を付けています。

    メインフレームへの回帰のトレンドは随分前に始まっていました。ユーザはトータルで安ければメインフレームでもSUNでもPC Linux、Windowsでも何でも良いのです。トータルで安いとは通常の意味でTCOに加え、既存のソフトウェア資産が活用できるか、安全性・信頼性などの必要要件なども含め、最適なシステムは何かを検討し、Linux対応メインフレームが最適な選択肢であっても何ら不思議ではありません。

    実際問題として「SUNにとって、恐竜の復活は悪夢」でしょう。SUNはエンタープライズ市場のハイエンドを狙い、いいところまで来た、と思っていたところに過去の遺産に市場を丸ごと横取りされてしまった形ですから。しかし、このままではSUNは衰退するばかりですね…
    何故、今、新たにSUNを選択するのか?その理由が見当たりません。

    # 個人的には元気にやって欲しい企業なんですけどね…

  • 日本のWEB改竄被害状況

    随分前からあったようですが最近まで知りませんでした。日本に特化しているのでZone-Hより便利ですね。

  • Firefoxはしばらくjavascript off!

    このblogでFirefoxを薦めているので念のため。気づいている方も多いとは思いますがFirefoxは1.0.4がリリースされインストールするまで、しばらくソフトウェアのインストール機能とJavaScriptを無効に設定するべきです。

    次の2つ無効に設定します(チェックをはずす)

    ツール>オプション>Web機能>Webサイトによるソフトウェアのインストールを許可する
    ツール>オプション>Web機能>JavaScriptを有効にする

  • PHPに足りないもの

    よく「中規模以上のプロジェクトにPHPは向かない」と聞きますがJavaに比べると確かにその通りです。Beanなんて考え方は無いですし「JCPで作られた数々の標準に対応するような物がない」と言われても仕方ない状況です。言語仕様についても結構アバウトで微妙な仕様が突然変わったりします。
    # 最近では5.0.3でコンストラクタをprivateで宣言できなくなった件があ
    # ります。これは次の5.0.5で修正されますが。
    # PHP4->PHP5ではオブジェクトを配列にキャストするとPHP5ではおかしな
    # 動作をするなどがあります。

    (特に現在は)PHPでJavaのような環境を前提としたしシステム開発には無理があります。Javaのようにいたれりつくせりの環境、アプリケーションサーバの付加分散等までフレームワークでやってしまえるような環境であるJavaと比べれば、明らかにPHPは中規模・大規模に向かないと言えます。

    PHPでの開発は、どちらかと言うと、C言語での開発に近いのではと思います。いたれりつくせりの標準フレームワークは無い事、詳細は異なりますがアバウトなデータ型管理、などC言語での開発に似ている点はいくつかあると思います。C言語がJavaのような標準フレームワークを持っていないくても色々な分野で利用されています。最近ではC言語での大規模開発は相対的に少なくなって来ているとは思いますが、C言語で中規模以上の開発は向かない、と言う方はいないと思います。

    ここでプロジェクトの規模について簡単に整理してみます。プロジェクトの規模には大きく分けて2種類あると考えています。1つは開発時の開発体制の規模、もう1つは運用時のシステムの規模です。

    「開発体制規模が大きなシステム=運用時のシステム規模が大きなシステム」は成り立ちません。PHPが向かないと言われているシステムは「開発体制規模が大きなプロジェクト」であり、「運用時のシステム規模が大きなプロジェクト」ではありません。作るアプリケーションによりますがPHPで大規模システム(後者)を構築すると非常に開発効率が良い場合もあります。開発者が20名を超える中規模(会社によっては100名以下は小規模という会社もいくつもあると思いますが)システムの場合、プロジェクト管理により高度な技術的な知識が必要となり、プロジェクトを進行しづらい状況もあるとは思います。反対に安直にJavaで作ってしまい、スケーラビリティに欠けるWebシステムになってしまった、と言う話もよく聞きます。
    # スケーラビリティに欠けるシステムはPHPでも簡単につくれますが、
    # Javaのフレームワークを過信する間違いはよく聞きます。

    PHPに足りない物は開発者の分業を可能とするフレームワークです。PHP5になって、PHP4との互換性を考えなければ、フレームワークを構築する開発者は随分やりやすくなってきています。PHP5になりフレームワークをルールに則り利用する事を強制する事も可能なりました。DIを実装しているMapleなどのフレームワークが充実してくるとこの状況も徐々に改善してくる事と思います。特に日本製フレームワーク、MapleEnthaに期待したいと思います。

  • 物の見方は変わるもの

    mixiのコミュニティで見つけたのですが、

    中華人民共和国の毛沢東初代主席が、1964年7月10日に日本社会党の訪中団に語った 「日本軍国主義に感謝」 の英訳を探しています。
     もし無いようなら新たに英訳しなければと思っていますが、捏造疑惑を避けるため、できれば日本以外のサイトで見つけたいのです。

    という事で、かつて毛沢東は 

    「〔いわゆる侵略について、日本は〕何も申し訳なく思うことはありません。日本軍国主義は中国に大きな利益をもたらし、中国人民に権力を奪取させてくれました。みなさんの皇軍なしには、われわれが権力を奪取することは不可能だったのです。……過去のああいうことは、良い事であり、われわれの助けになったとも言えるのです」

    と言ったらしい。その情報源を探されていたようですが

    http://en.wikiquote.org/wiki/Mao_Zedong
    http://www.google.com/search?num=100&hl=ja&q=mao+zedong+++10+July+1964++Sasaki%2C+Kuroda%2C&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=

    にあると回答がありました。コンピュータと人のネットワークはすばらしいですね。NetNewsでも同じような情報交換ができましたがSNSの場合は更に自由度が高い事、mixiは基本的に匿名システムでは無いことがレベルの高いネットワークが可能な理由なのかも知れません。

    中国では最近は反日感情が高いようですが物の見方が変われば180度違った意見がある事を再確認しました。

    mixiにアカウントをお持ちの方:元ネタは http://mixi.jp/view_bbs.pl?id=929346 です。

  • 間違いは起きるもの

    米軍の機密情報、「コピーアンドペースト」操作で流出、だそうです。
    どの程度の機密性がある文書であったかは分かりませんが、イラク検問所でイタリア人が殺害された事件の報告書、とあるので安全保障に大きく影響するような機密情報ではなかったと思います。

    PDFの文書に機密情報部分が黒塗りの■を付けただけであった為、テキストを選択しペーストすると機密情報が参照できてしまった、という話です。

    これと似たような話でMS WORDの履歴機能で情報が漏洩してしまった、と言う話も時々聞きます。記憶に残っている物ではSCOの訴状がMS WORDで作成され、履歴が残っていた為どの会社に対して訴訟を検討していたか判明した、等があります。会社などで見積書など作る場合には履歴機能には十分注意する必要があります。

    ここでふと思ったのですが日本ではWebサイトの脆弱性を利用して情報を参照する事は違法と判断される可能性が非常に高いです。(1審の1例だけでは確定してる、とは言えないので)日本ではPDFに機密文書と記載されているにも関わらず「コピーアンドペースト」で情報を参照してしまうと罪になるのでしょうか? 先の判決からすると「コピーアンドペースト」で情報を参照する行為も犯罪と判断されるかも、と一瞬思ってしまいました。適用された法律は他人のIDを不正利用する事を禁止する法律だったはずですから自分のPCでPDFを見ても問題無しですね。

    もしパスワードがあるPDFファイル等ならどうなんでしょう?クラックすると無罪?有罪? 第三者がクラックしたパスワードと知らずに使用したら無罪?有罪? どちらなのでしょう?

    会社などでキーロガーを導入してセキュリティを確保している場合もあると思います。PC本体をサーバルームに設置するブレードPC等では簡単にハードウェアレベルのキーロガーを導入できると思います。この場合、従業員が圧縮したファイルにパスワード付けて送信し、その圧縮ファイルをキーロガーから取得したパスワードを使用して解凍したら有罪でしょうか?

  • キーロガーを利用したフィッシング詐欺が急増

    随分前からキーロガー(キー入力を記録するソフトウェアやハードウェア)を利用した攻撃の可能性は指摘されていましたが、ついに流行するようになったようです。

    この攻撃では、Microsoftの「Internet Explorer」ブラウザに存在する脆弱性を悪用することが多い。

    とのこのですが、このサイトにアクセスされている方の26%(2005年4月)はまだInternet Explorerを利用されているようです。最新にしていれば大丈夫だろう、というのは甘いかも知れません。先月もあまりにMSの対応が遅い事を理由にパッチがまだ無いセキュリティホール情報が公開されていたりします。

    Firefoxの最新版以外にもセキュリティ上の問題があるので古いFirefox利用されている方も直ぐにバージョンアップする方が良いでしょう。

    Websenseの2月および3月の調査では、毎週のように、キーロガーの新しい亜種が約10個、そしてキーロガーをユーザーPCに植え付けるために新たに設置されたウェブサイトが100件以上発見されたという。2004年11月および12月の調査では、各週平均1個から2個の新亜種が、さらに10~15 件のウェブサイトが発見されていた。

    とありますが、今のところは海外サイト、特にブラジルが多いようですが転ばぬ先の杖としてIEは利用しないほうが良いと思います。

    IEでないと見れないサイトがあって不便と言う場合はFirefoxのUser Agent Switcherを利用すると良いでしょう。多くの場合、あまり問題無く利用できるようになります。例えば、DELLのサイトはIEかNetscape 4.7(古すぎて危ないですが)しかサポートしていませんがUser Agent Switcherでユーザエージェントを切り替えれば問題なく利用できます。

    中には本当にIEの事しか考えていないサイトもあるとは思いますが、そのようなサイトにはアクセスしないほうが良いと思います。

  • WindowsでCAPSキーをCTRLに変更

    LinuxならXでもコンソールでも自由にレイアウト変更可能ですが、Windowsでもレジストリを変更すれば可能です。ノートPCが使いづらいのでCAPSキーをCTRLキーにするためにレジストリを変更しています。このレジストリの変更ではCAPSキーもCTRLになるようになっています。左下のCTRLはCTRLのままです。個人的にはCAPSキーの必要性がないので使えなくても大丈夫だからです。.reg拡張子を持つファイルとして保存してダブルクリックすれば変更完了です。

    REGEDIT4

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout]
    “Scancode Map”=hex:00,00,00,00,00,00,00,00,03,00,00,00,1d,00,3a,00,3a,00,1d,00,\
    00,00,00,00

    自分のVAIO(Windows XP Professional)で使っていますが、レジストリの変更は危険を伴います。当然ですが無保証です。ご注意ください。

  • DELL 20インチモニタが7万6千円

    前回の様に約5万5千円という激安ではないですが、20インチUXGAモニタがオンラインクーポンを利用すると約7万6千円(送料、消費税込み)で買えます。価格.comでもこの価格帯は最安です。もう1台購入しました。

    D-Sub、DVI-D、S-Video、Compositeと4系統もサポートしています。この機能は使ったことが無いので使い心地は分かりませんが、PIP機能を使用するとS-VideoとComposite入力を画面上に出力できるようです。
    # つまり、DVDプレーや等の出力をキャプチャカード無しで
    # 画面上に出力できる。出力する場所も選べるようです。

    sRGBはサポートされていません。発色を優先するならやはりEIZOのLCD(EIZO FlexScan L565)方が良いですね。具体的にはEIZOのLCDに比べるとぎらぎらした感じがあり、白が白すぎるような気がします。今使っているこのDELLモニタはブライトネスを最小に設定して使用しています。色合いの問題を気にしなければお勧めのモニタと思います。23か24インチを一台買うより、この20インチモニタ2台の方がプログラムなどの作業は行い易いと思います。

  • 科学常識このぐらいは

    文部科学省がこのくらいの科学常識は知っているべき、ということでガイドラインを作るらしい。

    【科学常識チェック、〇か×か】(国際比較の共通質問から)
     〈1〉地球の中心部は非常に高温
     〈2〉すべての放射能は人工的に作られた
     〈3〉我々が呼吸に使う酸素は植物から作られた
     〈4〉赤ちゃんが男の子になるか女の子になるかを決めるのは父親の遺伝子
     〈5〉レーザーは音波を集中することで得られる
     〈6〉電子の大きさは原子よりも小さい
     〈7〉抗生物質はバクテリア同様ウイルスも殺す
     〈8〉大陸は何万年もかけて移動しており、これからも移動するだろう
     〈9〉現在の人類は、原始的な動物種から進化した
     〈10〉ごく初期の人類は、恐竜と同時代に生きていた
     〈11〉放射能に汚染された牛乳は沸騰させれば安全

    全く自慢にもならないですがこの記事に書いてある問題は全問正解でした。(正解はリンク先に記載されています)しかし、18歳以上を対象に「ごく初期の人類は恐竜と同時代に生きていた」と聞いた結果、日本人の正答率は54%!で国際順位で13位だそうです。耳を疑いたくなる結果ですね…

  • よく聞く話ですが…

    日本の医療が遅れている、と言う話はよく聞く話ですがNHKスペシャル「シリーズ 日本のがん医療を問う 第1夜 “救える命”を救うために」の統計はすごいですね。国立癌センター調べでは乳癌の治療で学会のガイドラインに合っている治療が行われているのが半分、1/4は不必要な治療、1/4は治療によって悪化!しているらしいです。

  • ブートローダのインストールで固まる場合の対処

    SATAが1台だけ搭載されているDELL PowerEdge 800にMomonga Linux 2をインストールを試みるとブートローダ(Grub)のインストール中に固まってしまいました。どうもブートローダのインストールができない状態のようなので、インストール中のXの画面から

    ALT+SHFIT+F2

    でVertual Console 2からtopコマンドと実行するとgrubプロセスが100%CPUを使用した状態でした。何らかの理由で無限ループに陥ったことが原因と思います。

    とりあえずの対処は手動でGrubをインストールすればOKです。まず、grubのプロセスIDを調べてkill PID、そして

    chroot /mnt/sysimage /sbin/grub-install –recheck /dev/sda

    と入力して手動でGrubをインストールすればOKです。インストール出来ない場合は–recheckを削除して試してください。あとはXの画面に

    ALT+F7

    で戻り、「再起動しますか?」と聞かれているはずなので再起動すればOKです。
    # バーチャルコンソールから再起動しても良いですが、一応…

    Grubがインストールできないケースはあまり無い(?)とは思いますが、情報として。

  • session_regenerate_idの使い方に注意!

    久しぶりにPHP-users MLを見るとsession_regenerate_id関数が「古いセッションIDに関連したセッション情報を削除しないのは困るよね」と投稿がありました。

    バグレポートではBogus(バグじゃない)というステータスになっていました。確かにsession_regenerate_id関数は新しいセッションIDを生成する為の関数として追加されました。新しいセッションIDを作れば仕様上は問題ない、と主張できるかもしれません。しかし、アプリケーションの作り方によってはセキュリティ上の問題を発生させる原因になるので変更するべきですね。

    セッションモジュール、セーブハンドラモジュール、シリアライザモジュールの各グローバル変数がマクロでアクセスされる作りになっています。(セッションモジュールは更にサブモジュールと持つ構造になっています。随分前ですがWeb+DB Pressに書いた通りです。興味のある方はどうぞ。)さらに引数などもマクロで定義されているため、初めて読むプログラマには非常に分かりづらいソースになっています。

    PHPセッションモジュールのソースを読んだ事がある方なら分かりますが、グローバル変数を使用している、今回の場合はPSマクロで利用するグローバル変数、のでセッションID、PS(id)、を保存しないとならないように思えます。
    # 今思いつきましたが、PS(data)にempty_stringを入れて
    # おけばOKなような気がします。

    session_destory関数にはバグがあるようでセッション情報は空になりますが、ファイルをunlinkしたいようなコードになっているのですが…、unlinkされていません。XFSなど、ディレクトリエントリにB-Treeを使用しているファイルシステムでは大量のファイルがあっても性能上や使用上問題ありません。個人的には50万ファイル(50万セッション)までファイル作成してベンチマークしてみましたが、性能は全く変わりませんでした。

    ext3を利用している場合、2の問題で困る可能性があります。一つはinodeの枯渇ともう一つパフォーマンスの低下です。デフォルトではinodeが枯渇する可能性は大きいと思います。DoSの原因にもなるので注意しましょう。Linuxの場合、ディレクトリエントリはキャッシュされているので多数のファイルがある場合でもかなり良い性能ですが、それでも何十万ファイルレベルになると遅くなります。

    セッション管理は有効期限を0に設定したセッションクッキー(ブラウザの終了と同時に削除されるクッキー)を利用し、自動再ログインなどの仕組みはアプリケーションでセキュリティ上の問題が許容される取り扱い方法を独自に実装する方が良い、と考えています。

    もし有効期限が長いセッションIDを利用してログイン状態を保ち、セッションIDの再生成でXSSのリスクを軽減されている場合はsession_destroyを使用してセッションの削除を忘れないようにしなければなりません。ご注意ください。