[MSA]同一メールアドレスでマイクロソフトアカウントとAzure ADアカウントを利用するリスク

こんにちは、富士榮です。

先日、職場または学校のアカウント（Azure Active Directory/Office365で管理されているアドレス）で新規にマイクロソフトアカウントをサインアップすることが出来なくなった、という話を紹介しました。

[MSA]職場または学校のアカウントで新規サインアップが不可に
http://idmlab.eidentity.jp/2016/09/msa.html


MPNやXBoxの開発関係など、まだAzure ADでのサインインをサポートしていないマイクロソフトのサービスが存在しているにも関わらず上記のような制限をかけたことについて、乱暴で性急な対応だ！という声も各国から上がっていますが、今回は逆にこれまでの様に複数のアカウントで識別子が共通になってしまっている状態だと何が起きえるのか？について考えてみたいと思います。

◆マイクロソフトアカウントでもAzure ADアカウントの両方でアクセスできるサービスを用意する

一番手っ取り早い方法として、Azure ADのOpenID Connectのv2 エンドポイントを使ったアプリケーションを開発してみます。

詳細は省くのとかなり手抜きなコードなので色々とツッコミどころはありますが、こんなコードを書きました。

◆アクセスする

v2 エンドポイントを使ったアプリケーションにアクセスし、ログインID（メールアドレス）を入力すると、ログイン用のIDをマイクロソフトアカウントとAzure ADアカウントから選択する画面が出てきます。

◆Azure ADのアカウントでログインする

まずは、Azure ADのアカウントでログインします。

職場または学校アカウントを選択すると、Azure ADのログイン画面へ遷移します。

結果、Azure ADからユーザ名をはじめとするID情報が取得できます。（id_tokenをほどいているだけですが）

preferred_usernameにログインIDが入っていることがわかります。

◆マイクロソフトアカウントでログインする

次にマイクロソフトアカウントでログインしてみます。
先ほどのID選択画面で個人のアカウントを選択すると、マイクロソフトアカウントのログイン画面へ遷移します。

結果、同じくID情報が取得できます。

同じくpreferred_usernameにログインIDが入ってきています。

◆何を注意すべきなのか？

上記の例では、どちらのアイデンティティ・プロバイダでログインしても同じ値がpreferred_usernameに入ってきてしまっています。この状態でユーザをpreferred_usernameで識別してしまうと便利な反面、セキュリティ面で問題があると言えます。個人でID登録できるマイクロソフトアカウントと管理者が登録・管理を行うAzure ADではIDの管理レベルが全く異なるからです。

上記のようなアプリケーションはB2BやB2Cのシナリオではそれほど珍しいものではありません。
アプリケーションが内部で自社のドメインのユーザからのアクセスならば管理メニューを出して、それ以外なら一般向けのメニューしか出さない、というようなロジックを書くこともあるためです。

通常は、自社ドメインのユーザは退職したら削除または無効化されログインできなくなるので、一見セキュリティ上問題はないように思われますが、退職前に自社ドメインのメールアドレスでマイクロソフトアカウントを作ってしまっていた場合、退職後も継続して管理メニューにアクセスできてしまうことになります。


今後は、マイクロソフトが新規にAzure ADやOffice365で使っているドメインのアカウントでマイクロソフトアカウントを作成することを禁止したので、すでにAzure ADやOffice365にドメインを追加している場合は、問題は減っていくとは思います。

ただ、
・現時点でAzure ADやOffice365に自社ドメインを追加していない
・すでに自社ドメインのアドレスでマイクロソフトアカウントを登録してしまっているユーザがいる
といった場合も多々あるはずなので、少なくとも「いくら信頼しているアイデンティティ・プロバイダとは言え、識別子だけで認可をすべきではない」ということを十分に認識してサービスの開発を行うべきだと言えるでしょう。

ちなみに、以前発生したOffice365のSAML SPの脆弱性も本質的には同じような問題に起因していましたね。

