2009年12月22日火曜日

ADFS2.0 RCリリース

12/18にリリースされていました。


アップデート内容ですが、"Geneva" Team Blogによると、下記の通りです。

・SAML 2.0 protocol support for Identity Provider Lite, Service Provider Lite and the eGov 1.5 Profile verified by Liberty Interoperable SAML 2.0 interoperability testing

以前お知らせしたようにLibertyのSAML2.0相互運用性にパスしています。

・Simplified user experience for configuring high availability federation server farm and proxy deployments

→冗長構成のフェデレーションサーバファームとProxyのデプロイが簡単に。

・Automatic encryption and signing certificate distribution and rollover across a farm of multiple federation servers, enabling zero touch management of trust relationships

→自動暗号化、証明書配布署名、複数のフェデレーションサーバから構成されるファーム間のロールオーバー、操作なしでの信頼関係構成

・Choice of deploying without SQL Server for storing AD FS 2.0 configuration data

→ADFS2.0の構成データストア用のSQL Serverなしでのデプロイが可能に

・Claims based authorization rules for restricting security token issuance

→制限されたセキュリティトークン発行の為のクレイムベース認可ルール

・Improved events, audits, and tracing for diagnostics

→診断のためのイベント、監査、トレースの増強

・Complete PowerShell support for end to end AD FS 2.0 management

→ADFS2.0の管理をするためのPowerShellの完全サポート

・Lots of other fixes and UI improvements!

→その他多数の修正とUIの改善


また、同時に以下のモジュールもリリースされています。
・Microsoft Federation Extensions for SharePoint 3.0 RC
・Windows CardSpace 2.0 Beta 2 Refresh

例によってVMイメージ(VHD)もあわせてダウンロード可能なので、環境をお持ちの方はそちらが手軽かも知れません。(私はHyper-V環境を持っていないのでゼロからの構築になりますが・・・)

2009年12月21日月曜日

安全なクラウド・コンピューティングの実現に向けたガイドライン

CSA(Cloud Security Alliance)が12/17にSecurity Guidance for Critical Areas of Focus in Cloud Computing V2.1をリリースしています。

ガイドラインによるとクラウドコンピューティングの定義は、
1)オンデマンドかつセルフサービス方式で利用されるようになっていること
2)ネットワーク経由でさまざまな場所からアクセスできること
3)共有コンピューティング・リソース・プールからリソースが提供されること
4)必要に応じて利用規模を迅速に拡大、縮小できること
5)何らかの方法で使用量が測定されること
だそうです。

また、クラウド環境におけるセキュリティを下記の13の領域(ドメイン)に分割してそれぞれに関する指針が提示されています。

1)Cloud Computing Architectural Framework
2)Governance and Enterprise Risk Management
3)Legal and Electronic Discovery
4)Compliance and Audit
5)Information Lifecycle Management
6)Portability and Interoperability
7)Traditional Security, Business Continuity, and Disaster Recovery
8)Data Center Operations
9)Incident Response, Notification, and Remediation
10)Application Security
11)Encryption and Key Management
12)Identity and Access Management
13)Virtualization


その中で12番目に来ている「アイデンティティ&アクセス管理」についてざくっと紹介しておきます。

ガイドラインによるとアイデンティティ&アクセス管理を以下の4つの主要な機能に分けています。
・アイデンティティプロビジョニング/デプロビジョニング
・認証(Authentication)
・連携(Federation)
・認可(Authorization)/ユーザプロファイル管理


資料ではそれぞれの機能領域について以下のように解説をしています。

◆アイデンティティプロビジョニング
クラウドコンピューティングサービスを採用する組織にとって主要なチャレンジのひとつはクラウドへのユーザのセキュアかつタイムリーなプロビジョニングとデプロビジョニングである。その上、企業内のユーザ管理プロセスに投資をしてきた企業はそれらのプロセスと経験をクラウドサービスに拡張/展開しようとするであろう。

◆認証(Authentication)
企業がクラウドサービスを活用し始める再、信頼でき、管理できる方法でのユーザ認証は重大な要求である。企業はクレデンシャル管理、マルチファクター認証等の強度の高い認証、委任された認証、すべての種類のクラウドサービスに渡る信頼の管理の様な認証に関連する取り組みを行う必要がある。

