Windows 10 Mobile セキュリティガイド

[アーティクル]
04/01/2016

このガイドでは、ID とアクセス制御、データ保護、マルウェアへの抵抗、およびアプリプラットフォームのセキュリティなど、Windows 10 Mobile オペレーティングシステムで最も重要なセキュリティ機能について詳しく説明します。

概要

Windows 10 Mobile は、スマートフォンと小型のタブレット向けに設計されています。使用されているセキュリティテクノロジは、あらゆる攻撃によるセキュリティ上の既知の脅威や最新の脅威から保護するために Windows 10 オペレーティングシステムで使用されているものと同じです。Windows 10 Mobile で採用されているセキュリティ機能は、大まかに次のカテゴリに分けられます。

ID とアクセス制御: ID とアクセス制御は、ユーザー認証のセキュリティの簡略化と強化を同時に実現するために大幅に拡張されています。導入しやすく使いやすい多要素認証 (MFA) を通じてユーザー ID を適切に保護する Windows Hello と Microsoft Passport などがあります。(Windows Hello のご利用には、Windows 生体認証フレームワークをサポートする顔認証や虹彩認証のための特殊な赤外線 (IR) カメラ、または指紋リーダーが必要です。)
データ保護: セキュリティ侵害に対する機密データの保護が強化されています。Windows 10 Mobile では複数のデータ保護テクノロジが使用されていますが、それらは使いやすく管理しやすい方法で提供されています。
マルウェアへの抵抗: Windows 10 Mobile は、マルウェアの脅威を軽減するため、エンタープライズレベルのセキュリティで保護されたハードウェアとセキュアブートをサポートすることで、重要なシステムリソースとアプリを保護します。
アプリプラットフォームのセキュリティ: Windows 10 Mobile のエンタープライズレベルのアプリプラットフォームは、複数層のセキュリティを提供しています。たとえば、Windows ストアでは、マルウェアがデバイスに到達するを防ぐために、すべてのアプリでマルウェアのチェックが行われます。さらに、AppContainer でアプリケーションを分離して、悪意のあるアプリが他のアプリを侵害することを防ぎます。

このガイドでは、これらのテクノロジの各概要と、それらを使用して Windows 10 Mobile のデバイスを保護する方法ついて説明します。

ID とアクセス制御

セキュリティの基本的要素として、ユーザーは一意の ID を持ち、その ID がリソースにアクセスするのを許可または拒否される、という概念があります。この概念は従来アクセス制御と呼ばれ、次の 3 段階からなります。

識別 - ユーザー (サブジェクト) が、ファイルやアプリなどのリソース (オブジェクト) にアクセスするために一意の ID をコンピューターシステムにアサートします。
認証 - アサートされた ID を証明し、サブジェクトが本当にサブジェクトであることを検証するプロセスです。
承認 - システムは、認証されたサブジェクトのアクセス権とオブジェクトのアクセス許可を比較し、要求されたアクセスを許可または拒否します。

これらの要素の実装方法により、攻撃者による機密データへのアクセスを防ぐ方法が異なります。ID が証明され、データにアクセスすることが承認されたユーザーだけがそのデータにアクセスできます。ただし、セキュリティの観点では、ID の証明にはさまざまなレベルがあり、承認の制限にもさまざまな要件があります。アクセス制御の柔軟性はほとんどの企業環境で必要なため、オペレーティングシステムにとっては課題となります。表 1 に、Windows のアクセス制御の一般的な課題と Windows 10 Mobile による解決策を示します。

表 1.アクセス制御の一般的な課題に対する Windows 10 Mobile による解決策

アクセス制御の課題	Windows 10 Mobile による解決策
多くの組織では、信頼性の高い代替手段の導入は複雑すぎ、コストもかかるため、ユーザーを承認して企業アプリケーションや企業ネットワークにアクセスするのを許可するために、パスワードを使用しています。	Windows Hello は生体認証を使用してユーザーを識別し、Microsoft Passport と密接に統合されているデバイスをロック解除してユーザーを識別、認証して、Windows 10 Mobile とそれをサポートする生体認証ハードウェアからユーザーが企業ネットワークや企業アプリケーションにアクセスするのを承認します。
組織がスマートカードを使用する場合は、スマートカードリーダーと、スマートカードの管理ソフトウェアを購入する必要があります。このような解決策は複雑で、導入にコストがかかるだけでなく、モバイルの生産性を低下させる傾向があります。	Windows Hello を Microsoft Passport と組み合わせることで、組織内全体に MFA を容易に、かつ費用対効果の高い方法で展開することができ、セキュリティに対する組織の姿勢を強化することができます。
モバイルデバイスのユーザーは、パスワードをタッチキーボードに入力する必要があります。そのような方法で複雑なパスワードを入力すると間違いやすく、キーボードより非効率的です。	Windows Hello は、生体認証センサーを備えたデバイスで、虹彩認証、指紋認証、顔認識ベースの認証ができます。このような生体認証識別オプションは、パスワードによるログオンよりも便利で効率的です。
企業のサービスにログオンする際に、長く複雑なパスワードを入力しなければない、しかも頻繁にパスワードの変更を強いられることをユーザーは不満に思っています。このストレスから、パスワードを再利用したりメモ帳に書き留めたり、脆弱なパスワードを作ったりすることが頻繁に起きています。	Microsoft Passport は、ユーザーが 1 度サインインすれば、複雑なパスワードを再入力しなくても、企業のリソースにアクセスできるようにします。認証資格情報は、組み込みのトラステッドプラットフォームモジュール (TPM) によりデバイスにバインドされ、削除されることはありません。

以降のセクションでは、これらの課題と解決策について詳しく説明します。

Microsoft Passport

Microsoft Passport では、パスワードの代わりに、Windows デバイスに完全に統合された強力な MFA が使用されます。認証には、Microsoft Azure Active Directory (Azure AD) を登録したデバイスと、デバイスをロック解除するための PIN または Windows Hello の生体認証ジェスチャが必要です。Microsoft Passport は、概念的にはスマートカードに似ていますが、公開キー基盤や追加のハードウェアの実装を必要とせず、生体認証の識別をサポートする点で、より柔軟性があります。

Microsoft Passport には、以前の Windows 認証に対して、次の 3 つの大きな利点があります。柔軟性の向上、業界標準ベース、より効果的なリスク軽減です。

効率性

まず、Microsoft Passport ではログオン時にパスワードを使う必要がなくなるため、攻撃者がユーザーの資格情報を盗んで再利用するリスクが軽減されます。ユーザーの秘密キーが含まれているユーザーキーマテリアルは、それを生成するデバイスでのみ使うことができます。キーマテリアルは TPM により保護され、これにより、キーマテリアルを取得して再利用しようとする攻撃者から保護することができます。すべての Windows 10 Mobile デバイスが TPM を装備していることは、Windows ハードウェア認定プログラムの要件になっています。

攻撃者が TPM で保護された Microsoft Passport 資格情報を侵害するためには、物理デバイスにアクセスした後、ユーザーの生体認証識別情報を偽装するかユーザーの PIN を推測する方法を見つける必要がありますが、これらはすべて、TPM のブルートフォース抵抗機能がモバイルデバイスをロックするか、盗難に対する保護メカニズムが起動されるか、またはユーザーまたは企業内管理者によりデバイスがリモートで消去される前に実行される必要があります。このテクノロジは、攻撃者がユーザーの資格情報を侵害する機会を大幅に減らします。

柔軟性

Microsoft Passport は、エンタープライズレベルのセキュリティと共にこれまでにない柔軟性も実現します。

最も重要な点は、Microsoft Passport は生体認証および PIN と連動して、長くて複雑なパスワードに勝るオプションを提供することです。ユーザーが、頻繁に変更されるパスワードを記憶し、再入力しなくても、Microsoft Passport では Windows Hello を通じて PIN ベース認証と生体認証を行って、ユーザーをより安全に識別することができます。

ユーザーがログオンしている Windows 10 Mobile デバイスも、認証要素となります。デバイスで使用される資格情報と秘密キーは、デバイス固有のもので、デバイスの TPM にバインドされています。

