もらったのはエコバックと消しゴムと、あと…

一見、ペンのように見えるのですが…

開けたらはさみ！ 持ち運びに便利＾＾
ちなみにホッチキスもあるらしい〜(欲しいなー笑)
大事に使います♪

2011年に偽造証明書が発行されるという事件がありました。

発行されてしまったのはComodo社とDigiNotar社の偽造証明書。
Comodo社のケースではGmailやskypeなどの偽造証明書が、
DigiNotar社のケースではなんと531件の偽造証明書が発行されてしまい、
DigiNotar社は事業継続が困難になり倒産に追い込まれてしまいました。
どうしてそのような事件が起きてしまったのでしょう？
まずComodo社のケースから見てみましょう。

認証局(CA)は、
申請者の情報を確認し発行する前の審査を行う登録局(RA)と
審査の結果を受けて証明書発行のみ行う発行局(IA)に分かれます。
1つの認証局が両方を行う場合もありますが、
Comodo社では事件の起きた2011年時点では登録局の業務を外部に委託しており、

Comodo社では認証を簡素化するために自動発行を行っていたため、
登録局がハッキングされ偽造証明書が発行されてしまいました。

一方、DigiNotar社では、ComodoHackerと名乗る人物が
DigiNotar社のシステムへのパスを不正に入手、
証明書を発行のための情報を得て偽造証明書を発行しました。

GoogleなどのWebブラウザには認証局が自ら署名して発行する
ルート証明書があらかじめ組み込まれています。
このルート証明書を使ってコンピュータはwebサイトに発行されている
証明書が正しいものなのか確認しています。

今回のケースでは偽造証明書は、ルート証明書が登録されているDigiNotar社の
証明書として不正に発行されてしまっていたため、信頼できる証明書として扱われてしまっていました。

なぜ偽造証明書に気づいたかというと、Google ChromeがGoogleのサイトのみ
各ページの証明書を発行するルート認証局の一覧を所持する機能をサポートしていたため、
偽のGmailのページにつけられたDigiNotarの証明書に対してセキュリティ警告したためでした。

それまでに実に531件もの偽造証明書が発行されてしまったため、
Google Chromeを始めとするWebブラウザベンダーによって
DigiNotar社のルート証明書がリストから削除されてしまい、
DigiNotar社は事業継続が困難になり倒産に追い込まれてしまいました。

実は、原則的には認証局は誰でも作ることが出来ます。

各認証局ごとに安全性への取り組みは異なりますが、
信頼できる証明書とは認証局が考える「PDCA」を遵守して発行される必要があります。

PとはPlan(企画・計画)。

認証局はそれぞれの証明書を発行する際の運用規定をまとめたCPSを制作し、
ホームページ上でまとめています。

DとはDo(実行)。

CPSに従って運用を行います。

CとはCheck(評価)。

定期的にセキュリティの脆弱性アセスメントを行い結果を監査報告します。
また、外部監査も行います。

AとはAction(改善・見直し) 。

セキュリティの促進やインシデント(問題)が起こった時のルールのドキュメント化などを行います。
ベリサインではこのようにCPSによって認証の運用規定を作成し、運用を行っています。

しかし、ComodoやDigiNotarの偽造証明書発行事件が起こってしまいました。
事件が起きた当時、業界全体での運用規定をまとめた文書の作成を行う議論が進んでいましたが、
この事件がおきたことで議論が加速し、
業界全体での運用規定をまとめた文書、Baseline Requirementが調印されることとなりました。

Baseline RequirementはCA Browser Forumによって制定されました。
Baseline Requirementは、それまでCPSによってそれぞれが定めていた運用規定を
業界でまとめた初の試みで、2012年の7月から発行されます。
ベリサインやジオトラスト、グローバルサインや、IEやsafari等の主要なCAとブラウザベンダーが
サインをしているため、Baseline Requirementに準拠しない場合は
ブラウザの信頼されるルート証明書から除外される可能性があります。

Baseline RequirementはベリサインのHPにて近日公開予定のようです。