参考）
　Office365のSAML脆弱性に見るマルチテナントSP実装時の注意点
　http://idmlab.eidentity.jp/2016/05/office365samlsp.html

Tao of Attributes - 属性之道 於京都 に参加してきました

11/30 の Internet Week および 12/1 の OpenID Summit Tokyo に引き続き 12/2 は京都にて「Tao of Attributes - 属性之道 於京都」が開催されました。

私は OpenID Summit Tokyo と Tao～ に参加したのですが、 OpenID Summit 側にはプレスも入っていましたし、他にもまとめてくれている人がいる（これとかこれ）ので、今回は Tao～ について少し書いておきたいと思います。

といっても当日参加された方はご存じだとは思いますが、かなりカオスな感じ（良い意味で）で進んだワークショップだったのではっきり言って理解＆メモしきれていません。（全編英語でしたし）

まぁ一番の収穫？はこの分野で世界的にもトップを走っている方々でもまだまだ整理がしきれていないんだな、という妙な安心感？が得られたこと。。です。

アジェンダの順に徒然とメモを書いておきます。

Session 1 Tao of Attributes

1. Tao of Attributes / Ken Klingenstein, Internet2

　・ロールとは何か？
　　→属性、クレームをまとめたもの
　　→誰がまとめるのか。コミュニティ、会社、属性プロバイダ・・・など
　　→動的に変化するもの
　　→それっていわゆる「アイデンティティ」だよね？

　・メタデータの重要性
　　→相互フェデレーションを可能とする

　・メタデータの新しい要素
　　→LoA（Level of Assuranse）※前日の OpenID Summit でも属性単位の LoA の話が出ていた
　　→グラフィカルなアイコン
　　→サービス属性、、など
　　→ユーザの同意が必要

　・属性オーソリティ（発行元）のタイプ
　　・企業：従業員コードとか
　　・政府機関、自治体：パスポート番号とか
　　・一時的なもの：位置情報とか
　　・コミュニティ
　　　・フォーマル：バーチャルな組織
　　　・インフォーマル：うわさ
　　・自分自身：使用する言語とか

　・PII（Personal Identifiable Information）の分類（かっこないは例）
　　・個人を特定しない属性（ePSA）
　　・プライバシのために設計された間接的な識別子（ePTID）
　　・プライバシのために設計されていない間接的な識別子（IPアドレス）
　　・直接の識別子（名前、住所）
　　・メールアドレスとFAX番号
　　・位置情報（携帯電話）
　　・センシティブ情報（健康状態、人種、宗教）


2. Attribute Exchange within eduGain Members and Scheme / ValterNordh, eduGAIN

　・eduGain のサービスの紹介
　　・http://www.geant.net/service/edugain/pages/home.aspx
　　・フェデレーション間の接続サービス（インターフェデレーションサービス）
　　・ディスカバリサービス
　　・メタデータサービス（MDS）

　・メタデータのやり取りの方法
　　・フェデレーションからMDSへのメタデータの送付（アップストリーム）
　　・フェデレーションがMDSよりメタデータの取得（ダウンストリーム）

　・属性リリース問題
　　・IdP管理者はどの属性が他のフェデレーションへ渡されているのかを知る必要がある
　　　（eduGainではメタデータの中のスキーマで工夫）


3. Attribute Verification Methods / Kick Willemse, OpenID Foundation

　メモれず・・・
　属性の分類と必要に応じて対象の属性が保証されていることが必要、という話。
　（さすがに資料なしのチョークトーク、且つカオスな感じにはついていけず）


4. Good Practice in Japan: Credit Mutual Exchange in Kyoto eLearning Consortium / Toyokazu Akiyama and Koji Ozaki, Kyoto Sangyo University

　・eラーニングシステムをコンソーシアム参加大学の間で共有するために Shibboleth を導入した
　　・コンソーシアムには50の大学が参加
　　・生徒が自身で登録して利用するシステムだったため、各大学の事務局が各登録を確認していたが手間が大かった
　　・Shibboleth を導入して各大学の IdP と連携出来る様に。


