IPA 情報セキュリティ白書2009 10大脅威 攻撃手法の『多様化』が進む

3/24に公開されていますね。
http://www.ipa.go.jp/security/vuln/documents/10threats2009.pdf

利用者への脅威の4位に「ユーザIDとパスワードの使い回しによる危険性」が挙げられていますが、どちらかというとサービスプロバイダ側の脆弱性に起因してユーザIDとパスワードが漏洩すると、同じユーザが他のサービスで同じパスワードを使っている可能性が高いから不正利用されちゃいますよ、という話でした。

このあたりを含めてアイデンティティプロバイダを切り離しておく、というのもサービスプロバイダにとって有効な考え方かも知れません。
どちらかというとアイデンティティ情報をセキュアに管理する、とか認証機能を強固にする、といったことはサービスプロバイダにとっては本来注力すべき領域ではないはずですし。

後は、サービスプロバイダが本当の意味でアイデンティティプロバイダを「信頼する」ためのフレームワーク（技術的にも、ビジネス上も）が必要になるんだと思います。漏洩時の責任分解とか賠償関連の取り決めとか。
そのあたりOpenIDのPAPEやLibertyのIAFとかの技術仕様に加えてちゃんと決めないと、本当の意味で普及は難しいんだと思います。

しかしこの情報セキュリティ白書、毎年の10大脅威を発表してきていますが、年々技術的要素が薄くなってきています。それだけ手口がソーシャルなものも含めて複雑化してきているんでしょうね。
見直してみると2004年はプロトコルの脆弱性の話やIEの脆弱性の話などで埋め尽くされてました。。。

UnboundID Directory Server

元SunのDirectory/Identity関係の人たちがスピンアウトして2007年に設立した会社「UnboundID」のプロダクトです。

「UnboundID Directory Services 2.0」というキーワードで、大規模ユーザを抱えるコンシューマ向けサービスプロバイダ向けの次世代アイデンティティ管理を実現を目指すそうです。
昨今のビジネスは大規模化、かつ分散されたWebサービスをベースに展開されており、ユーザの資格情報やアクセス権限などのアイデンティティ管理が重要性を増していて、サービスプロバイダからのアイデンティティプロバイダへのアクセス規模も同時に増大している、ということでこの会社では、
・高性能
・セキュア
・高い柔軟性
というキーワードで製品を提供することを目指すそうです。

実際のプロダクトとしてはOpenDSをベースにチューニングしたもので、何十億ものエントリの管理、何百万のリクエストへのレスポンスに対応できるそうです。

何よりも面白いなと思ったのは、そのスケーラビリティを維持するための仕組みです。
通常LDAPサーバを水平展開する場合って、
・マスタ⇒レプリカ（シングルマスタ）
・マスタ⇔マスタ（マルチマスタ）
のような構成をとります。

当然、大規模環境ではマルチマスタ構成が必要になってくるのですが、その場合書き込みトランザクションの衝突回避の仕組みが必要になります。
ActiveDirectoryでは一部機能（FSMO）をシングルマスタにすることで整合性を保つようになっていますが、この製品はRDBMSと同じようなトランザクション管理の仕組み（begin/commit/rollback）を取り入れています。
他にもRDBMSの特徴を取り込んでおり、triggerが使えたりするそうです。

LDAPクライアント側への工夫も必要になりそうですが、なかなか面白そうなので機会があれば触ってみたい製品です。

ILM"2" リリース延期！

ここしばらく噂はありましたが・・・

現在LAS VEGASで開かれているTEC2009で正式に発表があった模様です。

最新のスケジュールだと、
・2009年Q3 RC1リリース
・2010年Q1 RTM
ということです。

今のところ、理由は「更なるテストと、ウォークスルーシナリオが必要」ということだそうですが、本当は別の理由があるのでは・・・

IBM、Sunを買収へ？

ちまた（と言っても狭い業界ではありますが）では結構話題になっていますね。

ハードウェアやOS、JavaやDBの話は色々な憶測を含め話題にのぼっていますが、IdMやSSO関連はどうなるんでしょうね。

Sun主導のSAML LibertyとMS/IBM主導のws-federationがうまく融合するような話になるのかな？

第4回Liberty Alliance技術セミナー

先週3/6（金）に開催された第4回Liberty Alliance技術セミナーの資料が公開されています。
http://wiki.projectliberty.org/index.php/JapanSIG/Seminars/TechSeminar

残念ながら参加はできなかったので、早速資料をチェックしてみました。

・SAML2.0の仕様詳細とデモ実演

　SAMLって何？というところから、ProfileやBinding、Assertion、Protocolの定義内容などがわかりやすく解説されています。
　日本語の資料であまりわかりやすい資料がないので、貴重です。

・SAML2.0とOpenIDの相互運用デモ

　SAML、OpenID、CardSpaceの相互運用の取り組み、Concordia Projectの紹介などのオーバービューから具体的なデモシナリオ、デモ実演という流れです。デモが見たかったです・・・。


