2015年6月28日日曜日

[MIM]特権アカウント管理機能の概要

リリース目前のMicrosoft Identity Manager(MIM)ですが、なんといっても目玉機能は特権アカウント管理機能(Privileged Access Management / PAM)です。

以前のポストでどのような動きになるのか動画を紹介しましたが、今回は具体的な中身についてみていきたいと思います。

 参考)[MIM]特権アクセス管理のデモ動画
 http://idmlab.eidentity.jp/2015/04/mim.html


◆PAMで何ができるのか?

 現段階のリリース予定では、「Active Directoryの特権アカウントの管理」が可能になります。
 当然これまでもセキュリティ・グループへの追加・変更・削除は出来ましたが、
  ・時間制限付きのメンバシップの管理
  ・申請~承認のフロー
  ・多要素認証の要求
  ・履歴管理
 といった、実際に特権アカウントを管理する上で必要な機能をパッケージ化しています。


◆どのように実現しているのか?

 キーとなるのは以下です。
 ・片方向の信頼関係
 ・シャドーグループによるSID-Historyによる特権の紐づけ

 簡単に図示したのが以下の図です。


 通常、ドメインの移行をする際にリソースへのアクセスを維持するために使用するSID-Historyを使って、業務用ドメインの保護対象リソースへアクセスできるセキュリティ・グループと特権管理ドメイン上に作成した特権ロールの紐づけを実現します。
 このことにより、MIMが特権ロールのメンバシップを更新することにより実際には業務ドメイン上のグループに所属していないユーザでも一時的に保護対象リソースへアクセスすることが可能になります。

 MIMのPAM機能のロール管理は以下のような構造になっています。



◆どのように動くのか?

1.特権を付与する前の保護対象リソースへのアクセス

 今回は単純に共有フォルダへのアクセスをさせてみます。
 特権付与前の状態だと「アクセスが拒否」されます。


2.特権申請をする

 今回はMIMにサンプルで付属している特権管理ポータルを使い、ロールの利用を申請します。
 (REST APIを直接たたいて申請する方法もありますし、申請用のアドオン、PowerShellのコマンドレットが付属しています)
 単純にロール名を選択して[Elevate]をクリックします。


 すると要求の詳細(申請理由と期限)が入力できるので必要であれば入力してSubmitします。


3.申請を承認する

 今度は管理者で特権管理ポータルへログインし、承認を行います。
 誰から、何のために、どのくらいの期限で、という申請情報が来ているので[Approve]をクリックして承認を行います。


4.再び保護対象リソースへのアクセス

 特権申請をしたユーザで新しいセッションを開始して、自身が所属しているグループを確認すると、特権ドメイン上の特権グループおよび業務ドメイン上のグループのメンバになっていることがわかります。

 また、この状態であれば当然、共有フォルダへのアクセスが可能となっています。


 ※今回共有フォルダへのアクセスを例にしたため、PCログインのセッションが残っているので、セッションを切り替えるためにrunas等で新たに特権申請したユーザでのセッションを作成しなおす必要がありましたが、Webリソースなど都度ログインするようなアプリケーションであれば、都度権限チェックがなされるため本当に期間限定でリソースへのアクセスができるように見えます。

5.申請期限後に再び保護対象リソースへのアクセス

 申請した有効期限が過ぎてから再度リソースへアクセスすると最初と同じくアクセスが拒否されます。また、メンバとなっているグループを見ると特権グループから外れていることがわかります。



 ちなみにMIM側のジョブの走るタイミングによると思いますが、期限が切れるタイミングと実際にグループメンバから外れるタイミングには数分のタイムラグがあります。



次回以降、環境の構成方法などもう少し細かい方法を解説していきたいと思います。

2015年6月25日木曜日

[AzureAD]AAD ConnectとConnect HealthがGAになりました

ついにAzure AD ConnectとConnect Healthが一般公開されました。

