安全な Windows アプリの開発について

この入門記事では、アプリアーキテクトと開発者が、安全なユニバーサルWindowsプラットフォーム(UWP)アプリの作成を高速化するさまざまなWindows10プラッ 次の各段階で利用可能なWindowsセキュリティ機能の使用方法について詳しく説明します。認証、飛行中のデータ、および保存中のデータ。 各章に含まれている追加のリソースを確認することで、各トピックに関する詳細な情報を見つけることができます。

1 Introduction (はじめに)

安全なアプリを開発することは困難な場合があります。 モバイル、ソーシャル、クラウド、複雑なエンタープライズアプリの今日の急速な世界では、顧客はアプリがこれまで以上に早く利用可能になり、更新されることを期待しています。 また、多くの種類のデバイスを使用しているため、アプリエクスペリエンスの作成がさらに複雑になります。 Windows ユニバーサル Windows プラットフォーム (UWP) 用にビルドする場合は、従来のデスクトップ、ノート PC、タブレット、モバイル デバイスの一覧を含めることができます。また、モノのインターネット、Xbox One、Microsoft Surface Hub、HoloLens にまたがる新しいデバイスの一覧も増えています。 開発者は、関連するすべてのプラットフォームまたはデバイス間で、アプリがデータを安全に通信して保存することを確認する必要があります。

Windows セキュリティ機能を利用する利点の一部を次に示します。

• セキュリティ コンポーネントとテクノロジに一貫性のある API を使用することで、Windows をサポートするすべてのデバイスでセキュリティが標準化されます。
• これらのセキュリティシナリオをカバーするためにカスタムコードを実装した場合よりも、コードの記述、テスト、および保守が少なくなります。
• オペレーティングシステムを使用して、アプリがリソースやローカルまたはリモートのシステムリソースにアクセスする方法を制御するため、アプ

認証中に、特定のサービスへのアクセスを要求しているユーザーのidが検証されます。 Windows Hello は、Windows アプリでより安全な認証メカニズムを作成するのに役立つ Windows のコンポーネントです。 これを使用すると、個人識別番号（PIN）またはユーザーの指紋、顔、虹彩などの生体認証を使用して、アプリに多要素認証を実装できます。

Data-in-flightは、接続とそれを介して転送されるメッセージを指します。 この例として、webサービスを使用してリモートサーバーからデータを取得することが挙げられます。 Secure Sockets Layer(SSL)とSecure Hypertext Transfer Protocol(HTTPS)を使用すると、接続のセキュリティが保証されます。 仲介者がこれらのメッセージにアクセスしたり、許可されていないアプリがwebサービスと通信したりするのを防ぐことは、飛行中のデータを保護する

最後に、保存データは、メモリ内または記憶媒体上に存在するデータに関連する。 Windows アプリには、アプリ間の未承認のデータ アクセスを防止するアプリ モデルがあり、デバイス上のデータをさらにセキュリティで保護するための暗号化 API を提供します。 Credential Lockerと呼ばれる機能を使用して、ユーザーの資格情報をデバイスに安全に保存し、オペレーティングシステムが他のアプリがアクセスできないようにすることができます。

2認証要素

データを保護するには、データへのアクセスを要求する人を特定し、要求するデータリソースにアクセスする権限を付与する必要があります。 ユーザーを識別するプロセスは認証と呼ばれ、リソースへのアクセス権限を決定するプロセスは承認と呼ばれます。 これらは密接に関連する操作であり、ユーザーにとっては区別がつかない可能性があります。 たとえば、データが1つのサーバー上にあるのか、多くのシステムに分散されているのかなど、さまざまな要因に応じて、比較的単純な操作または複雑な操作になります。 認証および承認サービスを提供するサーバーは、idプロバイダーと呼ばれます。

特定のサービスおよび/またはアプリで自分自身を認証するために、ユーザーは、自分が知っているもの、持っているもの、および/または自分が何かで構成される資格情報を使用します。 これらのそれぞれは、認証要因と呼ばれます。

• ユーザーが知っていること 通常はパスワードですが、個人識別番号（PIN）または"秘密の"質問と回答のペアにすることもできます。
• ユーザーが持っているもの ほとんどの場合、ユーザー固有の認証データを含むUSBスティックなどのハードウェアメモリデバイスです。
• ユーザーが何か 多くの場合、彼らの指紋を包含するが、ユーザーのスピーチ、顔、眼（目）特性、または行動のパターンのようなますます一般的な要因があります。 データとして保存されている場合、これらの測定値は生体認証と呼ばれます。

