ADFS

オンプレミスのActive Directory クラウドのAzure Active Directory マイクロソフト系のインフラ管理者にとってオンプレミスの時代に特に重要だったのはActive Directory(以下AD)でした。拙著(Windowsインフラ管理者入門)でも触れたところです。Windowsのドメインという仕組みがあり、そのドメインの中でIDを司るADがあり、アプリケーションはADに対応し、ADに参加したWindowsクライアントからアプリケーションを利用していたのです。 クラウド時代においても依然としてADは重要です。ですが、様々なクラウドサービスを利用し、他の企業とも連携していく必要性が高まる中で、企業内ネットワークに閉じてADのIDのみを利用したシステムだけを利用していればよい時代はとっくに終わりました。 オンプレミスのADをActive Directory Federation Services(以下ADFS)を介して外部とフェデレーションで結ぶという形態での社外ネットワークへの対応もありますが、現在向かっている方向は明らかにAD + ADFSという構成ではなく、クラウド上のIDaaSであるAzure Active Directory(以下AAD)です。AADをID基盤として利用する形態を中心に進化しています。 AADはマイクロソフトが提供するクラウドサービス(Office 365, Azure, Dynamics 365等)のほぼ全てのID基盤となっています。マイクロソフトのクラウドサービスを使っているユーザーは特に意識していなくてもすでにAADを利用しており、クラウド上にIDを保持しています。しかもAADは基本料金無料で提供されています。 また、オンプレミスにADを持つ企業が簡単にAAD上にIDを保持できるように、IDを同期、連携する仕組みも完全に無料で提供されています。 マイクロソフト系のインフラ管理者にとってオンプレミス時代にはADを、クラウド時代にはAADを軸にIDを管理し、そのIDを軸に様々なアプリケーション利用をコントロールすることはほぼ必然であり、まずはじめに抑えておく必要がある部分です。 AADでサービス連携、企業関連系、コンシューマーID連携 AADにはSAML 2.0, WSFederation, OpenConnectID、OAuth 2.0等の業界標準のプロトコルも採用され、マイクロソフトが提供するクラウドサービスにとどまらずインターネット上の様々なサービスと業界標準のプロトコルで連携可能になっています。AzureAD B2B, AzureAD B2C等、企業間の連携やtwitter, facebook等のコンシューマー向けのIDとの連携機能も備えています。 過去、ADを中心としたIDシステムにおいて企業間、グループ企業間でシームレスに連携させることは非常に困難でした。単純にネットワーク的につながっていないものを接続する所から苦労は始まり、個別にシステム毎に連携方法を模索し、ロジックを作り込んでいるケースが多くありました。 クラウド時代には過去と同じような苦労をする必要はありません。IDはインターネット上に存在しており、自由に標準的なプロトコルで連携可能となるのです。 セキュリティ対策 クラウド上にIDシステムが存在することでセキュリティ面の心配をする人も多くいると思います。ですがそれは逆です。むしろクラウド上にIDを保持することの方がセキュリティ面で有利である時代になっています。 クラウドサービスを全く使わずにIDもシステムも完全に社内ネットワークで閉じている状況であれば確かに外部からの攻撃に対しては非常に強いでしょう。入り口も出口も無く、窓を全て締め切っていれば外界から攻撃する手段はありません。それは事実です。ですが、このようにインターネットと分離した環境であったはずの環境においても利便性を求めた結果本来の設計とは異なる構成となってしまい、大規模なセキュリティ事故が起きた実例があります。 このクラウド時代に外部から完全に閉ざした鎖国状態のシステムを作っても生産性高く活動を行えるはずがありません。そうなるとインターネットとの接続をどうしてももつ必要があります。その段階でクラウド上にIDをもつか、オンプレミス上にあるIDに対しての認証の窓口を開かなくてはいけません。 インターネット上に常に存在し、多数の攻撃にさらされながらそれに耐え、しっかりとした運用体制やセキュリティ対策の取られているクラウド上のIDaaSを利用するのと、オンプレミスで自分たちで面倒を見ているシステムとでどちらがセキュリティが高いでしょうか。クラウド上のIDaaSには大量のIDをさばきながら取得できる情報を活用した高付加価値のセキュリティ対策サービスが多数備わっているという現実もあります。ここは人によって意見が分かれる場所かもしれませんが、私見ではあきらかにクラウド上にIDをおいたほうがセキュリティが高くできる現実がすでにあり、今後もその傾向はどんどん強まっていくと考えられます。 むしろ積極的にクラウド上にIDを置き、IDaaSが継続的に進化し続ける機能を把握し、それを有効に活用すべき時代になっていると考えます。 まずAzure Active Directoryの活用から マイクロソフト系のインフラ管理者がクラウドに足を踏み出す際には、個人的なおすすめとして是非AADの活用から考えてもらいたいと思います。AD+ADFSではなく、他社のIDaaSサービスではなくAADを利用してほしいです。 AADはマイクロソフトのクラウドサービスの根幹となり、全てのシステム、全ての仕組みに関連するものだからです。 そして、AADは無料でありいくつでも作成できるものなのですが、「本番AAD」を1つ作成し、基本的に全てのものをそこに紐付ける形にすることをお勧めします。つまりそれはシステム毎にID、Passwordを別々に作成して分割する…ということをしないようにするということです。私のおすすめは全て、例外なくです。他社製のクラウドサービスを利用するときですらです。 この構成をお勧めするのには様々な理由があり簡単に言い表すことは難しいのですが「1つのIDを利用して全てのものを利用可能とするのが最も便利でセキュアで運用コストが低いから」です。この点はもっと説明が必要ですのでまた今後のブログエントリで解説していきたいと思います。