公式blog)Azure AD Connect & Connect Health is now GA!
 http://blogs.technet.com/b/ad/archive/2015/06/24/azure-ad-connect-amp-connect-health-is-now-ga.aspx

それぞれを一言で紹介すると以下の通りとなります。
モジュール解説主な機能
Azure AD ConnectAzure ADとオンプレミスADのハイブリッド構成(SSO、ID同期)を構成するためのツール群AD FS/AAD Syncの簡単設定機能
マルチフォレストAD連携、非ADのオンプレミスIdPとのID同期
Connect HealthAD FSのモニタリングツールリクエスト数、ログインエラー数などのモニタリングとグラフィカル表示


今回はAAD Connectの方を中心に紹介したいと思います。


◆AAD ConnectのリリースによりDirSyncおよびAAD Syncの個別リリースが終了

重要なポイントですがAAD Connectがリリースされたことにより、DirSyncおよびAAD Syncについては今後個別のモジュールとしてリリースされることはありません。今後はAAD Connectの更新として提供されることとなります。

Azure AD Connect incorporates the components and functionality previously released as Dirsync and AAD Sync. These tools are no longer being released individually, and all future improvements will be included in updates to Azure AD Connect, so that you always know where to get the most current functionality.

出典)https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-learn-more/


◆AAD ConnectではActive Directory以外のIDストアもサポート

現状ではまだExpress Settings(簡単設定)を行うためにはActive Directoryが存在する環境でしかAAD Connectの設定はできませんが、今後はActive Directory以外のIDストアをベースにAzure ADと同期を行うことができるようになると思われます。

Ignite 2015のセッションスライド。他のIDストアとの接続が明示されている。



ドメイン参加していないサーバにAAD ConnectをセットアップしようとするとExpress Settingsは使えないもののセットアップ・ウィザードは先に進められる。



オンプレミスのIDストアの設定にDirectory Typeというプルダウンが存在する。(現在はActive Directoryしか選択できないが)



Synchronization Managerの初期状態で管理エージェントとして以下の3種類が選択できる。

  • Active Directory Domain Service
  • Azure Active Directory
  • Extensible Connectivity 2.0(ECMA2.0)





◆その他

ウィザードの最後にドメイン参加したWindows 10のデバイスの情報をAzure ADと同期するためのオプションについての記載もあり、今後のハイブリッドシナリオの拡張を予感させます。



今後はこのツールがAzure ADとのハイブリッドシナリオでは主役となるはずなので、他の拡張要素についても今後紹介していこうと思います。
しかし一昔前に比べてものすごく簡単にセットアップができるようになったもんです・・・。

2015年6月20日土曜日

[IdM全般]トレーニングコンテンツ色々/プロジェクトの進め方~モバイルデバイス管理~開発まで

最近のポストで2回ほど紹介したMicrosoft Virtual Academy(MVA)というオンライントレーニングコースですが、その後もアイデンティティ関連のコースを探索していたら何個か面白いものが出てきたので紹介したいと思います。

参考)これまで紹介したポスト
[IdM全般]アイデンティティ管理プロジェクトに必要なスキル(Active Directory/Azure AD編)
[AzureAD]入門コンテンツ - クラウド時代のActive Directory次の一手シリーズ



今回紹介させて頂くコンテンツの一つ目は「ID とアクセス管理の全体像」シリーズです。

基本はMicrosoft Conference 2014の中のセキュリティ~ID管理系のコンテンツを集めたシリーズになっており、以下の6つのコンテンツ+セットアップ手順書のセットになっています。
  • 基本から見直すセキュリティ~標的型攻撃の実態と取り組むべきセキュリティ対策~
  • Dynamic Identity Framework~クラウド時代適応のためのID管理手法~
  • ハイブリッドな認証基盤で生産性を高めるために必要な基礎知識
  • モバイルの企業活用を支えるデバイス統合管理ソリューション
  • Azure Rights Managementによる社外ユーザーとのセキュアのコンテンツ共有の実現
  • 多要素認証Deep Dive~ハイブリッド認証基盤だからこそ実現できる柔軟で高機能な多要素認証~