ユーザーによって作成されたパスワードは、それ自体が認証要素ですが、多くの場合、十分ではありません。 スマートカードはより高いレベルのセキュリティを提供できますが、盗まれたり、紛失したり、置き忘れたりする可能性があります。 指紋または眼スキャンによってユーザーを認証できるシステムは、最高かつ最も便利なレベルのセキュリティを提供する可能性がありますが、高価で特化したハードウェア(顔認識用のIntel RealSenseカメラなど)が必要であり、すべてのユーザーが利用できるわけではない可能性があります。

システムで使用される認証方法を設計することは、データセキュリティの複雑で重要な側面です。 一般に、認証に使用する要素の数が多いほど、システムの安全性が高くなります。 同時に、認証が使用可能である必要があります。 通常、ユーザーは1日に何度もログインするため、プロセスは高速でなければなりません。 認証タイプの選択は、セキュリティと使いやすさのトレードオフであり、単一要素認証は最も安全で使いやすく、多要素認証はより安全になりますが、より多くの要素が追加されるにつれて複雑になります。

2.1シングルファクタ認証

この形式の認証は、単一のユーザー資格情報に基づいています。 これは通常パスワードですが、個人識別番号（PIN）である可能性もあります。

ここでは、単一要素認証のプロセスです。

• ユーザーは、ユーザー名とパスワードをidプロバイダーに提供します。 Idプロバイダーは、ユーザーのidを検証するサーバープロセスです。
• Idプロバイダーは、ユーザー名とパスワードがシステムに保存されているものと同じかどうかを確認します。 ほとんどの場合、パスワードは暗号化され、他の人がパスワードを読むことができないように追加のセキュリティが提供されます。
• Idプロバイダーは、認証が成功したかどうかを示す認証ステータスを返します。
• 成功すると、データ交換が開始されます。 失敗した場合は、ユーザーを再認証する必要があります。

今日、この認証方法は、サービス全体で最も一般的に使用されています。 また、認証の唯一の手段として使用される場合、認証の最も安全性の低い形式でもあります。 パスワードの複雑さの要件、"秘密の質問"、および定期的なパスワードの変更は、パスワードを使用してより安全にすることができますが、彼らはユーザーに多くの負担をかけ、彼らはハッカーに対する効果的な抑止力ではありません。

パスワードの課題は、複数の要因を持つシステムよりも、パスワードを正常に推測する方が簡単であるということです。 小さな Web ショップからユーザー アカウントとハッシュされたパスワードでデータベースを盗む場合、他の Web サイトで使用されるパスワードを使用できます。 複雑なパスワードは覚えにくいため、ユーザーは常にアカウントを再利用する傾向があります。 IT部門にとって、パスワードを管理することは、リセットメカニズムを提供する必要があり、パスワードを頻繁に更新する必要があり、安全な方法で保存す

そのすべての欠点に対して、単一要素認証はユーザーに資格情報の制御を提供します。 彼らはそれを作成して変更し、認証プロセスにはキーボードだけが必要です。 これは、単一要素認証と多要素認証を区別する主な側面です。

2.1.1Web認証ブローカ

前述したように、IT部門のパスワード認証の課題の一つは、ユーザー名/パスワードのベース、リセットメカニズムなどを管理するための追加のオーバーヘッドです。 ますます普及しているオプションは、認証のためのオープン標準であるOAuthを介した認証を提供するサードパーティのidプロバイダーに依存することです。

OAuthを使用すると、it部門は、ユーザー名とパスワードを使用してデータベースを維持したり、パスワード機能をリセットしたりする複雑さを効果的に「外部委託」できます。 Facebook、X、Microsoftなどのサードパーティのidプロバイダーに。

ユーザーはこれらのプラットフォームで自分のidを完全に制御できますが、アプリはユーザーが認証された後、認証されたユーザーを承認するために使用できる

Windows の Web 認証ブローカーには、OAuth や OpenID などの認証プロトコルと承認プロトコルを使用するアプリ用の API とインフラストラクチャのセットが用意されています。 アプリは、次の方法で認証操作を開始できます。 WebAuthenticationBroker APIは、その結果、aの戻り値になります WebAuthenticationResult. 通信フローの概要を次の図に示します。