最近この手の相互運用のネタが結構流行っていますが、まだSAMLやOpenIDなどのキーワードが浸透しきっていないせいか、「相互運用」の意味が理解しづらいものとなっているのでは？と感じています。
Libertyなどで話題に上っている「相互運用」はあくまで利用者の視点でSAML対応のIdPで認証されたユーザがシームレスにOpenID対応のRPのサービスを利用できる、ということを指しています。（SUICAとICOCAの相互運用とイメージ的には近いかも知れません）

ただ、それぞれのキーワードの定義をものすごく乱暴に解説すると、
・SAML：認証の仕組みではなく、認証情報の連携や属性交換の仕組み。認証状態（認証されたIdP情報）や属性をXMLベースのAssertionで受け渡す
・OpenID：認証の仕組みではなく、認証情報の連携や属性交換の仕組み。IdP（OP）のURI自体がIDとなっている
・CardSpace：InfoCardというメタファを利用して認証プロバイダをユーザ自身に選択させる仕組み
となります。
こうやってみると、SAMLとOpenIDやCardSpaceを同列に並べてしまうことにちょっと違和感を感じてしまいます。

全体的に言葉遊びになってしまいがちですが、うまくマッチする日本語がないのが最大の原因なのかも知れませんね。

ILM"2"のワークフロー概要その２

前回書いたとおり、実際に承認フローを作成してみたいと思います。

例として、以下のような承認フローを作ります。

設定項目	設定値
要求元	ILM”2”ユーザ（システムユーザを除く）
要求操作	要求元の属性の変更操作
操作対象	要求元のOfficePhone属性
承認者	要求元のmanager属性に設定されているユーザ

設定作業の流れは以下の通りです。
１．Authorization Flowの定義
２．Management Policy Rule（MPR）の定義
３．定義した承認フローのテスト


詳細な手順は以下の通りです。（ILM"2"管理者で実行します）

１．Authorization Flowの定義
　①AdministrationメニューよりWorkflowsを選択します




















　②Newをクリックして新しいワークフローを作成します













　③ワークフロー名、説明、タイプの設定を行います
　　今回は、以下の値を設定しました。

設定項目	設定値
Workflow Name	Manager_Approval
Description	マネージャによる承認フロー
Workflow Type	Authorization

　④アクティビティを追加します
　　今回は承認フローなので、Approvalを選択しSelectボタンをクリックします。



















　⑤アクティビティの設定を行います
　　今回は以下の設定を行います。