先週、ベリサインさんでカンファレンスがあったので参加してきました！
その中で常時SSLとbaseline requirementについてもお話があったので、
自分でも調べてまとめてみました。

SSL証明書はこれまではログインの画面や、ネットでのショッピングの際に
選んだものが表示されるショッピングカートのページのみにつけられていました。
常時SSLとは、ログイン画面などだけではなく、
トップページ等ユーザが訪問する全てのページでHTTPS通信を行うようにすることです。

Firesheepなどwifi通信で暗号化されていないセッションを自動的に検出してcookieの
情報を読み取るツール等が出現したことが原因です。

cookieを使うと一度訪問したwebサイトにもう一度訪れた時に、
cookieの情報をもとにwebサイトはユーザを識別することが出来ます。

例えば、何回訪問したかといった情報や、ログイン情報を記憶し入力を省略したり、
見たページから好みに合いそうな商品や広告を表示することができます。

さらに、cookieにはセキュアcookieというものがあります。
セキュアcookieにすると受け渡しするのは暗号化されているhttps通信の時のみにすることができます。

Firesheepはカフェやホテル等、オープンなwifiを通じて
firesheepが登録しているサイトに、暗号化されていないhttp通信でログインしている
ユーザのcookieの情報を簡単に見ることが出来てしまいます。
さらに情報を見るだけではなくその情報を使ってなりすましてアクセスすることだって出来てしまうのです。

そのため全てのページにSSLをかけてhttps通信にすることで
情報を暗号化して守ろう！というのが常時SSLです。Firesheepは暗号化されていないセッションを検出するものなので
https通信にすることでcookieの情報を守ることができます。

すでに常時SSLを実装しているサイトとして、twitterやFacebook、Google等があります。
GoogleではGmailとGoogleAppのユーザ向けに、
Facebookでは選択可能になっていますが約2割のユーザが常時SSLを選択しています。

やりとりをする情報が重要なサイトやログインするユーザの多いサイトでは
セキュリティは常に意識して運営していきましょう！

先日、VeriSignさんと打ち合わせがありました。
VeriSignさんとは何度かお会いしていますが、今回は社会人になって初めての打ち合わせ。
知らない言葉もたくさん出てきたので自分なりに調べてみました。

今回はSANsとワイルドカード証明書についてです。

普通、サーバ証明書はコモンネーム１つにつき、サーバ証明書を１枚申請します。

ワイルドカード証明書とSANsは１枚のサーバ証明書で複数のコモンネームへのSSL通信を可能にする方法です。

ワイルドカード証明書はコモンネームを、「*.usausa.usa」のように
アスタリスクをサブドメインに相当する階層に記載した形で申請します。
すると、ワイルドカード証明書は複数のサブドメインを使用しているサイトで
それぞれのコモンネームでサーバ証明書を取らなくても１枚のSSLサーバ証明書で
httpsアクセスを有効にします。
ただし、アスタリスク(＊)の後ろのドメイン名は同一である必要があるため、
たとえば、www.usausa.netのようにドメイン名が違うとまた別にSSLサーバ証明書を取得する
必要があります。
→現在ベリサインでは発行していません。

SANsはコモンネームをwww.usausa.usaで申請し、SANsにusausa.usaを登録すると、
１枚のサーバ証明書でwww.usausa.usaとusausa.usaの両方でhttps通信を有効にすることが出来ます。
SANsはワイルドカードとは異なり、SANsに登録すれば同一ドメイン名でなくてもSSLが有効になります。
→ベリサインでは2012年6月15日以降の申請からSANsフィールドを追加するそうです。

ただし、どちらも対応していないブラウザや携帯端末が多く、
その場合SSL通信が可能なのは申請したコモンネームのみになってしまいます。

お知らせがあります…

ついにこあくま、社会人になりました！！

今日から、アルバイトではなく社員としてdirectorzで働くことになりました。

directorzは主にサーバのホスティング事業とサーバ証明書(SSL)の取得代行サービスを行う会社です。

…というわけでみなさん！

directorzにサーバをください♪