アプリはブローカーとして機能し、アプリで Web ビューを介して ID プロバイダーとの認証を開始します。 Idプロバイダーがユーザーを認証すると、idプロバイダーからユーザーに関する情報を要求するために使用できるトークンがアプリに返されます。 セキュリティ対策として、認証プロセスをidプロバイダーと仲介できるようにするには、アプリをidプロバイダーに登録する必要があります。 この登録手順はプロバイダごとに異なります。

を呼び出すための一般的なワークフローは次のとおりです。 WebAuthenticationBroker プロバイダと通信するためのAPI。

• Idプロバイダーに送信される要求文字列を作成します。 文字列の数と各文字列の情報は、webサービスごとに異なりますが、通常、それぞれにURLを含む2つのURI文字列が含まれています。1つは認証要求が送信されるもので、もう1つは承認が完了した後にユーザーがリダイレクトされます。
• コール WebAuthenticationBroker.AuthenticateAsync、要求文字列を渡し、idプロバイダからの応答を待ちます。
• コール WebAuthenticationResult.ResponseStatus 応答が受信されたときのステータスを取得します。
• 通信が成功した場合は、idプロバイダーから返された応答文字列を処理します。 失敗した場合は、エラーを処理します。

通信が成功した場合は、idプロバイダーから返された応答文字列を処理します。 失敗した場合は、エラーを処理します。

このプロセスのサンプルC＃コードは以下のとおりです。 詳細および詳細なチュートリアルについては、以下を参照してください WebAuthenticationBroker. 完全なコードサンプルについては、 GitHub上のWebAuthenticationBrokerサンプル.

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番目の資格情報をどのように受け取るかを選択できます。 このタイプの認証の例は、SMSを使用して確認コードがユーザーの携帯電話に送信される一般的に使用されるプロセスです。

• ユーザーは、ユーザー名とパスワードをidプロバイダーに提供します。
• Idプロバイダーは、単一要素認証のようにユーザー名とパスワードを検証し、システムに保存されているユーザーの携帯電話番号を検索します。
• サーバは、生成された確認コードを含むＳＭＳメッセージをユーザの携帯電話に送信する。
• ユーザーは、ユーザーに提示されたフォームを介して、idプロバイダーに確認コードを提供します。
• Idプロバイダーは、両方の資格情報の認証が成功したかどうかを示す認証ステータスを返します。
• 成功すると、データ交換が開始されます。 それ以外の場合は、ユーザーを再認証する必要があります。

ご覧のように、このプロセスは、2番目のユーザー資格情報がユーザーによって作成または提供されるのではなく、ユーザーに送信されるという点で、単一要素認証とは異なります。 したがって、ユーザーは必要な資格情報を完全に制御することはできません。 これは、スマートカードが2番目の資格情報として使用されている場合にも当てはまります。組織は、それを作成してユーザーに提供することを担当しています。

2.2.1 Azure Active Directory

Azure Active Directory(Azure AD)は、クラウドベースのidおよびアクセス管理サービスであり、単一要素認証または多要素認証のidプロバイダーとして機能します。 Azure AD認証は、確認コードの有無にかかわらず使用できます。

Azure ADは単一要素認証を実装することもできますが、企業は通常、多要素認証のより高いセキュリティを必要とします。 多要素認証の構成では、Azure ADアカウントで認証するユーザーは、確認コードをSMSメッセージとして携帯電話またはAzure Authenticatorモバイルアプリに送信することがで

さらに、Azure ADはOAuthプロバイダーとして使用でき、標準ユーザーにさまざまなプラットフォーム間のアプリに対する認証と承認のメカニズムを提供します。 詳細については、以下を参照してください Azure Active Directory と Azureでの多要素認証.

2.4Windowsこんにちは

Windows では、便利な多要素認証メカニズムがオペレーティング システムに組み込まれています。 Windows Hello は、Windows に組み込まれている新しい生体認証サインイン システムです。 では営業システム、Windowsこんにちはき顔や指紋認証のロック解除ユーザーのデバイス Windows secure credential storeは、デバイス上の生体認証データを保護します。

Windowsこんにちは提供を確実にデバイスを認識し、個人ユーザーは、アドレスの最初の部分の間、ユーザーは、要求されたサービスまたはデータ項目です。 デバイスは、ユーザーを認識した後も、要求されたリソースへのアクセスを許可するかどうかを決定する前に、ユーザーを認証する必要があります。 Windowsこんにちはも強い二要素認証(2FA)は、完全に統合Windowsおよび置換再利用可能なパスワードの組み合わせで特定のデバイス、生体やジェスチャーをピンと張ります。 PINは、Microsoftアカウント登録の一部としてユーザーによって指定されます。