将来的には、Microsoft Passport は、ユーザーが Windows 10 Mobile デバイスをリモート資格情報として使用して、Windows 10 が実行されている PC にサインインすることを可能にします。PIN または生体認証を使って電話のロックを解除し、電話から PC のロックを解除するようになります。ユーザーがサインインしようとしている PC とユーザーの資格情報とが物理的に別の場所にある状況でも、Microsoft Passport により電話でサインインができます。この事実は、MFA の実装を、他のソリューションよりも低コストでシンプルなものにするでしょう。ユーザー認証をデバイスごとに登録する代わりに、ユーザーが電話を使用してどの企業デバイスにもサインインできるようになれば、電話でのサインインは、ユーザーと IT 担当者の両方の手間を省くことになるでしょう。

Microsoft Passport を使うと、データセンターの柔軟性も実現します。これを Windows 10 Mobile モバイルデバイスで展開するには Azure AD をセットアップする必要がありますが、既存の Active Directory 環境の置き換えや削除は必要ありません。Azure AD の接続を使用して、組織はこれらの 2 つのディレクトリサービスを同期できます。Microsoft Passport は、既存のインフラストラクチャに構築および追加され、Azure ad とのフェデレーションを可能にします。

Microsoft Passport はデスクトップでもサポートされ、すべてのデバイスで強固な認証を実装するための一貫した方法を組織に提供します。この柔軟性により、Microsoft Passport を使って社内の Windows PC シナリオに既存のスマートカードまたはトークンの展開を簡単に補完して、モバイルデバイスからアクセスする機密性の高いリソースまたはシステムを保護するために、MFA を現在装備していないモバイルデバイスとユーザーに MFA を追加することができます。

標準化

ソフトウェアベンダーと企業ユーザーの両者が、専用 ID と認証システムは将来性がないと認識しています。将来性があるのは、さまざまなデバイス、基幹業務 (LOB) アプリ、外部アプリケーションと Web サイトの間で安全な認証を行うことができる、オープンで相互運用可能なシステムです。この目的のために、業界関係者のグループが FIDO (Fast IDentity Online) Alliance を形成しました。FIDO Alliance は、強力な認証デバイス間の相互運用性不足と、ユーザーがユーザー名とパスワードを作成および記憶する際に直面する問題の解決に取り組む非営利組織です。FIDO Alliance は、オンラインサービスのユーザーを安全に認証するパスワードに取って代わる、オープンで拡張性と相互運用性に優れたメカニズムを定義する仕様を開発することで、認証の性質を変えようとしています。この新しい標準により、どのようなビジネスネットワーク、アプリ、Web サイト、またはクラウドアプリも、標準化されたインターフェイスとプロトコルのセットを使用して、既存または将来のさまざまな FIDO 対応デバイスとオペレーティングシステムプラットフォームのインタフェースとして機能できるようになります。

2014 年、Microsoft は FIDO Alliance の理事会に加盟しました。FIDO 標準により、グローバルエコシステムが強固なパスワードレス認証のユーザーエクスペリエンスを一貫して大幅に改善するためのユニバーサルフレームワークが実現できます。2014 年 12 月に公開された FIDO 1.0 仕様では、パスワードレス (UAF とも呼ばれる) と 2 要素認証 (U2F) の 2 種類の認証が提供されています。FIDO Alliance は、U2F と UAF FIDO 1.0 標準の最高の部分を組み合わせて 2.0 仕様の提案作成に取り組んでいます。もちろん、新しい考え方も取り込んでいます。Microsoft では、レビューやフィードバックを受けるため FIDO 2.0 仕様ワークグループに Microsoft Passport テクノロジを提供しました。FIDO 2.0 仕様の進展に合わせて FIDO Alliance と継続的に連携しています。FIDO 製品の相互運用性は FIDO 認証の特長です。FIDO ソリューションを市場に導入すると、企業とコンシューマーの両方にとって重要なニーズを解決できると Microsoft は考えています。

Windows Hello

Windows Hello は Windows 10 の新しい生体認証フレームワークです。生体認証識別子はオペレーティングシステムに直接組み込まれているため、虹彩、顔、または指紋を使ってモバイルデバイスのロックを解除することができます。Windows Hello は Microsoft Passport の資格情報をロック解除します。これにより、Microsoft Office 365 のような SaaS (Software as a Service) 型アプリケーションなどのリソースや証明書利用者に対する認証を有効にします。

Windows Hello では、エンタープライズシナリオに適した次の 3 つの生体認証センサーオプションがサポートされています。

顔認識: 特殊な赤外線カメラを使い、写真やスキャンと実際の人物の違いを確実に見分けます。複数のベンダーが、このテクノロジを組み込んだ外付けカメラを出荷しており、主要な製造元は統合された顔認識テクノロジを搭載したノート PC を既に出荷しています。Surface Pro 4、Surface Book は共にこのテクノロジをサポートしています。
指紋認識: センサーを使ってユーザーの指紋をスキャンします。指紋リーダーは、数年前から Windows オペレーティングシステムで使えましが、Windows 10 の検出、スプーフィング対策、および認識アルゴリズムは以前のバージョンの Windows より強化されています。Windows Biometric Framework をサポートする既存の指紋リーダーのほとんどは、(外付けまたはノート PC や USB キーボードとの一体型に関係なく) Windows Hello で使うことができます。
虹彩スキャン: 目の虹彩、つまりカラフルで非常に細かい部分ををスキャンするよう設計されたカメラを使用します。データには高い精度が必要なため、虹彩スキャンでは赤外線光源と高品質カメラの組み合わせが使用されます。Microsoft Lumia 950 と 950 XL デバイスは、このテクノロジをサポートしています。

注

生体認証ジェスチャを登録する前に、ユーザーは、ロック解除暗証番号 (PIN) を作成する必要があります。PIN は、デバイスで、生体認証ジェスチャをキャプチャできない場合に、フォールバックメカニズムとして使用されます。

生体認証のこれら 3 つの要素 (顔、指紋、虹彩) はどれも一人一人異なります。個人を一意に識別するための十分なデータをキャプチャするため、生体認証スキャナーは複数の条件でまたは追加情報を伴って最初にキャプチャを実行する場合があります。たとえば、虹彩スキャナーは、眼鏡またはコンタクトレンズを着用した目、着用しない目の両方のイメージをキャプチャします。

エンタープライズ環境で生体認証データのなりすましが重大な問題になることがよくあります。Windows 10 Mobile には、生体認証デバイスの信頼性を保証し、保存されている生体認証の測定点に対する意図的な競合を防ぐ、いくつかのなりすまし対策技術が使用されています。これらの手法により、他人受入率 (なりすましの生体認証データが認証される確率) が改善され、MFA の全体的な操作性と管理機能が維持されています。

登録時で収集された生体認証は、アルゴリズム形式に変換され、元のイメージに戻すことができません。アルゴリズム形式だけが保持され、実際の生体認証イメージは変換後にデバイスから削除されます。Windows 10 Mobile デバイスは、アルゴリズム形式の生体認証データを暗号化するとともに、暗号化されたデータをデバイスにバインドします。この両方の動作により、他者が電話からデータを削除するのを防ぐことができます。結果として、Windows Hello に使われる生体認証情報は、ローカルのジェスチャであり、ユーザーのデバイス間でローミングすることはありません。

Windows Hello には、いくつかの主なメリットがあります。まず、資格情報の盗難や共有の問題への対処に役立ちます。攻撃者は携帯電話を入手してユーザーの生体認証 ID を偽装しなければならず、これはデバイスのロック解除パスワードを盗難するより難しい作業です。次に、生体認証では認証システムは常にユーザーと一体なので、忘れる、失くす、置き忘れる、といった心配がありません。ユーザーは、長くて複雑なパスワードを忘れてしまうことを心配する代わりに、Windows 10 Mobile デバイスにログオンするためのエンタープライズレベルの安全な方法を活用できます。最後の点として、Microsoft では Windows Hello のサポートをオペレーティングシステムに直接組み込んでいるため、追加の展開は必要はありません。必要なのは、サポートされている生体認証センサーを備えたデバイスのみです。

生体認証の要素を感知するデバイスは、迅速かつ正確に、Windows Hello にデータを報告する必要があります。このため、Microsoft では、Windows Hello に搭載する前に、どの要素とデバイスが信頼でき、正確であるかを決定します。詳しくは、「Windows 10 の仕様」をご覧ください。

データ保護

Windows 10 Mobile では、引き続き、承認されないアクセスや開示に対して情報を保護するための解決策を提供していきます。

デバイスの暗号化