5. Scope of SCOPE for OpenID Connect / Nat Sakimura, OpenID Foundation

　時間切れでスキップ



Session 2 Level of Assurance

6. GakuNin LoA Story / Hiroyuki Sato, University of Tokyo

　時間切れでスキップ


7. Challenge at Kyoto University / Yasuhiro Nagai, Kyoto University

　・LoA は「利用頻度 x セキュリティレベル」の2軸で考えている
　・各セキュリティレベルに応じて以下の認証レベルを導入している
　　Level 1 ) フェース to フェース の認証なし
　　Level 2 ) 静的パスワード＋ICカード
　　Level 3 ) 静的パスワード＋ICカード＋動的パスワード（ワンタイムパスワード）
　　Level 4 ) 静的パスワード＋ICカード＋電子証明書
　・電子証明書は学生証（Felica）に最初から入れてある


8. The University PKI Architecture in Japan and the LoA / Yasuo Okabe, Kyoto University

　・3つのレイヤーで PKI を構築／利用
　　・Open Domain PKI / SMIMEなど外部とのやり取りに利用
　　・Campus PKI / キャンパス内システムに利用
　　・Grid PKI / コンピューターグリッドに利用

　・UPKIの仕様は以下のURLより
　　https://upki-portal.nii.ac.jp/upkispecific/specific


9. Discussion

　時間切れ、というより各セッション内で。。。


10. Dinner

　がんこ
　絶景でした。山縣有朋の別邸だったそうです。

日本クラウドセキュリティアライアンス キックオフシンポジウムに参加してきました

といっても途中までしか聴けなかったのですが、以前紹介したCSA（Cloud Security Alliance）の日本支部のキックオフシンポジウムが開催されたので行ってきました。（大盛況でした）

国内においてもクラウドサービスプロバイダが増えてくるに当たり、CSAのガイダンスを適用・実装するための指針を出したり、国内市場特有のニーズに対応したり、ということを目的として今後活動していくということなのでクラウドサービスを提供するプロバイダも利用する企業やユーザにとっても目の離せない存在になるのではないでしょうか？

ちなみにそもそもこのCSAをはじめとするクラウドコンピューティングにおけるセキュリティのガイドラインは、良く「クラウド」の定義で引き合いに出されるNIST（アメリカ国立標準技術研究所）がクラウドの効果的で安全に利用についてレポートを出していたものの、実際にクラウドサービスを調達する際のセキュリティ上の要求事項が具体的にまとまらなかった、というところから整備が進んで来たものだったようです。

日本においては特に契約条項や品質に対する要求レベル、情報の取り扱いに関連する法規も当然米国とは異なりますので、このような団体によって地域にあったガイドライン化が進むと良いのでは、と思います。


アイデンティティ管理に関しては今日はISACAの顔をした下道さんが「クラウドコンピューティングとeID」というテーマで講演をしてくださいました。
印象に残ったのは、改めて「ID=アイデンティティ」ということを強調していた点です。これは何年も前からアイデンティティ管理界隈では話がされてきていることですが、今でもID=Identifier（識別子）という認識が根強いということでした。

本シンポジウムの内容から少し横道にそれますが、、、

「アイデンティティ」とは個人を特徴づけるものであり、単なる識別番号やメールアドレスなどといったものだけではなく、趣味や身体的特徴や宗教などといったその人を特徴づける属性情報を含んでいます。
そのような意味でアイデンティティとは個人の尊厳そのものとも言うことが出来、それは実世界であろうがデジタルワールドであろうが適切に取り扱われるべきである、という考えはそのあたりに起因しています。