Windowsこんにちはか交換のための伝統的な2FAシステムです。 これは概念的にはスマートカードに似ています：認証は文字列比較の代わりに暗号化プリミティブを使用して実行され、ユーザーの鍵材料は耐タンパー性ハー Microsoftこんにちはを必要としませんのインフラに必要な部品のスマートカードを展開。 特に、現在証明書を持っていない場合は、証明書を管理するために公開鍵インフラストラクチャ（PKI）は必要ありません。 Windowsこんにちはを併せ持つ強みは主にスマートカード展開の柔軟性のための仮想スマートカードおよび堅牢なセキュリティのための物理的スマートカードせずにその問題点がありました。

デバイスを登録しなければWindowsこんにちは前にユーザを認証します。 Windowsこんにちは用の非対称性(公開鍵暗号化する一方法を設定して公開鍵暗号化データの相手で復号化を使用するものとする。 の場合はWindowsこんにちはを成形することができます。セットの公開鍵と非公開鍵のペアおよび書き込みますは、鍵のデバイスの信頼できるプモジュール(TPM)チップです。 デバイスが登録された後、UWP アプリはシステム API を呼び出してユーザーの公開鍵を取得し、これを使用してユーザーをサーバーに登録できます。

アプリの登録ワークフローは次のようになります:

収集する登録情報には、この単純なシナリオよりも多くの識別情報が含まれている場合があります。 たとえば、アプリが銀行などのセキュリティで保護されたサービスにアクセスする場合、サインアッププロセスの一環として、身元証明などを要求す すべての条件が満たされると、このユーザーの公開鍵はバックエンドに保存され、ユーザーが次にサービスを使用するときに検証するために使用されます。

Windows Hello の詳細については、「Windows Hello for Business の概要Windows Hello 開発者ガイドを参照してください。

3飛行中のデータセキュリティ方法

データインフライトのセキュリティ方法は、ネットワークに接続されたデバイス間で転送中のデータに適用されます。 データは、プライベート企業イントラネットの高セキュリティ環境上のシステム間で、またはwebの非セキュア環境内のクライアントとwebサービス間で転送される可能性があります。 Windows アプリは、ネットワーク API を介した SSL などの標準をサポートし、開発者がアプリに適切なレベルのセキュリティを確保できる Azure API Management などのテクノロジと連携します。

3.1リモートシステム認証

リモートコンピュータシステムとの通信が発生する一般的なシナリオは2つあります。

• ローカルサーバーは、直接接続を介してユーザーを認証します。 たとえば、サーバーとクライアントが企業イントラネット上にある場合などです。
• Webサービスは、インターネットを介して通信されます。

データはもはや安全なネットワークの一部ではなく、悪意のある攻撃者がデータを傍受しようとする可能性も高いため、webサービス通信のセキュリティ要件 さまざまな種類のデバイスがサービスにアクセスするため、たとえばWCFとは対照的に、RESTfulサービスとして構築される可能性が高く、サービスへの認証と承認にも新たな課題が生じることを意味します。 ここでは、安全なリモートシステム通信のための2つの要件について説明します。

最初の要件は、メッセージの機密性です: クライアントとwebサービスの間で渡される情報（たとえば、ユーザーの身元やその他の個人情報）は、転送中に第三者が読み取ることができないようにして これは通常、メッセージが送信される接続を暗号化し、メッセージ自体を暗号化することによって実現されます。 秘密/公開鍵の暗号化では、公開鍵は誰でも使用でき、特定の受信者に送信されるメッセージを暗号化するために使用されます。 秘密鍵は受信者によってのみ保持され、メッセージを復号化するために使用されます。

第二の要件は、メッセージの整合性です: クライアントとwebサービスは、受信したメッセージが相手側から送信されることを意図したものであり、メッセージが転送中に変更されていないことを確 これは、デジタル署名を使用してメッセージに署名し、証明書認証を使用することによって実現されます。

3.2 SSL connections

クライアントへの安全な接続を確立および維持するために、webサービスはSecure Sockets Layer(SSL)を使用できます。 SSLは、サーバ証明書と同様に公開鍵の暗号化をサポートすることにより、メッセージの機密性と整合性を提供します。 SSLはTransport Layer Security(TLS)に取って代わられますが、TLSはしばしばsslと呼ばれます。

クライアントがサーバ上のリソースへのアクセスを要求すると、SSLはサーバとのネゴシエーションプロセスを開始します。 これはSSLハンドシェイクと呼ばれます。 暗号化レベル、公開暗号化キーと秘密暗号化キーのセット、およびクライアント証明書とサーバー証明書のid情報は、SSL接続の期間中のすべての通信の基礎とし また、サーバーはこの時点でクライアントの認証を要求する場合もあります。 接続が確立されると、接続が閉じるまで、ネゴシエートされた公開鍵ですべてのメッセージが暗号化されます。

3.2.1SSLピン留め

SSLは暗号化と証明書を使用してメッセージの機密性を提供できますが、クライアントが通信しているサーバーが正しいかどうかを確認するためには何も サーバーの動作は、許可されていないサードパーティによって模倣され、クライアントが送信する機密データを傍受する可能性があります。 これを防ぐために、SSLピン留めと呼ばれる手法を使用して、サーバー上の証明書がクライアントが期待し信頼する証明書であることを確認します。

アプリにSSLピン留めを実装するには、いくつかの異なる方法があり、それぞれに長所と短所があります。 最も簡単な方法は、アプリのパッケージマニフェストの証明書宣言を使用することです。 この宣言により、アプリパッケージはデジタル証明書をインストールし、それらに排他的な信頼を指定できます。 これにより、証明書チェーンに対応する証明書を持つアプリとサーバー間でのみSSL接続が許可されます。 このメカニズムにより、信頼された公開証明機関に第三者の依存関係が必要ないため、自己署名証明書の安全な使用も可能になります。

検証ロジックをより詳細に制御するために、HTTPS 要求に応答してサーバーから返された証明書を検証するための API を使用できます。 このメソッドでは、要求を送信して応答を検査する必要があるため、要求で機密情報を実際に送信する前に、これを検証として追加してください。

次のC#コードは、このSSLピン留め方法を示しています。 ザ- バリダテスルート メソッドは、 HttpClient HTTP要求を実行するクラス。 クライアントが応答を送信した後、クライアントは応答を使用します。 RequestMessage。輸送情報。ServerIntermediateCertificates サーバーから返された証明書を検査するためのコレクション。 その後、クライアントは、含まれているサムプリントを使用して証明書チェーン全体を検証できます。 この方法では、サーバー証明書の有効期限が切れて更新されたときに、アプリで証明書のサムプリントを更新する必要があります。

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 へのアクセスの公開と保護

Webサービスへのアクセスを許可するには、API呼び出しが行われるたびに認証を必要とする必要があります。 パフォーマンスとスケールを制御できることは、webサービスがweb全体で公開されるときに考慮すべきことでもあります。 Azure API Management は、3 つのレベルで機能を提供しながら、Web 全体で API を公開するのに役立つサービスです。

出版社/管理者 APIのAzure API Managementのパブリッシャーポータルを介して簡単にAPIを構成することができます。 ここでは、API セットを作成し、それらへのアクセスを管理して、誰がどの API にアクセスできるかを制御できます。

開発者 これらの API へのアクセスを希望する場合は、開発者ポータルを介してリクエストを行うことができ、すぐにアクセスを提供するか、発行者/管理者の承認を必要とすることができます。 開発者は、API ドキュメントとサンプル コードを開発者ポータルで表示して、Web サービスによって提供される API を迅速に採用することもできます。

ザ- アプリ これらの開発者が作成したものは、Azure API Managementが提供するプロキシを介してAPIにアクセスします。 プロキシはどちらも、パブリッシャー/管理者のサーバー上のAPIの実際のエンドポイントを隠す、あいまいさの層を提供し、また、あるAPIへの呼び出しが別のAPIにリダイレクトインされたときに公開されたAPIの一貫性を維持するためのAPI変換などの追加のロジックを含めることができる。 また、IPフィルタリングを使用して、特定のIPドメインまたはドメインのセットから発信されるAPI呼び出しをブロックすることもできます。 また、Azure API Managementは、APIキーと呼ばれる一連の公開キーを使用して各API呼び出しを認証および承認することにより、webサービスを安全に保ちます。 認証に失敗すると、APIとそれがサポートする機能へのアクセスがブロックされます。

Azure API Managementでは、webサービスのパフォーマンスを最適化するために、サービス(調整と呼ばれる手順)へのAPI呼び出しの数を減らすこともできます。 詳細については、以下を確認してください Azure API Management そして、AzureCon2015でAzure API Management。

4保存データのセキュリティ方法

デバイスに到着したデータのことを、"保存データ" と呼びます。このデータは、承認されていないユーザーやアプリからアクセスできない安全な方法でデバイスに格納する必要があります。 Windows のアプリ モデルでは、必要に応じてデータを共有する API を提供しながら、すべてのアプリによって格納されたデータに、そのアプリのみがアクセスできるように、多くの処理が行われます。 データを暗号化し、資格情報を安全に保存できるようにするために、追加の API も利用できます。

4.1Windowsアプリモデル

伝統的に、Windowsはアプリの定義を持っていませんでした。 これは、最も一般的に実行可能ファイル（と呼ばれていました。exe）、これには、インストール、状態の保存、実行長、バージョン管理、OS統合、またはアプリ間通信が含まれていませんでした。 ユニバーサルWindowsプラットフォームモデルは、インストール、実行時環境、リソース管理、更新、データモデル、およびアンインストールをカバーするアプリモデルを定義

Windows10アプリはコンテナ内で実行されるため、既定では制限された特権があります(ユーザーが追加の特権を要求して付与することができます)。 たとえば、アプリがシステム上のファイルにアクセスしたい場合は、次のファイルピッカーからファイルピッカーを選択します。 窓。ストレージ。ピッカーズ ユーザーがファイルを選択できるようにするには、名前空間を使用する必要があります（ファイルへの直接アクセスは有効になっていません）。 別の例は、アプリがユーザーの位置データにアクセスしたい場合、デバイス機能を宣言する必要がある場所を有効にする必要があり、ダウンロード時にユーザーにこのアプリがユーザーの位置へのアクセスを要求することを要求します。 さらに、アプリがユーザーの場所に初めてアクセスするときに、追加の同意プロンプトがユーザーに表示され、データにアクセスする許可が要求されます。

このアプリモデルはアプリの「刑務所」として機能し、手を差し伸べることはできませんが、外部から到達できない「城」ではありません（管理者権限を持 Windows の Device Guard では、組織/IT 部門が実行を許可する (Win32) アプリを指定できるため、このアクセスをさらに制限できます。

アプリモデルは、アプリのライフサイクルも管理します。 たとえば、アプリがバックグラウンドに入るとすぐに、コード内のアプリの停止に対処するためにアプリに短い期間を与えた後、プロセスは中断され、 オペレーティングシステムは、インターネット/Bluetooth接続、電源の変更などのさまざまなイベントによってトリガーされたスケジュールで、特定のバックグラウンドタスクの実行を要求するアプリのメカニズムを提供します。、および音楽遊ぶか、またはGPSの追跡のような特定のシナリオで）。

デバイス上のメモリリソースが不足している場合、windowsはアプリを終了することによってメモリ領域を解放します。 このライフサイクルモデルは、中断と終了の間に追加の時間がないため、アプリが中断されるたびにデータを保持するように強制します。

詳細については、以下を参照してください それは普遍的です: Windows10/11アプリケーションのライフサイクルを理解する.

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

認証されたサービスにアクセスするWindowsアプリでは、多くの場合、ユーザーに資格情報をローカルデバイスに保存するオプションが提供されます。 ユーザーがユーザー名とパスワードを入力すると、アプリはその後のアプリの起動でそれらを自動的に使用します。 これは、攻撃者がこの保存されたデータにアクセスした場合にセキュリティの問題になる可能性があるため、Windows では、パッケージ化されたアプリがセキュリティで保護された資格情報ロッカーにユーザーの資格情報を格納する機能を提供します。 アプリはCredential Locker APIを呼び出して、アプリのストレージコンテナに保存するのではなく、ロッカーから資格情報を保存および取得します。 資格情報ロッカーはオペレーティングシステムによって管理されますが、アクセスはそれらを格納するアプリに制限されているため、資格情報ストレージのための安全に管理されたソリューションを提供します。

ユーザーが保存する資格情報を指定すると、アプリは資格情報ロッカーへの参照を取得します。 PasswordVault 内のオブジェクト Windows.Security.Credentials 名前空間。 次に、aを作成します PasswordCredential Windowsアプリの識別子とユーザー名とパスワードを含むオブジェクト。 これはに渡されます PasswordVault.Add 資格情報をロッカーに保存する方法。 次のC＃コード例は、これがどのように行われるかを示しています。

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

次のC#コード例では、アプリは、アプリに対応するすべての資格情報を要求します。 FindAllByResource の方法 PasswordVault オブジェクト。 複数が返された場合は、ユーザー名の入力を求められます。 資格情報がロッカーにない場合、アプリはユーザーに資格情報の入力を求めます。 その後、ユーザーは資格情報を使用してサーバーにログインします。

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();

    IReadOnlyList<PasswordCredential> credentialList = null;

    try
    {
        credentialList = vault.FindAllByResource(resourceName);
    }
    catch(Exception)
    {
        return null;
    }

    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;
}