Windows 10 Mobile では、オペレーティングシステムパーティションとデータストレージパーティションを含む全内部ストレージを暗号化する BitLocker テクノロジに基づくデバイスの暗号化が使用されています。ユーザーはデバイスの暗号化をアクティブ化することができ、IT 部門は MDM ツールを使用して企業が管理するデバイスの暗号化をアクティブ化したり適用したりすることができます。デバイスの暗号化がオンになると、電話に保存されているすべてのデータは自動的に暗号化されます。暗号化が有効化されている Windows 10 Mobile では、デバイスを紛失したり盗まれたりした場合に、保存されたデータの機密性が保護されます。Windows Hello のロックとデータ暗号化の組み合わせにより、承認されていない第三者が機密性の高い情報をデバイスから取得することは非常に困難になります。

固有のセキュリティ要件を満たすため、IT 担当者はデバイスの暗号化を機能させる方法をカスタマイズすることができます。デバイスの暗号化では、ユーザー固有の暗号も定義することができます。たとえば、Windows 10 Mobile でデータの暗号化に使用するアルゴリズムとキーのサイズ、どのトランスポート層セキュリティ (TLS) 暗号を許可するか、米国連邦情報処理標準 (FIPS) ポリシーを有効にするかどうかを指定できます。表 2 に、Windows 10 Mobile デバイスで、デバイスの暗号化をカスタマイズするために変更できるポリシーを示します。

表 2.Windows 10 の暗号化ポリシー

領域名	ポリシー名	説明
暗号化	FIPS アルゴリズムのポリシーを許可する	FIPS ポリシーを有効または無効にします。このポリシーを強制するには、再起動する必要があります。既定値は、無効です。
BitLocker	暗号化の方法	BitLocker ドライブの暗号化方法と暗号強度を構成します。既定値は AES-CBC 128 ビットです。デバイスで指定された値を使用できない場合は、他の値が使用されます。
暗号化	TLS 暗号	このポリシーには、Secure Sockets Layer (SSL) 接続でに許可されている暗号アルゴリズムのリストが含まれています。

すべての使用可能なポリシーの一覧については、「ポリシー CSP」をご覧ください。

エンタープライズデータの保護

企業では、個人データと企業データのストレージの複合が急速に進んでいます。個人データが企業のデバイスに保存され、企業データが個人のデバイスに保存されることがめずらしくありません。このような状況では、企業の機密データが危害を受ける可能性が高くなります。

増大しているリスクの 1 つとしては、承認されたユーザーが機密データを偶発的に開示してしまうケースがあります。個人のデバイスが企業リソースにアクセスすることを企業が許可している場合、これは急速に機密データの漏洩の最大の原因になります。さまざまな組織で共通している 1 つの例は、従業員がメールをするために個人の電話を会社の Microsoft Exchange Server に接続することです。従業員は、電話を使用して機密性の高いデータを添付したメールをやりとりします。メールを送ろうとして、誤って業者の情報をコピーしてしまう、ということが起きる可能性があります。コンテンツの保護には、最も弱いリンクくらいの強さしかありません。この例のように、承認されていない人とうっかり機密データを共有することは、標準的なデータの暗号化では防げない場合があります。

Windows 10 Mobile では、エンタープライズデータ保護 (EDP) により個人データと企業データが分離され、データの漏洩が回避されます。その主な機能は、次のとおりです。

個人データと企業データを自動的にタグ付けする。
ローカルまたはリムーバブルストレージにデータが保存されている間、データを保護する。
どのアプリが企業データにアクセスできるかを制御する。
どのアプリが仮想プライベートネットワーク (VPN) 接続にアクセスできるかを制御する。
ユーザーが企業のデータを公共の場所にコピーすることを防ぐ。

注

EDP は、現在一部の顧客により評価テストが行われています。EDP について詳しくは、「エンタープライズデータ保護の概要」をご覧ください。

Enlightenment

通常、サードパーティのデータ損失防止ソリューションでは、開発者がアプリをラップすることが要件とされています。これに対し、EDP ではインテリジェンスが Windows 10 Mobile 内に置かれているため、ラッパーは必要ありません。結果として、特別な操作を必要とせずに、ほとんどのアプリを EDP と連携させることができます。

アプリを変更しなくても EDP のポリシーを強制できます。つまり、通常ビジネスデータの処理に使用しているアプリ (LOB アプリなど) を許可されたリストに追加することで、このアプリが処理するデータは常に暗号化されます。ただし、アプリでコモンコントロールが使用されていない場合は、このアプリから企業アプリ以外のアプリに切り取り・貼り付け操作を行うと、エラー表示なしで失敗します。また、アプリで個人データを処理する必要があった場合、この個人データも暗号化されます。

したがって、場合によってはユーザーエクスペリエンスを向上させるために、開発者はそれぞれのアプリにコードを追加し、コンパイルして、EDP アプリケーションプログラミングインターフェイスを使用するよう enlightenment させる必要があります。対象となるのは次のようなアプリです。

ファイルの保存にコモンコントロールを使用していない。
テキストボックスにコモンコントロールが使用されていない。
個人データと企業データを同時に処理している (たとえば、1 つのビューに個人データと企業データを表示する連絡先アプリや、単一のインスタンスでタブに個人の Web ページと企業の Web ページを表示するブラウザなど)。

図 1 は、EDP と連携させるためにアプリの enlightenment が必要な場合をまとめたものです。この好例が Microsoft Word です。Word は、個人データと企業データに同時にアクセスできるだけでなく、たとえば、企業データを含む添付物をメール添付するなど、企業データを転送することができます。

いずれにせよ、ほとんどのアプリでは、EDP 保護を使用するための enlightenment を必要としません。必要なのは、アプリを EDP の許可リストに追加することだけです。enlightenment されていないアプリでは、データが個人または企業として自動的にタグ付けされないため、EDP ポリシーを適用するとすべてのデータが企業データとして処理されてしまいます。この好例が、LOB アプリです。LOB アプリを EDP ポリシーに追加すると、このアプリが処理するすべてのデータが保護されます。別の例として、更新されないレガシアプリがあります。EDP ポリシーに追加することができますが、EDP が存在していることすら気づかずに使うことになります。

図 1

図 1.enlightenment が必要なのはどの場合ですか?

データ漏洩のコントロール

EDP をサポートする MDM ソリューションで EDP を構成するには、EDP の許可リストに承認されたアプリを追加します。Windows 10 Mobile が実行されているデバイスが MDM ソリューションに登録されている場合は、このポリシーが承認しないアプリは企業データにアクセスできません。

企業データを承認されないアプリや Web 上の承認されない場所にアクセスさせたり、貼り付けたりする試みがユーザーにより行われない限り、EDP はシームレスに機能します。たとえば、承認されたアプリから別の承認されたアプリに企業データをコピーする作業は通常どおり動作しますが、承認されたアプリから承認されないアプリに企業データをコピーしようとすると、EDP によりブロックされます。同様に、承認されないアプリを使って企業データを含むファイルを開こうとすると、EDP によりブロックされます。

また、承認されたアプリから承認されないアプリや Web 上の承認されない場所へのコピー・貼り付けは、次に示す EDP 保護のレベルの 1 つをトリガーしない限り、実行できません。

ブロック: EDP は、ユーザーが操作を完了するのをブロックします。
オーバーライド: EDP は、操作が適切でないことをユーザーに通知しますが、ポリシーの上書きを許可します。ただしその操作は監査ログに記載されます。
監査: EDP は、ユーザーの操作をブロックせず、通知もしませんが、監査ログには記録します。
オフ: EDP は、ユーザーの操作をブロックせず、通知せず、監査ログにも記録しません。

データの分離

名前が示すように、データの分離は個人データと企業データとを分離します。ほとんどのサードパーティソリューションでは、アプリラッパーを利用して、企業データはコンテナー内、個人データはコンテナー外に置かれます。同じ目的でも個人データと企業データを分けて異なる 2 つのアプリを使わなければならないことはよくあることです。

EDP でも同様のデータの分離が行われますが、コンテナーは使用されません。また、企業データにアクセスした後は、第 2 のインスタンスで個人データにアクセスするような特殊なアプリも必要ありません。個人データと企業データを物理的に分離するためのコンテナー、パーティション、専用のフォルダーは使用しません。代わりに、Windows 10 Mobile がアクセス制御ブローカーとして、企業のデータを識別します。これは可能なのは、企業データが企業に対して暗号化されているためです。つまり、EDP は、企業データの暗号化を利用したデータの分離を提供します。

視覚的な合図

Windows 10 Mobile では、EDP の状態が視覚的な合図でユーザーに示されます (図 2 を参照)。