昨日まではあまり実感もなかったのですが(約２年間directorzでアルバイトをしていたので…)、今日スーツを着た時、急に実感が湧いてちゃんと出来るかな…と不安でいっぱいです。

(こあくまブログも「女子大生」の部分をどうしよう？ですね笑)

今後、こあくまはdirectorzでサーバ証明書の取得代行のお仕事するので、こあくまブログではSSLを中心に勉強していることを更新していく予定です。よろしくお願いしますっ

株式会社リクルートさんが主催している今年で7回目のイベントです。

そして、今回のMashup Awardsで、なんと！小悪魔賞を作ってもらうことになりました！

Mashupとは混ぜ合わせるという意味で、

Web APIを２つ以上組み合わせて新しいアプリケーションを作ることを言います。

Web APIは、企業や個人がインターネット上に公開している何らかの機能を提供するサービスで、

大半が無償で公開されています。

地図のデータベースを提供したり、商品の検索結果を提供したり…さまざまなAPIがあります。

Mashupとは、２つ以上のAPIを混ぜ合わせて新しいサービスを提供するアプリケーションを作る…

Web APIの良いトコ取り…！な技術です。が！！！！

企業や個人がWeb APIを無償で提供し、思いつかないようなすごいサービスが他の人の手によって生まれ、

みんながそれを使ったら、Webの世界がもっと便利になっていく、Mashupにはそんなすばらしい利点があるのです！

では、実際にどんなMashup作品があるのか、Mashup Awardsの過去の受賞作品を見てみましょう！

2010年の最優秀賞をとったのは、

毎日の子供の成長が見やすいように整理されていて、

パソコンをあまり使えないおじいちゃんおばあちゃんに孫の成長を見せてあげられるしくみだったり、

他人には見られず見てほしい人にだけ見てもらえるようになっていたり…

娘Emiriちゃんの成長の記録のためにパパがつくったEmiri Systemという育児日記のサービスでした！

こあくま的に一番好きなのはMA5で優秀賞をとったTRAVATARです。

すれ違い通信によってキャラクターがiphoneの中を渡り歩いて旅をしていくアプリです。

キャラクターが勝手に渡り歩いていくのでどこまで行ったのかな？と見るのも楽しそうだし、

すれ違った人とちょっとしたコミュニケーションがとれたりするのもおもしろそう！と思いました＊

今回のMashup Awardsの作品募集期間は9月7日から11月7日までの２ヶ月間で、

Mashup Awardsのホームページにて作品を募集しています。

小悪魔賞にはもちろん！賞品があります！(賞品が何かはまだナイショですー＊)

最優秀賞を狙うのはもちろんですが、小悪魔賞を狙ったステキな作品の応募をお待ちしております！

アクセスコントロールとは、何らかの方法で許可させた利用者しか

利用できないようにすることでセキュリティを強化する仕組みです。

アクセスコントロールの方法として一番わかりやすいのはIDとパスワードですよね。

でもIDとパスワードを忘れちゃったり、第三者にIDとパスワードを盗まれちゃったり…

何よりめんどくさいですよね。

もう一つの方法はIPアドレスによるアクセスコントロールです。

特定のIPアドレスのみの利用を許可したり、拒否したりします。

でもこの方法だとIIPアドレスが一定ではない場合、例えば、携帯電話からのような場合利用できないので不便です。

そこで、クライアント証明書によるアクセスコントロールです！

証明方法はクライアント証明書をインストールしているかを確認されるだけなので

最初のインストールのみ行えば後はなにもしなくていいのでとても便利です！

IDやパスワードを打ったり、IPアドレスのしくみを理解するのって

普段あまりコンピュータを使わないひとには難しかったりしますよね。

１年前のこあくまはIPアドレスなんて知らなかったし、

むずかしい設定は全部他の人にやってもらったり…(今もですが笑)

なので、サイトでクライアント証明書でのアクセスコントロールすることを

サイトを構築するプログラマーの人が設定しておけば、

普段あまりコンピュータを使わない人でも教えてもらいつつクライアント証明書を一度インストールするだけで

サイトを見るのが簡単になるから良いのではないかなーと思いました。