特に2つ目のDynamic Identity Framework(DIF)のセッションでは実際のコンサルティングプロジェクトで企業のID管理の現状分析と課題の洗い出しを行う方法論について語られているのでプロジェクトにかかわる方には参考になるかもしれません。

もちろんそのような方には、JNSAのアイデンティティ管理WGの出している「改訂版クラウド環境におけるアイデンティティ管理ガイドライン」もあわせておすすめです。(宣伝)



二つ目に紹介するMVAコンテンツはAndroid / iOSのようなモバイルデバイスを管理するためのソリューションセット「Enterprise Mobility Suite(EMS)」に関する「Taming Android and iOS with Enterprise Mobility Suite」というコンテンツです。
URL:http://goo.gl/8IOhcm

基礎的な部分からAndroid / iOSそれぞれについての具体的な仕組みや設定についてデモを交えて紹介しています。


最後は開発系コンテンツの「Customizing ASP.NET Authentication with Identity」です。
URL:http://goo.gl/t95rEu

OAuth/ソーシャルアイデンティティ連携から多要素認証まで、ASP.NET Identityでどうやって実装するのか、具体的な実装方法に関する紹介をしています。


私を含めBlogやTechnet / MSDNなどだと都度都度情報が分散してしまっているので、こういう形でまとめてあると基礎から勉強しなおすにはいいですね。


2015年6月19日金曜日

[AzureAD]アクセスルールで社外からのアクセスを制御する

※現在Public Previewとして提供されている機能なので、今後の機能変更などが発生する可能性があります。

Office365やGoogleApps等のSaaSアプリケーションのメリットはどこからでも(社内からも、社外からも)アクセスできるところにあります。
ただ、企業の情報システム部門としてはいつでも、どこでもアクセス出来るからと言って、自宅のPCやネットカフェなどの安全ではない端末からIDとパスワードだけでアクセスされるのはちょっと、、ということもあり、オンプレミスのAD FSなどと組み合わせて信頼できるネットワークからのみのアクセス出来るようにしたり、多要素認証を強制したり、と安全性を何とか確保しようと日々努力をしています。

たとえば以下のような方式です。
・社内ネットワークからしかアクセス出来ないようにする
 方法1:VPNで社内ネットワークへ参加しないとAD FSに到達できないように構成する
 方法2:AD FSのクレーム・ルールを書いてクライアントIPによって承認を制御する 
・社内ネットワーク以外からのアクセスであれば多要素認証を要求する
 方法1:AD FSの多要素認証を構成し、社外ネットワークの場合の認証ポリシーを構成する

これまで、これらの方法はいずれもAD FSが必要でしたが今回紹介するアクセスルールを使うとAzure Active Directory(Azure AD)だけで実装ができるようになるので、より手軽に実装が可能になります。

ちなみに話はそれますが、個人的にはAD FSとWeb Application Proxy(WAP)を使って社内のIdPをDMZに配置してインターネットからでも利用できるようにするくらいなら、素直にAzure ADで認証をしてしまった方が良いと考えています。セキュリティの専門家を自社に抱えていて、DMZのIdPを守る努力を日々継続的に実行できるなら話は別ですが、なかなかあることではないので、Azure ADなりOktaなりの外部のIDaaSに任せてしまった方が安全なのではないかと思います。(さらに多要素認証を使えばより強固になりますし)
この辺りはまた別の機会に書いていこうと思います。


本題に戻ります。

現在、Azure ADのアプリケーション・アクセスルールで出来ることは以下の通りです。

アプリケーション単位で、
・必ず多要素認証を要求する
・社外からのアクセスなら多要素認証を要求する
・社外からのアクセスをブロックする
ことができる。
その際、
・ルール適用対象のグループ
・ルール適用除外のグループ
を設定することができる。


