Microsoft Passport ガイド
このガイドでは、Windows 10 オペレーティング システムに含まれる Windows Hello と Microsoft Passport の新しいテクノロジについて説明します。資格情報の従来の脅威を軽減するこれらのテクノロジの特定の機能に着目し、Windows 10 ロールアウトに含まれるこれらのテクノロジの設計と展開の方法について説明します。
情報セキュリティの基本的前提は、システムで使用ユーザーを識別できることです。ユーザーを識別する場合、システムは、ユーザーが自分自身を適切に識別できるかどうか (認証と呼ばれる処理) を判断し、この適切に認証されたユーザーが実行できる内容 (承認プロセス) を決定できます。世界中に展開されたコンピューター システムの大部分は、認証と承認の判断方法としてユーザー資格情報に依存しています。つまり、これらのシステムのセキュリティは、ユーザーが作成した再利用可能なパスワードに依存しています。「記憶によるもの、持ち物によるもの、本人の特長によるもの」を含む認証が、ある問題をしっかりと浮き彫りにしているとよく言われます。それは、利用可能なパスワードは認証要素そのものであるため、パスワードを手に入れたユーザーは、元の所有者を偽装できるという点です。
従来の資格情報の問題
1960 年代中ごろから、Fernando Corbató と Massachusetts Institute of Technology の彼のチームはパスワードの導入を提唱し、ユーザーと管理者はユーザーの認証と承認用のパスワードの使用に対応する必要がありました。時間の経過と共に、最新のパスワードの保存と使用方法が少しずつ進化してきましたが (パスワードのハッシュ化とソルトという 2 つの注目すべき改善点)、未だに 2 つの重大な問題に直面しています。それは、パスワードの複製と盗難が簡単である点です。実装を失敗すると、パスワードが危険にさらされてしまう可能性があり、ユーザーは利便性とセキュリティの難しい舵取りを強いられます。
資格情報の盗難
パスワードの最大のリスクは単純です。攻撃者がパスワードを簡単に盗むことができる点です。パスワードの入力、処理、または保存を行うすべての場所に脆弱性があります。たとえば、攻撃者が、アプリケーション サーバーへのネットワーク トラフィックを傍受したり、アプリケーションやデバイスにマルウェアを埋め込んだり、デバイスへのユーザーのキーボード操作をログに記録したり、ユーザーが入力する文字を観察したりして、認証サーバーから一連のパスワードまたはハッシュを盗むことができます。これらは、最も一般的な攻撃の方法です。1 つまたは複数のパスワードを盗もうと、さらに珍しい攻撃を仕掛けてくる可能性があります。
盗難のリスクは、パスワードが表示される認証要素がパスワードのみである場合に高まります。認証要素を追加しない場合、システムは、パスワードを手に入れた人物であれば誰でも、承認済みユーザーだと見なします。
加えて、資格情報再生に関連するリスクがあります。この場合、攻撃者がセキュリティで保護されていないネットワークを傍受して有効な資格情報を取得し、後でその資格情報を再生して有効なユーザーを偽装します。ほとんどの認証プロトコル (Kerberos や OAuth など) は、資格情報交換プロセスにタイム スタンプを追加して再生攻撃を防いでいますが、保護されるのは、認証システムが発効したトークンであり、ユーザーが最初にチケットを取得するために入力したパスワードではありません。
資格情報の再利用
使用する接続システムとアプリケーションの数が増えるにつれて、資格情報の需要も増します。Microsoft Research の 2007 年の調査によると、Web ユーザーが所有するパスワードの平均数は 6.5 個と算出されました。正確な数にはばらつきもあるようですが、その後の調査ではこの数が大幅に増えています。パスワードの要件 (「利便性と複雑性のトレード」セクションで説明) はさまざまで、ユーザーは簡単に覚えることのできるパスワードを選ぶ傾向が強く、多くの場合、パスワードを 1 つ決めると、それを複数のサイトで使ってしまうと言われています。上級者のユーザーは基本のパスワードを選び、それを各サイトに合わせて変更しますが (たとえば、「4joe」を基本のパスワードとして、「bank4joe」、「airline4joe」、および「school4joe」に変更)、そのような行為は、パスワードの推測に対して驚くほど些細な抵抗にしかなりません。パスワード変更時に古いパスワードを再利用できないようにパスワード履歴を残す個別のシステムがありますが、複数のシステムで同じパスワードを使わないようにするメカニズムはありません。
ユーザー名としてメール アドレスを使う一般的な手法により、問題がさらに悪化します。侵入したシステムからユーザー名とパスワードのペアをうまく復元した攻撃者は、この同じペアを他のシステムに試してみることができます。驚くほど多くの場合、この方法により、攻撃者は侵入したシステムから別のシステムに入り込むことができます。ユーザー名にメール アドレスを使用すると、他の問題も発生します。それについては、このガイドの後半で説明します。
利便性と複雑性のトレード
ほとんどのセキュリティで利便性とセキュリティの間に矛盾が起きています。システムのセキュリティを増すと、一般的にユーザーの利便性が低下します。システム設計者と導入担当者は、システムのセキュリティ向上のための豊富なツールを持っていますが、ユーザーにも選択権があります。ユーザーは、セキュリティ対策が動作の邪魔になると判断すると、この対策を回避する方法を探す傾向にあります。この行動により、ちょっとしたせめぎ合いが起こります。ユーザーは、組織のパスワード ポリシーの進化に合わせて、そのポリシーの準拠に必要な作業を最小限に抑えるための手段を取り入れます。
パスワードの複雑性
攻撃者のブルート フォース攻撃分析によってパスワードが推測されることが、パスワードの主なリスクの場合、ユーザーがパスワードにさまざまな文字セットを追加したり、パスワードを長くすることが妥当のように考えられますが、実際の問題として、パスワードの長さと複雑性の要件には 2 つのマイナスの副作用があります。1 つ目は、パスワードを再利用してしまうことです。Herley、Florêncio、および van Oorschot の予想によると、パスワードが強力なほど、再利用される傾向にあるようです。ユーザーは強力なパスワードの作成と記憶に熱心に取り組むため、複数のシステムで同じ資格情報を使う傾向があります。2 つ目は、パスワードを長くしたり、文字セットを追加しても、パスワードの推測が必ずしも難しくなるわけではないことです。たとえば、P@ssw0rd1 は、大文字、小文字、数字、特殊文字を含む 9 文字ですが、インターネット上で現在利用可能な多くの一般的なパスワード解読ツールを使うと、簡単に推測されます。これらのツールは、コンピュータで生成された一般的なパスワードの辞書を使用してパスワードを攻撃できます。つまり、password など基本となる単語から始まり、一般的な文字に置き換えていきます。そのため、完全にランダムな 8 文字のパスワードのほうが、実際には P@ssw0rd123 よりも推測に時間がかかる場合があります。
パスワードの有効期限
パスワード ベースのシステムでは、再利用可能なパスワードが唯一の認証要素であるため、設計者は資格情報の盗難と再利用のリスクを軽減しようとします。この一般的な方法の 1 つは、有効期間を制限したパスワードを使うことです。一部のシステムでは、1 回だけ使用できるパスワードを採用していますが、それよりはるかに一般的な手法なのが、特定の期間で有効期限が切れるパスワードの作成です。パスワードの有効期間を制限することで、攻撃者が盗んだパスワードを使える期間を制限します。この方法は、長期間使用されたパスワードが盗まれ、その後長い間使われる場合の対抗策として役立ち、パスワードの解読が、国家レベルの攻撃者以外には難しい時代に戻ります。パスワードの解読では時間の制約があるため、スマートな攻撃者は、パスワードの解読よりもパスワードの盗難を試みようとするでしょう。
製品化されたパスワード解読ツールと、GPU を搭載した解読装置や分散クラウド ベースの解読ツールなどのメカニズムで大規模な処理能力を幅広く使えるため、攻撃者にとっては、パスワードを盗むよりも、パスワードを解読するほうが効率的な場合が多くなり、この状態が覆されています。また、セルフ サービス型のパスワード リセット メカニズムを幅広く使えるということは、攻撃者がパスワードを変更してその有効期間をリセットする場合、必要なパスワードの有効期間は短時間で済みます。セルフ サービス型のパスワード リセット メカニズムを提供する企業は比較的少ないですが、インターネット サービスでは一般的です。さらに、多くのユーザーは、Windows と Mac OS X のシステム上でセキュリティ保護された資格情報ストアを使用し、インターネット サービス用の重要なパスワードを保管しているため、オペレーティング システムのパスワードを侵害した攻撃者は、手間をかけずに他のサービスのパスワードを膨大に手に入れることができます。
最後に、パスワードの有効期限を極端に短くすると、ユーザーはそれぞれの有効期間でパスワードに小さな変更しか加えなくなります。たとえば、password123 から、password456 や password789 のように変更します。この方法では、特に攻撃者が古いパスワードのいずれかを把握している場合、パスワードの解読に必要な作業が少なくなります。
パスワード リセット メカニズム
ユーザーが自分のパスワードを上手に管理できるようにするため、ユーザーが自分のパスワードを変更するための方法を提供するサービスもあります。一部の実装では、ユーザーは最新のパスワードでログオンする必要があり、他の実装では、ユーザーの登録済みのメール アドレスに電子メールが送るようにする [パスワードを忘れた場合] オプションを選ぶことができます。これらのメカニズムの問題は、攻撃者が悪用できるようにその多くが実装されている点です。たとえば、リセットされた電子メールはセキュリティ侵害されたアカウントに送られるため、ユーザーの電子メールのパスワードをうまく推測または盗難できた攻撃者は、被害者の他のすべてのアカウントのパスワード リセットを簡単に要求することができます。このため、ほとんどの企業ネットワークでは、ユーザーのパスワードをリセットできるのは管理者のみとなるように構成されています。Active Directory では、管理者がパスワードをリセットしたら、ユーザーは管理者による設定パスワードを入力した後のみパスワードを変更できるようにするため、[次回ログオン時にパスワードを変更する必要があります] フラグの使用をサポートしています。一部のモバイル デバイス管理 (MDM) システムでは、モバイル デバイスで同じような機能をサポートします。
ユーザー パスワードの不注意
不注意による問題が、これらの設計と実装上の弱点をさらに悪化させます。一部のユーザーは、パスワードの取り扱いにまったく注意が足りていません。安全でない場所にパスワードを書き留めたり、簡単に連想できるパスワードを選んだり、マルウェアに対する対抗策 (ある場合) を最低限しか実行しなかったり、他のユーザーに自分のパスワードを渡してしまうことさえあります。これらのユーザーは、気にしていないため、必ずしも注意不足というわけではありません。物事を早く終わらせたいと考えており、非常に厳格なパスワードの長さや有効期限のポリシーまたは膨大なパスワードが、ユーザーの妨げとなっています。
資格情報のリスク軽減
これまで説明した問題を考慮すると、再利用可能なパスワードにはセキュリティ上の問題点があることが明確なように思われます。その根拠は単純です。認証要素を追加すると、パスワードの盗難が成功しても、攻撃者がそれに関連する別の要素を持っていない限りシステムにログオンできないため、パスワード自体の価値が低下します。残念ながら、この単純な根拠には多くの複雑で実質的な問題があります。セキュリティとオペレーティング システムのベンダーは、何十年もの間、再利用可能な資格情報により発生する問題を解決しようとしていますが、得られた結果はわずかです。
再利用可能なパスワードにより発生するリスクに対して最も分かりやすい軽減策は、1 つまたは複数の認証要素を追加することです。過去 30 年間のその時々で、さまざまなベンダーが、生体認証識別子 (指紋、虹彩、網膜のスキャン、掌形認識など)、ソフトウェア ベースとハードウェア ベースのトークン、物理と仮想のスマート カード、音声、またはユーザーの携帯電話を利用したショート メッセージ サービス (SMS) による認証を使用するように求めることで、この問題を解決しようとしてきました。これらの認証システムとその長所と短所の詳細な説明については、このガイドの範囲外ですが、選択する認証方法に関係なく、次の主要な課題により、どの多要素認証 (MFA) ソリューションも導入が制限されます。
インフラストラクチャの複雑性とコスト。アクセス時にユーザーが追加の認証要素を入力する必要のあるシステムでは、その情報を収集する方法を用意する必要があります。指紋リーダー、眼球スキャナー、スマート カード リーダーなどを追加して、現場のハードウェアを改良することはできますが、そのコストを積極的に負担し、実施に必要な作業をサポートしてくれる企業はほとんどありません。
標準化不足。Microsoft は、Windows Vista オペレーティング システムの一部としてオペレーティング システム レベルのスマート カードをサポートしていましたが、スマート カードとリーダーのベンダーは、他の認証デバイスの製造元と同じように、独自のドライバーを自由に出荷し続けました。標準化が不足すると、アプリケーションとサポートの両方が断片的になります。つまり、ソリューションの製造元が互換性があると宣伝していたとしても、企業内のソリューションと組み合わることができるとは限りません。
下位互換性。MFA の使用のために展開済みオペレーティング システムとアプリケーションを変更することは、非常に難しい作業であることが実証されています。リリースから約 3 年が経過して、Microsoft Office 2013 はようやく MFA をサポートするようになりました。商用とカスタムの両方の基幹業務 (LOB) アプリケーションの大部分は、基になるオペレーティング システムで提供される認証システム以外を利用できるように変更されることはありません。
ユーザーの不自由。物理的なトークンの取得、追跡、および使用をユーザーに求めるソリューションは大抵不評です。ユーザーが、利便性を向上すると考えられるリモート アクセスまたは他のシナリオのために特定のトークンを用意する必要がある場合、ユーザーは、デバイスを追加する作業に対して直ぐに不満を抱える傾向にあります。コンピューター (スマート カード リーダーなど) に取り付ける必要のあるソリューションに対しては、この抵抗が増大します。その理由は、そのようなソリューションでは、移植性、ドライバー サポート、およびオペレーティング システムとアプリケーションの統合による問題が発生するためです。
デバイスの互換性。すべてのハードウェア フォーム ファクターが、認証方法をすべてサポートしているわけではありません。たとえば、ベンダーの努力が一時的で足りなかったとしても、携帯電話と互換性のあるスマート カード リーダーの市場はこれまで誕生しませんでした。そのため、Microsoft が、リモート ネットワーク アクセスの認証システムとしてスマート カードを最初に実装したとき、従業員がログオンできるのは、スマート カード リーダーが装着されたデスクトップまたはノート PC からのみという 1 つの大きな制約がありました。ハードウェアまたはソフトウェアを追加しなければならない認証方法では、この問題に直面する場合があります。たとえば、いくつかの一般的な「ソフト トークン」システムは、限られた数のモバイル ハードウェア プラットフォームで動作するモバイル アプリに依存しています。
別の厄介な問題として、組織の認識と成長に対応する必要があります。強固な認証システムは複雑です。コンポーネントの数が多く、設計、保守、および運用に多くの費用がかかる可能性があります。一部の企業の場合、スマート カード配布に必要な社内公開キー基盤 (PKI) を維持するための追加コストとオーバーヘッド、または追加デバイスの管理作業が、強力な認証の装備で得られる価値を超えてしまいます。これは、金融機関が直面する一般的な問題の中の特殊なケースの 1 つです。不正行為の削減にかかるコストが、不正行為自体のコストよりも大きな場合、優れた不正防止対策の経済性を正当化するのは困難です。
資格情報の問題解決
パスワードが原因で発生する問題の解決は簡単ではありません。パスワード ポリシーのみを強化しても役に立ちません。ユーザーは、単にパスワードを再利用、共有、またはメモしてしまう場合があります。ユーザーの教育は認証セキュリティにとって重要ですが、教育だけでも問題を取り除けません。
お分かりのように、新しい認証システムには複雑性、コスト、または脆弱性があるため、認証システムの追加が役に立つとは限りません。Microsoft の Windows 10 では、Windows Hello と Microsoft Passport という 2 つの新しいテクノロジでこれらの問題を解決しています。これらのテクノロジと連携して、セキュリティとユーザーの利便性の両方を向上させます。
Microsoft Passport では、既存の資格情報を確認して、ユーザーのジェスチャ (生体認証または PIN ベース) で保護されるデバイス固有の資格情報を作成することで、パスワードを強力な 2 要素認証 (2FA) に置き換えます。この組み合わせにより、ログオンとアクセス制御用の再利用可能なパスワードだけでなく、物理と仮想スマート カードも効果的に置き換えられます。
Windows Hello は、顔認識または指紋認証に基づいて、優れた信頼性の完全統合型生体認証を提供します。Windows Hello では、特別な赤外線 (IR) カメラとソフトウェアを組み合わせて精度を向上し、スプーフィングから保護します。主要なハードウェア ベンダーは、Windows Hello と互換性のあるカメラを統合したデバイスを出荷しており、指紋リーダー ハードウェアを使用したり、このハードウェアが現在搭載されていないデバイスに取り付けたりできます。Windows Hello をサポートするデバイスでは、簡単な生体認証ジェスチャにより、ユーザーの Microsoft Passport 資格情報のロックが解除されます。
Windows Hello とは
Windows Hello は、Microsoft が Windows 10 に組み込まれた新しい生体認証サインイン システムに付けた名前です。Windows Hello はオペレーティング システムに直接組み込まれているため、顔または指紋を識別して、ユーザーのデバイスのロックを解除できます。ユーザーが自分固有の生体認証識別子を入力して、デバイス固有の Microsoft Passport 資格情報にアクセスする場合に認証が行われます。つまり、攻撃者がデバイスを盗んでも、PIN がない限りデバイスにログオンすることはできません。Windows のセキュリティ保護された資格情報ストアは、デバイス上の生体認証データを保護します。Windows Hello を使ってデバイスのロックを解除することで、承認済みユーザーは、Windows エクスペリエンス、アプリ、データ、Web サイト、およびサービスのすべてにアクセスできます。
Windows Hello 認証システムは、Hello と呼ばれています。Hello では、各デバイスと特定のユーザーを独自に組み合わせています。デバイス間でローミングされません。サーバー間で共有されません。デバイスから簡単には抽出できません。複数のユーザーが 1 つのデバイスを共有する場合、そのデバイスでは、各ユーザーに固有の Hello が与えられます。格納された資格情報のロックを解除 (またはリリース) するために使用できるトークンとして、Hello を捉えることができます。Hello 自体はアプリやサービスの認証を行いませんが、認証を行うための資格情報をリリースします。
Windows 10 の起動時、オペレーティング システムは次の 3 種類の Hello をサポートします。
PIN。Windows Hello を使ってデバイス上の生体認証を有効にする前に、初期 Hello ジェスチャとして PIN を選ぶ必要があります。PIN を設定したら、必要に応じて生体認証ジェスチャを追加できます。資格情報をリリースするには常に PIN ジェスチャを使うため、怪我をしたり、センサーが利用できなかったり、センサーが正しく機能しないなどの理由で、任意の生体認証を使えなくても、デバイスのロックを解除してこれまで通り使うことができます。
顔認識。この種類では、赤外線で表示する特殊なカメラを使用するため、写真やスキャンと実際の人物の違いを確実に見分けられます。複数のベンダーが、このテクノロジを組み込んだ外付けカメラを出荷しており、主要なノート PC の製造元は、このカメラを自社のデバイスにも取り入れています。
指紋認識。この種類では、静電容量方式指紋センサーを使用して指紋をスキャンします。指紋リーダーは Windows コンピューターで長年使われていましたが、最新のセンサーは、信頼性が大幅に向上し、エラーの頻度が低下しています。既存の指紋リーダーのほとんどが (外付けまたはノート PC や USB キーボードとの一体型に関係なく)、Windows 10 で動作します。
これらの Hello ジェスチャの実装に使われる生体認証データは、ローカル デバイスのみに安全に保存されます。ローミングされたり、外付けデバイスやサーバーに送信されることはありません。Windows Hello は、デバイス上に生体認証識別データのみを保存するため、攻撃者が生体認証データを盗むために侵害できる場所は 1 つもありません。他の用途で収集および保存した生体認証 (法執行機関または身元確認目的で収集および保存された指紋など) が公開される侵害が発生しても、大きな脅威にはなりません。攻撃者が実際に生体認証を盗んでも、識別子のテンプレートが手元にあるだけで、攻撃者がこのテンプレートを生体認証センサーに提示できる形式に簡単に変換することはできません。Windows Hello と互換性のあるセンサーは、データ パスも改ざんされにくいため、攻撃者が偽造した生体認証データをうまく挿入できる機会は大幅に減ります。さらに、攻撃者がセンサー パイプラインにデータを挿入しようとする前にも、攻撃者はデバイスへの物理的アクセス権を取得する必要があります。このためには、他のそれほど難しくない攻撃を複数回仕掛けます。
Windows Hello には、いくつかの主なメリットがあります。まず、Microsoft Passport と組み合わせると、資格情報の盗難と共有の問題が効果的に解決されます。攻撃者はデバイスと特定の生体認証の両方を取得する必要があるため、ユーザーに関する知識がない場合、アクセス権の入手は非常に難しくなります。次に、生体認証の使用は、ユーザーがシンプルな認証システムを常に手元に置けるというメリットがあります。覚えられなかったり、失くしたり、置き忘れることはありません。ユーザーは、長すぎて複雑なパスワードを覚えられないと心配するのではなく、すべての Windows デバイスにサインインするための便利で安全な方法を活用できます。最後に多くの場合、Windows Hello を使うためには、展開または管理用に追加するものは何もありません (本ガイド後半に記載のとおり、Microsoft Passport には追加の展開が必要になります)。Windows Hello サポートは、オペレーティング システムに直接組み込まれています。ユーザーまたは企業は、互換性を備えた生体認証デバイスを追加して生体認証ジェスチャ認識を入力し、組織的なロールアウトの一部または個別ユーザーやグループのどちらかが、必要なセンサーを追加します。Windows Hello は Windows に含まれるため、使用を開始する場合に追加で展開する必要はありません。
Microsoft Passport とは
Windows Hello は、個別のユーザを認識するための堅牢な方法をデバイスに提供します。これは、ユーザーと要求したサービスやデータ項目とのパスの最初の部分に対応します。デバイスがユーザーを認識しても、要求されたリソースへのアクセス権を与えるかどうかを決める前に、ユーザーをまだ認証する必要があります。Microsoft Passport は強力な 2FA で、Windows に完全に組み込まれています。これにより、再利用可能なパスワードが、特定のデバイスと Hello や PIN の組み合わせに置き換わります。Microsoft Passport は、従来の 2FA システムの単なる代替機能ではありません。概念的にはスマート カードと似ています。文字列比較ではなく、暗号化プリミティブを使用して認証が行われます。ユーザーのキー マテリアルは、が改ざんされにくいハードウェア内にセキュリティ保護されています。Microsoft Passport では、スマート カード展開に必要なインフラストラクチャ コンポーネントも追加する必要はありません。具体的には、現在 PKI を所持していない場合は必要ありません。Microsoft Passport では、スマート カードの主な利点である、仮想スマート カードの展開の柔軟性と物理スマート カードの堅牢なセキュリティを組み合わせ、それぞれの欠点を排除しています。
Microsoft Passport には、最新の Windows 認証に対して、次の 4 つの大きな利点があります。柔軟性の向上、業界標準ベース、効果的なリスク軽減策、およびエンタープライズ対応です。それでは、各利点を詳しく見てみましょう。
柔軟性
Microsoft Passport はこれまでにない柔軟性を発揮します。再利用可能なパスワードの形式と使用方法は固定されていますが、Microsoft Passport は、管理者とユーザーの両方に認証を管理するためのオプションを提供します。何よりもまず、Microsoft Passport は生体認証識別子と PIN の両方と連携するため、生体認証をサポートしないデバイス上でもユーザーの資格情報は保護されます。ユーザーは、デバイス本体の PIN または生体認証ジェスチャの代わりに、自分の電話を使って資格情報をリリースできます。Microsoft Passport は、使用中のデバイスのハードウェアを上手に活用します。ユーザーが新しいデバイスにアップグレードすると、Microsoft Passport はそのデバイスに対応します。組織は、必要に応じて生体認証センサーを追加することで既存のデバイスをアップグレードすることができます。
また、データ センターの柔軟性も実現します。展開するには、Active Directory 環境に Windows Server 2016 Technical Preview ドメイン コント ローラーを追加する必要がありますが、既存の Active Directory サーバーを置き換えまたは削除する必要はありません。Microsoft Passport に必要なサーバーは、既存のインフラストラクチャに構築され、機能も追加されます。ドメインまたはフォレストの機能レベルを変更する必要はありません。社内サーバーを追加するか、Microsoft Azure Active Directory を使うと、ネットワーク上に Microsoft Passport を展開できます。Microsoft Passport の使用で有効にすべきユーザーの選択は、完全に自分次第です。サポートするポリシーとデバイス、およびユーザーがアクセスする認証要素を選びます。これにより、Microsoft Passport を使って、強力な資格情報保護を現在装備していないユーザーにこれを追加して、既存のスマート カードまたはトークンの展開を簡単に補完したり、機密性の高いリソースまたはシステムに保護を追加する必要のあるシナリオで Microsoft Passport を簡単に展開したりできます (「Microsoft Passport for Work 展開の設計」セクションで説明)。
標準化
ソフトウェア ベンダーと企業ユーザーの両者が、専用 ID と認証システムは将来性がないと認識しています。将来は、さまざまなデバイス、LOB、外部アプリケーションと Web サイト全体で安全な認証を可能にする、オープンで相互運用可能なシステムにかかっています。このため、業界関係者のグループは FIDO (Fast IDentity Online Allianc) を形成し、非営利組織は、強力な認証デバイス間の相互運用性不足と、ユーザーがユーザー名とパスワードを作成と記憶する際に直面する問題の解決に取り組みました。FIDO Alliance は、オンライン サービスのユーザーを安全に認証するパスワードに取って代わる、オープンで拡張性と相互運用性に優れたメカニズムを定義する仕様を開発することで、認証の性質を変化しようとしています。セキュリティ デバイスとブラウザー プラグインの新しい標準を使うと、既存または将来のさまざまな FIDO 対応デバイスのインタフェースとして機能する Web サイトまたはクラウド アプリケーションを実現できます。詳しくは、FIDO Alliance の Web サイトをご覧ください。
Microsoft は、2013 年に FIDO Alliance に加盟しました。FIDO 標準により、グローバル エコシステムが強固なパスワードレス認証のユーザー エクスペリエンスを一貫して大幅に改善するためのユニバーサル フレームワークが実現できます。2014 年 12 月に公開された FIDO 1.0 仕様では、パスワードレス (ユニバーサル認証フレームワーク [UAF] とも呼ばれる) と 2 要素認証 (U2F) の 2 種類の認証が提供されています。FIDO Alliance は、U2F と UAF FIDO 1.0 標準の最高の部分を組み合わせて 2.0 仕様の提案作成に取り組んでいます。Microsoft はこの提案作成に積極的に参加しており、Windows 10 はこれらの概念のリファレンス実装です。Windows 実装は、これらのプロトコルをサポートするだけでなく、ユーザー インターフェイス、ストレージ、認証後のユーザーのデバイス キーやトークンの保護、管理者ポリシーのサポート、展開ツールの提供など、この仕様には含まれていないエンド ツー エンドのエクスペリエンスの他の側面もサポートしています。Microsoft は、FIDO 2.0 仕様を進展させるために、FIDO Alliance と今後も連携する予定です。FIDO 製品の相互運用性は FIDO 認証の特長です。FIDO ソリューションを市場に導入すると、企業とコンシューマーの両方にとって重要なニーズを解決できると Microsoft は考えています。
効率性
Microsoft Passport は、2 つの主要なセキュリティ リスクを効率的に軽減します。まず、ログオン時の再利用可能なパスワードの使用を排除することで、ユーザーの資格情報がコピーまたは再利用されるリスクを軽減します。トラステッド プラットフォーム モジュール (TPM) 標準をサポートするデバイスでは、ユーザーのキー マテリアルをユーザーの TPM に保存できるため、攻撃者によるキー マテリアルの取得と再利用がさらに困難になります。TPM のないデバイスの場合、Microsoft Passport は資格情報データをソフトウェアで暗号化して保存しますが、管理者はこの機能を無効にして、「TPM または何も展開しない」を強制的に設定できます。
次に、Microsoft Passport は集中管理された 1 台のサーバーに依存することはないため、サーバー侵害のリスクが排除されます。論理的には、攻撃者は 1 つのデバイスを侵害しますが、侵入者が環境全体にアクセスするために利用できる攻撃場所は 1 つもありません。
エンタープライズ対応
Windows 10 のすべてのエディションには、個別ユーザー用の Microsoft Passport 機能が含まれています。エンタープライズと個人のユーザーは、Microsoft Passport を活用して互換性のあるアプリケーションとサービスの個別の資格情報を保護できます。さらに、ユーザーが Windows 10 Professional と Windows 10 Enterprise を実行しているエンタープライズは、Microsoft Passport for Work も使用できます。これは、Microsoft Passport の拡張バージョンで、グループ ポリシー オブジェクト (GPO) で PIN の強度と生体認証を使用するための Microsoft Passport の設定を一元的に管理する機能が含まれます。
Microsoft Passport の機能
ID プロバイダー (IDP) でサインインするのに Microsoft Passport を使うには、ユーザーは構成済みデバイスが必要です。つまり、Microsoft Passport を使うためにデバイスを構成すると、Microsoft Passport ライフ サイクルが開始されます。デバイスをセットアップしたら、ユーザーはサービスの認証にそのデバイスを使用できます。このセクションでは、デバイスはどのように登録されるのか、ユーザーが認証を要求した場合に何が起こるのか、キー マテリアルがどのように保存と処理されるのか、どのサーバーとインフラストラクチャのコンポーネントがこのプロセスのさまざまな部分に関係するのかについて考えます。
新しいユーザーまたはデバイスの登録
Microsoft Passport の目標は、ユーザーが、新しいデバイスを開いて、組織のネットワークに安全につなぎ、組織データをダウンロードして管理し、新しい Hello ジェスチャを作成してデバイスを保護できるようにすることです。Microsoft は、登録時に Microsoft Passport と合わせて使用するデバイスのセットアップのプロセスを説明します。
注
これは、Microsoft Passport と Active Directory または Azure AD を合わせて使用する場合に必要な組織構成とは別です。その構成については、本ガイドの後半で説明します。この構成は、ユーザーが登録を開始する前に完了する必要があります。
登録プロセスは次のようになります。
ユーザーは、デバイス上のアカウントを構成します。
このアカウントには、デバイス上のローカル アカウント、社内の Active Directory ドメインに格納されているドメイン アカウント、Microsoft アカウント、または Azure AD アカウントがあります。新しいデバイスの場合、この手順は、Microsoft アカウントへのログオンぐらい簡単な場合があります。Windows 10 デバイス上の Microsoft アカウントにログオンすると、デバイス上で Microsoft Passport が自動的にセットアップされます。ユーザーは、Microsoft Passport を有効にするために特別な作業をする必要はありません。
このアカウントを使用してログオンするには、ユーザーは既存の資格情報を入力する必要があります。
アカウントを「所有」する IDP は、資格情報を受信し、ユーザーを認証します。この IDP 認証には、既存の 2 要素認証、つまり証明が使用される場合があります。たとえば、Azure AD アカウントを使用して新しいデバイスを登録したユーザーは、Azure AD が送信する SMS ベースの証明を入力する必要があります。
ユーザーが IDP に証明を入力したら、ユーザーは PIN 認証 (図 1) を有効にします。
PIN はこの特定の資格情報に関連付けられます。
.png "図 1")
図 1. [アカウント設定] コントロール パネル項目での PIN のセットアップ
ユーザーが PIN を設定すると、すぐに使えるようになります (図 2)。
.png "図 2")
図 2. 設定直後に使えるようになる PIN
Microsoft Passport はデバイスと資格情報のペアを使うため、選んだ PIN は、有効なアカウントとその特定のデバイスとの組み合わせにのみ関連付けられていることに注意してください。PIN は、アカウントの管理者が構成した長さと複雑性のすべてのポリシーに準拠する必要があり、そのポリシーはデバイス側で適用されます。Microsoft Passport がサポートするその他の登録シナリオは次のとおりです。
Windows 8.1 オペレーティング システムからアップグレードするユーザーは、既存のエンタープライズ パスワードを使用してログオンします。これにより、IDP 側で MFA がトリガーされます。テキスト メッセージや音声コードなどの証明の受信と返信の後、IDP はアップグレードした Windows 10 デバイスに対してユーザーを認証し、ユーザーは自分の PIN を設定できるようになります。
通常、スマート カードを使ってログオンするユーザーには、まだログオンしたことのない Windows 10 デバイスに初めてログオンする場合に PIN のセットアップを求めるメッセージが表示されます。
通常、仮想スマート カードを使ってログオンするユーザーには、まだログオンしたことのない Windows 10 デバイスに初めてログオンする場合に PIN のセットアップを求めるメッセージが表示されます。
ユーザーがこのプロセスを完了すると、Microsoft Passport は、デバイスの新しい公開/秘密キーのペアを生成します。TPM はこの秘密キーを生成して保存します。デバイスに TPM がない場合は、秘密キーはソフトウェアで暗号化され、保存されます。この最初のキーは、保護機能キーとも呼ばれます。これは 1 つのジェスチャのみに関連付けられます。つまり、ユーザーが、PIN、指紋、および顔を同じデバイスに登録すると、各ジェスチャに固有の保護機能キーが割り当てられます。保護機能キーは、特定のコンテナーの認証キーを安全にラップします。各コンテナーの認証キーは 1 つのみですが、このキーを別の固有な保護機能キー (それぞれが固有のジェスチャに関連付けられている) でラップして複数のコピーを作成できます。Microsoft Passport は、ユーザーまたは管理者が必要に応じて資格情報をリセットするのに使用できる管理キーも生成します。保護機能キーに加えて、TPM が有効なデバイスは、TPM の構成証明を含むデータ ブロックを生成します。
この時点で、ユーザーには、デバイスで定義された PIN ジェスチャとその PIN ジェスチャに関連する保護機能キーが割り当てられます。つまり、ユーザーは PIN を使ってデバイスに安全にログオンできるため、デバイスの信頼済みセッションを確立し、PIN に代わる方法として生体認証ジェスチャのサポートを追加します。生体認証ジェスチャを追加する場合も、基本的には同じ順番になります。Windows が固有のキー ペアを生成して安全に保存した後、ユーザーは自分の PIN を使ってシステムに対して認証し、新しい生体認証 (「カメラに向かってスマイル!」) を登録します。今後のログオンでは、PIN または登録済み生体認証ジェスチャのいずれかを使用できるようになります。
コンテナーとは
MDM ソリューションに関連して、コンテナーという用語を頻繁に耳にすることがあるかもしれません。Microsoft Passport でもこの用語を使用しますが、少し異なる方法で使用します。このコンテキスト内のコンテナーは、キー マテリアルまたはデータの論理グループの省略表現です。Windows 10 では 2 つのコンテナーをサポートしています。既定のコンテナーは、ユーザーの Microsoft アカウントまたは他のコンシューマー向け ID プロバイダーに関連するキー マテリアルなど、個人アカウント用のユーザーのキー マテリアルを保持します。エンタープライズ コンテナーは、職場または学校のアカウントに関連する資格情報を保持します。
エンタープライズ コンテナーは、組織で登録されたデバイスにのみ存在します。社内の Active Directory または Azure AD など、企業の IDP のキー マテリアルが含まれます。エンタープライズ コンテナーには、Active Directory または Azure AD の主要なデータのみが含まれます。デバイス上にエンタープライズ コンテナーが存在する場合は、既定のコンテナーとは別にロックが解除されます。データと、個人と企業の資格情報およびサービス間のアクセスは、個別に維持されます。たとえば、生体認証ジェスチャを使用して管理するコンピューターにログオンするユーザーは、Web サイトでの商品購入のためにログオンする場合、PIN を入力して個人コンテナーのロックを個別に解除できます。
これらのコンテナーは論理的に分かれています。組織は、ユーザーが既定のコンテナーに保存する資格情報をまったく制御できません。既定のコンテナーのサービスに対して認証されたアプリケーションは、エンタープライズ コンテナーの資格情報を使うことはできません。ただし、個別の Windows アプリケーションは、Microsoft Passport アプリケーション プログラミング インターフェイス (API) を使い、必要に応じて資格情報へのアクセスを要求できるため、Microsoft Passport 活用して、コンシューマーとLOB アプリケーションの両方を拡張できます。
ディスクやレジストリなどに物理コンテナーがないことに留意することが重要です。コンテナーは、関連項目のグループ化に使用される論理ユニットです。Microsoft Passport に保存されたキー、証明書、および資格情報は、コンテナーまたはフォルダーを実際に作成しなくても保護されます。
各コンテナーにはキー セットが実際に保存されており、そのいくつかは他のキーを保護するために使用されます。図 3 では、保護機能キーを使用して認証キーを暗号化し、この認証キーを使用してコンテナーに保存されている各キーを暗号化する例について説明します。
.png "図 3")
図 3. 1 つまたは複数のキー セットを保持する各論理コンテナー
コンテナーには、何種類かのキー マテリアルを含めることができます。
認証キーは、常に非対称の公開/秘密キーのペアです。このキーのペアは登録時に生成されます。ユーザーの PIN または以前生成した生体認証ジェスチャのいずれかを使って、アクセスのたびにロックを解除する必要があります。新しいキーの生成時、ユーザーが PIN をリセットするまで認証キーは存在します。新しいキーを生成したら、これまで古いキーで保護していたすべてのキー マテリアルの暗号化を解除し、新しいキーを使って再暗号化する必要があります。
仮想スマート カード キーは、仮想スマート カードを生成し、コンテナーに安全に保存すると生成されます。ユーザーのコンテナーのロックが解除されると、このキーは利用可能になります。
Secure/Multipurpose Internet Mail Extensions (S/MIME) のキーと証明書は、証明機関 (CA) によって生成されます。ユーザーの S/MIME 証明書に関連付けられたキーは、Microsoft Passport コンテナーに保存されるため、コンテナーのロックが解除されるたび、ユーザーはこのキーを使うことができるようになります。
IDP キー。キーには、使用する IDP に応じて対称キーまたは非対称キーがあります。1 つのコンテナーには、一部制限がありますが、0 個以上の IDP キーを含められます。(たとえば、エンタープライズ コンテナーには 0 個または 1 個の IDP キーを含めることができます。)IDP キーは、図 3 に示すようにコンテナーに保存されます。証明書ベースの Microsoft Passport for Work の場合、コンテナーのロックを解除すると、IDP キーまたはキーのペアへのアクセスを必要とするアプリケーションは、アクセスを要求できます。IDP キーを使用すると、このコンピューターから IDP に送信された認証要求またはトークンの署名または暗号化を行うことができます。通常、IDP キーの有効期間は長いですが、認証キーよりも短い有効期間を設定することもできます。
Microsoft アカウント、Active Directory アカウント、および Azure AD アカウントはすべて、非対称キーのペアを使う必要があります。デバイスが、公開キーと秘密キーを生成し、IDP で公開キーを登録し (後で検証するために保存)、秘密キーを安全に保存します。企業の場合、2 つの方法で IDP キーを生成できます。
IDP キーのペアは、Windows ネットワーク デバイス登録サービス (NDES) を介してエンタープライズ CA と関連付けることができます。このサービスについては、「ネットワーク デバイス登録サービス ガイダンス」で説明します。この場合、Microsoft Passport は、既存の PKI の証明書と同じキーを使って新しい証明書を要求します。このオプションにより、既存の PKI を保持する組織は、必要に応じてその PKI を使い続けられます。人気のある仮想プライベート ネットワーク システムなど、多くのアプリケーションで証明書を使用する必要がある場合、このモードで Microsoft Passport を展開すると、証明書ベースの機能をすべて維持しながら、ユーザーのパスワードからすばやく切り替えることができます。また、企業は保護したコンテナーに追加の証明書を保存することもできます。
IDP は IDP キーのペアを直接生成できます。これにより、PKI を持たないまたは PKI を必要する環境で Microsoft Passport を展開する場合のオーバーヘッドがすぐに低下します。
キーを保護する方法
キー マテリアルを生成する場合は、常に攻撃から保護する必要があります。これを実現する最も堅牢な方法は、ハードウェアをカスタマイズすることです。セキュリティ クリティカルなアプリケーションのキーの生成、保存、および処理には、これまでずっとハードウェア セキュリティ モジュール (HSM) を使用してきました。スマート カードは特別な種類の HSM で、Trusted Computing Group TPM 標準に準拠しているデバイスでもあります。可能であれば、Microsoft Passport for Work 実装は、オンボード TPM ハードウェアを活用して、キーの生成、保存、および処理を行います。ただし、Microsoft Passport と Microsoft Passport for Work にはオンボード TPM は必要ありません。管理者はソフトウェアのキー操作を許可することができます。この場合、コンピューターの管理権限を持つ (またはエスカレートできる) ユーザーは、IDP キーを使って要求に署名できます。または、TPM を持たないデバイスは、TPM を持つデバイスを使ってリモートから認証できる場合もあります。この場合、機密性の高い操作はすべて、TPM を使って実行されるため、キー マテリアルは何も公開されません。
可能であれば、TPM ハードウェアを使用することをお勧めします。TPM は、PIN のブルート フォース攻撃など、さまざまな既知の潜在的な攻撃を防げます。アカウント ロックアウト後も、TPM はさらなる保護を追加します。TPM がキー マテリアルをロックすると、ユーザーは PIN をリセットする必要があります。(つまり、IDP がユーザーの再登録を許可する前に、ユーザーは MFA を使って IDP に対して再認証する必要があります。)PIN をリセットすると、古いキー マテリアルで暗号化されたすべてのキーと証明書は削除されます。
認証
企業のイントラネットで保護されたリソースにログオンまたはアクセスする必要があるインターネット サイトを使用する場合など、ユーザーが保護されたキー マテリアルにアクセスする場合、認証プロセスでは最初にキーのリリースと呼ばれるプロセスが行われ、ユーザーの PIN または生体認証ジェスチャを入力してデバイスのロックを解除します。ドアのロックを解除する物理的な鍵を使用する場合を考えてみてください。ドアのロックを解除する前に、ポケットまたは財布から鍵を取り出す必要があります。組織のネットワークに接続した個人デバイスの場合、ユーザーは PIN または生体認証を使ってキーをリリースします。社内または Azure AD ドメインに接続したデバイスの場合、組織の PIN を使います。
このプロセスでは、デバイス上のプライマリ コンテナーの保護機能キーのロックを解除します。そのコンテナーのロックが解除されると、アプリケーション (つまりユーザー) は、コンテナー内にある IDP キーをすべて使うことができます。
これらのキーを使って、IDP に送信される要求に署名し、指定したリソースへのアクセスを要求します。キーのロックを解除しても、アプリケーションはキーを自由に使えないことを理解することが重要です。アプリケーションは特定の API を使って、特定の動作にキー マテリアルが必要な操作を要求できます (たとえば、電子メール メッセージの暗号化の解除または Web サイトへのログオン)。これらの API 使ってアクセスする場合、ユーザーのジェスチャなど明示的な検証は必要ありません。キー マテリアルは要求元のアプリケーションに公開されません。代わりに、アプリケーションは、認証、暗号化、または暗号化解除を求め、Microsoft Passport レイヤーは、実際の作業を処理し、結果を返します。必要に応じて、アプリケーションはロック解除されたデバイス上でも強制的に認証を要求できます。PIN の再入力または認証ジェスチャの実行を求めるメッセージが表示されます。ここでは、機密性の高いデータまたは操作の保護レベルをさらに追加します。たとえば、デバイスのロック解除に同じアカウントと PIN またはジェスチャをすでに使っていても、ユーザーがアプリケーションを購入する場合、Windows ストアを構成して認証を要求するとします。
実際の認証プロセスは次のようになります。
クライアントは空の認証要求を IDP に送信します。(これはハンドシェイク プロセスの場合だけです。)
IDP は nonce と呼ばれるチャレンジを返します。
デバイスは、適切な秘密キーを使って nonce に署名します。
デバイスは、元の nonce、署名付き nonce、および nonce の署名に使うキーの ID を返します。
IDP は、キー ID で指定した公開キーを取得し、このキーを使って nonce の署名を検証し、デバイスが返した nonce と元の nonce が一致することを確認します。
手順 5 の確認がすべて成功したら、IDP は 2 つのデータ項目を返します。デバイスの公開キーで暗号化された対称キーとその対称キーで暗号化されたセキュリティ トークンです。
デバイスは、その秘密キーを使って対称キーの暗号化を解除し、次にその対称キーを使ってトークンの暗号化を解除します。
デバイスは、認証の証明として IDP からのトークンを示して、元のリソースの通常の認証要求を行います。
IDP が署名を検証する場合、指定したユーザーとデバイスから送られた要求であることを確認します。デバイスに固有の秘密キーで nonce に署名します。これにより、ユーザー、デバイスの種類、またはその両方に基づいてコンテンツ アクセスにポリシーを適用できるように、IDP は要求元のユーザーとデバイスの ID を決定できます。たとえば、IDP は、モバイル デバイスのリソース セットとデスクトップ デバイスの別のリソース セットそれぞれ 1 つずつへのアクセスを許可できます。
Windows 10 の今後のリリースで予定されているリモート ロック解除は、2 要素認証としてモバイル デバイスからリモート認証をシームレスに実現する次のシナリオに基づいています。たとえば、自分の会社内で別の部門を訪れ、一時的にコンピューターを確認する必要がありますが、盗難の可能性があるため資格情報を公開したくないとします。資格情報を入力する代わりに、Windows 10 のログオン画面で [他のユーザー] をクリックしてユーザー名を入力し、リモート認証のタイトルを選び、自分の電話のアプリを使います。ここでは、組み込まれた顔認識センサーを使ってすでにロックを解除しています。電話とコンピューターでは、Bluetooth 経由でペアリングとハンドシェイクが行われます。電話に認証 PIN を入力すると、コンピューターは IDP から ID 確認を受け取ります。これらすべてにおいて、どこかにパスワードを入力したり、PC に PIN を入力したりする必要はありません。
インフラストラクチャ
Microsoft Passport は、インフラストラクチャで利用可能な互換性 IDP を使用できるかに依存しています。現時点では、次の 4 つの展開の可能性があります。
Active Directory 証明書サービスを中心とした既存の Windows ベース のPKI を使用します。このオプションには、デバイスに証明書を発行する方法など、その他のインフラストラクチャが必要です。社内環境の Microsoft System Center 2012 R2 Configuration Manager Technical Preview 以降、または Microsoft Passport に参加するモバイル デバイスを管理できる Microsoft Intune など、NDES を使ってデバイスを直接登録できます。
Microsoft Passport の IDP として機能するように Windows Server 2016 Technical Preview ドメイン コントローラーを構成できます。このモードでは、Windows Server 2016 Technical Preview ドメイン コントローラーは、既存の Windows Server 2008 R2 以降のドメイン コントローラーと共に IDP として機能します。既存のすべてのドメイン コントローラーを置き換え、Active Directory サイトごとに少なくとも 1 つの Windows Server 2016 Technical Preview ドメイン コントローラーだけを導入し、フォレスト Active Directory ドメイン サービス (AD DS) スキーマを Windows Server 2016 Technical Preview に対して更新するための要件はありません。
ドメイン コントローラーとグローバル カタログを探すためにクライアントが使う通常の検出メカニズムは、ドメイン ネーム システム (DNS) SRV レコードに依存していますが、このレコードにはバージョン データが含まれていません。Windows 10 コンピューターは、すべての利用可能な Active Directory サーバーを検索する SRV レコードを DNS に照会し、Microsoft Passport IDP として機能するレコードを識別するために各サーバーに照会します。ユーザーが生成する認証要求の数、ユーザーが配置される場所、およびネットワークの設計すべてが、必要な Windows Server 2016 Technical Preview ドメイン コントローラーの数を増やします。
Azure AD は、単独で、または社内 AD DS フォレストと一緒に IDP として機能します。Azure AD を使う組織では、Azure AD Device Registration サービスが提供する機能を使ってローカル ドメインにデバイスを追加しなくても、デバイスを直接登録できます。
IDP とは別に、Microsoft Passport には MDM システムも必要です。このシステムは、Azure AD を使う場合はクラウド ベースの Intune、または本ドキュメントの「展開の要件」に記載されたシステム要件に適合する社内の System Center Configuration Manager 展開になります。
Microsoft Passport for Work 展開の設計
Microsoft Passport for Work は、現在および将来のディレクトリ インフラストラクチャとデバイス展開を統合することを目的としていますが、ここでの柔軟性とは、展開の設計時に考慮すべき注意事項がたくさんあることを意味しています。この決定事項の一部は技術的ですが、組織的なものや政治的なものまであります。このセクションでは、Microsoft Passport for Work の実装方法に関して決定する必要のある重要事項を紹介します。個々のデバイスは、ユーザー側のインフラストラクチャを変更することなく、Microsoft Passport の各バージョンを使えることを忘れないでください。Microsoft Passport for Work を使用すると、ユーザー認証とデバイス登録を制御して一元的に管理できます。Microsoft Passport for Work の初期バージョンを使用するには、各デバイスに Azure AD の ID が必要になります。これにより、デバイスを自動登録して、新しいデバイスの登録方法とオプション ポリシーの適用方法の両方を提供し、Microsoft Passport for Work を管理します。
1 つの展開方法
さまざまな組織が、機能とニーズに応じて、Microsoft Passport の展開にさまざまなアプローチを必ず取りますが、展開方法は 1 つのみです。組織全体に Microsoft Passport for Workを展開して、すべてのデバイスとリソースを最大限に保護します。組織がこの展開方法を実現するためには、次の 3 つの基本的な手段のいずれかを実行します。
組織で最も適したデバイスまたはユーザーの展開方法に従って、Microsoft Passport for Work を展開します。
強力な認証資格情報を保持するユーザーに対してのみ重要なリソースへのアクセスを制限する従来のアクセス ポリシーを使って、価値の高いターゲットまたはリスクの高いターゲットにMicrosoft Passport for Work を最初に展開します。
物理スマート カードまたは仮想スマート カードと共に強力な認証の追加形式として Microsoft Passport for Work を使い、既存の多要素環境に Microsoft Passport for Work を統合します。
すべての場所で Microsoft Passport for Work を展開する
この方法では、組織的なロールアウトで組織全体に Microsoft Passport を展開します。いくつかの点で、この方法は他のデスクトップの展開プロジェクトと似ています。唯一の違いは、Windows 10 デバイスで Microsoft Passport の使用を開始する前に、デバイスの登録をサポートするために Microsoft Passport インフラストラクチャを所定の場所に用意しておくことが必要です。
注
その後も、インフラストラクチャを変更することなく、Windows 10 にアップグレードしたり、新しい Windows 10 デバイスを追加したりできます。デバイスを Azure AD に追加して適切なポリシーを受け取るまで、デバイスで Microsoft Passport for Work を使うことができないだけです。
この方法の主な利点は、組織のすべての部分を平等に保護することです。高度な攻撃者には、重要な情報を持たないけれども、悪用して重要な情報を入手できるユーザーやシステムなど、大規模な組織のセキュリティの弱点を特定することでセキュリティを侵害するほどの優れたスキルがあります。企業データのアクセスに攻撃者が使えるすべてのデバイスに対して一貫した保護を適用することで、この種の攻撃から見事に保護します。
この方法の欠点は複雑性です。小規模な組織にとって、すべてのデバイスに対する新しいオペレーティング システムのロールアウトの管理は、彼らの経験と能力の範囲を超えている場合があります。これらの組織の場合、ユーザーは自分でアップグレードすることができます。新しいユーザーは、参加時に新しいデバイスを受け取るため、Windows 10 になるかもしれません。特に高度に分散したり、多くの物理的なサイトに運用が分かれている大規模な組織では、展開に関する多くの知識とリソースがあるかもしれませんが、大規模なユーザー ベースと空間全体でロールアウト作業を調整する場合の課題に直面します。
Windows 10 のデスクトップ展開について詳しくは、Windows 10 TechCenterをご覧ください。
この展開方法の重要な点の 1 つは、Windows 10 をどのようにしてユーザーの手元に支給するかです。さまざまな組織でハードウェアとソフトウェアの更新方法は大きく異なるので、万能な方法はありません。たとえば、一部の組織では、既存のハードウェアで 2 ～ 3年ごとに新しいデスクトップ オペレーティング システムをユーザーの手元に支給し、必要な場合にのみ新しいハードウェアを追加する組織的な方法を進めます。他の組織では、購入したデバイスに付属する Windows クライアント オペレーティング システムのバージョンに関係なく、ハードウェアを交換して展開します。どちらの場合でも、通常、サーバーとサーバー オペレーティング システムの展開サイクルは異なり、デスクトップとサーバーのサイクルが、組織的な場合と、組織的でない場合があります。
ユーザーに対する Windows 10 展開の問題だけでなく、方法とタイミング (または可能性) を考慮する必要があります。ユーザーに生体認証デバイスを展開する可能性があります。Windows Hello は複数の生体認証識別子を活用できるため、デバイス オプションが幅広くなります。選択した生体認証を組み込んだ新しいデバイスの購入、選択ユーザーへの適切なデバイスの配布、スケジュールされたハードウェア交換に含まれる生体認証デバイスのロールアウトとユーザーにデバイスが届くまでの PIN ジェスチャの使用、2 要素認証としてのリモート ロック解除の単独使用などがあります。
重要またはリスクの高いターゲットへの展開
この方法では、ほとんどのネットワークですべてのアセットが同様に保護されているか、または同様の価値があるかが考慮されます。これには 2 つの方法があります。1 つ目の方法では、価値が高いために侵害のリスクが最も高いユーザーとサービスを保護することに焦点を当てます。たとえば、機密性の高い内部データベースまたは主な経営幹部のユーザー アカウントなどです。別の方法では、頻繁に出張するユーザー (つまり、デバイスの紛失や盗難または通行中の資格情報の盗難などの高いリスクを持つユーザー) など、最も脆弱なネットワーク領域に焦点を当てます。どちらの場合でも方法は同じです。Microsoft Passport を選択的かつ迅速に展開して、特定のユーザーとリソースを保護します。たとえば、機密性の高い内部データベースにアクセスする必要があるすべてのユーザーに、生体認証センサーの付いた新しい Windows 10 デバイスを配布し、それらのユーザーがデータベースに Microsoft Passport でセキュリティで保護しながらアクセスできるように最低限必要なインフラストラクチャを展開するとします。
Microsoft Passport for Work の重要な設計機能の 1 つは、ユーザーが組織の IDP (社内、ハイブリッド、または Azure AD に関係なく) で独自のデバイスを登録できるようにすることで、Bring Your Own Device (BYOD) 環境をサポートすることです。最も重要な潜在的ターゲットへの追加安全対策として生体認証を理想的に使うことで、最も脆弱なユーザーまたは資産を保護する Microsoft Passport をすばやく展開する機能を活用できる場合があります。
インフラストラクチャへの Microsoft Passport の統合
スマート カード、仮想スマート カード、またはトークン ベースのシステムにすでに投資している組織は、Microsoft Passport のメリットを引き続き受けられます。これらの組織の多くは、展開の経費と複雑性が原因で、物理トークンとスマート カードを使って重要な資産しか保護していません。Microsoft Passport は、再利用可能な資格情報を現在使っているユーザーを保護するため、これらのシステムを有効に補完します。すべてのユーザーの資格情報の保護は、資格情報に不正にアクセスして侵害を拡大しようとする攻撃者を回避する重要な手順の 1 つです。この方法は、スケジュール設定と展開にも大きな柔軟性を与えます。
一部の企業では多目的スマート カードを展開しています。これにより、ビルの入出管理、コピー機や他のオフィス機器の利用、食堂での購入品の記録、リモート ネットワーク アクセス、およびその他のサービスが提供されます。このような環境で Microsoft Passport を展開しても、これらのサービスに対してスマート カードを使い続けられます。既存の使用事例に合わせて既存のスマート カード インフラストラクチャを所定の場所に残し、Microsoft Passport にデスクトップとモバイル デバイスを登録し、Microsoft Passport を使って ネットワークとインターネット リソースへのアクセスをセキュリティで保護します。この方法では、既存の PKI を登録サービスと Microsoft Passport 自体にリンクする必要があるため、インフラストラクチャの複雑化と組織の高度な成長が必要です。
スマート カードは、Microsoft Passport 登録の初期ログインをブートストラップするなど、他の重要な方法で Microsoft Passport を効果的に補完できます。ユーザーがデバイス上で Microsoft Passport に登録する場合、登録プロセスの一部では従来のログオンが必要になります。スマート カードや仮想スマート カードに必要なインフラストラクチャをすでに展開している組織は、従来のパスワードを使う代わりに、スマート カードまたは仮想スマート カードでログオンすることで、ユーザーが新しいデバイスを登録できるようにします。ユーザーがスマート カードを使って自分の ID を組織 IDP に証明した後、ユーザーが PIN をセットアップすると、以降のログオンで Microsoft Passport が使えるようになります。
ロールアウト方法の選択
選択するロールアウト方法は、いくつかの要因によって異なります。
展開する必要のあるデバイスの数。この数は展開全体に大きな影響を与えます。75,000 ユーザーのグローバル ロールアウトは、さまざまな都市の 200 ～ 300 ユーザーのグループ向けの段階的な展開とは要件が異なります。
Microsoft Passport for Work 保護を展開するスピード。これは、従来のコストと利点のトレードオフ関係です。Microsoft Passport for Work のセキュリティ上の利点と、広範囲な展開に必要なコストと時間とのバランスを取る必要があります。関係するコストと利点をどのように評価するかによって、それぞれの組織でまったく異なる決定が行われる場合があります。Microsoft Passport を使って、できるだけ短時間で、できるだけ幅広くカバーすると、セキュリティ上の利点が最大限に発揮されます。
展開するデバイスの種類。Windows デバイスの製造元は、Windows 10 に最適な新しいデバイスを積極的に発表しているため、新しく購入したタブレットやポータブル デバイスで初めて Microsoft Passport を展開し、その後、通常の交換時期に合わせてデスクトップ上で Microsoft Passport を展開するかもしれません。
現在のインフラストラクチャの概要。Microsoft Passport の各バージョンは、Active Directory 環境に応じて変更する必要はありませんが、Microsoft Passport for Work をサポートするには、互換性 MDM システムが必要になる場合があります。ネットワークのサイズと構成に応じて、モバイル登録と管理サービスの展開そのものが大きなプロジェクトになる場合があります。
クラウドの計画。すでにクラウドへの移行を計画している場合は、社内環境を大幅に変更することなく、既存の社内 AD DS セットアップと一緒に IDP として Azure AD を使えるため、Microsoft Passport for Work の展開プロセスが簡単になります。Microsoft Passport for Work の今後のバージョンでは、クラウドから Microsoft Passport for Work を使えるように、すでに Azure AD パーティション内の社内 AD DS ドメインのメンバーであるデバイスを同時に登録できる機能をサポートします。AD DS と Azure AD を組み合わせたハイブリッド展開は、ユーザーに Microsoft Passport for Work のすべてのサービス (および Microsoft Office 365 の統合) を提供しながら、ローカルの AD DS ドメインに対してコンピューター認証とポリシー管理を維持できます。社内 AD DS のみを使う予定の場合、社内環境の設計と構成では、加える必要のある変更の種類を指示します。
展開要件
表 1 では、企業内での Microsoft Passport for Work の展開に関する 6 つのシナリオを紹介します。Windows 10 の初回リリースでは、Azure AD のみのシナリオがサポートされています、社内の Microsoft Passport for Work のサポートは、2015 年後半でリリースされる予定です。 (詳しくは「ロードマップ」をご覧ください。)
選んだシナリオに応じて、Microsoft Passport for Work の展開には次の 4 つの要素が必要になる場合があります。
Microsoft Passport をサポートする組織 IDP。これには、Azure AD、または既存の AD DS フォレスト内にある一連の社内 Windows Server 2016 Technical Preview ドメイン コント ローラーがあります。Azure AD を使うと、Microsoft Passport IDP として機能する Azure AD と古いの認証要求を処理する社内の AD DS 環境を合わせた、ハイブリッド ID 管理を確立できます。この方法では、Microsoft Exchange Server または Microsoft SharePoint など、旧バージョンの Windows や社内アプリケーションを実行するコンピューター アカウントとデバイスを管理することで、Azure AD の柔軟性をすべてを提供します。
証明書を使う場合は、Microsoft Passport for Work のポリシー管理を許可する MDM システムが必要です。社内またはハイブリッド展開のドメインに参加しているデバイスには、Configuration Manager Technical Preview 以降が必要です。Azure AD の展開には、Intune または互換性のある Microsoft 以外 MDM ソリューションを使う必要があります。
社内展開でデバイスへの Microsoft Passport の資格情報のプロビジョニングをサポートするには、Windows Server 2016 Technical Preview に含まれる Active Directory フェデレーション サービス (AD FS) の近日公開予定バージョンが必要です。このシナリオでは、AD FS は、クラウド ベースの展開で Azure AD が実行するプロビジョニングに代わるものです。
証明書ベースの Microsoft Passport の展開では、登録が必要なすべてのデバイスにアクセス可能な CA を含む PKI が必要です。社内で証明書ベースの Microsoft Passport を展開する場合、実際には Windows Server 2016 Technical Preview ドメイン コント ローラーは必要ありません。社内の展開では、Windows Server 2016 Technical Preview の AD DS スキーマを適用し、AD FS の Windows Server 2016 Technical Preview バージョンをインストールしている必要があります。
表 1. Microsoft Passport の展開要件
| Microsoft Passport の認証方法 | Azure AD | ハイブリッド Active Directory | 社内 Active Directory のみ |
|---|---|---|---|
| キー ベース | Azure AD サブスクリプション |
|
1 つ以上の Windows Server 2016 Technical Preview ドメイン コントローラー Windows Server 2016 Technical Preview の AD FS |
| 証明書ベース | Azure AD サブスクリプション PKI インフラストラクチャ Intune |
|
AD DS の Windows Server 2016 Technical Preview スキーマ Windows Server 2016 Technical Preview の AD FS PKI インフラストラクチャ System Center 2012 R2 Configuration Manager SP2 以降 |
Windows 10 の現在のリリースが Azure AD のみのシナリオをサポートしていることに注意してください。Microsoft では、今後リリース予定の Microsoft Passport for Work の機能について、組織が環境を準備できるようにするため、表 1 に将来的な予定を記載しています。
ポリシー設定の選択
Microsoft Passport for Work の展開におけるもう 1 つの重要な側面は、企業に適用するポリシー設定を選ぶことです。この選択には 2 つの部分があります。Microsoft Passport 自体を管理するために展開するポリシーと、デバイスの管理と登録を制御するために展開するポリシーです。有効なポリシーを選ぶための詳細はこのガイドで説明しませんが、「Microsoft Intune のモバイル デバイス管理機能」は参照例として役立つ可能性があります。
Microsoft Passport の実装
個人の資格情報を保護するだけの場合、各ユーザー デバイス上での Windows Hello または Microsoft Passport の使用には、構成は必要ありません。企業がこの機能を無効にしないかぎり、組織の IDP に登録されているデバイス上であっても、ユーザーは個人の証明書に Microsoft Passport を使うことができます。ただし、ユーザーが Microsoft Passport for Work を使えるようにするには、「展開の要件」セクション前半に記載されているとおり、インフラストラクチャに必要なコンポーネントを追加する必要があります。
Azure AD の使い方
Azure AD のみの組織で Microsoft Passport for Work を使う場合、次の 3 つのシナリオがあります。
Office 365 に含まれる Azure AD のバージョンを使う組織。これらの組織の場合、追加作業は必要ありません。一般利用として Windows 10 がリリースされている場合、Microsoft によって、Office 365 Azure AD のスタックの動作が変更されています。ユーザーが職場または学校のネットワークへの参加を選ぶと (図 4)、デバイスは Office 365 テナントのディレクトリ パーティションに自動的に追加され、このデバイスの証明書が発行され、テナントがこの機能を登録した場合、デバイスは Office 365 MDM の対象となります。さらに、ユーザーにはログオンを求めるメッセージが表示されます。MFA が有効な場合は、Azure AD がユーザーの電話に送信する MFA 証明 の入力を求めるメッセージが表示されます。
Azure AD の無料利用枠を使う組織。これらの組織の場合、Microsoft は、Azure AD への自動ドメイン参加を有効にしていません。無料利用枠にサインアップした組織は、この機能を有効または無効にするオプションが与えられるため、組織の管理者が有効にすると決めないかぎり、自動ドメイン参加は有効にはなりません。この機能を有効にした場合、図 4 に示す [職場または学校への接続] ダイアログ ボックスを使用して Azure AD ドメインに参加するデバイスは、Microsoft Passport for Work サポートに自動的に登録されますが、これまで参加していたデバイスは登録されません。
Azure AD の MDM 機能一式にアクセスできる Azure AD Premium に登録した組織。この機能には、Microsoft Passport for Work を管理するコントロールが含まれます。Microsoft Passport for Work の使用を無効または強制できるポリシーを設定して、TPM の使用を要求し、デバイスの PIN セットの長さと強度を制御できます。
.png "図 4")
図 4: Office 365 組織の参加による Azure AD へのデバイスの自動登録
デバイス登録の有効化
証明書付き Microsoft Passport for Work を使う場合、デバイスの登録システムが必要になります。つまり、Configuration Manager Technical Preview、Intune、互換性のある Microsoft 以外の MDM システムをセットアップし、デバイスを登録できるように有効にします。これは、IDP に関係なく、証明書付き Microsoft Passport for Work を使えるようにするための前提条件です。それは、登録システムが必要な証明書を持つデバイスをプロビジョニングするためです。
Microsoft Passport ポリシーの設定
Windows 10 の初回リリースでは、Microsoft Passport for Work を使用すると、次の設定を制御できます。
Microsoft Passport が TPM セキュリティ ハードウェアを備えたデバイス上のみで使えるように要求できます。つまり、デバイスは TPM 1.2 または TPM 2.0 を使います。
ハードウェア推奨オプションで Microsoft Passport を有効にできます。つまり、使用可能な場合は TPM 1.2 または TPM 2.0 によって、または TPM が使用可能でない場合はソフトウェアによってキーが生成されます。
ユーザーが証明書ベースの Microsoft Passport を使えるかどうかを構成することができます。これは、別途適用するポリシーではなく、デバイス展開プロセスの一部として行われます。
ユーザーが登録時に生成する PIN の長さと複雑性を定義できます。
組織で Windows Hello の使用を有効にするかどうかを制御できます。
これらの設定は、MDM システムの GPO または構成サービス プロバイダー (CSP) を通じて実装できるため、ツールは使い易く、柔軟性に優れており、任意のユーザーのみに設定を適用することができます。(Microsoft Passport for Work CSP について詳しくは、「PassportForWork CSP」をご覧ください。)
ロードマップ
ユニバーサル Windows アプリとサービスが進化するスピードは、Windows の従来のサイクル (設計/ビルド/テスト/リリース) が顧客のニーズを満たすのに時間がかかり過ぎることを意味しています。Windows 10 のリリースの一環として、Microsoft は、Windows の開発、テスト、および配布の方法を変化しようとしています。3 ～ 5 年ごとの大規模なモノリシック リリースの代わりに、Windows エンジニアリング チームは、セキュリティ、品質、操作性を犠牲にせずに、小規模なリリースの頻度を増やし、新しい機能とサービスをすばやく市場に投入しようとしています。このモデルは、Office 365 と Xbox エコシステムでうまく機能しました。
Windows 10 の初回リリースでは、Microsoft は、Microsoft Passport と Windows Hello の次の機能をサポートしています。
Windows の指紋リーダー フレームワークを使用した指紋リーダーによる生体認証
互換性のある赤外線対応カメラを搭載したデバイスでの顔認識機能
個人で所有するデバイスと企業が管理するデバイス上にある個人の資格情報用 Microsoft Passport
クラウド専用 Azure AD を展開した組織をサポートする Microsoft Passport for Work
Microsoft Passport の PIN の長さと複雑性を制御するグループ ポリシー設定
Windows 10 の今後のリリースでは、次の追加機能のサポートを追加する予定です。
虹彩認識を含む、生体認証識別子の他の種類
社内 Azure AD 展開とハイブリッド社内展開/Azure AD 展開用のキー ベースの Microsoft Passport for Work の資格情報
スマート カードや仮想スマート カードの証明書など、信頼済み PKI で発行された Microsoft Passport for Work の証明書
悪意のあるユーザーまたはプログラムがソフトウェアでキーを作成できないようにキーを保護する TPM の構成証明 (このキーは TPM を証明できないため、偽造を識別できる)
長期的に見て、Microsoft は、Microsoft Passport と Windows Hello の両方の機能の改善や拡張を継続し、管理性と安全性に関する顧客の追加要件にも対応できるようにします。また、FIDO Alliance やさまざまなサード パーティと連携し、Web と LOB のアプリケーション開発者の両者に Microsoft Passport を採用してもらえるように努力しています。