◆連携(Federation)
クラウドコンピューティング環境においてはアイデンティtフェデレーション(Federated Identity Management)は、企業がその企業が選択したアイデンティティプロバイダを使用してクラウドサービスのユーザ認証を行う上で、重大な役割を演じる。その中で、サービスプロバイダとアイデンティティプロバイダの間でID属性を安全な方法で交換することは重要な要求である。クラウド内でアイデンティティフェデレーションを考える企業は、サポートされる範囲において、アイデンティティライフサイクル管理や信頼性・完全性を守るあらゆる認証方式を兼ね備える様々なチャレンジやソリューションを理解すべきである。

◆認可/ユーザプロファイル管理
ユーザプロファイルとアクセスコントロールポリシーに対する要求は対象となるユーザがコンシューマの様に個人なのか、従業員や学校や医療機関など企業に所属しているのかによって様々である。SPI環境(※)におけるアクセスコントロールは、クラウドサービスへのアクセスをコントロールし、監査可能な方法で実行する為に使用するユーザプロファイルとポリシー情報の信頼関係を構築することを含む。

※SPI:以下の頭文字
 Software as a Service
 Platform as a Service
 Infrastructure as a Service


また、その上で各機能に対する推奨ポイントを以下のようにまとめています。

◆アイデンティティプロビジョニングに関する推奨
・クラウドプロバイダによって提供されるケイパビリティは現在の企業の要求には適切とは言えない。カスタマーは管理の複雑性を増大させるクラウドプロバイダに特化したカスタムコネクタを開発する様なプロプライエタリなソリューションを避けるべきである。
・カスタマーはクラウドプロバイダによって提供される実用的で(望ましくはSPMLスキーマに則った)標準的なコネクタを利用すべきである。もしクラウドプロバイダが現在SPMLに対応していないのであれば、対応するように要求すべきである。
・クラウドカスタマーは自身の信頼できるアイデンティティ情報レポジトリをクラウドのアプリケーションとプロセスに対応できるように修正もしくは拡張すべきである。

◆認証(Authentication)に関する推奨
クラウドプロバイダとカスタマ企業は両者ともクレデンシャル管理、強固な認証に関して適切にリスクを低減させる費用対効果の良いソリューションで実現させるべきである。

SaaSおよびPaaSプロバイダは彼らのアプリケーションやプラットフォームにアクセスする為のビルトインの認証サービスもしくは企業に認証を委任する為のサービスを提供している。カスタマへは認証方式について以下の選択肢が提供される。
・企業向けの認証。企業はユーザ認証をフェデレーションによってSaaSベンダと信頼関係が構築された企業自身のアイデンティティプロバイダを経由して実施する。
・個人ユーザ向けの認証。企業は複数のサイトにおいて単一のクレデンシャルセットの利用を可能にするGoogleやYahoo,OpenID、LiveIDなどのユーザセントリック認証を利用する。
・認証委任する為のプロプライエタリな方式を要求するSaaSプロバイダは継続する前に適切なセキュリティ検証がなされているかを徹底的に検証されるべきである。一般的にはオープンスタンダードを利用すべきである。

IaaSについては認証戦略は企業における既存環境を利用できる。
・IT要員については既存のシステムと手続きを利用できるので、VPNの確立が良いと思われる。
・いくつかのソリューションは企業ネットワークとのVPNトンネルを作成する、もしくは連携させることが可能である。VPNトンネルはSSOやLDAPベースの認証システムなど既存のアイデンティティ管理システムをアプリケーションが利用するような場合に有効である。
・VPNトンネルが使えないような場合はアプリケーションはSSLの様なネットワークの暗号化とともに様々なフォーマット(SAMLやWS-Federationなど)の認証アサーションに対応する様に設計されるべきである。このアプローチは企業に対し、企業内だけでなくクラウドについてもSSO連携(Federated SSO)が可能にする。
・OpenIDはアプリケーションが企業ユーザを超えて使われる場合における別の選択肢である。しかしながら、OpenIDのクレデンシャルのコントロールは企業の外部にあるので、そのようなユーザに対するアクセス権限は適切に制限されるべきである。
・クラウドプロバイダによって提供されるローカル認証サービスはOATHに準拠すべきである。OATHに準拠したソリューションであれば、企業は単一ベンダーの認証クレデンシャルに固定されることを避けることができる。
・(テクノロジーに関係なく)強固な認証を有効にするためにクラウドアプリケーションは企業にSAMLで認証を委任する機能をサポートすべきである。
・クラウドプロバイダはワンタイムパスワードやバイオメトリクス、デジタル証明書、ケルベロスなど様々な強固な認証オプションを提供することを考えるべきである。このことは企業に対して彼らの既存インフラの利用についての別の選択肢を提供する。