スタート画面: スタート画面で、EDP ポリシーが管理するアプリには視覚的な合図が表示されます。
ファイル: ファイルエクスプローラーでは、ファイルやフォルダーに企業データが含まれているか、暗号化されているかが視覚的な合図で示されます。

たとえば、Fabrikam 社に Erwin という従業員がいるとします。Erwin は、Microsoft Edge のスタート画面を開きます。タイルを見ると、ブラウザが EDP ポリシーにより管理されていることがわかります。Erwin は、Fabrikam 社の営業用 Website を開き、スプレッドシートをダウンロードします。File Explorer で、Erwin は、ダウンロードしたファイルに視覚的な合図が含まれていることを確認します。つまり、このファイルは暗号化されており、企業データが含まれています。Erwin がスプレッドシートから EDP ポリシーで管理されていないアプリ (たとえば、Twitter アプリなど) にデータを貼り付けようとすると、EDP ポリシーで設定した保護レベルに応じて、保護のオーバーライドを許可するが操作を記録する、などのメッセージが表示されます。

図 2

図 2.EDP の視覚的な合図

マルウェアへの対抗

ソフトウェアによって私たちの生活の多くが自動化されたのと同様、マルウェアによってデバイス上の攻撃も自動化されています。それらの攻撃は執拗です。マルウェアは常に変化しており、デバイスに感染すると、検出や削除がかなり困難な場合があります。

マルウェアに対抗する最適な方法は、感染を防止することです。Windows 10 Mobile には強力なマルウェアへの対抗が用意されています。マルウェアへの対抗は、セキュリティで保護されたハードウェアを活用することで、スタートアッププロセス、コアオペレーティングシステムのアーキテクチャの両方を保護します。

表 3 に、具体的なマルウェアの脅威と、Windows 10 Mobile に用意された軽減策を示します。

表 3.脅威と Windows 10 Mobile の軽減策

脅威	Windows 10 Mobile の軽減策
ブートキットファームウェアは、ファームウェアをマルウェアに置き換えます。	すべての認定デバイスには、セキュアブート付きの Unified Extensible Firmware (UEFI) が搭載され、UEFI とオプション ROM を更新するには署名済みファームウェアが必要です。
Windows が起動する前に、ブートキットによりマルウェアが起動する。	セキュアブート付きの UEFI は、Windows より先に悪意のあるオペレーティングシステムが起動できないように、Windows ブートローダーの整合性を検証します。
システムまたはドライバーのルートキット (典型的にはオペレーティングシステムで表示されない悪意のあるソフトウェア) により、Windows の起動中、マルウェアへの対抗ソリューションが起動する前に、カーネルレベルのマルウェアが起動する。	Windows トラストブートにより、Microsoft ドライバーを含む Windows ブートコンポーネントが検証されます。トラストブートと並行してメジャーブートが実行され、デバイスのブート状態を検証する情報がリモートサーバーに提供されて、トラストブートと他のブートコンポーネントがシステムを正常にチェックしたことが確認されます。
マルウェアが、アプリから他のアプリまたはオペレーティングシステムに感染する。	Windows 10 Mobile のすべてのアプリは、他のすべてのプロセスや機密性の高いオペレーティングシステムのコンポーネントから切り離されて、AppContainer 内で実行されています。アプリから、AppContainer の外部のリソースにはアクセスできません。
承認されていないアプリまたはマルウェアがデバイス上で起動しようとしている。	Windows 10 Mobile のアプリはすべて、Windows ストアまたはビジネス向け Windows ストアから入手するされたものです。Device Guard により、管理ポリシーはどのポリシーに実行を許可するかを正確に選択するよう強制されます。
ユーザーレベルのマルウェアが、システムやアプリケーションの脆弱性を悪用し、デバイスを所有する。	ASLR (Address Space Layout Randomization)、データ実行防止 (DEP)、ヒープアーキテクチャ、およびメモリ管理のアルゴリズムの機能強化により、脆弱性の悪用に成功する可能性が低下します。保護されたプロセスは、信頼されないプロセスを互いに、および機密性の高いオペレーティングシステムコンポーネントから切り離します。
ユーザーが、リスクを認識せずに、危険なウェブサイトにアクセスする	SmartScreen の URL 評価機能により、ブラウザーを悪用してデバイスを制御しようとする悪意のある Web サイトへのユーザーのアクセスが防止されます。
マルウェアが、ブラウザーのアドオンの脆弱性を悪用する。	Microsoft Edge は、Microsoft Activex や、ツールバーによく使われるブラウザーヘルパーオブジェクトなど、従来のバイナリ拡張機能を実行しないユニバーサル Windows プラットフォーム (UWP) に構築されているアプリであるため、これらのリスクがありません。
悪意のあるコードが含まれる Web サイトが、Web ブラウザの脆弱性を悪用し、クライアントデバイスでマルウェアを実行する。	Microsoft Edge には拡張保護モードが用意されています。このモードは、AppContainer ベースのサンドボックスを使って、ブラウザーで実行される拡張機能 (Adobe Flash や Java など) またはブラウザー自体に攻撃者が検出する可能性がある脆弱性に対してシステムを保護します。

注

Windows 10 Mobile デバイスでは、Qualcomm などの SoC ベンダーにより提供される System on a Chip (SoC) 設計が使用されています。このアーキテクチャを使用して、SoC ベンダーとデバイスの製造元により、前 UEFI ブートローダーとUEFI 環境が提供されています。UEFI 環境には、UEFI 仕様のセクション 27 で説明されている UEFI セキュアブート標準が実装されています。http://www.uefi.org/specsandtesttoolsをご覧ください。この標準では、すべての UEFI ドライバーおよびアプリケーションが、実行される前に、UEFI ベースのデバイス内にプロビジョニングされたキーと照合して検証されるプロセスについて説明しています。

以降のセクションでは、これらの機能強化について詳しく説明します。

エンタープライズレベルのセキュリティで保護されたハードウェア

Windows 10 Mobile のセキュリティ機能の利点を最大限に活用するには、ハードウェアベースのセキュリティを強化する必要があります。これらの機能強化には、セキュアブート付きの UEFI、TPM、生体認証センサー (ハードウェアに依存) が含まれます。

セキュアブート付きの UEFI

Windows 10 Mobile デバイスが起動すると、デバイスのストレージシステム上にブートローダーを見つけることによってオペレーティングシステムの読み込みのプロセスが開始されます。安全策がないと、電話は、信頼されているオペレーティングシステムかマルウェアかも判断せずにコントロールをブートローダーに渡す可能性があります。

UEFI は、BIOS に置き換わる最新の標準ベースソリューションです。実際に、BIOS と同じ機能を提供しながら、セキュリティ機能と他の高度な機能を追加します。BIOS と同様、UEFI はデバイスを初期化しますが、セキュアブート機能を備える UEFI コンポーネント (バージョン 2.3.1 以降) は、オプション ROM、UEFI アプリ、オペレーティングシステムブートローダー内にある信頼されたファームウェアだけを携帯電話で起動できるようにします。

UEFI は、ファームウェアを実行する前に、ファームウェアのデジタル署名を確認する内部整合性チェックを実行できます。携帯電話の製造元だけが、有効なファームウェアの署名を作成するのに必要なデジタル証明書にアクセスできるため、UEFI は、Windows 10 Mobile より先に読み込まれるファームウェアベースのマルウェアに対して保護を行い、その悪意のある動作が Windows 10 Mobile に表示されないようにすることができます。この種のファームウェアベースのマルウェアは通常、ブートキットと呼ばれています。

UEFI とセキュアブートを備えたモバイルデバイスが起動すると、UEFI ファームウェアはブートローダーのデジタル署名を検証し、デジタル署名後に何者もこれを変更していないことを確認します。ファームウェアは、信頼された機関がブートローダーのデジタル署名を発行したことも確認します。このチェックにより、ブートローダーが信頼されていることと、署名以降に変更されていないことの両方をチェックした後のみシステムを起動することができます。

Windows 10 Mobile のデバイスでは、セキュアブートは常に有効化されています。また、信頼されるのは、Windows オペレーティングシステムの署名のみです。

Windows 10 Mobile、アプリ、またマルウェアでさえ、UEFI 構成を変更することはできません。セキュアブート付きの UEFI について詳しくは、「UEFI による OS 前の環境の保護」をご覧ください。

Trusted Platform Module (トラステッドプラットフォームモジュール)