そのような意味でアイデンティティ管理とは広義で言うと単なるプロビジョニングやシングルサインオンといった技術や運用に関することだけでなく、各国（日本、米国、EUなど）のそれぞれの個人情報保護に関連する法規と深く関連してきます。
特にクラウドをはじめとするインターネット上のサービスでアイデンティティ情報が適切に（関連法規に従い）扱われるかどうかは管理（コントロール）されるべきである、というところから色々な技術や製品などが着目／実装されてきています。

機能	関連技術等
サービス側から必要となる情報を要求する	クレイムベースのセキュリティモデル、InfoCard
必要最低限の情報のみを開示する	U-Prove
本人の同意を持って情報を開示する	ID-WSF、OpenID-CX

と、少しそれてしまいましたが、参加メンバを見ても今後の活動がとても楽しみです。


尚、他にも下道さんも監訳に参加されているオライリージャパンさんより「クラウドセキュリティ＆プライバシー」の日本語版が先行販売されていました。

その他関連リソース
・ASPIC Japan（ASP・SaaSインダストリ・コンソーシアム）によるCSAクラウド・セキュリティ・ガイダンス ver.1.0 日本語版
　http://www.aspicjapan.org/pdf/20100324-csa.pdf
・日本クラウドセキュリティアライアンス
　http://www.cloudsecurityalliance.jp/
・CSA Security Guidance for Critical Areas of Focus in Cloud Computing V2.1
　http://www.cloudsecurityalliance.org/csaguide.pdf
・CSA Guidance for Identity & Access Management V2.1
　http://www.cloudsecurityalliance.org/guidance/csaguide-dom12-v2.10.pdf
　※CSAガイダンスの中でアイデンティティ＆アクセス管理に関する部分に特化したもの

識別、認証、認可におけるIdMの役割

たまにはプロダクトの話ではなく、IdMそのものについて書いてみようと思います。

さて、この手のシステムをやっているとお客様を含めついつい混同されがちなのが、識別と認証と認可というキーワードだと思います。そのような混同があるのでIdMツールを入れればシングルサインオンまで含め全部何とかなる、といった勘違いが起きるのだと思います。

そこで、今回は識別、認証、認可といったキーワードの定義とIdMはそれらのキーワードに対して何をしてくれるものなのか？について整理をしてみようと思います。

まずはそれぞれの言葉の定義を見てみましょう。

識別：物事の相違を見分けること
認証：何らかの知識を元に対象の正当性を確認すること
認可：認めて許すこと

たとえば、グリム童話の「7匹の子ヤギ」に当てはめてみましょう。（コンセプトはサルでもわかるIdMの役割！です）

■識別
オオカミ：お母さんだよ。扉を開けておくれ。
　→識別情報「お母さん」を与えている
子ヤギ　：（ああお母さんか）
　→ドアの向こうの相手が「お母さん」という知っている対象を名乗っていると識別①

■認証（失敗の例Ⅰ）
子ヤギ　：（本当にお母さんかな？声がおかしいぞ）
　→名乗った名前（お母さん）と声（オオカミの声）という属性を使って正当性を確認
子ヤギ　：お母さんはそんな声じゃない。おまえはお母さんじゃない！
　→認証失敗②

■認証（失敗の例Ⅱ）
オオカミ：（チョークを食べて声を変えて再び）お母さんだよ。扉を開けておくれ。
　→識別情報「お母さん」を与えている
子ヤギ　：（ああお母さんか）
　→ドアの向こうの相手が「お母さん」という知っている対象を名乗っていると識別
　→ここまでは先ほどと同じ
子ヤギ　：（本当にお母さんかな？声はお母さんの声に似ているな。ん？扉から見える手が黒いぞ。おかしいぞ）
　→名乗った名前（お母さん）と手の色（オオカミの手）という属性を使って正当性を確認
子ヤギ　：お母さんの手はそんな色じゃない。おまえはお母さんじゃない！
　→認証失敗③

