安全な Windows アプリの開発についてIntro to secure Windows app development

この入門記事では、アプリの設計者および開発者がセキュリティで保護されたユニバーサル Windows プラットフォーム (UWP) アプリの作成を促進するさまざまな Windows 10 プラットフォームの機能をより深く理解します。This introductory article helps app architects and developers better understand the various Windows 10 platform capabilities that accelerate creating secure Universal Windows Platform (UWP) apps. ここでは、認証、移動中データ、および保存データの各段階で利用可能な、Windows のセキュリティ機能に使用方法について詳しく説明します。It details how to use the Windows security features available at each of the following stages: authentication, data-in-flight, and data-at-rest. 各章にあるその他のリソースを確認すれば、各トピックについてさらに詳しい情報を得ることができます。You can find more in-depth information on each topic by reviewing the additional resources included in each chapter.

1 はじめに1 Introduction

セキュリティで保護されたアプリの開発は、容易な作業ではありません。Developing a secure app can be a challenge. モバイル アプリ、ソーシャル アプリ、クラウド アプリ、および複雑なエンタープライズ アプリが急速に進歩する現在では、アプリがこれまでよりも早く利用可能になり、更新されることをユーザーは期待しています。In today’s fast-paced world of mobile, social, cloud, and complex enterprise apps, customers expect apps to become available and updated faster than ever. また、ユーザーはさまざまな種類のデバイスを使用するので、アプリ エクスペリエンスの実現はますます複雑になっています。They also use many types of devices, further adding to the complexity of creating app experiences. Windows 10 ユニバーサル Windows プラットフォーム (UWP) 用にビルドする場合、含めることが可能なデバイス リストには、デスクトップ、ノート、タブレット、モバイル デバイスなどの従来のデバイスの他に、モノのインターネット、Xbox One、Microsoft Surface Hub、HoloLens にわたる新しいデバイスがあり、今後も増加します。If you build for the Windows 10 Universal Windows Platform (UWP), that could include the traditional list of desktops, laptops, tablets, and mobile devices; in addition to a growing list of new devices spanning the Internet of Things, Xbox One, Microsoft Surface Hub, and HoloLens. 開発者は、関連するすべてのプラットフォームまたはデバイスで、アプリが安全に通信し、データを保存できるようにする必要があります。As the developer, you must ensure your apps communicate and store data securely, across all the platforms or devices involved.

Windows 10 のセキュリティ機能を利用する利点を次にいくつか示します。Here are some of the benefits of utilizing Windows 10 security features.

  • セキュリティのコンポーネントやテクノロジ用の一貫性のある API を使用することにより、Windows 10 をサポートするすべてのデバイスで、標準的なセキュリティを実現できます。You will have standardized security across all devices that support Windows 10, by using consistent APIs for security components and technologies.
  • これらのセキュリティ シナリオに対応するカスタム コードを実装する場合よりも、作成、テスト、保守の対象となるコードの量は少なくなります。You write, test, and maintain less code than you would if you implemented custom code to cover these security scenarios.
  • オペレーティング システムを使用して、アプリのリソースと、ローカルまたはリモートのシステム リソースにアプリがアクセスする方法を制御するため、アプリの安定性と安全性が高まります。Your apps become more stable and secure because you use the operating system to control how the app accesses its resources and local or remote system resources.

認証時に、特定のサービスへのアクセスを要求するユーザーの ID が検証されます。During authentication, the identity of a user requesting access to a particular service is validated. Windows Hello は、Windows アプリでより安全な認証メカニズムを作成するのに役立つ Windows 10 のコンポーネントです。Windows Hello is the component in Windows 10 that helps create a more secure authentication mechanism in Windows apps. これらコンポーネントを利用すると、暗証番号 (PIN)、またはユーザーの指紋、顔、虹彩などの生体認証を使って、アプリ用の多要素認証を実装できます。With it, you can use a Personal Identification Number (PIN) or biometrics such as the user’s fingerprints, face, or iris to implement multi-factor authentication for your apps.

移動中データとは、接続とそれを通してやり取りされるメッセージを表します。Data-in-flight refers to the connection and the messages transferred across it. これの例は、Web サービスを使用したリモート サーバーからのデータ取得です。An example of this is retrieving data from a remote server using web services. Secure Sockets Layer (SSL) と Secure Hypertext Transfer Protocol (HTTPS) を使うことで、接続の安全性が確保されます。The use of Secure Sockets Layer (SSL) and Secure Hypertext Transfer Protocol (HTTPS) ensures the security of the connection. 仲介するものがこれらのメッセージにアクセスするのを防ぎ、または承認されていないアプリが Web サービスと通信するのを防ぐことが、移動中データを保護するうえでの鍵となります。Preventing intermediary parties from accessing these messages, or unauthorized apps from communicating with the web services, is key to securing data in flight.

最後に、保存データとは、メモリや記憶域メディアに存在するデータのことです。Lastly, data-at-rest relates to data residing in memory or on storage media. Windows 10 では、アプリ間の承認されていないデータ アクセスを防止するアプリ モデルがあり、デバイス上のデータの安全性をさらに高める暗号化 API が提供されています。Windows 10 has an app model that prevents unauthorized data access between apps, and offers encryption APIs to further secure data on the device. 資格情報保管ボックスと呼ばれる機能を使用すると、デバイスにユーザー資格情報を安全に保存することができ、オペレーティング システムが他のアプリからのアクセスを防止します。A feature called Credential Locker can be used to securely store user credentials on the device, with the operating system preventing other apps from accessing them.

2 認証要素2 Authentication Factors

データを保護するために、データへのアクセスを要求する人は、特定され、要求するデータ リソースへのアクセスが承認される必要があります。To protect data, the person requesting access to it must be identified and authorized to access the data resources they request. ユーザーを特定するプロセスは認証と呼ばれ、リソースへのアクセス特権を判別することは承認と呼ばれます。The process of identifying a user is called authentication, and determining access privileges to a resource is called authorization. これらは密接な関係のある操作であり、ユーザーには区別できないかもしれません。These are closely related operations, and to the user they might be indistinguishable. 操作には、比較的単純な操作から複雑な操作まであります。これは、さまざまな要因 (データが 1 台のサーバーに存在するか、多数のシステム間で分散しているかなど) によって決まります。They can be relatively simple or complex operations, depending on many factors: for example, whether the data resides on one server or is distributed across many systems. 認証サービスおよび承認サービスを提供するサーバーは、ID プロバイダーと呼ばれます。The server providing the authentication and authorization services is referred to as the identity provider.

特定のサービスやアプリを使ってユーザー自身を認証するには、ユーザーは、自分が知っている情報、自分が持っているもの、自分の特徴からなる資格情報を使用します。To authenticate themselves with a particular service and/or app, the user employs credentials made up of something they know, something they have, and/or something they are. これらはそれぞれ認証要素と呼ばれます。Each of these are called authentication factors.

  • ユーザーが知っている情報とは、通常パスワードですが、暗証番号 (PIN) や "秘密" の質問と答えのペアの場合もあります。Something the user knows is usually a password, but it can also be a personal identification number (PIN) or a “secret” question-and-answer pair.
  • ユーザーが持っているものとは、ほとんどの場合、ハードウェアのメモリ デバイス (ユーザーに固有の認証データを含んでいる USB スティックなど) です。Something the user has is most often a hardware memory device such as a USB stick containing the authentication data unique to the user.
  • ユーザーの特徴とは、多くの場合、指紋を意味しますが、ユーザーの音声、顔、眼球 (目) の特性、または動作パターンなどの要素も一般的になってきています。Something the user is often encompasses their fingerprints, but there are increasingly popular factors like the user’s speech, facial, ocular (eye) characteristics, or patterns of behavior. これらの測定値は、データとして保存されると生体認証と呼ばれます。When stored as data, these measurements are called biometrics.