◆連携(Federation)に関する推奨
クラウドコンピューティング環境においてアイデンティティの連携は、連携した企業に認証、シングルサインオン、サービスプロバイダとアイデンティティプロバイダの間での属性交換を有効にする為の主要な要素である。クラウド内でアイデンティティフェデレーションを考える企業は、サポートされる範囲において、アイデンティティライフサイクル管理や信頼性・完全性を守るあらゆる認証方式を兼ね備える様々なチャレンジやソリューションを理解すべきである。
・クラウドプロバイダを探している企業はそのプロバイダが最低でも一つの標準(SAML、WS-Federation)をサポートしていることを確認すべきである。SAMLは主要なSaaS、PaaSクラウドプロバイダによって広くサポートされているフェデレーション標準である。複数の標準をサポートすることは柔軟性を増すことを可能にする。
・クラウドプロバイダは異なったアイデンティティプロバイダから標準フェデレーションフォーマットを受け入れる為の柔軟性を持つべきである。しかしながら現状の大多数のクラウドプロバイダは単一の標準(例えばSAML1.1やSAML2.0)だけをサポートしている。クラウドプロバイダには各種フェデレーションゲートウェイによって実装されることが考えられる複数のフェデレーショントークンをサポートすることが望まれる。
・組織は連携されたパブリックSSOと連携されたプライベートSSOの比較検討をすることを望むと考えられる。連携されたパブリックSSOはクラウドプロバイダとSAMLやWS-Federationの様な標準に基づき連携するが、一方で連携されたプライベートSSOはVPNを介して既存のSSOアーキテクチャを利用する。
・組織はトークンの発行と確認を管理するためにフェデレーションの実装を外部に出すためにフェデレーションゲートウェイを選択することを望むと考えられる。この方法を利用することで企業はフェデレーションゲートウェイに対して各種トークンの発行を委任することができる。そして、フェデレーションゲートウェイはトークンのフォーマットを変換することが可能である。

◆アクセスコントロールに関する推奨
クラウドサービスに関するアクセスコントロールソリューションの選択や妥当性のレビューは様々な側面を持ち、以下の考慮を伴なう。
・サービスやデータの種類に応じたアクセスコントロールモデルの適切さのレビュー
・ポリシーやユーザプロファイル情報の信頼できるソースを認識する
・データに対する必要なプライバシーポリシーへのアクセスサポート
・ポリシーとユーザ情報を特定する為のフォーマットの選択
・ポリシー管理ポイント(PAP)からポリシー決定ポイント(PDP)への伝搬ポリシーのためのメカニズムの決定

ポリシー情報ポイント(PIP)からポリシー決定ポイント(PDP)へのユーザ情報の伝搬に関するメカニズムの決定
・ポリシー決定ポイントからのポリシー決定の要求
・ポリシー強制ポイント(PEP)におけるポリシー決定の強制
・監査に必要なログ情報