詳細については、以下を参照してください クレデンシャルロッカー.

4.3保存されたデータ保護

一般に保存データと呼ばれる保存されたデータを処理する場合、暗号化すると、許可されていないユーザーが保存されたデータにアクセスできなくなります。 データを暗号化する2つの一般的なメカニズムは、対称キーを使用するか、非対称キーを使用するかのいずれかです。 ただし、データの暗号化では、データが送信されてから保存された時間の間にデータが変更されないようにすることはできません。 つまり、データの完全性を保証することはできません。 メッセージ認証コード、ハッシュ、およびデジタル署名を使用することは、この問題を解決するための一般的な手法です。

4.3.1データ暗号化

対称暗号化では、送信者と受信者の両方が同じキーを持ち、それを使用してデータの暗号化と復号化の両方を行います。 このアプローチの課題は、鍵を安全に共有して、両当事者がそれを認識できるようにすることです。

これに対する1つの答えは、公開鍵と秘密鍵のペアが使用される非対称暗号化です。 公開鍵は、メッセージを暗号化したい人と自由に共有されます。 秘密鍵は常に秘密にされているので、あなただけがそれを使用してデータを復号化することができます。 公開鍵の発見を可能にするための一般的な技術は、デジタル証明書（単に証明書とも呼ばれる）を使用することです。 証明書には、名前、発行者、電子メールアドレス、国などのユーザーまたはサーバーに関する情報に加えて、公開鍵に関する情報が保持されます。