■認証（成功の例）
オオカミ：（手に白い粉を塗って）お母さんだよ。扉を開けておくれ。
　→識別情報「お母さん」を与えている
子ヤギ　：（ああお母さんか）
　→ドアの向こうの相手が「お母さん」という知っている対象を名乗っていると識別
子ヤギ　：（本当にお母さんかな？声はお母さんの声に似ているな。扉から見える手もお母さんの手に似ているな）
　→名乗った名前（お母さん）と手の色（白く塗ったオオカミの手）という属性を使って正当性を確認
子ヤギ　：（確かにお母さんだ）
　→認証成功④

■認可
子ヤギ　：（お母さんは家族だから扉を開けても良いな）お帰りなさい。（扉を開ける）
　→認可⑤


整理すると、
①で対象が与えた情報を元に子ヤギは対象を識別します。
ここで最初から「田中です」と言っても「誰やねん」という話になり子ヤギからは識別されませんので次のフェーズ（認証）へは物事は進みません。

次に②で子ヤギは対象が与えた情報（声）を元に本当に対象があらかじめ与えた識別情報と合致しているかどうかの正当性の検証を行います。
ここでは「声」が子ヤギの知っている「お母さん」のものとは異なるので認証失敗です。

同様に③では、「声」に加えて対象が与えた情報（手の色）を元に正当性の検証を行います。
ここでも「手の色」が子ヤギの知っている「お母さん」のものとは異なるので認証失敗です。
ちなみに何故チョークを食べると声が優しくなるのかは不明です。。

続いて、④では対象が与えた「声」と「手の色」の両方が子ヤギの知っている「お母さん」のものと同じであることから子ヤギは対象の正当性を認めます。つまりやっと認証成功です。
いわゆる2要素認証ですね。

最後に、対象が正当に「お母さん」であることが確認されたので、「お母さん」の持つ属性（家族）を見てあらかじめ定義された行為（家に入ること）を許可します。
これが新聞屋だったら例え正当性が確認できても家に入れる、ということはしなかったでしょう。（つまり家族ではないので家に入ることは許可されない）


ちょっと回りくどかったと思いますが、上記が識別、認証、認可の定義です。
さて、やっとIdMの話です。

IdM（狭義のIdM=provisioning/synchronizationを中心としたもの）の役割は、
・管理対象レポジトリのエントリの追加／削除
・管理対象エントリ属性の変更
であると言うことができます。
ここにワークフローやセルフサービスが入ってきたとしてもそれはあくまでプロビジョニングの条件設定や属性変更の一手段にすぎません。

上記の童話に当てはめてみると、
・管理対象レポジトリ　　→　子ヤギの脳
・エントリ　　　　　　　→　知識（お母さんは知っている。田中さんは知らない）
・管理対象エントリ属性　→　お母さんの声は優しい。お母さんの手は白い。お母さんは家族だ。
となります。（なんかグロいですね・・・）

IdMは子ヤギが識別したり認証したり認可をしたりするために必要な情報の提供をしているだけで、実際に識別や認証や認可をしているのは子ヤギそのものなんです。
ですから、IdMシステムの定義をする際は、対象システムがどんな情報をベースに識別し認証し認可するのか、という情報の洗い出しを厳密に行うことが非常に大切です。

この例をベースに考えると、子ヤギ（システム）は、
・名前（お母さん）を識別機能に使う
・声と手の色を認証機能に使う
・続柄（家族）を認可機能に使う
という洗い出しをあらかじめしておいて、IdMシステムに対しては
・名前
・声
・手の色
・続柄
という4つの属性を子ヤギの脳（対象レポジトリ）の中で正しい状態に保つ、ということが求められる機能だ、という定義を行います。


実際は認証連携やシングルサインオンなど、他のシステムが認めたオブジェクトに対して認可を行ったりすることもあり機能の分割がややこしいのですが、よ～く考えると上記の機能分解ができるはずなので、じっくり考えてIdMで管理が必要な属性と同期先となるレポジトリの定義を整理して行きましょう。