ユーザーが作成したパスワードは認証要素ですが、パスワードだけでは不十分な場合があります。これは、パスワードを知っている人物が、パスワードの所有者であるユーザーになりすますことができるためです。A password created by the user is an authentication factor in itself, but it often isn’t sufficient; anyone who knows the password can impersonate the user who owns it. スマート カードではより高いレベルのセキュリティを実現できますが、盗難、紛失、置き忘れなどの可能性があります。A smart card can provide a higher level of security, but it might be stolen, lost, or misplaced. 指紋や眼球のスキャンによってユーザーを認証するシステムでは、最高かつ最も便利なレベルのセキュリティを実現できる可能性があります。ただし、高額で特別なハードウェアが必要になります (たとえば、顔認証用の Intel RealSense カメラなど)。このようなハードウェアは、すべてのユーザーが利用できるわけではありません。A system that can authenticate a user by their fingerprint or by an ocular scan might provide the highest and most convenient level of security, but it requires expensive and specialized hardware (for example, an Intel RealSense camera for facial recognition) that might not be available to all users.

システムで使う認証方法を設計することは、データ セキュリティにおいて複雑かつ重要な要素であるといえます。Designing the method of authentication used by a system is a complex and important aspect of data security. 一般的に、認証で使う要素の数が多いほど、システムのセキュリティは高くなります。In general, the greater number of factors you use in authentication, the more secure the system is. 同時に、認証は使いやすいものであることが必要です。At the same time, authentication must be usable. 通常、ユーザーは 1 日に何度もログインするため、このプロセスは迅速に行われる必要があります。A user will usually log in many times a day, so the process must be fast. 認証の種類を選ぶときは、セキュリティと使いやすさのバランスを取る必要があります。単一要素認証は、セキュリティが最も低いレベルになりますが、最も使いやすい方法です。多要素認証では、認証要素が増えるに従って、セキュリティのレベルは高くなりますが、複雑になっていきます。Your choice of authentication type is a trade-off between security and ease of use; single-factor authentication is the least secure and easiest to use, and multi-factor authentication becomes more secure, but more complex as more factors are added.

2.1 単一要素認証2.1 Single-factor authentication

この形式の認証は、1 つのユーザーの資格情報に基づいています。This form of authentication is based on a single user credential. 通常、これはパスワードですが、暗証番号 (PIN) の場合もあります。This is usually a password, but it could also be a personal identification number (PIN).

単一要素認証のプロセスを次に示します。Here’s the process of single-factor authentication.

  • ユーザーは、ユーザー名とパスワードを ID プロバイダーに提供します。The user provides their username and password to the identity provider. ID プロバイダーとは、ユーザーの身元を確認するサーバー プロセスです。The identity provider is the server process that verifies the identity of the user.
  • ID プロバイダーでは、ユーザー名とパスワードがシステムに保存されているものと同じであるかどうかを確認します。The identity provider checks whether the username and password are the same as those stored in the system. ほとんどの場合、パスワードは暗号化され、セキュリティを高めて他の人が読み取れないようにします。In most cases, the password will be encrypted, providing additional security so that others cannot read it.
  • ID プロバイダーは、認証が成功したかどうかを示す認証状態を返します。The identity provider returns an authentication status that indicates whether the authentication was successful.
  • 成功した場合、データ交換が開始されます。If successful, data exchange begins. 失敗した場合、ユーザーは再認証が必要です。If unsuccessful, the user must be re-authenticated.

単一要素認証

今日、この認証方法はさまざまなサービスで最も一般的に使われている方法です。Today, this method of authentication is the most commonly used one across services. この認証形式を唯一の認証方法として使った場合、これは最もセキュリティ レベルの低い認証形式になります。It is also the least secure form of authentication when used as the only means of authentication. パスワードの複雑さの要件、"秘密の質問"、定期的なパスワードの変更によって、パスワードを使うセキュリティを高めることはできますが、ユーザーの負担が増え、ハッカーに対する効果的な抑止力とはなりません。Password complexity requirements, "secret questions," and regular password changes can make using passwords more secure, but they put more burden on users and they’re not an effective deterrent against hackers.

パスワードの課題は、複数の要素を備えるシステムよりも容易に推測されてしまうということです。The challenge with passwords is that it is easier to guess them successfully than systems that have more than one factor. 小さなオンライン ショップから、ユーザー アカウントとハッシュされたパスワードのデータベースを盗めば、使用されているパスワードを他の Web サイトで使えます。If they steal a database with user accounts and hashed password from a little web shop, they can use the passwords used on other web sites. 複雑なパスワードは覚えにくいため、ユーザーはアカウントを常に再利用する傾向があります。Users tend to reuse accounts all the time, because complex passwords are hard to remember. IT 部門では、パスワード管理には、リセット メカニズムを提供、パスワードを頻繁に更新することを要求、そして安全な方法でパスワードを保存するという複雑さも伴います。For an IT department, managing passwords also brings with it the complexity of having to offer reset mechanisms, requiring frequent updates to passwords, and storing them in a safe manner.

欠点はありますが、単一要素認証ではユーザーが資格情報を制御できます。For all of its disadvantages, single-factor authentication gives the user control of the credential. 資格情報の作成や変更はユーザーが行い、認証プロセスで必要となるのはキーボードだけです。They create it and modify it, and only a keyboard is needed for the authentication process. これが、多要素認証にはない単一要素認証の主な特徴です。This is the main aspect that distinguishes single-factor from multi-factor authentication.

2.1.1 Web 認証ブローカー2.1.1 Web authentication broker

前述のように、パスワード認証を使用した課題の 1 つ、IT 部門は、追加したユーザー名/パスワード、リセット メカニズムなどのベースの管理のオーバーヘッド。急速に普及のオプションでは、OAuth、認証のためのオープン標準を認証しているプランをサード パーティの id プロバイダーに依存します。As previously discussed, one of the challenges with password authentication for an IT department is the added overhead of managing the base of usernames/passwords, reset mechanisms, etc. An increasingly popular option is to rely on third-party identity providers that offer authentication through OAuth, an open standard for authentication.

OAuth を使用すると、IT 部門は、ユーザー名とパスワードのデータベース、パスワードのリセット機能などの維持という複雑さを、Facebook、Twitter、Microsoft などのサード パーティの ID プロバイダーに効果的に "委託" することができます。Using OAuth, IT departments can effectively "outsource" the complexity of maintaining a database with usernames and passwords, reset password functionality, etc. to a third party identity provider like Facebook, Twitter or Microsoft.

ユーザーがこれらのプラットフォームで自身の ID を完全に制御しますが、アプリはプロバイダーにトークンを要求し、ユーザーが認証された後、ユーザーの同意を得て、それを認証されたユーザーの承認に使用することができます。Users have complete control over their identity on these platforms, but apps can request a token from the provider, after the user is authenticated and with their consent, which can be used to authorize authenticated users.

Windows 10 の Web 認証ブローカーは、アプリが認証プロトコルと承認プロトコル (OAuth や OpenID など) を使うための API のセットとインフラストラクチャを提供します。The web authentication broker in Windows 10 provides a set of APIs and infrastructure for apps to use authentication and authorization protocols like OAuth and OpenID. アプリでは、WebAuthenticationBroker API を使って認証操作を開始できます。その結果として、WebAuthenticationResult が返されます。Apps can initiate authentication operations through the WebAuthenticationBroker API, resulting in the return of a WebAuthenticationResult. 通信フローの概要を次の図に示します。An overview of the communication flow is illustrated in the following figure.

WAB ワークフロー

アプリはブローカーとして機能します。アプリでは、WebView を利用して ID プロバイダーを使い、認証を開始します。The app acts as the broker, initiating the authentication with the identity provider through a WebView in the app. ID プロバイダーがユーザーを認証すると、トークンがアプリに返されます。このトークンを使って、ID プロバイダーに対してユーザーに関する情報を要求することができます。When the identity provider has authenticated the user, it returns a token to the app that can be used to request information about the user from the identity provider. セキュリティ対策として、アプリが ID プロバイダーの認証プロセスを仲介する前に、アプリを ID プロバイダーに登録する必要があります。As a security measure, the app must be registered with the identity provider before it can broker the authentication processes with the identity provider. この登録手順は、プロバイダーごとに異なります。This registration steps differ for each provider.