Windowsアプリ開発者は、以下を使用できます SymmetricKeyAlgorithmProvider と アシンメトリッキーアルゴリズムプロバイダ uwpアプリで対称暗号化と非対称暗号化を実装するクラス。 さらに、 CryptographicEngine クラスを使用して、データの暗号化と復号化、コンテンツの署名、デジタル署名の検証を行うことができます。 アプリはまた、使用することができます DataProtectionProvider のクラス Windows.Security.Cryptography.DataProtection 保存されたローカルデータを暗号化および復号化する名前空間。

4.3.2メッセージ改ざんの検出(Mac、ハッシュ、および署名)

MACは、mac暗号化アルゴリズムへの入力として対称キー（秘密キーと呼ばれる）またはメッセージを使用した結果のコード（またはタグ）です。 秘密鍵とアルゴリズムは、メッセージ転送の前に送信者と受信者によって合意されます。

Macはこのようなメッセージを確認します。

• 送信者は、MACアルゴリズムへの入力として秘密鍵を使用してMACタグを導出します。
• 送信側は、MACタグとメッセージを受信側に送信します。
• 受信機は、秘密鍵とメッセージをMACアルゴリズムへの入力として使用することによってMACタグを導出する。
• 受信側は、MACタグと送信側のMACタグを比較します。 それらが同じであれば、メッセージが改ざんされていないことがわかります。