トラステッドプラットフォームモジュールは、コンピューティングプラットフォームのセキュリティとプライバシーを強化する、データ改ざんに強い暗号化モジュールです。PC、タブレット、携帯電話のような信頼されたコンピューティングプラットフォームにコンポーネントとして組み込まれています。信頼されたコンピューティングプラットフォームは、ソフトウェアだけでは実現できないプライバシーとセキュリティのシナリオをサポートできるように、TPM と連携するように特別に設計されています。すべての Windows 10 Mobile デバイスが TPM を装備していることは、Windows 10 Mobile デバイスのハードウェア認定の要件になっています。

信頼されたコンピューティングプラットフォームの一部として TPM を適切に実装すると、ハードウェアに信頼の基盤がもたらされます。つまり、ハードウェアが信頼できる方法で動作します。たとえば、何者もキーを TPM からエクスポートできないというプロパティを持つ TPM でキーを作成すると、キーは決して TPM から持ち出されることはありません。TPM とプラットフォームを緊密に統合すると、起動プロセスの透明性が増し、プラットフォームの起動に使われるソフトウェアの信頼性の高いレポートを生成することでデバイス正常性シナリオがサポートされます。

次のリストに、Windows 10 Mobile で TPM により提供される主な機能について説明します。

暗号化キーの管理: TPM は、キーを作成、保存し、定義された方法での使用を許可します。Windows 10 Mobile は TPM を使って、BitLocker ボリューム、仮想スマートカード、証明書、および他のさまざまなキーの暗号化キーを保護します。
整合性測定値の保護と報告: Windows 10 Mobile は、メジャーブート機能に使われる選択したハードウェアおよび Windows ブートコンポーネントの整合性関連の測定値を記録し、保護するためにも TPM を使います。このシナリオでは、メジャーブートは、ファームウェアからドライバーまで、各コンポーネントを測定し、それらの測定値をデバイスの TPM に保存します。そこから、独立したシステムが Windows 10 Mobile デバイスのブート状態を確認できるように、測定値ログをリモートでテストできます。
TPM が本当に TPM であることの証明: TPM を偽装するマルウェアから自身を区別するために TPM が必要とするプライバシーとセキュリティを保護するために、暗号化キーの管理および測定の整合性に大きな主眼を置いています。

Windows 10 Mobile では、2.0 標準に準拠する TPM 実装がサポートされます。TPM 2.0 標準は、いくつかの機能強化が加えられて 1.2 標準より優れたものになっていますが、その中で最も重要なものは暗号化の機敏性です。TPM 1.2 は、暗号化アルゴリズムとハッシュアルゴリズムの固定セットに制限されています。2000 年代初めの TPM 1.2 標準が出現した時点で、セキュリティのコミュニティではこれらのアルゴリズムは強力な暗号化であると見なされていました。それ以来、暗号化アルゴリズムと暗号解読攻撃の進歩の結果、より強化な暗号化に対する期待が高まってきました。TPM 2.0 では、強力な暗号化保護を行う追加のアルゴリズムと、特定の地域または業界で推奨されるアルゴリズムのプラグイン機能がサポートされています。さらに、TPM コンポーネント自体を変更せずに将来のアルゴリズムを追加できる可能性も確保されています。

TPM は相手先ブランド供給業者 (OEM) によってハードウェアのマザーボードに個別のモジュールとして埋め込まれる必要があるという考える人は多くいますが、TPM はファームウェアに実装しても有効です。Windows 10 Mobile では、2.0 標準に準拠するファームウェア TPM のみがサポートされています。Windows では、個別ソリューションとファームウェアベースのソリューションは同じ実装要件とセキュリティ要件を満たすため区別されません。したがって、TPM を活用できる Windows 10 の機能は、Windows 10 Mobile でも使うことができます。

注

Microsoft では、任意のバージョンの Windows 10 Mobile を実行しているデバイスに TPM 2.0 を実装することを求めています。詳しくは、「最小ハードウェア要件」をご覧ください。

次のようないくつかの Windows 10 Mobile セキュリティ機能には、TPM が必要です。

仮想スマートカード
メジャーブート
正常性の認証 (TPM 2.0 以降が必要)

その他の機能でも、使える場合は TPM が使用されます。たとえば、Microsoft Passport では TPM は必要ありませんが、使える場合は使っています。組織では、Microsoft Passport で TPM を要件とするポリシーを設定できます。

生体認証

Windows 10 Mobile では、生体認証が主要なセキュリティ機能になっています。Microsoft では、生体認証を (以前のバージョンの Windows の場合のように) 単にプラットフォームのトップに付属させたのではなく、Windows 10 Mobile に完全に統合しました。これは大きな変更点です。以前の生体認証実装は、主に、認証を簡略化するフロントエンド方式でした。内部では、生体認証がパスワードにアクセスするために使われた後、バックグラウンドでの認証に使われていました。生体認証は便利でしたが、必ずしもエンタープライズレベルの認証ではありませんでした。

Microsoft では、Windows 10 Mobile デバイスを製造する OEM に、エンタープライズレベルの生体認証センサーの重要性を説いてきました。これらの顔認識と虹彩スキャンセンサーは、Microsoft Passport および Windows Hello などの MFA 機能により完全にサポートされています。

今後、OEM がさらに進化したエンタープライズレベルの生体認証センサーを製造し、モバイルデバイスへの統合を継続すると Microsoft では予想しています。この結果、生体認証は MFA システムの一部としてより一般的な認証方法となります。

エンタープライズレベルのセキュリティで保護された Windows のスタートアップ

セキュアブート付きの UEFI は、ハードウェアテクノロジを使ってブートキットからユーザーを保護します。セキュアブートは、デバイス、ファームウェア、およびブートローダーの整合性を検証できます。ブートローダーが起動すると、ユーザーはシステムの残りの部分の整合性を保護するためオペレーティングシステムに依存する必要があります。

トラストブート

ブートローダーが信頼できることをセキュアブート付きの UEFI が確認し、Windows 10 Mobile を起動したら、すべての Windows スタートアップコンポーネントが信頼でき (信頼された発行元によって署名されているなど)、整合性があることを確認することで、Windows トラストブート機能が残りのスタートアッププロセスを保護します。ブートローダーは、Windows カーネルのデジタル署名を読み込む前に検証します。その後、Windows カーネルは、ブートドライバー、およびスタートアップファイルを含む、Windows スタートアッププロセスの他のすべてのコンポーネントを検証します。

何者かによってファイルが変更されている場合 (マルウェアが改ざんした場合や、破損した場合など)、トラストブートが問題を検出し、破損したコンポーネントを自動的に修復することを試みます。修復されると、短時間の遅延の後に Windows が正常に起動します。

メジャーブート

以前のバージョンの Windows におけるルートキットやブートキットの最も大きな課題は、クライアントが検出できないことがよくあるという点です。多くの場合、Windows の防御およびマルウェア対策ソリューションの前に起動し、システムレベルの特権を持っていたため、ルートキットやブートキットは自身を完全に偽装しながら、システムリソースへのアクセスを続けることができました。セキュアブート付きの UEFI とトラストブートはほとんどのルートキットやブートキットを防ぐことができましたが、侵入者もいくつかの攻撃方法を悪用できる可能性がありました (たとえば、何者かが、Microsoft 以外のドライバーなどの起動コンポーネントの署名に使われた署名を侵害して、これを悪意のあるコンポーネントの署名に使った場合など)。

Windows 10 Mobile では、TPM ハードウェアコンポーネントを使うメジャーブート機能を実装することにより、ファームウェア、Windows ブートコンポーネント、およびドライバーなど、重要なのスタートアップ関連コンポーネントの一連の測定値が記録されます。メジャーブートは、測定データを切り離してマルウェア攻撃に対して保護する TPM のハードウェアベースのセキュリティ機能を使用するため、ログデータはさらに高度な攻撃からも適切に保護されます。

メジャーブートでは、測定データの取得と改ざんに対する保護に重点が置かれます。ただし、データを分析してデバイスの正常性を判断し、より完全なセキュリティサービスを提供できるサービスを組み合わせる必要があります。次のセクションでは、まさにそのようなサービスについて説明します。

デバイスの正常性の認証

デバイスの正常性の認証は、低レベルのマルウェアの感染を防止する、Windows 10 Mobile の新機能です。デバイスの正常性の認証では、デバイスの TPM およびファームウェアを使用して、デバイスの BIOS と Windows のスタートアッププロセスの重要なセキュリティプロパティを測定します。これらの測定は、カーネルレベルのマルウェアまたはルートキットに感染しているシステム上であっても同様に行われるため、攻撃者がプロパティを偽装する可能性が低くなります。