プロバイダーと通信するための WebAuthenticationBroker API の呼び出しに使われる一般的なワークフローを次に示します。Here’s the general workflow for calling the WebAuthenticationBroker API to communicate with the provider.

  • ID プロバイダーに送信される要求文字列を作成します。Construct the request strings to be sent to the identity provider. 文字列の数と各文字列に含まれる情報は、Web サービスごとに異なりますが、通常は、URI 文字列が 2 つあり、それぞれに URL が含まれています。1 つは認証要求の送信先となる URL で、もう 1 つは認証の完了後にユーザーがリダイレクトされる URL です。The number of strings, and the information in each string, is different for each web service but it usually includes two URI strings each containing a URL: one to which the authentication request is sent, and one to which the user is redirected after authorization is complete.
  • 要求文字列を渡して WebAuthenticationBroker.AuthenticateAsync を呼び出し、ID プロバイダーからの応答を待ちます。Call WebAuthenticationBroker.AuthenticateAsync, passing in the request strings, and wait for the response from the identity provider.
  • WebAuthenticationResult.ResponseStatus を呼び出し、応答を受け取ったときの状態を取得します。Call WebAuthenticationResult.ResponseStatus to get the status when the response is received.
  • 通信が成功したら、ID プロバイダーから返された応答文字列を処理します。If the communication is successful, process the response string returned by the identity provider. 通信が失敗した場合は、エラーを処理します。If unsuccessful, process the error.

通信が成功したら、ID プロバイダーから返された応答文字列を処理します。If the communication is successful, process the response string returned by the identity provider. 通信が失敗した場合は、エラーを処理します。If unsuccessful, process the error.

このプロセスに関するサンプルの C# コードを次に示します。Sample C# code that for this process is below. 詳しい情報やチュートリアルについては、「WebAuthenticationBroker」をご覧ください。For information and a detailed walkthrough, see WebAuthenticationBroker. 完全なコード サンプルについては、「GitHub の WebAuthenticationBroker サンプル」をご覧ください。For a complete code sample, check out the WebAuthenticationBroker sample on GitHub.

string startURL = "https://<providerendpoint>?client_id=<clientid>";
string endURL = "http://<AppEndPoint>";

var startURI = new System.Uri(startURL);
var endURI = new System.Uri(endURL);

try
{
    WebAuthenticationResult webAuthenticationResult = 
        await WebAuthenticationBroker.AuthenticateAsync( 
            WebAuthenticationOptions.None, startURI, endURI);

    switch (webAuthenticationResult.ResponseStatus)
    {
        case WebAuthenticationStatus.Success:
            // Successful authentication. 
            break;
        case WebAuthenticationStatus.ErrorHttp:
            // HTTP error. 
            break;
        default:
            // Other error.
        break;
    }
}
catch (Exception ex)
{
    // Authentication failed. Handle parameter, SSL/TLS, and
    // Network Unavailable errors here. 
}

2.2 多要素認証2.2 Multi-factor authentication

多要素認証では、複数の認証要素を使います。Multi-factor authentication makes use of more than one authentication factor. 通常、パスワードなどの "知っている情報" は、携帯電話やスマート カードなどの "持っているもの" に結合されます。Usually, "something you know," such as a password, is combined with "something you have," which can be a mobile phone or a smart card. 攻撃者がユーザーのパスワードを検出しても、デバイスやカードを使わないと、アカウントにアクセスすることはできません。Even if an attacker discovers the user’s password, the account is still inaccessible without the device or card. また、攻撃者がデバイスやカードだけを手に入れても、パスワードがなければ、攻撃者はこれらを使うことはできません。And if only the device or card is compromised, it is not useful to the attacker without the password. したがって、多要素認証は単一要素認証よりもセキュリティが高くなりますが、複雑にもなります。Multi-factor authentication is therefore more secure, but also more complex, than single-factor authentication.

多要素認証を使うサービスでは、多くの場合、サービスに 2 番目の資格情報を提供する手段をユーザーが選択できます。Services that use multi-factor authentication will often give the user a choice in how they receive the second credential. この種類の認証の例として、SMS を利用して確認コードをユーザーの携帯電話に送信するという一般的に使われるプロセスを挙げることができます。An example of this type of authentication is a commonly used process where a verification code is sent to the user’s mobile phone using SMS.

  • ユーザーは、ユーザー名とパスワードを ID プロバイダーに提供します。The user provides their username and password to the identity provider.
  • ID プロバイダーでは、ユーザー名とパスワードを単一要素認証の場合と同様に確認し、その後で、システムに保存されているユーザーの携帯電話番号を検索します。The identity provider verifies the username and password as in single-factor authorization, and then looks up the user’s mobile phone number stored in the system.
  • サーバーは、生成された確認コードを含んでいる SMS メッセージをユーザーの携帯電話に送信します。The server sends an SMS message containing a generated verification code to the user’s mobile phone.
  • ユーザーは、ユーザーに提示された形式で確認コードを ID プロバイダーに提供します。The user provides the verification code to the identity provider; through a form presented to the user.
  • ID プロバイダーは、両方の資格情報の認証が成功したかどうかを示す認証状態を返します。The identity provider returns an authentication status that indicates whether the authentication of both credentials were successful.
  • 成功した場合、データ交換が開始されます。If successful, data exchange begins. 失敗した場合、ユーザーは再認証が必要です。Otherwise, the user must be re-authenticated.

2 要素認証

以上の説明でわかるように、このプロセスは、2 番目のユーザーの資格情報がユーザーによって作成または提供されるのではなく、ユーザーに送られるという点が、単一要素認証とは異なります。As you can see, this process also differs from single-factor authentication in that the second user credential is sent to the user instead of being created or provided by the user. そのため、ユーザーは、必要な資格情報を完全に制御することはできません。The user is therefore not in complete control of the necessary credentials. このことは、スマート カードを 2 番目の資格情報として使う場合にも該当します。2 番目の資格情報の作成とユーザーへの提供は、組織が管理します。This also applies when a smart card is used as the second credential: the organization is in charge of creating and providing it to the user.

2.2.1 Azure Active Directory2.2.1 Azure Active Directory

Azure Active Directory (Azure AD) は、クラウド ベースの ID およびアクセスの管理サービスであり、単一要素認証や多要素認証の ID プロバイダーとして使うことができます。Azure Active Directory (Azure AD) is a cloud-based identity and access management service that can serve as the identity provider in single-factor or multi-factor authentication. Azure AD 認証は、確認コードの有無にかかわらず使うことができます。Azure AD authentication can be used with or without a verification code.

Azure AD では単一要素認証を実装することもできますが、通常、企業では最もセキュリティ レベルの高い多要素認証を必要とします。While Azure AD can also implement single-factor authentication, enterprises usually require the higher security of multi-factor authentication. 多要素認証の構成の場合、Azure AD アカウントを使ったユーザー認証では、確認コードを SMS メッセージとして携帯電話に送信したり、Azure Authenticator モバイル アプリに送信したりすることができます。In a multi-factor authentication configuration, a user authenticating with an Azure AD account has the option of having a verification code sent as an SMS message either to their mobile phone or the Azure Authenticator mobile app.

さらに、Azure AD は OAuth プロバイダーとして使用でき、さまざまなプラットフォームのアプリに対する認証および承認メカニズムを標準ユーザーに提供できます。Additionally, Azure AD can be used as an OAuth provider, providing the standard user with an authentication and authorization mechanism to apps across various platforms. 詳しくは、「Azure Active Directory」および「Azure の多要素認証」をご覧ください。To learn more, see Azure Active Directory and Multi-Factor Authentication on Azure.

2.4 Windows Hello2.4 Windows Hello

Windows 10 では、便利な多要素認証メカニズムがオペレーティング システムに組み込まれています。In Windows 10, a convenient multi-factor authentication mechanism is built into the operating system. Windows Hello は、Windows 10 に組み込まれた新しい生体認証サインイン システムです。Windows Hello is the new biometric sign-in system built into Windows 10. Windows Hello はオペレーティング システムに直接組み込まれているため、顔または指紋を識別して、ユーザーのデバイスのロックを解除できます。Because it is built directly into the operating system, Windows Hello allows face or fingerprint identification to unlock users’ devices. Windows のセキュリティ保護された資格情報ストアは、デバイス上の生体認証データを保護します。The Windows secure credential store protects biometric data on the device.