Windowsアプリは、MACメッセージの検証を実装することができます。 MacAlgorithmProvider キーを生成するクラスと CryptographicEngine MAC暗号化アルゴリズムを実行するクラス。

4.3.3ハッシュの使用

ハッシュ関数は、任意の長さのデータブロックを取り、ハッシュ値と呼ばれる固定サイズのビット列を返す暗号アルゴリズムです。 これを行うことができるハッシュ関数のファミリー全体があります。

上記のメッセージ転送シナリオでは、MACの代わりにハッシュ値を使用できます。 送信者はハッシュ値とメッセージを送信し、受信者は送信者のハッシュ値とメッセージから独自のハッシュ値を導出し、2つのハッシュ値を比較します。 Windows で実行されているアプリは、 HashAlgorithmProvider クラスを呼び出して、使用可能なハッシュ アルゴリズムを列挙し、そのうちの 1 つを実行できます。 ザ- CryptographicHash クラスはハッシュ値を表します。 ザ- CryptographicHash.GetValueAndReset このメソッドは、使用ごとにオブジェクトを再作成することなく、異なるデータを繰り返しハッシュするために使用できます。 のAppendメソッド CryptographicHash クラスは、ハッシュされるバッファに新しいデータを追加します。 このプロセス全体を次のC#コード例に示します。

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デジタル署名