スマートフォンでもクライアント証明書が使えます。

クライアント証明書も含めて、スマートフォンをリモート管理する方法が

ベリサインさんにはあり、MDMと言います。

たくさんの情報が入ったスマートフォンをなくしてしまっても、

リモート管理によって初期化したりできるので安心安全です！

＊追記＊

ベリサインさんからクライアント証明書について載っている書籍の紹介をしてもらいました。

翔泳社さんから出ている、SEのためのネットワークの基本 (SEの現場シリーズ)という本です！

こちらも要チェックです！

前回、サーバ証明書について勉強しました。

サーバ証明書は、サイトをつくっている企業が存在していること、

そのサイトが本物の企業がつくった本物のサイトである(フィッシングサイトではない)ことを証明する仕組みがあります。

クライアント証明書はサーバ証明書と技術的には同じ物です。(SSLの仕組みおさらいはココで)

では何が違うのか？それは証明する対象です。

クライアント証明書はサイトを作った企業ではなくサイトを見る個人が本物であることを証明します！

そのため、サイトを利用する個人のなりすましを防ぎ、

正しいクライアント証明書を持っていない人は、アクセスすることができません。

つまり、クライアント証明書はアクセスコントロールに便利です。

(アクセスコントロール…？続きます！)

アプリケーションに対する証明に使えるコードサイニング証明書というものもあります。

アプリケーションやファイルにデジタル署名した後、ウェブで公開したりCD-ROMで配布することで

配布元が正しい企業であることを保証、改ざんを防ぐことができるため、

ユーザにインストールの不安を回避させることのできる効果があります。

今回は、小悪魔女子大生のサーバエンジニア日記と日本ベリサイン株式会社さんがコラボ！

暗号化だけではないSSLサーバ証明書の役割や企業の実在性証明、フィッシングについて楽しく学びましょう。

来場者の方にはこあくま特製ノベルティーをプレゼントしちゃいます！

ノベルティーにはこのためにつくったNEWキャラクターも登場しているのでみなさんぜひ遊びにきてゲットしてくださいねー

そのページを見るユーザに安心感を与えるという役割がありました。

一般にSSLというと、暗号化をするためのものというイメージがありますが、

実在性証明をメインで使っているページもあります。

１つ目は、早稲田大学の合格発表のページ。

大学の合格発表は、受験者にとってとても大事な情報です。

そのため早稲田大学では、合格者の番号は確かに大学側が出したものであるという証明のために合格発表のページには実在性証明が使われています。

２つ目は東京証券取引所の適時開示です。

会社の出す情報は株価に影響を及ぼします。そのため、東京証券取引所が運営する適時開示のページには実在性証明が使われています。

３つ目はマーケティングデータを取り扱っている情報販売の富士経済のページです。

富士経済さんは、特定のページだけではなく、サイト全体にSSLをかけています。

これは情報の大事さを十分に理解している、マーケティングデータ屋さんならではの

情報発信者としての責任の持ち方だと思います。

実在する会社が運営する本物のページであるということを証明するのは、

相手が目に見えないインターネットという環境のなかでは、

公開する情報が大事なものであればあるほど情報発信者としては注意を払わなければならないことだと思います。

さて、ここで、もうひとつの「お金にかかわるページ」についてのお話です。

3月11日に、東日本で大地震が起き、被災地の支援のために日本中で義援金が集められていますよね。

インターネットでも義援金を受け付けている口座の情報を載せている支援サイトのページがたくさんあります。

しかし、ほとんどのサイトでSSLサーバ証明書は付けられていません。

支援サイトに便乗して、公的機関やどこかで聞いたことのあるような名前を使った義援金詐欺をはたらくサイトが増えています。

そのため、ベリサインさんでは、被災地支援の義援金を受け付けたり、震災情報や被災情報を提供するウェブサイトにSSLサーバ証明書を無償提供しているそうです。

口座番号を載せて義援金を募る企業のページはSSLサーバ証明書をかけ、そのページを見るユーザも証明書を確認すれば詐欺を少しでも減らせるのではないかな？と思いました。