Windows Hello は、個々のユーザーを認識するための堅牢な方法をデバイスに提供します。これにより、ユーザーと要求されたサービス (またはデータ項目) との間のパスの最初の部分が処理されます。Windows Hello provides a robust way for a device to recognize an individual user, which addresses the first part of the path between a user and a requested service or data item. デバイスがユーザーを認識しても、要求されたリソースへのアクセス権を与えるかどうかを決める前に、ユーザーをまだ認証する必要があります。After the device has recognized the user, it still must authenticate the user before determining whether to grant access to a requested resource. Windows Hello は、Windows に完全に統合された強固な 2 要素認証 (2FA) も行い、再利用可能なパスワードを、特定のデバイスと生体認証ジェスチャまたは PIN の組み合わせに置き換えます。Windows Hello also provides strong two-factor authentication (2FA) that is fully integrated into Windows and replaces reusable passwords with the combination of a specific device, and a biometric gesture or PIN. PIN は、Microsoft アカウントの登録時にユーザーが指定します。The PIN is specified by the user as part of their Microsoft account enrollment.

Windows Hello は、従来の 2FA システムの単なる代替機能ではありません。Windows Hello isn’t just a replacement for traditional 2FA systems, though. 概念的にはスマート カードと似ています。文字列比較ではなく、暗号化プリミティブを使用して認証が行われます。ユーザーのキー マテリアルは、が改ざんされにくいハードウェア内にセキュリティ保護されています。It’s conceptually similar to smart cards: authentication is performed by using cryptographic primitives instead of string comparisons, and the user’s key material is secure inside tamper-resistant hardware. Microsoft Hello では、スマート カード展開に必要なインフラストラクチャ コンポーネントも追加する必要はありません。Microsoft Hello doesn't require the extra infrastructure components required for smart card deployment, either. 具体的には、現在、公開キー基盤 (PKI) を所持していない場合は、証明書を管理するための PKI は必要ありません。In particular, you don’t need a Public Key Infrastructure (PKI) to manage certificates, if you don’t currently have one. Windows Hello では、スマート カードの主な利点である、仮想スマート カードの展開の柔軟性と物理スマート カードの堅牢なセキュリティを組み合わせ、それぞれの欠点を排除しています。Windows Hello combines the major advantages of smart cards—deployment flexibility for virtual smart cards and robust security for physical smart cards—without any of their drawbacks.

ユーザーがデバイスを使って認証する前に、デバイスを Windows Hello に登録する必要があります。A device must be registered with Windows Hello before users can authenticate with it. Windows Hello は非対称 (公開/秘密キー) の暗号化を使用しています。この暗号化では、相手が秘密キーを使って暗号化解除できるデータを、公開キーを使用して暗号化します。Windows Hello uses asymmetric (public/private key) encryption in which one party uses a public key to encrypt the data that the other party can decrypt using a private key. Windows Hello では、公開/秘密キーの組のセットを作成し、デバイスのトラステッド プラットフォーム モジュール (TPM) チップに秘密キーを書き込みます。In the case of Windows Hello, it creates a set of public/private key pairs and writes the private keys to the device’s Trusted Platform Module (TPM) chip. デバイスが登録されると、UWP アプリは、システム API を呼び出してユーザーの公開キーを取得することができ、このキーを使ってユーザーをサーバーに登録することができます。After a device has been registered, UWP apps can call system APIs to retrieve the user’s public key, which can be used to register the user on the server.

アプリの登録ワークフローは、次のようになります。The registration workflow of an app might look like the following:

Windows Hello の登録

収集する登録情報には、この単純なシナリオよりも多くの識別情報が含まれる場合があります。The registration information you collect may include a lot more identifying information than it does in this simple scenario. たとえば、アプリが、バンキング用などのセキュリティで保護されたサービスにアクセスする場合、サインアップ プロセスの一部として ID やその他の項目の証明を要求する必要があります。For example, if your app accesses a secured service such as one for banking, you’d need to request proof of identity and other things as part of the sign-up process. すべての条件が満たされると、ユーザーの公開キーがバックエンドに保存され、次回ユーザーがサービスを利用するときの検証でこの公開キーが使われます。Once all the conditions are met, the public key of this user will be stored in the back-end and used to validate the next time the user uses the service.

Windows Hello について詳しくは、「Windows Hello ガイド」および「Windows Hello 開発者向けガイド」をご覧ください。For more information on Windows Hello, see the Windows Hello guide and the Windows Hello developer guide.

3 移動中データに関するセキュリティ保護の方法3 Data-in-flight security methods

移動中データに関するセキュリティ保護の方法は、ネットワークに接続されているデバイス間でやり取りされるデータに適用されます。Data-in-flight security methods apply to data in transit between devices connected to a network. データは、プライベートな社内イントラネットの高度なセキュリティ環境にあるシステムの間で転送される場合と、セキュリティで保護されていない Web 環境にあるクライアントと Web サービスの間で転送される場合があります。The data may be transferred between systems on the high-security environment of a private corporate intranet, or between a client and web service in the non-secure environment of the web. Windows 10 アプリでは、ネットワーキング API を利用して SSL などの標準をサポートしており、Azure API 管理などのテクノロジとも連携します。これにより、開発者はアプリで適切なレベルのセキュリティを確保することができます。Windows 10 apps support standards such as SSL through their networking APIs, and work with technologies such as Azure API Management with which developers can ensure the appropriate level of security for their apps.

3.1 リモート システムの認証3.1 Remote system authentication

リモート コンピューター システムとの通信が発生する一般的なシナリオは、2 つあります。There are two general scenarios where communication occurs with a remote computer system.

  • ローカル サーバーで、直接接続を経由してユーザーを認証します。A local server authenticates a user over a direct connection. たとえば、サーバーとクライアントが社内イントラネット上に存在する場合などです。For example, when the server and the client are on a corporate intranet.
  • Web サービスとの通信はインターネット経由で行われます。A web service is communicated with over the Internet.

Web サービス通信では、データはもはやセキュリティで保護されたネットワークだけに含まれるのではなく、悪意のある攻撃者が検索してデータを傍受する可能性も高くなるので、Web サービス通信のセキュリティ要件は、直接接続のシナリオの場合よりも高くなります。Security requirements for web service communication are higher than those in direct connection scenarios, as data is no longer only a part of a secure network and the likelihood of malicious attackers looking to intercept data is also higher. さまざまな種類のデバイスがサービスにアクセスするため、たとえば WCF サービスではなく RESTful サービスとしてデバイスがビルドされる可能性があります。このため、認証およびサービスへの承認からも新しい課題が生まれます。Because various types of devices will access the service, they will likely be built as RESTful services, as opposed to WCF, for instance, which means authentication and authorization to the service also introduces new challenges. セキュリティで保護されたリモート システム通信の 2 つの要件について説明します。We’ll discuss two requirements for secure remote system communication.

最初の要件は、メッセージの機密性を示します。クライアントと web サービス (たとえば、ユーザーと他の個人情報の id) の間で渡される情報は転送中にサード パーティで読み取ることはできません。The first requirement is message confidentiality: The information passed between the client and the web services (for example, the identity of the user and other personal information) must not be readable by third parties while in transit. 通常これは、メッセージ送信に使われる接続を暗号化したり、メッセージ自体を暗号化したりすることによって実現されます。This is usually accomplished by encrypting the connection over which messages are sent and by encrypting the message itself. 秘密キー/公開キーの暗号化では、公開キーはだれでも利用でき、公開キーを使って、特定の受信者に送信されるメッセージを暗号化します。In private/public key encryption, the public key is available to anyone, and is used to encrypt messages to be sent to a specific receiver. 秘密キーは受信者のみが保持しており、秘密キーを使って、メッセージの暗号化を解除します。The private key is only held by the receiver and is used to decrypt the message.

2 番目の要件は、メッセージの整合性を示します。クライアントと web サービスは、受信メッセージのもので、その他のパーティが送信するためのものであるし、メッセージが転送中に変更されていないことを確認できる必要があります。The second requirement is message integrity: The client and the web service must be able to verify that the messages they receive are the ones intended to be sent by the other party, and that the message has not been altered in transit. これは、デジタル署名を使ったメッセージへの署名と、証明書の認証の利用によって実現されます。This is accomplished by signing messages with digital signatures and using certificate authentication.

3.2 SSL 接続3.2 SSL connections

セキュリティで保護された接続を確立し、維持するために、Web サービスでは、Secure Hypertext Transfer Protocol (HTTPS) によってサポートされている Secure Sockets Layer (SSL) を使うことができます。To establish and maintain secure connections to clients, web services can use Secure Sockets Layer (SSL), which is supported by the Secure Hypertext Transfer Protocol (HTTPS). SSL では、公開キーの暗号化、およびサーバーの証明書をサポートすることによって、メッセージの機密性と整合性が実現されます。SSL provides message confidentiality and integrity by supporting public key encryption as well as server certificates. トランスポート層セキュリティ (TLS) は SSL に取って代わるものですが、TLS は非公式に SSL と呼ばれることがよくあります。SSL is superseded by Transport Layer Security (TLS), but TLS is often casually referred to as SSL.