では早速やってみたいと思います。

今回、テスト用アプリケーションにはGoogle Appsを利用し、多要素認証のON/OFF、ルール適用除外グループへの参加/不参加、社内/社外からのアクセスの各パターンでの挙動を確認します。
(ちなみに必ず多要素認証を要求する、というルールは単純すぎるので除外しています。単に多要素認証が要求されるだけなので)

初めに書いてしまいますが、結果は以下の表のようになります。
※External Usersというグループについてルールの適用を除外するように設定をしています。
ルールアクセス元所属グループ多要素認証結果
作業中でない場合、多要素認証が必要です
- 除外:External Users
社内ネットワークExternal UsersYesOK
NoOK
Google UsersYesOK
NoOK
社外ネットワークExternal UsersYesOK
NoOK
Google UsersYesOK
NoNG
※多要素認証設定が要求される
作業中でない場合、アクセスをブロック
- 除外:External Users
社内ネットワークExternal UsersYesOK
NoOK
Google UsersYesOK
NoOK
社外ネットワークExternal UsersYesOK
NoOK
Google UsersYesNG
NoNG



では、順番に行きます。
まずは、「作業中でない場合、多要素認証が必要です」というルールを使います。
※「作業中=社内ネットワークからのアクセス」ととらえてください。翻訳・・・


社内ネットワークの定義は多要素認証プロバイダの管理コンソールで行います。



まずは多要素認証が設定されているユーザでアクセスします。


当然ですが、社内からでも社外からでもアプリケーションが利用できます。


次に、多要素認証が設定されていないユーザで社内ネットワークからアクセスしてみます。
こちらも当然問題ありません。

一方で同じユーザを使って社外ネットワークからアクセスしてみます。
今回は多要素認証が必要となるので、ログオン時に多要素認証のセットアップを要求されます。


ただ、この同じユーザを除外対象のグループ(External Users)へ参加させて再度アクセスすると今度は問題なくアプリケーションが利用できます。


次に、「作業中でない場合、アクセスをブロック」というルールを使います。



ルールに適合するケースは単にアクセス出来てしまうだけなので、条件に適合しない場合の挙動を確認します。
除外対象グループメンバに所属していないユーザが、社外からアクセスした場合が該当しますので試してみます。



見事にブロックされました。
エラーメッセージをよく見ると、「User account 'アカウント名' does not satisfy Access Policy」とある通り、アクセス条件を満たさなかったのでエラーが出ていることがわかります。

内勤の人など、業務上に社外からアクセスする必要がない人についてはこのようなルールを適用して安全にアプリケーションを使う、というのも良いシナリオかも知れませんね。

2015年6月13日土曜日

[IdM全般]アイデンティティ管理プロジェクトに必要なスキル(Active Directory/Azure AD編)

以下のblogにアイデンティティ・アクセス管理プロジェクトを実行する上で強みとなるスキルのリストが挙げられています。

 Killer Skills for an Identity and Access Management (IAM) Project
 http://blog.avatier.com/killer-skills-for-identity-and-access-management-project/


Red hot identity and access management skillsということで色々なスキルのリストが上がっていますが、PCが燃えあがる絵は単純に炎上プロジェクトに見えてしまいますね。

さて、書かれている内容ですが、テクニカルに寄ってはいますが、非常に基本的なスキルセットが羅列されているので新入社員を育てる上では参考になるかもしれません。
 ※ちょうど、社内でどうやって技術者を育てるのか考える時期に来ている人も多いはず。
 ※ちなみに私も参画しているJNSAのアイデンティティ管理WGのテーマとしても人材育成がテーマ候補として挙がっていたりします。


必要なスキルとして挙がっているのは以下の通りです。
・LDAP関連の知識
・データベースに関する知識/SQL関連の知識
・認証/認可のモデルに関する理解
・スクリプト言語