設定項目	設定値
Approvers	[//Requestor/Manager]　※要求元のManager属性
Approval Threshold	1（初期値）
Duration	7（初期値）
Escalated Approvers	ilm2admin
Email Templates	（初期値）

　⑥設定を保存します














２．MPRの定義
　①AdministrationメニューよりManagement Policiesを選択します




















　②Newをクリックして新しいMPRを作成します














　③MPR名、説明、権限の設定を行います
　　今回は、以下の値を設定しました。

設定項目	設定値
Display Name	Change_Attribute_OfficePhone
Description	OfficePhone属性の変更
Permissions	未チェック（初期値）

　④要求元と要求操作の設定を行います
　　今回は、以下の値を設定しました。

設定項目	設定値
Requestors	[SET]NonSystemUsers
Operations	Modify resource attributes

ちなみにRequestorに設定したSETはシステムユーザ以外を指定するために以下のDynamic Membership設定を行っています。














　⑤ターゲットリソース（前後）および対象の属性の設定を行います















　　対象属性は本のマークをクリックすると検索することができます。




































　⑥適用するワークフローを設定します
　　ここでは、先ほど作成したAuthorization FlowのManager_Approvalを設定します。
















　⑦設定を保存します













　　以上でワークフローおよびMPRの定義は完了です。


３．定義した承認フローのテスト
　テストに使用するユーザおよび属性は以下の通りです。

属性	値	変更後属性
Display Name	一郎 鈴木	-
Account Name	e0001	-
Manager	ilm2admin	-
Office Phone	03-1234-5678	06-9876-5432

　①テストユーザ（e0001）でILM"2" Portalへログインします














　②My ProfileメニューよりOffice Phone属性を変更します
　　【変更前】













　　【変更後】












　③変更を保存します














　④承認待ちステータスになったことが表示されます













　⑤再度My Profileを確認するとOffice Phone属性が更新されていないことが確認できます













　⑥Manage My Requestメニューより承認要求が作成されていることが確認できます













　⑦承認ユーザ（ilm2admin）でILM"2" Portalにログオンし、Approve Requestメニューを表示します












　⑧承認要求を選択し、Approveをクリックして承認を行います




























　⑨テストユーザ（e0001）でILM"2" Portalへログインし、Office Phone属性を確認すると変更されています

ILM"2"のワークフロー概要

しばらく間が空いてしまいましたが、今回はILM"2"のワークフロー機能をひも解いて見ようと思います。

■ILM"2"の中のワークフロー機能の位置づけ

ILM"2"の中のワークフロー機能の位置づけは
・ILM Web Serviceの構成要素の一つ
・Management Policy Rule(MPR)が実行される際のプロセスの一つ
です。

















■動作の概要

ILM Web Serviceへの要求（属性の更新など）があると、あらかじめ定義されたMPRに基づいて要求は処理されます。
MPRは、要求（要求元、操作）と操作対象（対象となるリソース／SET、対象の属性）、実行されるフローの組み合わせで定義され、ILM Web Serviceへの要求がMPRに定義された要求と操作対象にマッチするとフローとILMSDBへの要求操作（CRUD）が実行されます。











■定義可能なフローの種類
ILM"2"では以下の3種類のフローを定義することができます。

種別	説明
Authentication	要求元を認証するために利用する（通常のパスワードで認証できないような状況／パスワードリマインドなどに利用）
Authorization	要求の実行条件を満たすか確認するために利用する（承認フロー、操作対象の属性が適切かどうかの検査など）
Action	ILMSDBへの操作完了後のアクションを定義する（通知する、OSRを使ってプロビジョニングを行うなど）

■フロー種別詳細
各フローには実行する動作（アクティビティ）を定義します。
・Authenticationフロー
Authenticationフローでは以下の2種類のアクティビティを利用することができます。

アクティビティ	説明
Lockout Gate	Authenticationフローのロックアウトを行うために利用する
QA Gate	質問への回答で要求者を認証を行うために利用する

　また、各アクティビティにはそれぞれ詳細な設定を行うことができます。

アクティビティ	設定項目	初期値
Lockout Gate	ロックアウト閾値に達した後、ロックアウトされる期間（分）	15
	ロックアウト閾値（Authenticationフローで失敗できる回数）	3
	恒久的にロックアウトされるまでにロックアウト閾値に達して良い回数	3
QA Gate	トータルの質問の数	3
	事前登録時に表示される質問の数	3
	事前登録しなければならない質問の数	3
	ランダムに表示される質問の数	3
	正解しなければならない質問の数	3
	実際の質問	-

・Authorizationフロー
Authorizationフローでは以下の2種類のアクティビティを利用することができます。

アクティビティ	説明
Approval	承認フローを定義するために利用する
Filter Validation	操作対象の属性が適切かどうかをあらかじめ定義したフィルタを利用して確認する
Function Evaluator	フロー内で利用する関数を定義する
Group Validation	ILM”2”のデフォルトのグループへの適合しているかを確認する
Notification	特定の宛先へ通知を行う

　また、各アクティビティにはそれぞれ詳細な設定を行うことができます。

アクティビティ	設定項目	初期値
Approval	承認者（ILMSDB上のユーザ／グループを静的に設定、もしくは要求者の属性などから動的に取得して設定）	-
	承認者の数	1
	エスカレーションタイムアウトまでの期間（日）	7
	メールテンプレート ・承認待ち（承認者へ送付） ・ 承認待ちのエスカレーション（承認者へ送付） ・ 承認完了（承認者へ送付） ・ 否認（要求者へ送付） ・ 要求のタイムアウト（要求者へ送付）	-
Filter Validation	フィルタ対象属性を含むFilterScopeオブジェクト	-
Function Evaluator	アクティビティ名	-
	本関数を実行した結果の値をストアする対象のオブジェクトと属性	-
	値として設定する属性名	-
Group Validation	ILM”2”のグループ管理でサポートされるプロパティを設定するかどうかを検証する（非サポートのプロパティを設定した場合はこのアクティビティは失敗する）	-
	ActiveDirectoryのグループ管理でサポートされるプロパティを設定するかどうかを検証する（非サポートのプロパティを設定した場合はこのアクティビティは失敗する）	-
	マルチフォレスト環境におけるActiveDirectoryのグループ管理でサポートされるプロパティを設定するかどうかを検証する（非サポートのプロパティを設定した場合はこのアクティビティは失敗する）	-
Notification	受信者（ILMSDB上のユーザ／グループを静的に設定、もしくは要求者の属性などから動的に取得して設定）	-
	メールテンプレート	-

・Actionフロー
Actionフローでは以下の4種類のアクティビティを利用することができます。

アクティビティ	説明
Function Evaluator	フロー内で利用する関数を定義する
Notification	特定の宛先へ通知を行う
Password Reset Activity	ランダムパスワードの生成とリセットを行う
Synchronization Rule Activity	あらかじめ定義したSynchronization Ruleを実行する（プロビジョニング／デプロビジョニング／属性毎に動作を変更）

　また、各アクティビティにはそれぞれ詳細な設定を行うことができます。

アクティビティ	設定項目	初期値
Function Evaluator	アクティビティ名	-
	本関数を実行した結果の値をストアする対象のオブジェクトと属性	-
	値として設定する属性名	-
Notification	受信者（ILMSDB上のユーザ／グループを静的に設定、もしくは要求者の属性などから動的に取得して設定）	-
	メールテンプレート	-
Password Reset Activity	生成するパスワードの文字列長	10
Synchronization Rule Activity	実行するSynchronization Rule	-
	Synchronization Ruleの対象の中で実行するアクション（プロビジョニング／デプロビジョニング／属性毎に動作を変更）	-

次回は実際に承認フローを設定する手順を解説したいと思います。