クライアントがサーバーにあるリソースへのアクセスを要求すると、SSL はサーバーとのネゴシエーション プロセスを開始します。When a client requests access to a resource on a server, SSL starts a negotiation process with the server. これは、SSL ハンドシェイクと呼ばれます。This is called an SSL handshake. 暗号化レベル、公開暗号化キーと秘密暗号化キーのセット、およびクライアントとサーバーの証明書に含まれている ID 情報が、SSL 接続が行われている間のすべての通信における基盤として認識されます。An encryption level, a set of public and private encryption keys, and the identity information in the client and server certificates are agreed upon as the basis of all communication for the duration of the SSL connection. このとき、サーバーは、認証されるクライアントを要求する場合があります。The server may also require the client to be authenticated at this time. 接続が確立されると、接続が閉じられるまで、すべてのメッセージがネゴシエートされた公開キーで暗号化されます。Once the connection is established, all messages are encrypted with the negotiated public key until the connection closes.

3.2.1 SSL のピン留め3.2.1 SSL pinning

SSL では、暗号化と証明書を使ってメッセージの機密性を実現できますが、クライアントが通信しているサーバーが正しいサーバーであることを確認するための処理は行いません。While SSL can provide message confidentiality using encryption and certificates, it does nothing to verify that the server with which the client is communicating is the correct one. サーバーの動作は、承認されていない第三者によって模倣され、クライアントが転送した重要なデータが傍受される可能性があります。The server’s behavior can be mimicked by an unauthorized third-party, intercepting the sensitive data that the client transmits. これを防ぐためには、SSL のピン留めと呼ばれる手法を使って、サーバー上の証明書がクライアントで想定され、信頼されている証明書であることを確認します。To prevent this, a technique called SSL pinning is used to verify that the certificate on the server is the certificate that the client expects and trusts.

アプリに SSL のピン留めを実装する方法はいくつかあります。それぞれの方法に長所と短所があります。There are a few different ways to implement SSL pinning in apps, each with their own pros and cons. 最も簡単な方法は、アプリのパッケージ マニフェストで証明書の宣言を利用する方法です。The easiest approach is via the Certificates declaration in the app’s package manifest. この宣言によって、アプリ パッケージはデジタル証明書をインストールし、それらの証明書に排他的信頼を指定することができます。This declaration enables the app package to install digital certificates and specify exclusive trust in them. その結果、アプリと、対応する証明書が証明書チェーンにあるサーバーとの間だけで SSL 接続が許可されます。This results in SSL connections being allowed only between the app and servers that have the corresponding certificates in their certificate chain. このメカニズムにより、信頼できる公共の証明機関に対するサード パーティの依存関係は不要になるので、セキュリティで保護された自己署名証明書の使用も可能になります。This mechanism also enables the secure use of self-signed certificates, as no third party dependency is needed on trusted public certification authorities.

SSL マニフェスト

検証ロジックをより細かく制御したい場合は、API を利用して、HTTPS 要求に応じてサーバーから返される証明書を検証できます。For more control over the validation logic, APIs are available to validate the certificate(s) returned by the server in response to an HTTPS request. この方法では、要求の送信と応答の確認が必要になることに注意してください。重要な情報を要求に含めて実際に送信する前に、この方法を検証方法として追加してください。Note that this method requires sending a request and inspecting the response, so be sure to add this as a validation before actually sending sensitive information in a request.

次の C# コードは、この SSL のピン留め方法を示しています。The following C# code illustrates this method of SSL pinning. ValidateSSLRoot メソッドでは、HttpClient クラスを使って HTTP 要求を実行します。The ValidateSSLRoot method uses the HttpClient class to execute an HTTP request. クライアントが応答を送信した後で、クライアントは RequestMessage.TransportInformation.ServerIntermediateCertificates コレクションを使って、サーバーから返された証明書を調べます。After the client sends the response, it uses the RequestMessage.TransportInformation.ServerIntermediateCertificates collection to inspect the certificates returned by the server. その後で、クライアントは含まれている拇印を使って、証明書チェーン全体を検証することができます。The client can then validate the entire certificate chain with the thumbprints it has included. この方法では、サーバー証明書の有効期限が切れて新しい証明書に置き換わると、証明書の拇印がアプリで更新される必要があります。This method does require the certificate thumbprints to be updated in the app when the server certificate expires and is renewed.

private async Task ValidateSSLRoot()
{
    // Send a get request to Bing
    var httpClient = new HttpClient();
    var bingUri = new Uri("https://www.bing.com");
    HttpResponseMessage response = 
        await httpClient.GetAsync(bingUri);

    // Get the list of certificates that were used to
    // validate the server's identity
    IReadOnlyList<Certificate> serverCertificates = response.RequestMessage.TransportInformation.ServerIntermediateCertificates;
  
    // Perform validation
    if (!ValidateCertificates(serverCertificates))
    {
        // Close connection as chain is not valid
        return;
    }
    // Validation passed, continue with connection to service
}

private bool ValidateCertificates(IReadOnlyList<Certificate> certs)
{
    // In this example, we iterate through the certificates
    // and check that the chain contains
    // one specific certificate we are expecting
    foreach (var cert in certs)
    {
        byte[] thumbprint = cert.GetHashValue();

        // Check if the thumbprint matches whatever you 
        // are expecting
        var expected = new byte[] { 212, 222, 32, 208, 94, 102, 
            252, 83, 254, 26, 80, 136, 44, 120, 219, 40, 82, 202, 
            228, 116 };

        // ThumbprintMatches does the byte[] comparison 
        if (ThumbprintMatches(thumbprint, expected))
        {
            return true;
        }
    }
    return false;
}

3.3 REST API の公開と REST API へのアクセスの保護3.3 Publishing and securing access to REST APIs

Web サービスへのアクセスの承認を確実に行うためには、API の呼び出しが行われるたびに認証する必要があります。To ensure authorized access to web services, they must require authentication every time an API call is made. Web サービスが Web 経由で公開されている場合、パフォーマンスとスケールを制御できるようにすることも考慮する必要があります。Being able to control performance and scale is also something to consider when web services are exposed across the web. Azure API Management は、API を Web に公開する場合に役立つサービスであり、3 つのレベルで機能を提供します。Azure API Management is a service that can help expose APIs across the web, while providing features on three levels.

API の発行者/管理者は、Azure API Management の発行者ポータルを使って、簡単に API を構成できます。Publishers/Administrators of the API can easily configure the API through the Publisher Portal of Azure API Management. ここでは、API のセットを作成でき、API へのアクセスを管理して、だれがどの API へアクセスできるかを制御できます。Here, API sets can be created and access to them can be managed to control who has access to which APIs.

開発者は、これらの API にアクセスする必要がある場合、開発者ポータルを使って要求できます。開発者ポータルは、直ちにアクセスを提供するか、発行者/管理者による承認を要求します。Developers wanting access to these APIs can make requests through the Developer Portal, which can either immediately provide access or require approval by the publisher/administrator. 開発者は、開発者ポータルで API ドキュメントとサンプル コードを参照し、Web サービスで提供されている API を迅速に採用することができます。Developers can also view the API documentation and sample code in the Developer Portal, to rapidly adopt the APIs offered by the web service.

これらの開発者が作成したアプリは、Azure API Management に用意されているプロキシを経由して API にアクセスします。The apps that these developers create then access the API through the proxy offered by Azure API Management. プロキシでは、不明瞭レイヤーによって発行者/管理者のサーバーにある API の実際のエンドポイントが隠蔽され、また API 変換などのロジックを追加して、API の呼び出しが別の API にリダイレクトされる場合に、公開されている API が一貫性を保つようにできます。The proxy both provides a layer of obscurity, hiding the actual end-point of the API on the publisher/administrator’s server and can also include additional logic like API translation to ensure the exposed API is kept consistent when a call to one API is redirected to another. また、IP フィルタリングを使って、特定の IP ドメインやドメインのセットで発生した API 呼び出しをブロックすることもできます。It can also use IP filtering to block API calls originating from a specific IP domain or set of domains. また、Azure App 管理では、各 API 呼び出しの認証と承認のために公開キーのセット (API キーと呼ばれます) を使って、Web サービスのセキュリティ保護を維持します。Azure API Management also keeps its web services secure by using a set of public keys, called API keys, to authenticate and authorize each API call. 認証が失敗した場合、API へのアクセスや API がサポートする機能へのアクセスがブロックされます。When authorization fails, access to the API and the functionality it supports is blocked.