◆IDaaSに関する推奨
Identity as a Service(IDaaS)はプライバシー、完全性、監査可能性についての追加の考慮をした上で、内部IAMの導入がそうしたようにベストプラクティスに従う必要がある。
・企業内ユーザにとって。管理者はクラウドプロバイダが提供するクラウドに安全にアクセスするために提供されるオプション、もしくは直接のVPN接続やSAML等の業界標準と強固な認証によるアクセスを比較レビューする必要がある。クラウドを使う事によるコスト削減は従業員情報が外部に保管されることに起因するプライバシー考慮に関するリスク緩和とバランスされる必要がある。
・パートナーなどの外部ユーザにとって。情報オーナーは彼らのSDLC※に脅威に対するアセスメントと同様にIAMの相互作用について盛り込む必要がある。アプリケーションセキュリティ(様々なコンポーネントの相互に作用、それらにより発生するSQLインジェクションやクロスサイトスクリプティングなど脆弱性)も同様に考慮され守られなければならない。
・PaaSカスタマーはどのIDaaSベンダがプロビジョニング、認証、アクセスコントロールポリシーに関する通信、情報監査について業界標準をサポートしているかの範囲を調査すべきである。
・プロプライエタリなソリューションはプロプライエタリなコンポーネントに対する透過性の欠如によりクラウドにおけるIAM環境に関して重大なリスクとなる。プロプライエタリなネットワークプロトコルや暗号化アルゴリズム、データ通信はしばしばセキュリティ低下や強固さの低下、相互運用性の低下をもたらす。外部化を行う上でIAMコンポーネントにオープンスタンダードを使うことは非常に重要なことである。
・IaaSカスタマーにとって。仮想サーバを起動する際に使用するサードパーティイメージはユーザとイメージ自身の信憑性について確認される必要がある。そのイメージに対して提供されるライフサイクル管理のサポートに関するレビューは社内ネットワークにインストールされるソフトウェアに対するのと同様の確認が必要である。

※SDLC:Software Development Life Cycle

2009年12月10日木曜日

FIM2010RC1 update2リリース

早くもupdate2がリリースされています。

今回からはMicrosoft Updateでのリリースになっており、現在カタログサイトからダウンロード可能です。








今回のリリースでは以下の領域に関する複数の更新を含んでいるとのことです。
•Sets
•Setup
•Codeless Provisioning
•Management Policy Rules
•Portal user interface
•Schema
•Self-service Password Reset
•Synchronization engine
•Workflow

また、update1までの不具合となっていたナビゲーションバーに出てくるリソースの数の不整合が今回のリリースで改修されたようです。
http://social.technet.microsoft.com/Forums/en/ilm2/thread/184bb2b7-b20a-4c8a-ab7d-d7098bd997ba

2009年12月3日木曜日

FIM2010のパフォーマンス その2

前回に引き続きパフォーマンスに関するネタです。
※前回同様に情報ソースはDarryl Russiさんのblogです。

今回は実際にパフォーマンステストを行った2種類のトポロジの紹介です。また、同時にどのようなハードウェアを使ったのかも紹介されています。
・トポロジ関連情報
http://blogs.msdn.com/darrylru/archive/2009/10/06/fim-2010-performance-testing-topology.aspx
・ハードウェア関連情報
http://blogs.msdn.com/darrylru/archive/2009/10/09/fim-2010-performance-testing-hardware.aspx

※製品チームがリリースに際して実際にテストを行っている環境(トポロジ、スペック)だそうです。マイクロソフトのIT部門のワークロードに対応するサイジングになっているということです。(あくまでテスト環境用のハードウェアですよ、、と断りはついていますが・・・つまりは冗長性についてはあんまり考慮してないってことです)

まず、テストに使ったハードウェアスペックですが、下記の2種類です。

コンポーネント標準機ハイスペック機
CPUCore2 Quad Q6600 2.4GHzXeon E5410(Quad Core) 2.33GHz x 2
メモリ4GB32GB
ディスクシングルドライブ136GB(10krpm) x 8
【内訳】
Cドライブ(OS/アプリケーション) x 1
Eドライブ(SQLログファイル) x 1
Fドライブ(SQLデータファイル) x 6(RAID0)



次にトポロジです。

■標準的なトポロジ
いわゆるシンプルな構成です。
・ポータル、FIM Service、FIM Service用DBの同居(ハイスペック機)
・FIM Synchronization Service+DB(ハイスペック機)
の2台構成









■NLBトポロジ
少々複雑な構成です。
・ポータル x2 (NLB)(標準機)
・FIM Service x 2 (NLB)(標準機)
・FIM Service用DB x 1(ハイスペック機)
・FIM Synchronization Service+DB x 1(ハイスペック機)
の6台構成



















現実にはハードウェアロードバランサーを使うケースや各DBをクラスタリングするケース、既存のMOSSの中にフロント(ポータル)を取り込む構成など色々あるとは思いますが、あくまでテストのスコープがFIM単体のパフォーマンスなのでこのような構成でテストをしているようです。

次回以降、これらの環境を使って各コンポーネントの実際のパフォーマンス測定を行った結果をご紹介します。