デバイスの正常性の認証と Microsoft Intune や Microsoft 以外の MDM ソリューションを統合し、これらのハードウェアで計測されるセキュリティプロパティをその他のデバイスのプロパティと組み合わせて、デバイスの正常性および準拠状態の全体像を把握することができます。その後は、ジェイルブレイクされたデバイスの検出からデバイスの準拠の監視、準拠レポートの生成、ユーザーまたは管理者へのアラート、デバイス上での修正操作の開始、および Office 365 などのリソースへの条件付きアクセスの管理など、さまざまなシナリオでこの統合を使うことができます。

条件付きアクセス

次の例では、Windows 10 の保護措置が Microsoft Intune や Microsoft 以外の MDM ソリューションとどのように統合され、連携するかを示します。この例により、電話において Windows 10 Mobile のセキュリティアーキテクチャがいかに準拠を監視し、検証しているか、また、デバイスハードウェアに基づく安全性と信頼性がいかに企業リソースをエンドツーエンドに保護しているかが明らかです。

ユーザーが電話の電源を入れると:

Windows 10 Mobile のセキュアブート機能がスタートアップシーケンスを保護し、定義された信頼できる構成でデバイスを起動させて、出荷時の信頼できるブートローダーを読み込みます。
セキュアブートのプロセスが完了すると、Windows 10 Mobile のトラストブートが、Windows カーネルのデジタル署名と、スタートアッププロセス中に読み込まれ、実行されたコンポーネントを検証します。
手順 1 と 2 に並行して、ハードウェア保護のセキュリティゾーン (ブートアクティビティを監視するブート実行パスから分離されているゾーン) では、電話の TPM が独立して実行されます。これにより、TPM のみがアクセスできる秘密によって署名されている、保護された、改ざん証明の監査証跡が作成されます。
デバイス正常性認証が有効な MDM ソリューションにより管理されるデバイスが、保護され、改ざんされにくく、改ざん証明の通信チャネルを通じて、この監査証跡のコピーを Microsoft 正常性認証サービス (HAS) に送信します。
HAS がこの監査証跡を確認し、暗号化され署名されたレポートを発行し、これをデバイスに転送します。
デバイス正常性認証が有効な MDM ソリューションから、保護され、改ざんされにくく、改ざん証明の通信チャネルを通じて、ユーザーはこのレポートを確認することができ、デバイスが準拠 (正常) 状態で実行されているか、アクセスできるか、組織のセキュリティ要件やポリシーに対応した修正操作をトリガーしているかを評価することができます。

このソリューションでは、他の方法では検出が非常に困難な低レベルのマルウェアを検出して防止することができます。したがって、Microsoft では、Windows 10 Mobile のクラウドベースの正常性認証サーバー機能を活用して高度なマルウェアに感染しているデバイスを検出しブロックする、Intune などのデバイス正常性認証が有効な MDM システムの実装を検討することをお勧めします。

アプリプラットフォームのセキュリティ

Windows 用に構築されたアプリケーションは安全で欠陥がないように設計されていますが、現実的には、人間の手によるエラーから、脆弱性のあるコードが作られる可能性があります。悪意のあるユーザーやソフトウェアは、このような脆弱性を識別すると、システムに損害を与えてコントロールすることを狙って、メモリ内のデータを操作しようとします。

このようなリスクを軽減するため、Windows 10 Mobile には、マルウェアがデバイスを侵害するするのを困難にする一連の機能強化が含まれています。さらに、Windows 10 Mobile では、どのアプリをモバイルデバイスで動作させるかを組織が選択することができます。さらに、新たに発見された脆弱性が悪用される可能性を大幅に削減する機能強化が含まれます。これらの機能強化の影響を十分に理解するには、オペレーティングシステムのアーキテクチャやマルウェアの悪用手法に関する詳しい知識が必要ですが、以下のセクションでは大まかに説明します。

Device Guard

Device Guard は、ハードウェアとソフトウェアの両方のシステム整合性について強化された機能から構成される機能セットです。これらの機能は、オペレーティングシステム全体を何も信頼しないことをベースとしたモデル (trust-nothing model) に移動することにより、Windows オペレーティングシステムのセキュリティに変革をもたらしました。

Windows 10 Mobile 上のすべてのアプリは、デジタル署名され、Windows ストアまたは信頼されたエンタープライズストアから入手したものである必要があります。Device Guard は、これをさらに制限するポリシーが実装されています。既定では、Device Guard は Windows ストアからのすべてのアプリをサポートします。アプリが Windows 10 Mobile デバイスで実行できるかできないかを定義するポリシーを作成することができます。アプリがデジタル署名されていない場合やポリシーによって禁止されている場合、そのアプリは信頼されているストアからのものでなく、Windows 10 Mobile で実行されません。

高度なハードウェア機能 (「エンタープライズレベルのセキュリティで保護されたハードウェア」セクションを参照) によって、これらのセキュリティ機能が実現されます。これらのハードウェア機能をコアオペレーティングシステムとより深く統合することによって、Windows 10 Mobile ではこれらの機能を新しい方法で活用できます。Device Guard では、この追加のセキュリティ機能を提供するためにセキュアブート付きの UEFI を必要とします。

AppContainers

Windows 10 Mobile のセキュリティモデルは最小限の特権の原則に基づいており、それを実現するために分離が使用されます。すべてのアプリ、さらにはオペレーティングシステム自体のいくつかの部分も、AppContainer (その内部でアプリとそのプロセスが実行されるセキュリティで保護された分離境界) と呼ばれる独自の分離のサンドボックス内で実行されます。各 AppContainer は、セキュリティポリシーにより定義および実装されます。

特定の AppContainer のセキュリティポリシーでは、AppContainer 内からアプリがアクセスすることができるオペレーティングシステムの機能が定義されます。機能とは、地理的な位置情報、カメラ、マイク、ネットワーキング、センサーなどの Windows 10 Mobile のデバイスリソースです。

一意の分離されたストレージの場所へのアクセスを含む一連の既定のアクセス許可が、すべての Appcontainer に付与されています。さらに、アプリコード自体内で、他の機能へのアクセスを宣言することができます。実行時には、追加の機能と特権へのアクセスを要求することはできません (従来のデスクトップアプリケーションでは可能でした)。

AppContainer の概念は、次に示す理由で便利です。

攻撃の危険性を縮小します。アプリは、アプリケーションコードで宣言され、実行するためには関数が必要な機能にしかアクセスできません。
ユーザーの同意と制御。アプリで使用される機能は、Windows ストアのアプリの詳細ページに自動的に公開されます。機密性の高い情報を公開する可能性のある機能にアプリがアクセスすると、ユーザーに承認と同意の提供を求めるプロンプトが自動的に発行されます。
アプリの分離。Windows アプリ間の通信は厳しく制御されます。アプリは互いに分離され、事前に定義された通信チャネルとデータ型を介してのみ通信することができます。

アプリは、正当なタスクの実行に必要な最小限の特権を受け取ります。そのため、悪意のある攻撃者がアプリを悪用した場合でも、アプリは特権を昇格できず、また AppContainer 内に収められているため、潜在的な損害は限定的です。Windows ストアには、アプリに必要なアクセス権と、アプリの年齢区分、発行元が表示されます。

Device Guard と AppContainer の組み合わせにより、承認されていないアプリが実行されるのを防ぐことができます。マルウェアがアプリのエコシステムに滑り込むと、AppContainer によりアプリは制御され、潜在的な損害が制限されます。Windows 10 Mobile の何も信頼しないことをベースとしたモデルは、どのコンポーネントも完璧ではなく、アプリ、Appcontainer、および Windows 10 Mobile 自体の潜在的な脆弱性こそ、攻撃者にシステムを侵害する機会を与えている、という仮定に基づきます。このため、冗長な脆弱性を軽減する必要があります。次のいくつかのトピックでは、Windows 10 Mobile で冗長な対策について説明します。

アドレス空間レイアウトのランダム化

システムへのアクセスを取得するために攻撃者が使う最も一般的な手法の 1 つは、既に実行されている特権付きプロセスで脆弱性を見つけ、重要なシステムコードやデータが置かれているメモリ内の場所を推測または発見して、その情報を悪意のあるペイロードで置き換える手法です。初期のオペレーティングシステムでは、システムメモリに直接書き込むことができるすべてのマルウェアがそのような操作を実行できました。マルウェアは、よく知られた予測可能な場所にあるシステムメモリを上書きするだけでした。