私の経験的に言うと、一般的な開発経験者にプロジェクトに入ってもらう際にまず第一にハードルになるのが実は最初に挙がっているLDAP関連、特にActive Directoryに関する知識・スキルだと思っています。
エンタープライズ領域においてアイデンティティ管理プロジェクトはやはり開発プロジェクトになることが多いので開発者をアサインするのですが、反面LDAPやActive Directoryはインフラ領域(下手するとネットワーク領域)にあるので、開発者からすると非常にハードルが高いようです。
また、インフラ系のエンジニアにとってもクラウド上のAzure ADに関してはやはり基礎から理解をしておきたい分野です。

そんな方にはマイクロソフトが用意している教育コンテンツのMVA(Microsoft Virtual Academy)、ということでActive Directory/Azure AD関係のコンテンツをまとめてみました。
一部英語のコンテンツもありますが、日本語の字幕があるのはうれしいですね。


カテゴリタイトルURL
基礎Active Directory を理解するhttp://goo.gl/jHgGn4
クラウド時代の Active Directory 次の一手シリーズ第 1 回 Active Directory の位置づけhttp://goo.gl/nAFcX0
第 2 回 Active Directory ドメイン サービスの新しい役割http://goo.gl/Sp6hBF
第 3 回 Active Directory フェデレーション サービスの役割 解説編http://goo.gl/1uEyS9
第 4 回 Active Directory フェデレーション サービスの役割 構築編http://goo.gl/VHgHoN
Azure Active DirectoryMicrosoft Azure Active Directory の概要http://goo.gl/4UzIWO
(MCP 70-533 対応) Microsoft Azure インフラの実装 ~ Part 2 Azure Active Directory の実装編http://goo.gl/mykkL0
Azure Multi-Factor Authenticationhttp://goo.gl/Yk7Ne5
Office 365Office 365 Identity Managementhttp://goo.gl/8bfJfl

2015年6月11日木曜日

[Windows10]K-Byte Fingerprint Security ReaderでWindows Hello

先日のポストでIntel RealSense F200でWindows Hello(顔認証)を試して玉砕した話は書きましたが、今度は指紋認証デバイスを試してみます。

 前回のポスト:[Windows10]Intel RealSense F200でWindows Hello
 http://idmlab.eidentity.jp/2015/06/windows10intel-realsense-f200windows.html


今回使ったのは、K-ByteのFingerprint Security Readerです。
日本のAmazonでは売っていないので、USのAmazon.comで探すとたったの$12で購入することができます。(USからの送料を入れると$33ちょっとで購入できます。Express Shippingを使ったので5日くらいで届きました)



こちらから購入できます。
http://amzn.to/1S7fFYr

特にドライバをインストールする必要もなく、生体認証デバイスとして認識されます。


デバイスを正しく認識できれば、アカウント設定のサインインオプションのWindows Helloのところに指紋認証のセットアップメニューが出てきます。


さっそくセットアップをしてみます。

Windowsのご挨拶。。。。なかなか素敵な翻訳です。

「開始する」をクリックするとPINの入力を求められます。


次に指紋の登録を求められるので、数回スキャンをします。

何度かスキャンします。


うまく行くと登録が完了しますので、さっそくログアウトしてみます。


ログイン画面にサインインオプションとして指紋が追加されます。
※画面ショット取得の都合上、ここから英語OSの画面を掲載しています。
 (単純にログイン画面の画面ショットを撮るためにVM上に構成したのですが、手元のVMが英語版しかなかったので。。。設定は物理マシン上の日本語OSで画面ショットを取得しています)

ここで指紋をスワイプし、うまく認識されるとログインできます。


ちなみに、うまく認識できないと以下のようなエラーが出ます。



単純に指紋認証だとWindows8.1のころとそれほど変化がないので、個人的にはやはり早く顔認証を使ってみたいなぁ、、と思います。


追記)
 尚、現状だとMicrosoftアカウントもしくはローカルアカウントだとWindows Helloが使えますが、AAD JoinしたAzureAD上のアカウントでログインするとBioEnrollmentHost.exeがクラッシュしてWindows Helloのセットアップができません。
