★☆★JNSAメールマガジン 第30号 2014.3.7.☆★☆
JNSAメールマガジン 第30号 をお届けします。
こんにちは JNSAメールマガジン 第30号 をお届けします。
立春を過ぎると一雨ごとに暖かくなると言われていますが、相変わらず寒さが厳しくコートが手離せない毎日が続きます。春の暖かさが待ち遠しい今日この頃です。
さて、前回に引き続き、読者の方に「認証」について理解を深めて頂くためのコラムの２回目となります。前回のコラムをご覧になっていない方は、こちらで過去のコラムを順次公開していますので、ぜひご覧下さい。
https://www.jnsa.org/aboutus/ml.html
今回は、JNSA幹事でアルテア・セキュリティ・コンサルティング代表二木真明様から「認証とフェデレーション」というテーマで寄稿いただきました。
初回は「認証」の中でも特にサーバ側の問題に焦点を当てた内容で、HASHコンサルティング株式会社徳丸浩様から寄稿いただきました。
「認証とフェデレーション」
（JNSA幹事 アルテア・セキュリティ・コンサルティング代表 二木 真明）
フェデレーションという言葉は聞き慣れないかもしれません。認証の領域では、異なる認証システム（や、その主体となる組織）の間で、信頼関係を構築し、互いのIDをそれぞれの認証に基づき、相互乗り入れするような場合に使われます。これにより、たとえば、他の組織のシステムに対し、自社のIDを使ってログインするということが可能になり、組織を越えた「シングル・サインオン」が可能になります。
よく、シングルサインオンは便利だが、一度破られると全システムが危険にさらされるので好ましくない、というような議論を耳にします。昨今、IDとパスワードの使い回しによる問題が顕在化する中でクローズアップされがちな意見ですが、正しい反面、いささか一面的な感じがします。たとえば、認証の強固さという面から見ると、複数のサービスに対してそれぞれの認証システムを強固なものにするにはコストがかかりますし、管理の手間もかかります。一方、シングル・サインオンでは、その核となる認証システムに対して十分な強度を与えることで、安全を担保できます。たとえば、スマートカードなどを使って行われる強固な認証を用いれば、（セッション管理などが脆弱でない限り）すべてのシステムの入口の安全を担保できます。これを各システムごとに行おうとすれば大変です。
もちろん破られた場合のリスクは格段に高まりますから、認証の強度は最も重要度が高いサービスが要求するレベルに合わせる必要があります。市販のシステムでは、承認（Authorization）の機能と組み合わせて、そのユーザが使っている認証方式の強度に応じて、アクセス先を制限できるような機能も提供されます。たとえば、グループ会社や取引先間でIDの相互乗り入れを許すようなケースでは、相手先やその認証方式に応じて、アクセス制限をかけるのが一般的です。
クラウド時代の今日、業務の一部をクラウド上のサービスを使って行うようなケースも増えています。しかし、多くの場合、クラウド事業者が提供するサービス認証はパスワード認証を基本としており、その強度はユーザ側のパスワード管理に大きく依存します。ここで役に立つのがフェデレーションの機能です。Webベースのサービスでは、SAMLと呼ばれるデータ交換方式を使用した認証連携が多用されます。SAML方式では、認証やID管理機能を提供するIdP（アイデンティティ・プロバイダ）とSP（サービス・プロバイダ）という主要な二つの役割（これ以外にも、様々な属性情報を提供するアトリビュート・プロバイダなども定義されています）をそれぞれ異なる事業者が担えます。SP側はアクセス要求があると利用者がIdPによる認証を受けているかどうかを確認し、認証されていなければ、IdPにリダイレクトして認証を受けさせます。IdPは認証が成功するとアサーションと呼ばれる電子署名されたデータを利用者経由でSPに送り返します。SP側は、あらかじめ持っているIdPの証明書を使用して署名を検証し、認証が行われたことを確認してアクセスを許可します。この方式を使用することで、自社の認証システムでクラウドサービスの認証を行ったり、複数のクラウドサービスに対して、強固な認証を提供する事業者が発行するIDを利用してアクセスすることが可能となります。実際、サービスとしてこうしたID管理と認証機能のみを提供する事業者はいくつも存在します。自社IDと連携させない場合は、こうした事業者を利用することで、クラウド上のサービスの認証強度を大幅に高めることができます。
クラウド、とりわけアプリケーションレベルのサービスを提供するSaaSでは、利用者がWebブラウザを使用して直接使うだけではなく、APIと呼ばれるシステム間インターフェイスを利用して、複数のサービスや自社システムを直接連携させるような使い方もよく行われます。このようなAPI連携の場合のフェデレーションをWebブラウザを必要とするSAML方式で行うのは困難です。このような場合、一般にOAuthと呼ばれる連携方式が使用されます。OAuthを使用することで、SAMLを使って行われるのと同様の認証連携をシステム間で行うことができます。
様々なインターネット上のサービスで、IDの相互乗り入れを実現しようという動きがOpenIDです。すでに、SNSやメールサービスなど様々なクラウド上のサービスでOpenIDがサポートされており、IDの相互乗り入れが出来るようになっています。このOpenIDによる連携はAPI間連携も包含していて、その実装にはOAuthの発展型である、OpenID Connectという方式が使われます。たとえば、個人による利用であれば、最も認証強度が高いと思われるサービスのIDを使用して、他のサービスを使うことで、全体の認証強度を上げることができます。ただ、こうした事業者が提供するIDを使用する場合、リスクもあります。昨今、事業者のサイトが侵入され、利用者のIDやパスワードが抜き取られる事件が頻発しています。もし、自分が認証を委ねている事業者でこのような事件が発生した場合、他のサービスも危険にさらされる可能性があります。一方、こうした事態が発覚した際に、その事業者でのパスワードや認証方式を変更するだけで、全てのサービスへの対応が完了するという利点もあります。
現在、SAML, OpenIDといった方式が主流になっており、様々なサービスや製品がこれらに対応しはじめています。しかし、依然として、特にオンプレミス（自社保有）の認証システムの問題から、こうしたフェデレーションが難しいケースも散見されます。独自のシステムであったり、使っているソフトウエアが古いため、こうしたフェデレーションに対応が難しいといった問題です。もちろん、システムを更新してこうした課題を解決するのが最も良いアプローチですが、一方で、
様々な理由からこうしたことが難しい場合もあるでしょう。こうした古い、もしくは互換性のないシステムとオープンなフェデレーション方式の間をとりもつような製品やサービスもいくつか見られます。過渡期にはこのようなサービスを使用するのもひとつの方法です。また、技術変化の早さを考えると、こうしたシステムを恒久的に利用して、新たな方式に対応させるコストを下げるという方法もありかもしれません。
クラウド時代の今日、認証やID管理におけるフェデレーションの重要性はますます高まっていくと考えられます。安全性を利便性をうまく共存させるために、こうした仕組みをうまく使っていく必要があるでしょう。
＃連載リレーコラム、ここまで
＜お断り＞本稿の内容は著者の個人的見解であり、所属企業及びその業務と関係するものではありません。
★西日本支部主催セミナー「NSF 2014 in Kansai」は盛況のうちに終了しました。多数のご来場ありがとうございました。
講演資料を掲載しましたのでぜひご覧ください。
https://www.jnsa.org/seminar/nsf/2014kansai/
★PKI相互運用技術WG・電子署名WG主催セミナー「PKI Day 2014」の申込み受付中です。
「PKI Day 2014」
https://www.jnsa.org/seminar/pki-day/2014/
＜日 時＞ 2014年3月13日（木）10時00分〜18時00分
＜場 所＞ IIJグループ本社 17階大会議室
（千代田区神田神保町1-105 神保町三井ビルディング）
＜申込み＞ 下記申込みフォームよりお願いします。
※終了しました。
【事務局からの連絡、お知らせ】
★JNSA拡大幹事会を開催します。
＜日程＞ 2014年3月20（木）〜3月21日（金）
＜場所＞ 千葉県「鴨川ヒルズリゾートホテル」（千葉県鴨川市天津3164-7）
http://www.kamogawahills.com/index.html
参加希望の方は事務局（sec@jnsa.org）までご連絡ください。
★せきゅり亭3月のお題は「ウイルス」「もも」です。
ウイットに富んだ投稿をお待ちしております！
https://www.jnsa.org/update/senryu.html
☆コラムに関するご意見、お問い合わせ等はJNSA事務局までお願いします。
*************************************
JNSAメールマガジン 第30号
発信日：2014年3月7日
発行： JNSA事務局
*************************************