Azure App 管理では、Web サービスのパフォーマンスを最適化するために、サービスでの API 呼び出しの回数を減らすこともできます (この手続きはスロットルと呼ばれます)。Azure API Management can also reduce the number of API calls to a service (a procedure called throttling) to optimizes the performance of the web service. 詳しくは、「Azure API 管理」および「AzureCon 2015 の Azure API 管理」をご覧ください。To learn more, review Azure API Management and Azure API Management at AzureCon 2015.

4 保存データに関するセキュリティ保護の方法4 Data-at-rest security methods

データがデバイスに到着すると、そのデータは "保存データ" と呼ばれます。When data arrives on a device, we refer to it as "data-at-rest." このデータは、承認されていないユーザーやアプリからのアクセスを防ぐために、セキュリティ保護の方法に従ってデバイスに保存する必要があります。This data needs to be stored on the device in a secure manner, so that it cannot be accessed by unauthorized users or apps. Windows 10 のアプリ モデルでは、アプリで保存されたデータはそのアプリによってのみアクセスできるようにして、必要な場合はデータを共有するための API を提供するように、さまざまな操作を行います。The app model in Windows 10 does a lot to ensure that the data stored by any app is only accessible to that app, while providing APIs to share the data when necessary. また、追加の API を利用して、データを暗号化し、資格情報を安全に保存することができます。Additional APIs are also available to ensure that data can be encrypted and credentials can be stored safely.

4.1 Windows アプリ モデル4.1 Windows app model

従来、Windows はアプリの定義を備えていませんでした。Traditionally, Windows has never had a definition of an app. 一般的には、実行可能ファイル (.exe) がアプリの定義として扱われていましたが、インストール、状態の記憶、実行の長さ、バージョン管理、OS の統合、およびアプリ間通信は、定義には含まれていませんでした。It was most commonly referred to as an executable (.exe), and this never included installation, storage of state, execution length, versioning, OS integration, or app-to-app communication. ユニバーサル Windows プラットフォーム モデルでは、インストール、ランタイム環境、リソース管理、更新プログラム、データ モデル、およびアンインストールを含めるように、アプリ モデルを定義します。The Universal Windows Platform model defines an app model that covers installation, runtime environment, resource management, updates, data model, and uninstallation.

Windows 10 アプリは、既定では (追加の特権を要求でき、ユーザーに与えられた) 特権を制限があることを意味、コンテナーで実行します。Windows 10 apps run in a container, which means that they have limited privileges by default (additional privileges can be requested and granted by the user). たとえば、アプリがシステム上のファイルにアクセスする場合、Windows.Storage.Pickers 名前空間のファイル ピッカーを使って、ユーザーにファイルを選ばせる必要があります (ファイルに直接アクセスすることはできません)。For example, if an app wants to access files on the system, a file picker from the Windows.Storage.Pickers namespace has to be used to let the user pick a file (no direct access to files is enabled). 別の例としては、アプリがユーザーの位置情報データにアクセスする場合、位置デバイス機能を有効にして、このアプリがユーザーの位置情報へのアクセスを要求することをダウンロード時にユーザーに確認する必要があります。Another example is if an app wants to access the user’s location data, it needs to enable the location device capability needs to be declared, prompting the user at download time that this app will request access to the user’s location. さらに、アプリが初めてユーザーの位置情報にアクセスするとき、追加の同意のプロンプトがユーザーに示され、データへのアクセスの許可を要求します。On top of that, the first time the app wants to access the user’s location, an additional consent prompt is shown to the user, requesting permission to access the data.

このアプリ モデルは、アプリが外部と通信できない "刑務所" として機能しますが、外部から通信できない "城" ではないことに注意してください (もちろん管理者特権を持つアプリケーションは中に入れます)。Note that this app model acts as a "jail" for apps, meaning that they can’t reach out, but it is not a “castle” that cannot be reached from the outside (applications with administrator privileges can of course still reach in). どの (Win32) アプリを実行できるかを組織/IT が指定することを可能にする、Windows 10 の Device Guard は、このアクセスをさらに制限するのに役立ちます。Device Guard in Windows 10, which enables organizations/IT to specify which (Win32) apps are allowed to execute, can further help limit this access.

また、このアプリ モデルはアプリのライフ サイクルを管理します。The app model also manages the app lifecycle. これは、既定では、アプリのバックグラウンド実行を制限します。たとえば、アプリがバックグラウンドに移動するとすぐに、プロセスは中断され (コードのアプリ中断処理を行うための少しの時間をアプリに与えた後で)、メモリはフリーズされます。It limits the background execution of apps by default, for example; as soon as an app goes into the background, the process is suspended – after giving the app a brief period to address app suspension in code – and its memory is frozen. オペレーティング システムは、アプリが特定のバックグラウンド タスクの実行 (インターネット/Bluetooth 接続、電源の変更などのさまざまなイベントによってトリガーされるスケジュールに従って、また音楽再生、GPS 追跡などの特定のシナリオで) を要求するためのメカニズムを提供します。The operating system does provide mechanisms for apps to ask for specific background task execution (on a schedule, triggered by various events such as Internet/Bluetooth connectivity, power changes, etc., and in specific scenarios such as music playing or GPS tracking).

デバイスのメモリ リソースが不足している場合は、Windows はアプリを終了することによってメモリ領域を解放します。When memory resources on the device are running low, Windows frees memory space by terminating apps. このライフ サイクル モデルでは、アプリは中断時に必ずデータを保持します。これは、中断してから終了するまでの間、猶予時間が与えられないためです。This lifecycle model forces apps to persist data whenever they’re suspended, because there is no additional time available between suspension and termination.

詳細については、次を参照してください。ユニバーサルは。Windows 10 のアプリケーションのライフ サイクルを理解します。For more information, see It's Universal: Understanding the Lifecycle of a Windows 10 Application.

4.2 保存された資格情報の保護4.2 Stored credential protection

多くの場合、認証済みのサービスにアクセスする Windows アプリでは、ユーザーは資格情報をローカル デバイスに保存することができます。Windows apps that access authenticated services often provide the users the option of storing their credentials on the local device. これは、ユーザーによって指定されたユーザー名とパスワードを、アプリが、次回以降の起動時に自動的に使う場合に便利です。This is a convenience for the users; when they provide their username and password, the app automatically uses them in subsequent launches of the app. この機能は、保存されているデータへのアクセス許可を攻撃者が手に入れた場合に、セキュリティ上の問題となる可能性があります。このため、Windows 10 では、Windows アプリはユーザーの資格情報を安全な資格情報保管ボックスに保存することができます。Because this can be a security issue if an attacker gains access to this stored data, Windows 10 provides the ability for Windows apps to store user credentials in a secure credential locker. アプリは、アプリのストレージ コンテナーに資格情報を保存するのではなく、資格情報保管ボックス API を呼び出して、保管ボックスに対して資格情報の保存や取得を実行します。The app calls the Credential Locker API to store and retrieve the credentials from the locker instead of storing them in the app’s storage container. 資格情報保管ボックスはオペレーティング システムによって管理されますが、アクセスは資格情報を保存したアプリに制限されます。これにより、資格情報の保存に関して、安全に管理されたソリューションが実現されます。The credential locker is managed by the operating system, but access is limited to the app that stores them, providing a securely managed solution for credential storage.

保存する資格情報をユーザーが指定すると、アプリでは、Windows.Security.Credentials 名前空間の PasswordVault オブジェクトを使って、資格情報保管ボックスへの参照を取得します。When a user supplies the credentials to be stored, the app gets a reference to the credential locker using the PasswordVault object in the Windows.Security.Credentials namespace. 次に、Windows アプリの識別子、およびユーザー名とパスワードが含まれている PasswordCredential オブジェクトが作成されます。It then creates a PasswordCredential object containing an identifier for the Windows app and the username and password. これが PasswordVault.Add メソッドに渡され、保管ボックスに資格情報が保存されます。This is passed to the PasswordVault.Add method to store the credentials in the locker. 次の C# コードの例は、これがどのように実行されるかを示しています。The following C# code example shows how this is done.