デジタル署名された保存されたメッセージのデータ整合性は、MAC認証と同様の方法で検証されます。 ここでは、デジタル署名のワークフローが動作する方法です。

• 送信者は、メッセージをハッシュアルゴリズムへの入力として使用することにより、ハッシュ値（ダイジェストとも呼ばれます）を導出します。
• 送信者は秘密鍵を使ってダイジェストを暗号化します。
• 送信者は、メッセージ、暗号化されたダイジェスト、および使用されたハッシュアルゴリズムの名前を送信します。
• 受信者は公開鍵を使用して、受信した暗号化されたダイジェストを復号化します。 次に、ハッシュアルゴリズムを使用してメッセージをハッシュし、独自のダイジェストを作成します。 そして最後に、受信者は二つのダイジェスト(受信して復号化したものと作成したもの)を比較します。 2つが一致した場合にのみ、受信者はメッセージが秘密鍵の所有者によって送信されたこと、したがって彼らが自分であると言う人であり、メッセージが転送中に変更されていないことを確認できます。

ハッシュアルゴリズムは非常に高速であるため、大きなメッセージからもハッシュ値をすばやく導き出すことができます。 結果のハッシュ値は任意の長さであり、メッセージ全体よりも短くすることができるため、公開鍵と秘密鍵を使用してメッセージ全体ではなくダイジェストのみを暗号化および復号化することが最適化されます。

詳細については、上の記事を見てみましょう デジタル署名, Mac、ハッシュ、および署名、および 暗号。

5 まとめ

Windows のユニバーサル Windows プラットフォームには、オペレーティング システムの機能を利用して、より安全なアプリを作成するためのさまざまな方法が用意されています。 OAuth ID プロバイダーを使用した単一要素認証、多要素認証、仲介認証など、さまざまな認証シナリオでは、認証に関する最も一般的な課題を軽減するための API が存在します。 Windowsこんにちは新たな生体認証ログイン認識システムのユーザーの積極的な取組みに反を回避するに正します。 また、trusted platformモジュールの外部で公開または使用することのできない複数のキーと証明書を提供します。 さらに、証明書idキーと証明書をオプションで使用することで、さらなるセキュリティ層を利用できます。

飛行中のデータを保護するために、SSL を介してリモートシステムと安全に通信する API が存在し、SSL ピン留めでサーバーの信頼性を検証する可能性を提供します。 API を安全かつ制御された方法で公開することは、API エンドポイントの追加の難読化を提供するプロキシを使用して、Web 全体で API を公開するための強力な構成オプションを提供することによって、Azure API Management が支援するものです。 これらの API へのアクセスは、API キーを使用して保護され、API 呼び出しを調整してパフォーマンスを制御できます。

データがデバイスに到着すると、Windowsアプリモデルは、アプリのインストール、更新、データへのアクセス方法をより詳細に制御しながら、他のアプリのデータに無許可の方法でアクセスしないようにします。 Credential lockerは、オペレーティングシステムによって管理されるユーザー資格情報の安全なストレージを提供し、ユニバーサルWindowsプラットフォームによって提供される暗号化

6 リソース

6.1ハウツー記事

• 認証とユーザー ID
• Windows Hello
• 資格情報保管ボックス
• Web 認証ブローカー
• 指紋生体認証
• スマート カード
• 共有証明書
• 暗号
• 証明書
• 暗号化キー
• データ保護
• MAC、ハッシュ、および署名
• 暗号化に関する輸出制限の順守
• 一般的な暗号化タスク

6.2コードサンプル

• 資格情報保管ボックス
• 資格情報ピッカー
• Azureログインによるデバイスのロックダウン
• エンタープライズ データ保護
• KeyCredentialManager
• スマート カード
• Webアカウント管理
• WebAuthenticationBroker

6.3APIリファレンス

• Windows.Security.Authentication.OnlineId
• Windows.Security.Authentication.Web
• Windows.Security.Authentication.Web.Core
• Windows.Security.Authentication.Web.Provider
• Windows.Security.Credentials
• Windows.Security.Credentials
• Windows.Security.Credentials.UI
• Windows.Security.Cryptography
• Windows.Security.Cryptography.Certificates
• Windows.Security.Cryptography.Core
• Windows.Security.Cryptography.DataProtection
• Windows.Security.ExchangeActiveSyncProvisioning
• Windows.Security.EnterpriseData