Address Space Layout Randomization (ASLR) により、その種の攻撃がかなり難しくなっています。重要なデータがメモリに格納される方法と場所がランダム化されるためです。ASLR により、マルウェアが攻撃に必要な特定の場所を見つけるのはより困難になります。図 3 は、重要な各種 Windows コンポーネントのメモリ内の場所が再起動のたびにどのように変わるかを示すことで、ASLR のしくみを示しています。

図 3

図 3.ASLR のしくみ

Microsoft では、Windows 10 Mobile における ASLR の実装を以前のバージョンに対して実質的に強化してきました。特に、はるかに大きいメモリ空間を活用できる 64 ビットシステムアプリケーションプロセスでは、Windows 10 Mobile が重要なデータを格納する場所をマルウェアが予測するのがさらに困難なためそう言えます。TPM を搭載したシステムで使うと、ASLR メモリランダム化のデバイス間での一意性はさらに高まるため、あるシステムで機能している悪用の成功が別のシステムで確実に機能することはより困難になります。Microsoft ではまた、ASLR を特定のアプリで機能させるのではなく、Windows 10 Mobile のシステム全体にわたって総体的に適用させています。

データ実行防止

マルウェアは、ユーザーが気づかずに後で実行することを狙って、悪意のあるペイロードをメモリに配置できることに依存しています。使うことを非常に困難です。

この保護を拡張することにより、情報の保存のみを目的として割り当てられた領域にマルウェアが書き込まれた場合に、マルウェアの実行を防止できればすばらしいことです。データ実行防止 (DEP) は、悪意のあるコードが自身の利益のために使うことができるメモリの範囲を大幅に削減することで、まさにそれを行います。DEP は、最新の CPU で No execute ビットを使ってメモリのブロックを読み取り専用とマークするため、マルウェアは悪意のあるコードの実行にそれらのブロックを使うことはできません。Windows 10 と Windows 10 Mobile のすべてのデバイスは、DEP をサポートしています。

Windows のヒープ

ヒープは、Windows が動的なアプリケーションデータの格納に使うメモリ内の場所です。Microsoft では、攻撃者が使用できるヒープの悪用のリスクを軽減することにより、以前の Windows のヒープ設計の強化が続けられています。

Windows 10 Mobile のヒープのセキュリティは、次のいくつかの重要な点で以前のバージョンの Windows より強化されています。

ヒープが使う内部データ構造は、メモリの破損からの保護が強化されました。
ヒープメモリ割り当ては、場所とサイズをランダム化するようになったため、攻撃者が上書きする重要なメモリの場所を予測することがさらに困難になっています。具体的には、Windows 10 Mobile では新たに割り当てられたヒープのアドレスにランダムオフセットが追加されるため、割り当てはかなり予測しにくくなります。
Windows 10 Mobile では、メモリブロックの前後に仕掛けとして "ガードページ" が使われます。攻撃者は、メモリブロックを越えて書き込もうとする場合 (バッファーオーバーフローと呼ばれる一般的な手法)、ガードページを上書きする必要があります。ガードページを変更しようとする試みはすべて、メモリの破損と見なされるため、Windows 10 Mobile がすぐにアプリを終了して対応します。

メモリの予約

Microsoft では、オペレーティングシステム用に、最小限の 64 KB のプロセスメモリが予約されています。アプリは、メモリのその部分を割り当てることができなくなったため、マルウェアがメモリ内の重要なシステムデータ構造を上書きすることはさらに困難になりました。

制御フローガード

Windows によりアプリケーションがメモリに読み込まれると、それらのアプリケーションにはコードのサイズ、要求されたメモリ、他の要素に基づいてスペースが割り当てられます。アプリケーションがコードを実行し始めると、他のメモリアドレスにある追加のコードを呼び出します。コードの場所間の関係はよく知られていますが (コード自体に書き込まれます)、Windows 10 Mobile が登場するまで、これらの場所間のフローがオペレーションシステムにより強制的に適用されることはありませんでした。このため、攻撃者が自分のニーズを満たすためにフローを変更することができました。つまり、アプリケーションが通常は実行できないコードを実行することにより、アプリケーションの悪用にこの動作を利用することができます。

Windows 10 Mobile では、この種の脅威が制御フローガード (CFG) 機能によって軽減されています。信頼されたアプリケーションがその作成者により CFG 呼び出しコードを使うようにコンパイルされている場合、CFG は呼び出されたコードの場所が信頼して実行できることを確認します。CFG により場所が信頼できないと認識された場合、潜在的なセキュリティリスクが存在するためアプリケーションがすぐに終了されます。

管理者が CFG を構成することはできません。代わりに、アプリケーション開発者がアプリケーションのコンパイル時に構成することで CFG を利用できます。CFG を有効にしてコンパイルされた信頼できる Windows アプリケーションを提供するよう、アプリケーション開発者とソフトウェアベンダーに依頼することを検討してください。もちろん、ブラウザーは攻撃の主要なエントリポイントであるため、Microsoft Edge、および他の Windows の機能は CFG を十分に活用します。

保護されたプロセス

一般に、コンピューターのセキュリティの問題を防止することは、問題による損傷を修復するよりも費用対効果に優れています。特にマルウェアの場合、ほとんどのセキュリティコントロールは、攻撃が最初に成功するのを防ぐために設計されています。マルウェアがシステムを感染させることができなければ、システムはマルウェアの影響を受けないという考え方です。

残念ながら、マルウェアの影響を受けないデバイスはありません。最良の予防的制御をすべて講じても、マルウェアはオペレーティングシステムやハードウェアプラットフォームに感染する方法を最終的に見つける可能性があります。そのため、多層防御戦略による防止は重要ですが、他の種類のマルウェア制御も必要です。

重要なセキュリティシナリオは、マルウェアがシステムで実行されることを前提としますが、実行できる処理を制限することです。Windows 10 Mobile には、既存のマルウェア感染によるセキュリティ侵害を減らすためのセキュリティ制御および設計機能が備わっています。保護されたプロセスは、そのような機能の 1 つです。

保護されたプロセスにより、Windows 10 Mobile は、信頼されていないプロセスが特別に署名されたプロセスを操作または改ざんできないようにします。保護されたプロセスはプロセスの信頼レベルを定義します。これにより、信頼性の低いプロセスが信頼されているプロセスに作用し、結果的に攻撃するのを防ぎます。Windows 10 Mobile では、オペレーティングシステム全体にわたり広範に保護されたプロセスが使用されています。

ビジネス向けストア

ビジネス向けストアを使用すると、IT 担当者は、組織のアプリの検索、入手、配布、管理を行うことができます。モデルが提供するアプリの配布方法は、組織のサイズに応じた柔軟な方法となっており、一部のシナリオでは追加のインフラストラクチャが不要です。

UWP アプリはサンドボックス化されており、これにより、アプリが侵害を受けたり改ざんされたりしてシステム、データ、およびその他のアプリケーションを危険にさらすリスクが制限されています。Windows ストアのエコシステムに入るすべてのアプリケーションはリリース前にレビューされるため、Windows ストアでは、マルウェアがデバイスに感染する可能性が下がっています。Windows ストアと同じインフラストラクチャで、カスタムの LOB アプリ、さらに一部の Windows ストアアプリも Windows 10 Mobile デバイスに配布することができるため、ビジネス向けストアはこの概念をさらに拡張しています。

UWP アプリは、ユーザーが入手した方法に関係なく安心して使うことができます。UWP アプリは、特権と機能が限定された AppContainer サンドボックス内で実行されます。たとえば、このアプリは、システムレベルのアクセスを持っておらず、他のアプリとのやり取りが厳しく制御されるため、ユーザーがアプリケーションのアクセス許可を明示的に付与しない限りデータにアクセスできません。

さらに、すべての UWP アプリは、最小限の特権のセキュリティ原則に従っています。アプリは、正当なタスクの実行に必要な最小限の特権のみ受け取るため、攻撃者がアプリを悪用した場合でも、悪用による損害はかなり限定的で、サンドボックス内に収まります。Windows ストアには、アプリの年齢区分と発行元に加えて、アプリが必要とする正確な機能 (カメラへのアクセスなど) が表示されます。

Windows ストアアプリの配布プロセスと Windows 10 Mobile のアプリサンドボックス機能により、ユーザーのシステムに悪意のあるアプリが侵入する可能性が大幅に減少します。

ビジネス向けストアについて詳しくは、「ビジネス向け Windows ストアの概要」をご覧ください。