var vault = new PasswordVault();
vault.Add(new PasswordCredential("My App", username, password));

次の C# コードの例では、アプリは PasswordVault オブジェクトの FindAllByResource メソッドを呼び出して、アプリに対応するすべての資格情報を要求します。In the following C# code example, the app requests all of the credentials corresponding to the app by calling the FindAllByResource method of the PasswordVault object. 複数の資格情報が返された場合、ユーザーは、ユーザー名の入力を求められます。If more than one is returned, it prompts the user to enter their username. 保管ボックスに資格情報がない場合、アプリは、ユーザーに対して資格情報を指定するように要求します。If the credentials are not in the locker, the app prompts the user for them. ユーザーは、資格情報を使ってサーバーにログインします。The user is then logged into the server using the credentials.

private string resourceName = "My App";
private string defaultUserName;

private void Login()
{
    PasswordCredential loginCredential = GetCredentialFromLocker();

    if (loginCredential != null)
    {
        // There is a credential stored in the locker.
        // Populate the Password property of the credential
        // for automatic login.
        loginCredential.RetrievePassword();
    }
    else
    {
        // There is no credential stored in the locker.
        // Display UI to get user credentials.
        loginCredential = GetLoginCredentialUI();
    }
    // Log the user in.
    ServerLogin(loginCredential.UserName, loginCredential.Password);
}

private PasswordCredential GetCredentialFromLocker()
{
    PasswordCredential credential = null;

    var vault = new PasswordVault();
    var credentialList = vault.FindAllByResource(resourceName);

    if (credentialList.Count == 1)
    {
        credential = credentialList[0];
    }
    else if (credentialList.Count > 0)
    {
        // When there are multiple usernames,
        // retrieve the default username. If one doesn't
        // exist, then display UI to have the user select
        // a default username.
        defaultUserName = GetDefaultUserNameUI();

        credential = vault.Retrieve(resourceName, defaultUserName);
    }
    return credential;
}

詳しくは、「資格情報保管ボックス」をご覧ください。For more information, see Credential locker.

4.3 保存されたデータの保護4.3 Stored data protection

保存されたデータ (一般に "保存データ" と呼ばれます) を扱う場合、これを暗号化することによって、承認されていないユーザーは、保存されたデータにアクセスできなくなります。When you are dealing with stored data, commonly referred to as data-at-rest, encrypting it can prevent unauthorized users from accessing the stored data. データを暗号化する一般的なメカニズムには、対称キーを使う方法と非対称キーを使う方法の 2 つがあります。The two common mechanisms to encrypt data are using either symmetric keys or using asymmetric keys. ただし、データを暗号化しても、データが送信されて保存されるまでの間に、データの変更を防ぐことができるとは限りません。However, data encryption can’t ensure that the data is unaltered between the time it was sent and the time it was stored. つまり、データの整合性を保証することはできません。In other words, the data integrity cannot be ensured. メッセージ認証コード、ハッシュ、デジタル署名を利用することが、この問題を解決するための一般的な手法です。Using message authentication codes, hashes, and digital signing are common techniques to solve this problem.

4.3.1 データの暗号化4.3.1 Data encryption

対称暗号化では、送信者と受信者は同じキーを所持し、そのキーを使ってデータの暗号化と暗号化解除を行います。With symmetric encryption, both the sender and recipient have the same key and use it to both encrypt and decrypt the data. この方法で重要となる点は、送信者と受信者の双方が把握しているキーを安全に共有することです。The challenge with this approach is securely sharing the key so both parties are aware of it.

このデータ保護の方法の 1 つとして、公開/秘密キー ペアを使う非対称暗号化があります。One answer to this is asymmetric encryption, in which a public/private key pair is used. 公開キーは、メッセージを暗号化するすべてのユーザーによって自由に共有されます。The public key is shared freely with anyone who wants to encrypt a message. 秘密キーは、常に秘密のまま保持され、データの受信者だけがこのキーを使ってデータの暗号化を解除できます。The private key is always kept secret so that only you can use it to decrypt the data. 公開キーを検出できるようにするための一般的な方法は、デジタル証明書 (単に証明書とも呼ばる場合もあります) を使うことです。A common technique to allow for discovery of the public key is by using digital certificates, also simply referred to as certificates. 証明書には、ユーザーやサーバーに関する情報 (名前、発行者、メール アドレス、国など) に加えて公開キーが含まれています。The certificate holds information about the public key, in addition to information about the user or server such as the name, issuer, email address and country.

Windows アプリの開発者は、SymmetricKeyAlgorithmProvider クラスと AsymmetricKeyAlgorithmProvider クラスを使って、UWP アプリに対称暗号化と非対称暗号化を実装することができます。Windows app developers can use the SymmetricKeyAlgorithmProvider and AsymmetricKeyAlgorithmProvider classes to implement symmetric and asymmetric encryption in their UWP apps. また、CryptographicEngine クラスを使って、データの暗号化と暗号化解除、コンテンツへの署名、デジタル署名の確認を実行することができます。Additionally, the CryptographicEngine class can be used to encrypt and decrypt data, sign content and verify digital signatures. アプリでは、Windows.Security.Cryptography.DataProtection 名前空間の DataProtectionProvider クラスを使って、保存されているローカル データの暗号化と暗号化解除を実行することもできます。Apps can also use the DataProtectionProvider class in the Windows.Security.Cryptography.DataProtection namespace to encrypt and decrypt stored local data.

4.3.2 メッセージの改ざんの検出 (Mac、ハッシュ、署名)4.3.2 Detecting message tampering (MACs, hashes, and signatures)

MAC は、対称キー (秘密鍵と呼ばれます) やメッセージを MAC 暗号化アルゴリズムへの入力として使った結果生成されるコード (またはタグ) です。A MAC is a code (or tag) that results from using a symmetric key (called the secret key) or a message as input to a MAC encryption algorithm. 秘密鍵とアルゴリズムは、メッセージを転送する前に、送信者と受信者の間で合意されます。The secret key and the algorithm are agreed upon by the sender and receiver before the message transfer.

MAC では、次のようにしてメッセージを確認します。MACs verify messages like this.

  • 送信者は、秘密鍵を MAC アルゴリズムへの入力として使うことで、MAC タグを取得します。The sender derives the MAC tag by using the secret key as input to the MAC algorithm.
  • 送信者は、MAC タグとメッセージを受信者に送信します。The sender sends the MAC tag and the message to the receiver.
  • 受信者は、秘密鍵とメッセージを MAC アルゴリズムへの入力として使うことで、MAC タグを取得します。The receiver derives the MAC tag by using the secret key and the message as inputs to the MAC algorithm.
  • 受信者は、取得した MAC タグと送信者の MAC タグを比較します。The receiver compares their MAC tag with the sender's MAC tag. これらが同じである場合、メッセージは改ざんされていないと見なされます。If they are the same then we know that the message has not been tampered with.

MAC による検証

Windows アプリでは、MacAlgorithmProvider クラスを呼び出して、MAC 暗号化アルゴリズムを実行するためのキーと CryptographicEngine クラスを生成することにより、MAC によるメッセージの検証を実装できます。Windows apps can implement MAC message verification by calling the MacAlgorithmProvider class to generate the key and CryptographicEngine class to perform the MAC encryption algorithm.

4.3.3 ハッシュの使用4.3.3 Using hashes

ハッシュ関数は、任意の長さのデータ ブロックを受け取り、固定ビット サイズの文字列 (ハッシュ値) を返す暗号アルゴリズムです。A hash function is a cryptographic algorithm that takes an arbitrarily long block of data and returns a fixed-size bit string called a hash value. この処理を実行できるハッシュ関数のファミリはすべて用意されています。There is an entire family of hash functions that can do this.