(バグなのか、環境が悪いのかはわかりませんが)

2015年6月6日土曜日

[Google/ACS]6/1を迎えてAzureACSのGoogle IDプロバイダーはどうなった

2015/04/20をもってGoogleのOpenID 2.0のサポートが終了し、マイクロソフトもAzure ACS(アクセス制御サービス)のGoogle IDプロバイダー設定を6/1までに変更するようにアナウンスを出していました。

関連ポスト)
 GoogleのOpenID 2.0サポート終了による影響いろいろ(Azure ACS編)
 http://idmlab.eidentity.jp/2015/03/googleopenid-20azure-acs.html

 [Google]4/20を迎えてAPIはどうなった?
 http://idmlab.eidentity.jp/2015/04/google420api.html


と、いうことで6月を超えたのでACSがどうなったのかを確認してみました。
結果、まだOpenID 2.0が動いています。結構しぶといです。
(人によって動いていない、という話もあるようなので環境に依存するのかもしれません)

これまで通りの動きです。
1.アプリケーションの認証の設定を行います。

2.実行するとレルムディスカバリ画面がでます。

3.Googleアカウントでログインします。

4.認可をおこないます。

5.アプリケーションからGoogleの属性が取得できています。




このように中々しぶとい状況ですが、MSDNには以下のアナウンスが出ています。
https://msdn.microsoft.com/ja-jp/library/azure/dn927169.aspx

2015 年 6 月 1 日 - ACS 名前空間は Google の OpenID 2.0 実装の使用を停止します。この日までに、ACS 名前空間の移行を完了して、Google OpenID Connect を使用する必要があります。この日までは、移行中に問題が発生しても、OpenID 2.0 にロールバックできます。
ほとんどの場合、アプリケーション コードの変更は必要ありません。アプリケーションに関連付けられているルール グループに ID プロバイダーとしての Google に対して "すべての要求をパススルーする" というルールが存在する場合は、コードの変更が必要になる場合があります。これは、移行によって Google からの新しい要求の種類 (サブジェクト) が ACS で利用可能になることから、アプリケーションが新しい要求の種類の存在を適切に処理できるようにコードを変更する必要が生じる場合があるためです。移行を正常に完了させるうえで、アプリケーションで新しい要求の種類を処理する必要はありません。
2017 年 1 月 1 日 - Google の OpenID 2.0 と OpenID Connect の実装では、Google ユーザーを一意に識別するのに、異なる識別子を使用します。ACS 名前空間の移行後は、現在の OpenID 2.0 識別子と新しい OpenID Connect 識別子の両方をアプリケーションで使用できるようになります。この日までにバックエンド システムでユーザーの識別子を OpenID Connect 識別子に切り替え、以降は OpenID Connect 識別子のみを使用する必要があります。これには、アプリケーション コードの変更が必要です。



ACS側の移行が終わっても次は2017/01/01までに従来のOpenID 2.0で使っていた識別子(nameidentifier)ではなく、OpenID Connectの識別子(subject)を使うようにアプリケーションの改修を行う必要があるようです。
ACS側でのクレームのマッピングを修正する形にしたほうが柔軟な気もしますので、私ならACSのクレームマッピング(規則グループ)を変えますが。。
※この図のnameidentifierとsubjectのマッピングを合わせてあげる形にします。既存アプリケーションはnameidentifier属性を見ているはずなので、OpenID Connect対応した際にGoogleから取得できるようになるsubject属性を出力側のnameidentifier属性にマッピングしてあげればアプリケーションを改修する必要はありません。


まだまだ余裕はありますが、こちらの改修も早めに実施しておいたほうがよさそうですね。

※使えなくなる瞬間どうなるのかを確認したいので、あえてACSの設定を移行せずに残してあるのですが、中々使えなくならないので、今後も引き続きウォッチしていきたいと思います。