アプリ管理

企業は、通常、デバイスにインストールされているアプリに対して何らかの構成とコントロールを実行します。これにより、組織は、たとえばソフトウェアのライセンス管理、必要なデバイスへの必要なアプリの展開、および企業デバイスに望ましくないアプリがインストールされることの防止など、いくつかのビジネス目標を達成します。

これらの目標を実現するうえで重要なコンポーネントがビジネス向けストアです。これは、Microsoft がホストする Windows ストアのインフラストラクチャ上に構築されたこのコンポーネントを使用して、Windows 10 ベースのデバイス上で Windows ストアアプリを展開することができるます。ビジネス向けストアは、強力であるとともに柔軟性に優れています。これを使用すれば、社内のインフラストラクチャを新たに立ち上げる必要なく、機能を拡張したりカスタマイズしたりすることができます。既存の MDM サービスがサポートされ統合されていますが、MDM サービスが必要なわけではありません。(ビジネス向けストアとの統合については、MDM サービスのベンダーに問い合わせてください。)ビジネス向けストアは、オンラインおよびオフラインのライセンス許可、さまざまなアプリ配布オプションなど、多種多様なシナリオ用に構成することができます。ビジネス向けストアの利用可能なシナリオについて詳しくは、「ビジネス向け Windows ストアの概要」をご覧ください。

IT 担当者向けの Web ベースのポータルは、Windows 10 Mobile アプリの展開を簡素化します。ビジネス向けストアのエクスペリエンス設計には、Windows ストアの使い慣れた外観が使用されています。そこには、ビジネスでの使用に対応した厳選されたアプリがカテゴリ順に表示されています。ストアでは、すべてのユーザーが Azure AD アカウントを使うことができ、それらは単一で一意の組織の ID にリンクします。

もう 1 つの主な利点はライセンス許可です。ビジネス向けストアでは、すべての UWP アプリのライセンスを追跡および管理することができます。どのユーザーが特定のアプリをインストールしたかを確認し、残っているライセンスを追跡して、Web インターフェイスを通じて直接新しいライセンスを獲得することができます。新しいライセンスはビジネス向けストア内に追加されるため、複雑なエクスポート/インポートプロセスは必要ありません。クライアントがオンラインの状態でインターネットに接続してさえいれば、ビジネス向けストアでのライセンス許可のシナリオは、手動のライセンス作業に比べてはるかに強化されています。

ビジネス向けストアでは、各ユーザーに適切なアプリを見つけてそれを入手し、アプリのライセンスを管理して、それぞれのユーザーにアプリを配布することができます。ビジネス向けストアを理解するための最良の方法は、次に説明する一般的なシナリオの手順を見てみることです。ここでは、MDM を使用せず、具体的には Windows 10 Mobile ユーザーに対してアプリを展開せずに、Windows 10 Mobile ユーザーにアプリが提供されます。このシナリオでは、各モバイルデバイスで必要な、現在 Windows ストアで無料で手に入るいくつかのアプリ (たとえば、Dell SonicWALL ソリューションで使用するための VPN アプリ) と、いくつかの社内で開発された LOB アプリを特定します。

IT 担当者側

ユーザーが新しい Windows 10 Mobile デバイスを受け取る前に、IT 担当者側では、プライベートストアとアプリを準備することで、アプリの展開プロセスを開始します。

まず、ビジネス向け Windows ストアを開き、Azure AD アカウントを使用してログインします。このアカウントは会社の一意の組織の ID にリンクされており、Azure AD テナントを必要とします。また、ビジネス向けストアを初めて使う場合は、Azure AD Enterprise Admin のアクセス許可が必要です。後で、ビジネス向けストア内のアクセス許可によりアクセスを委任できます。

次に、モバイルデバイスに展開するアプリを検索して入手し、アプリとライセンスを組織のインベントリに追加します。

既存の Windows ストアアプリに加えて、組織用に開発されたカスタムの LOB アプリをビジネス向けストアを使用して管理することができます。最初に、信頼できるアプリ開発者にアプリを発行するアクセス許可を付与します。IT 担当者と開発者は、これらのアプリを Windows デベロッパーセンターを通じて登録します。アプリは信頼された証明書を使って署名されている必要があります。これらのアプリは、Windows ストアの製品カタログには公開されず、組織外の人には表示されません。

Windows ストア内のプライベートストアからアプリを提供することができます。次の手順では、プライベートストアから入手できるよう、このアプリをマークします。これは、ビジネス向けストアの Web ポータルで行います。

または、ビジネス向けストアの Web ポータルで、次の 2 つのアプリ配布オプションのうちの 1 つを選択します。

1 つまたは複数の Azure AD ID を選択して、アプリを組織の従業員に割り当てる。
組織のプライベートストアにアプリを追加し、すべてのユーザーに対しこのアプリの検索とインストールを可能にする。

アプリの配布について詳しくは、「、プライベートストアを使用するアプリの配布」をご覧ください。

図 4 に、ビジネス向けストアを準備してアプリを展開するための IT プロセスを示します。

図 4

図 4.ビジネス向けストアのための IT プロセス

ビジネス向けストアでアプリを配布するプロセスについて詳しくは、「アプリの検索と入手」をご覧ください。

ユーザー側

ビジネス向けストアを準備した後は、ユーザー側のプロセスに引き継がれます。ユーザー側のプロセスは、ビジネス向けストア全体にわたって主要なアプリの展開方法が使用されており、わかりやすく、効率的で率直であるように設計されています。このプロセスには、MDM システムや、社内のインフラストラクチャは必要ありません。実際、ユーザーには "ビジネス向け" の文字は目に入らず、見慣れた Windows ストアにしか見えません。

ユーザーは、自分の Windows 10 Mobile デバイスで Windows ストアアプリを開きます。
作成したプライベートストアが追加されて、同じ Windows ストアのインターフェイスが表示されます。プライベートストアは、ゲームや音楽のアプリと同じように、新しいページとして表示されます。パブリックな Windows ストアと監督されているアプリを含む組織のプライベートストアのインターフェースは統合されています。
ユーザーは通常どおりの方法でアプリを選択し、インストールします。

必要に応じて、ユーザーが自分の Microsoft アカウントを使ってアプリ、音楽、映画、テレビ番組を個人的に購入することも選択できます。ユーザーは、会社とは別に、個人的に所有するために自ら支払って購入します。この柔軟性により、数多くの BYOD (Bring Your Own Device) シナリオ環境でのデバイスのハイブリッドなシナリオが可能になります。

Microsoft Edge

Windows 10 Mobile には、攻撃やマルウェアを阻止するために設計された重要な機能強化が含まれています。環境は、SmartScreen フィルター機能の大幅な強化のおかげで、マルウェアにさらに強くなりました。インターネットの閲覧は、完全に新しいブラウザーである Microsoft Edge のおかげでより安全な作業となっています。

Windows 10 Mobile には、読み取りビューなどの機能を超える、まったく新しい Web ブラウザーである、Microsoft Edge が含まれています。Microsoft Edge は、次のいくつかの点で Microsoft の Web ブラウザーより安全です。

Microsoft Edge では、Microsoft 以外のバイナリ拡張がサポートされません。Microsoft Edge では、組み込みの拡張機能を通じて Flash コンテンツと PDF の表示がサポートされますが、ActiveX コントロールや Java など、Microsoft 以外のバイナリ拡張機能はサポートされません。
Microsoft Edge は、UWP アプリとして設計されています。本質的に分離されており、ブラウザーをシステム、データ、他のアプリからサンドボックス化する AppContainer で実行されます。
Microsoft Edge により、セキュリティ構成タスクが簡略化されます。Microsoft Edge では、簡略化されたアプリケーション構造と単一サンドボックス構成が使われるため、必要なセキュリティ設定が少なくなります。さらに、セキュリティのベストプラクティスに沿った Microsoft Edge の既定の設定が Microsoft により確立されているため、設計上もより安全になっています。

Web ブラウザーは、セキュリティ戦略の重要なコンポーネントであり、それには十分な理由があります。ブラウザーは、ユーザーのインターネットへのインターフェイスであり、悪意のあるサイトや悪質なコンテンツが満載の環境であるためです。ほとんどのユーザーは、ブラウザーなしでは少なくともジョブの一部を実行できず、多くのユーザーはブラウザーに完全に頼っています。この現実のため、ブラウザーは悪意のあるハッカーが攻撃を開始する第 1 の経路となっています。

Windows 10 Mobile セキュリティ ガイド

概要