上記のメッセージ転送シナリオでは、MAC の代わりにハッシュ値を使うことができます。A hash value can be used in place of a MAC in the message-transfer scenario above. 送信者はハッシュ値とメッセージを送信し、受信者は、受信者独自のハッシュ値を送信者のハッシュ値とメッセージから取得して、2 つのハッシュ値を比較します。The sender sends a hash value and a message, and the receiver derives their own hash value from the sender's hash value and message and compares the two hash values. Windows 10 で実行されているアプリでは、HashAlgorithmProvider クラスを呼び出して、利用可能なハッシュ アルゴリズムを列挙し、それらのアルゴリズムのいずれかを実行できます。Apps running on Windows 10 can call the HashAlgorithmProvider class to enumerate the hash algorithms that are available and run one of them. CryptographicHash クラスは、ハッシュ値を表します。The CryptographicHash class represents the hash value. CryptographicHash.GetValueAndReset メソッドを使うと、メソッドを使用するたびにオブジェクトを作成しなくても、異なるデータを繰り返しハッシュできます。The CryptographicHash.GetValueAndReset method can be used to repeatedly hash different data without having to re-create the object for each use. CryptographicHash クラスの Append メソッドは、ハッシュ対象のバッファーに新しいデータを追加します。The Append method of the CryptographicHash class adds new data to a buffer to be hashed. この処理全体を次の C# コードの例に示します。This entire process is shown in the following C# code example.

public void SampleReusableHash()
{
    // Create a string that contains the name of the
    // hashing algorithm to use.
    string strAlgName = HashAlgorithmNames.Sha512;

    // Create a HashAlgorithmProvider object.
    HashAlgorithmProvider objAlgProv = HashAlgorithmProvider.OpenAlgorithm(strAlgName);

    // Create a CryptographicHash object. This object can be reused to continually
    // hash new messages.
    CryptographicHash objHash = objAlgProv.CreateHash();

    // Hash message 1.
    string strMsg1 = "This is message 1";
    IBuffer buffMsg1 = CryptographicBuffer.ConvertStringToBinary(strMsg1, BinaryStringEncoding.Utf16BE);
    objHash.Append(buffMsg1);
    IBuffer buffHash1 = objHash.GetValueAndReset();

    // Hash message 2.
    string strMsg2 = "This is message 2";
    IBuffer buffMsg2 = CryptographicBuffer.ConvertStringToBinary(strMsg2, BinaryStringEncoding.Utf16BE);
    objHash.Append(buffMsg2);
    IBuffer buffHash2 = objHash.GetValueAndReset();

    // Convert the hashes to string values (for display);
    string strHash1 = CryptographicBuffer.EncodeToBase64String(buffHash1);
    string strHash2 = CryptographicBuffer.EncodeToBase64String(buffHash2);
}

4.3.4 デジタル署名4.3.4 Digital signatures

保存されているメッセージがデジタル署名されている場合、そのメッセージに関するデータの整合性は、MAC による認証と同様の方法で検証されます。The data integrity of a digitally signed stored message is verified in a similar way to MAC authentication. デジタル署名のワークフローがどのように実施されるかを次に示します。Here is the way the digital signature workflow operates.

  • 送信者は、メッセージをハッシュ アルゴリズムへの入力として使って、ハッシュ値 (ダイジェストとも呼ばれます) を取得します。The sender derives a hash value (also known as a digest) by using the message as the input to a hash algorithm.
  • 送信者は、秘密キーを使ってダイジェストを暗号化します。The sender encrypts the digest using their private key.
  • 送信者は、メッセージ、暗号化されたダイジェスト、使われたハッシュ アルゴリズムの名前を送信します。The sender sends the message, the encrypted digest, and the name of the hash algorithm that was used.
  • 受信者は、公開キーを使って、受信したダイジェスト (暗号化されたダイジェスト) の暗号化を解除します。The receiver uses the public key to decrypt the encrypted digest it received. 次に、ハッシュ アルゴリズムを使ってメッセージをハッシュし、独自のダイジェストを作成します。It then uses the hash algorithm to hash the message to create a digest of its own. 最後に、受信者は 2 つのダイジェストを比較します (受信し暗号化を解除したダイジェストと、作成したダイジェスト)。And finally the receiver compares the two digests (the one it received and decrypted, and the one it made). 2 つのダイジェストが一致した場合にのみ、受信者は、メッセージが秘密キーの所有者から送信されたものであることを確信できます。これにより、メッセージが実際にその送信者からのものであり、メッセージが転送中に変更されていないことが保証されます。Only if the two match can the receiver be sure that the message was sent by the possessor of the private key, and therefore they are who they say they are, and that the message was not altered in transit.

デジタル署名

ハッシュ アルゴリズムは非常に高速であるため、サイズの大きいメッセージからでも、ハッシュ値をすばやく取得できます。Hashing algorithms are very fast, so hash values can be derived quickly from even large messages. 生成されたハッシュ値は任意の長さになりますが、メッセージ全体よりも短くなります。このため、公開キーと秘密キーを使ってメッセージ全体ではなくダイジェストのみを暗号化および暗号化解除する方法が最適な方法です。The resulting hash value is an arbitrary length and can be shorter than the full message, so using public and private keys to encrypt and decrypt only the digest rather than the full message is an optimization.

詳しくは、「デジタル署名」、「MAC、ハッシュ、および署名」、および「暗号化」の記事をご覧ください。For more information, take a look articles on Digital signatures, MACs, hashes, and signatures, and Cryptography.

5 まとめ5 Summary

Windows 10 のユニバーサル Windows プラットフォームには、オペレーティング システムの機能を活用してより安全なアプリを作成する方法が数多くあります。The Universal Windows Platform in Windows 10 offers a number of ways to leverage operating system capabilities to create more secure apps. 単一要素、多要素、または OAuth ID プロバイダーを利用する仲介の認証などさまざまな認証シナリオで、最も一般的な認証問題を軽減する API があります。In different authentication scenarios, such as single-factor, multi-factor, or brokered authentication with an OAuth identity provider, APIs exist to mitigate the most common challenges with authentication. Windows Hello によって、ユーザーを認識する新しい生体認証サインイン システムが提供されます。また、Windows Hello を使うことで、正しい ID を意図的に回避するような操作をアクティブに阻止することができます。Windows Hello provides a new biometric sign-in system that recognizes the user and actively defeats efforts to circumvent proper identification. さらに、キーと証明書に関する複数の層も提供されます。これらの層は、トラステッド プラットフォーム モジュールの外部で公開されたり、使われたりすることは決してありません。It also delivers multiple layers of keys and certificates that can never be revealed or used outside the trusted platform module. また、より詳細なセキュリティ レイヤーを、オプションである構成証明識別キーや証明書の利用時に使うことができます。Plus, a further layer of security is available through the optional use of attestation identity keys and certificates.

移動中データの安全性を確保するには、SSL 経由で安全にリモート システムと通信し、SSL のピン留めを使用してサーバーの信頼性を検証することができる API が利用できます。To secure data in flight, APIs exist to communicate with remote systems securely over SSL, while providing the possibility to validate the server’s authenticity with SSL pinning. 安全かつ制御された方法で API を発行することに関しては、Azure API 管理が、API のエンドポイントを不明瞭化する機能が加わったプロキシを使用して、Web 経由での API 公開用の強力な構成オプションを提供することにより支援します。Publishing APIs securely and in a controlled manner is something in which Azure API Management aids by providing powerful configuration options for exposing APIs across the web using a proxy that provides additional obfuscation of the API endpoint. これらの API へのアクセスは API キーを使用することによりセキュリティが確保され、パフォーマンスを制御するために API の呼び出しを抑制することが可能です。Access to these APIs is secured by using API keys and API calls can be throttled to control performance.

データがデバイスに到着すると、Windows アプリ モデルは、アプリがインストール、更新される方法、およびデバイスのデータにアクセスする方法をより細かく制御し、アプリが他のアプリのデータに承認されていない方法でアクセスするのを防止します。When the data arrives on the device, the Windows app model provides more control over how the app is installed, updated and accesses it data, while keeping it from accessing data of other apps in an unauthorized manner. 資格情報保管ボックスを利用することで、ユーザーの資格情報の保存用に、オペレーティング システムによって管理されるセキュリティで保護された記憶域を使用し、ユニバーサル Windows プラットフォームが提供する暗号化およびハッシュ化する API を使うことによって他のデータをデバイス上で保護することができます。Credential locker can provide secure storage of user credentials that is managed by the operating system and other data can be protected on the device by using the encryption and hashing APIs offered by the Universal Windows Platform.

6 リソース6 Resources

6.1 ハウツー記事6.1 How-to articles

6.2 コード サンプル6.2 Code samples

6.3 API リファレンス6.3 API reference