過去から何度も言われていることですが、パスワードは無期限に設定したほうがセキュリティ対策上好ましいです。(反対派も根強く存在しますが) 先日、Office 365の管理者画面に久しぶりにアクセスしたところ、推奨事項として簡単にパスワードを無期限に設定できるようになっていました。感動してTwitterに投稿した所、3000回近くリツイート、お気に入り登録がなされました。 マイクロソフトがついにパスワード無期限を推奨事項としてO365の管理画面に出してくれた！！素晴らしい！！！ pic.twitter.com/GqRNv7uOqu — Masahiko Ebisuda (@ebi) 2018年2月27日 個人的には過去最高のTwitter上での反応でした。それだけパスワードの定期変更が設定され、それに不満を持っている人が多いということなのだと思います。 ただ、画像のメッセージ上では「ユーザーアカウントをクラウドで管理している場合は、パスワードを無期限に設定することをお勧めします。」という表現になっています。 「これを推奨する理由の詳細を表示」のリンク先は下記のアドレスをなっており、そこではオンプレミス、クラウドにかかわらずパスワードの定期変更は良くないこととして解説されています。 - [Password Guidance - Microsoft Research](https://www.microsoft.com/en-us/research/publication/password-guidance/) それでも、あえてOffice 365上の管理画面にて「クラウドで管理している場合は」という書き方をしているのかと言うと・・・、そこにはAzure Active Direcotryが備えているセキュリティ対策機能の存在があるからだろうと思いますし、ADFSを使わずにAzure Active Directory上でユーザー認証を可能な状態にしてほしいという思想が表現されていると思います。 以下は私の推測や考えも混じっていますので全部そのままうのみにはしないでいただきたいのですが… まず、Azure Active Directoryの開発者はクラウド上でユーザーを管理する事、つまりパスワードハッシュもAzure Active Directory上まで同期する構成を強く推奨しています。（これは本当です。直接聞いてます。） そうすることによって、脆弱なパスワードを設定しているユーザーは一発で判別できますし、怪しい挙動をしているユーザーをAzure Active Directory側で検知できます。 オンプレミスのActive Directoryで適当な管理をしている状態よりもAzure Active Directory上で管理したほうが遥かにセキュアにできるんです。 わたしはこれは自明なことだと思います。だって、Azure Active Directoryからユーザーデータベースを引っこ抜くのと、オンプレミスのActive Directoryからデータベースを引っこ抜くなり、DCのイメージを盗み出すなりするのと、どちらが簡単でしょうか？圧倒的に後者の方が簡単ですよね。というか、前者はできる気がしないです。 よく「クラウドにパスワードを置くのはセキュリティ的に危ない。だからADFSをつかってオンプレミスにパスワードを置く。」という言い方をする人がいますよね。これ、二重の意味で間違っています。 まず、そもそもパスワードってどこにも置かれていません。パスワードがそのまま生で暗号化もハッシュ化もされずに置かれているなんてとんでもなく間違った設計です。危険なんてもんじゃなく、ひどすぎます。 たしかに、「パスワードを忘れた」ボタンをおしたらメールで生のパスワードを教えてくれるWebサービスは存在します。残念ながら。ですが、それはあまりにもひどすぎる実装なのであって、そもそもそんなサービスをつかってはいけないと言っても過言じゃないくらいのひどい実装です。(だから、パスワードは全部違うものにしましょうね。) パスワードはそのまま生で保存しては大変に危険なので、そのままは保存しないのが鉄則なんです。パスワードを生で保存しなくても正しいパスワードを入力したことを調べる術というのはきちんと存在していて、パスワードのハッシュ値を保存しておき、ユーザー認証時のパスワード入力に関してもそのハッシュ値を比較し、同一であれば正しいパスワードが入力されたということが判断できます。あるいはそもそもパスワードを必要としない実装にする方法もありますね。 なので、そもそも「パスワード」そのものはどこにも置かれていないのです。頭の中にあるだけです。その辺の紙に書かないでくださいね。(パスワード管理ソフトに可逆変換状態で保存されるのはありだと思います。) そして、ADFSを使ってオンプレミスのADで認証を行った場合は、セキュリティ的にAzure Active Direcotryで認証させるよりもセキュリティ的に強固であるという主張の根拠が私には全くわからないです。 たとえば、外部からのアクセスは全部ブロックしてるんです…というのでも、それAzure Active Directoryでもできますしね。マイクロソフトが物凄い数の世界中の組織のIDを束ねて超厳格に管理してくれているAzure Active Directoryと、自前で構築しているADFS + Active Directoryとを比較して「うちの組織の認証システムはMicrosoftよりもイケてる！」と言えるって凄い自信だなと思います。これって製品コードだけではなくて、運用面等まですべて含めての話ですからね。 それで、Azure Active Directoryを前提とした時に「パスワードは無期限に設定したほうがよい」というのは真だと思います。 オンプレミスのADFS + Active Directoryに関しては「やられてるんだけど気がついてません。」という状況の時にパスワード変更を行ってその結果、セキュリティ対策的に意味があるものになる…という可能性は無いことは無い(そもそも前提からおかしいんだけど)という感じには思うわけです。 そもそもは、パスワードを十分に長くて複雑なものにしておけば良いわけです。そして、その上でパスワードが盗まれても大丈夫なように多要素認証にもしておくべきです。さらにさらに、ユーザーの挙動をみて、怪しいものはブロックもできるようにしておけばさらに安心ですし、ルールを守れず脆弱なパスワードを付けてしまう人も一定数いるでしょうからそれは設定できないようにブロックしたり、設定されてしまっているものは洗い出せるようにすべきです。冗長化、負荷分散もしっかりとしていないといけませんね。インターネットに公開されている認証の窓口なので、攻撃も沢山くるでしょう、それも検知してブロックしなければですね。DDos攻撃だってくるでしょう、それも対処可能でなければいけません。Azure Active Directory(+ Premium P1, P2)ならこれ全部やってくれます。この前提の中では当たり前にパスワードは無期限にして、ユーザーに正しく複雑なパスワードを設定してもらうのが良いですね。 ...

日経SYSTEMSの2017年9月号のAzure Stackに関連する記事に私のコメントも掲載されています。 日本ビジネスシステムズの胡田氏は「Azure StackでID管理に用いるAzure Active Directoryは、ユーザー企業のオンプレミス環境で一般的なActive Directoryとは別物。混乱を招く恐れがある」と指摘する。私も、Web上や雑誌上でも記事を書いたり、インタビューを受けてコメントが掲載されたりなどかなり露出がふえており、大変ありがたいことです。私は人生の生存戦略において、外部露出を増やす戦略でやっていますので実名でこのように雑誌記事にコメントがのるのは大変ありがたいことでして、是非インタビューでもなんでもお声がけいただければと思います。 と、大変ありがたい話ではあるのですが、流石に短い紙面でこのコメントだけ掲載だと相当の誤解を産んでしまうのも致し方がないところだと思います。このコメントに関しては追加で補足をさせてもらおうと思います。 まず、Azure StackでID管理にAzure Active Directoryを用いるというのは半分正しく、半分正しくありません。Azure Stack自体へのアクセス、特に管理ポータルへのアクセス時に使うIDはAzure Active DirectoryとADFSのどちらかが選択可能です。推奨はAzure Active Directoryであり、つまりはクラウド上のIDですからインターネット接続が行えることが前提条件となります。Azure Active DirectoryのIDということはつまりはO365で利用しているIDとも共通とすることができるわけであり、Microsoftの戦略からするとクラウドIDの中心としてのAzure Active Directoryを軸に全てのクラウドサービスをコントロールしようとしていますので、Azure Stackもその1つということで何も違和感がありません。 ただ、一方で「インターネットには接続させない、クラウドサービスは利用できない」という環境ではAzure Active Directoryを使うことはできませんから、そのためのオプションとしてADFSおよびADFSと連携するActive DirectoryをIDとすることもAzure Stackでは可能となっています。この場合、「ユーザー企業のオンプレミス環境で一般的なActive Directory」のIDをそのまま利用可能となりますから、何も混乱なく利用可能となります。 さらにいうと、企業においてAzure Active Directoryを利用する場合にはそのIDはオンプレミスのActive DirectoryとAD Syncにて同期されているケースが非常員多いため、Azure Active DirectoryをIDとしている場合でも、それは事実上Active DirectoryのIDと統一であり、混乱を招くようなものではないケースが多いでしょう。 記事上では表現されていませんが、私が危惧している心配はAzure Stackのマネジメントポータル利用時のIDではなく、Azure Stack上に構築されるシステムへのアクセスに利用されるIDに関してなのです。 もちろんAzure Stack上にIaaSを利用してWindows Serverを展開し、そのWindows Serverを既存のネットワーク上のActive Directoryにドメイン参加させ、いつもと同じようにAD統合認証でシステムを作成する…、これはもちろんやろうと思えばできるのですが、これをやろうと思うと、オンプレミス同士にもかかわらずVPN接続が必要になってきます。これ、非常に違和感が出てしまうんじゃないかと思っています。 もちろんAzure StackはAzureそのものなのですから、VPNで接続するというのはAzureと同等であり、一貫性があります。 でも、同じ社内ネットワークに存在している「隣のサーバー」なのにVPNをはらないとネットワーク的につながらないというのはちょっと違和感を感じるひとが多いいんじゃないかと思うんです。 さらにAzure StackになるとInfrastructure as Codeも非常にやりやすくなります。コードにシステムを表現しておいて、それを展開して環境を作り出す…必要なくなったら消す…そんなことをバンバンするようになってくると…。既存環境へのVPN接続やドメイン参加をして…ということが非常に足かせになってしまいます。そもそも同じ環境を2つ作ろうとおもうと、コンピューターアカウントが重複して問題が発生してしまったりもしますしね。 つまり、Azure Stack上でAzure Stackらしい使い方をしようと思うと、今までのようにActive Directoryを使った認証にするのではなく、自然とAzure Active Directoryを使った認証システムを採用することになると思っています。 Azure Active Directoryに寄せることで色々とメリットも出てきます。Azure Active Directory Premiumの各種機能を使って認証を強化したり、セキュリティを強化したりできるが大きいでしょうか。 このあたりをきちんと理解してシステムを組んでいくようになるのがすぐ近い未来だと私は思っています。「社内であっても認証にActive DirectoryではなくAzure Active Directoryを使う」このあたりをきちんと理解し、システムを構築するようになるまでには、まだまだ結構色々とあちこちで苦労があるだろうなと思ってます。 雑誌のコメントにはこのようなバックグラウンドがあり、それが凝縮されてあのような表現になっているわけです。 Azure Stackを利用するなら、IaaSでVPNをつかって既存のシステムとネットワーク的にに連携してAD統合認証…ではなく、PaaSをつかって認証はAzure Active Directoryを使ったシステムをまず第一に考えて行きたいですね！ ...

皆さんこんにちは。胡田です。 ADFSでクレームルールを書いて様々なコントロールを行う…ということは技術的に可能なのですが、ものによっては意味がない、正しくない実装になってしまいますので注意してください。 例えば1例として、User-Agentを用いてアクセスをコントロールするような実装があります。ぐぐると解説記事もいっぱい出てきます。例えば以下。 - Restrict iOS apps which can access to Office 365 services (ADFS required) – beanexpert ADFSのクレームルールでuser agent(x-ms-client-user-agent)を参照してそれが特定の値であれば許可/拒否する…ということが開設されています。 これははっきり言ってひどい実装です。 HTTP(S)プロトコルにおいて、User-Agentヘッダはクライアントアプリが任意の値を埋め込むことが非常に簡単に行えるものです…、というかそもそもが自己申告制のものでして…こんなものを信じてなにかをコントロールするというのは「あなたは犯罪者ですか？」という質問の答えで許可/拒否するようなものです。 例えば「user agent change」というキーワードあたりでちょっとググるだけでも山ほどツールや手法が出てきます。 - user agent change - Google 検索 例えばProxyで書き換えるようなことも簡単にできますね。 - user agent change proxy - Google 検索 このあたりはHTTPプロトコルがそもそもどんなものなのか、ということを知っていれば当たり前に分かる話ではありますが…。 何をどのポイントでコントロールするか、というのはなかなかに難しいトピックではありますが、ADFSで色々とコントロールしようとするのは、Microsoftの今後の方向性からいっても相当の悪手だと思います。 MicrosoftソリューションであればAzure AD Premium( + Intune)を活用するのが吉だと思います。

今日は桃の節句ですね。さて、今週のトピックスです。 - Announcing preview of Azure HDInsight 3.6 with Apache Spark 2.1 | Blog | Microsoft Azure 1 user Get credits that enable: 4 Windows or Linux Virtual Machines 24 x 7 for a month And much more… Learn more [azure.microsoft.com ](http://b.hatena.ne.jp/ebibibi/?url=https%3A%2F%2Fazure.microsoft.com%2F) - テクノロジー - あとで読む - [](http://b.hatena.ne.jp/ebibibi/)ebibibi w, b, azure 27 clicks 2017/03/03 - Azure Command Line 2.0 now generally available | Blog | Microsoft Azure 1 user Back in September, we announced Azure CLI 2.0 Preview . Today, we’re announcing the general availability of the vm , acs , storage an… ...