安全開發 Windows 應用程式的簡介

  • 發行項

本簡介文章可協助應用程式架構設計人員和開發人員進一步瞭解各種 Windows 10 平臺功能，以加速建立安全 通用 Windows 平台 （UWP） 應用程式。 它會詳細說明如何使用下列每個階段可用的 Windows 安全性功能：驗證、數據進行中，以及待用數據。 您可以檢閱每個章節中包含的其他資源，以找到每個主題的更深入資訊。

1 簡介

開發安全應用程式可能是一項挑戰。 在現今行動裝置、社交、雲端和複雜企業應用程式的快節奏世界中，客戶期望應用程式比以往更快可供使用和更新。 它們也會使用許多類型的裝置，進一步增加建立應用程式體驗的複雜性。 如果您針對 Windows 10 和 Windows 11 通用 Windows 平台 （UWP） 建置，可能包含傳統桌面電腦、膝上型電腦、平板電腦和行動裝置清單;除了越來越多的新裝置清單，涵蓋物聯網、Xbox One、Microsoft Surface Hub 和 HoloLens。 身為開發人員，您必須確保應用程式在涉及的所有平臺或裝置上安全地通訊及儲存數據。

以下是使用 Windows 10 和 Windows 11 安全性功能的一些優點。

  • 您將針對安全性元件和技術使用一致的 API，在所有支援 Windows 10 和 Windows 11 的裝置上標準化安全性。
  • 如果您實作自定義程式碼來涵蓋這些安全性案例，則撰寫、測試及維護的程式代碼比您少。
  • 您的應用程式變得更穩定且安全，因為您使用操作系統來控制應用程式存取其資源和本機或遠端系統資源的方式。

在驗證期間，會驗證要求存取特定服務的使用者身分識別。 Windows Hello 是 Windows 10 和 Windows 11 中的元件，可協助在 Windows 應用程式中建立更安全的驗證機制。 透過它，您可以使用個人標識號（PIN）或生物特徵辨識技術，例如使用者的指紋、臉部或虹膜，為您的應用程式實作多重要素驗證。

數據進行中是指連線及其傳輸的訊息。 其中一個範例是使用 Web 服務從遠端伺服器擷取數據。 使用安全套接字層 （SSL） 和安全超文字傳輸通訊協定 （HTTPS） 可確保連線的安全性。 防止中繼方存取這些訊息，或未經授權的應用程式無法與 Web 服務通訊，是保護正式發行前小眾測試版數據的關鍵。

最後，待用數據與位於記憶體或儲存媒體上的數據有關。 Windows 10 和 Windows 11 具有應用程式模型，可防止應用程式之間未經授權的數據存取，並提供加密 API 來進一步保護裝置上的數據。 稱為 Credential Locker 的功能可用來安全地將使用者認證儲存在裝置上，操作系統可防止其他應用程式存取認證。

2 驗證因素

若要保護數據，要求存取數據的人員必須識別並獲授權，才能存取他們要求的數據資源。 識別使用者的程式稱為驗證，而判斷資源的存取許可權稱為授權。 這些是密切相關的作業，而且與使用者可能難以區分。 視許多因素而定，這些作業可能比較簡單或複雜：例如，數據位於一部伺服器上，或分散於許多系統。 提供驗證和授權服務的伺服器稱為識別提供者。

若要使用特定服務和/或應用程式來驗證自己，用戶會採用由他們知道的內容、他們所擁有的認證，以及/或他們所擁有的認證。 這些都稱為驗證因素。

  • 使用者知道 的內容通常是密碼，但它也可以是個人標識號（PIN）或「秘密」問答組。
  • 用戶擁有 的專案通常是硬體記憶體裝置，例如包含使用者唯一驗證數據的USB遊戲桿。
  • 使用者 通常包含其指紋，但使用者語音、臉部、眼部（眼睛）特性或行為模式等越來越受歡迎的因素。 儲存為數據時，這些測量稱為生物特徵辨識。

使用者所建立的密碼本身是驗證要素，但通常不夠;任何知道密碼的人都可以模擬擁有密碼的使用者。 智慧卡可以提供較高層級的安全性，但可能會遭竊、遺失或錯位。 可以透過指紋或眼部掃描來驗證用戶的系統，可提供最高且最方便的安全性層級，但需要昂貴且特殊的硬體（例如，用於臉部辨識的 Intel RealSense 相機），而該硬體可能無法供所有使用者使用。

設計系統所使用的驗證方法，是數據安全性的複雜且重要層面。 一般而言，您在驗證中使用的因素越多，系統就越安全。 同時，驗證必須可供使用。 使用者通常會每天登入多次，因此程序必須快速。 您選擇的驗證類型是安全性與易於使用之間的取捨;單一要素驗證是最不安全且最容易使用，而且多重要素驗證會變得更安全，但隨著新增更多因素而更加複雜。

2.1 單一要素驗證

這種形式的驗證是以單一使用者認證為基礎。 這通常是密碼，但也可能是個人標識號（PIN）。

以下是單一要素驗證的程式。

  • 使用者會提供其使用者名稱和密碼給識別提供者。 識別提供者是驗證使用者身分識別的伺服器進程。
  • 識別提供者會檢查使用者名稱和密碼是否與儲存在系統中的使用者名稱和密碼相同。 在大部分情況下，密碼將會加密，以提供額外的安全性，讓其他人無法讀取密碼。
  • 識別提供者會傳回驗證狀態，指出驗證是否成功。
  • 如果成功，數據交換就會開始。 如果失敗，則必須重新驗證使用者。

single-factor authentication

目前，這個驗證方法是跨服務最常使用的一種方法。 當做唯一的驗證方法使用時，這也是最不安全的驗證形式。 密碼複雜度需求、「秘密問題」和一般密碼變更可能會使使用密碼更安全，但他們給用戶帶來更大的負擔，而且對駭客沒有有效的威懾力。

密碼的挑戰是，比具有多個因素的系統更容易成功猜測密碼。 如果他們從一個小網店竊取具有用戶帳戶的資料庫和哈希密碼，他們可以使用其他網站上所使用的密碼。 使用者通常會一直重複使用帳戶，因為複雜密碼很難記住。 對於 IT 部門，管理密碼也帶來了必須提供重設機制、需要經常更新密碼，以及以安全方式儲存密碼的複雜性。

針對其所有缺點，單一要素驗證可讓使用者控制認證。 他們會建立並加以修改，而且驗證程式只需要鍵盤。 這是區分單一因素與多重要素驗證的主要層面。

2.1.1 Web 驗證代理人

如先前所述，IT 部門密碼驗證的挑戰之一是管理用戶名稱/密碼、重設機制等基礎的額外負荷。越來越受歡迎的選項是依賴透過 OAuth 提供驗證的第三方識別提供者，這是公開的驗證標準。

使用 OAuth，IT 部門可以有效地「外包」使用使用者名稱和密碼維護資料庫的複雜度、重設密碼功能等，轉交給 Facebook、X 或 Microsoft 等第三方識別提供者。

使用者在這些平臺上完全控制其身分識別，但應用程式可以在使用者通過驗證和同意後向提供者要求令牌，這可用來授權已驗證的使用者。

Windows 10 和 Windows 11 中的 Web 驗證代理人提供一組 API 和基礎結構，讓應用程式使用 OAuth 和 OpenID 等驗證和授權通訊協定。 應用程式可以透過 WebAuthenticationBroker API 起始驗證作業，進而傳回 WebAuthenticationResult。 下圖說明通訊流程的概觀。

wab workflow

應用程式會作為訊息代理程式，透過 應用程式中的 WebView 向識別提供者起始驗證。 當識別提供者驗證使用者時，它會將令牌傳回給應用程式，以用來向識別提供者要求使用者的相關信息。 身為安全性措施，應用程式必須先向識別提供者註冊，才能向識別提供者代理驗證程式。 每個提供者的註冊步驟都不同。

以下是呼叫 WebAuthenticationBroker API 以與提供者通訊的一般工作流程。

  • 建構要傳送至識別提供者的要求字串。 每個 Web 服務的字串數目和每個字串中的資訊都不同，但通常會包含兩個 URI 字串，每個字串都包含一個 URL：一個是傳送驗證要求，另一個是在授權完成之後重新導向使用者。
  • 呼叫 WebAuthenticationBroker.AuthenticateAsync、傳入要求字串，並等候來自識別提供者的回應。
  • 呼叫 WebAuthenticationResult.ResponseStatus 以取得收到回應時的狀態。
  • 如果通訊成功，請處理識別提供者傳回的回應字串。 如果失敗，請處理錯誤。

如果通訊成功，請處理識別提供者傳回的回應字串。 如果失敗，請處理錯誤。

此程式的 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 多重要素驗證

多重要素驗證會使用一個以上的驗證要素。 通常，「您知道的東西」，例如密碼，會結合「您擁有的東西」，這可以是行動電話或智慧卡。 即使攻擊者發現使用者的密碼，帳戶仍無法存取，而不需要裝置或卡片。 而且，如果只有裝置或卡片遭到入侵，則沒有密碼的攻擊者不會有用。 因此，多重要素驗證比單一要素驗證更安全，但也更為複雜。

使用多重要素驗證的服務通常會讓用戶選擇接收第二個認證的方式。 這種類型的驗證範例是常用的程式，其中驗證碼會使用SMS傳送至用戶的行動電話。

  • 使用者會提供其使用者名稱和密碼給識別提供者。
  • 識別提供者會在單一要素授權中驗證使用者名稱和密碼，然後查閱儲存在系統中的用戶行動電話號碼。
  • 伺服器會將包含所產生驗證碼的SMS訊息傳送給用戶的行動電話。
  • 用戶會將驗證碼提供給識別提供者;透過向用戶呈現的表單。
  • 識別提供者會傳回驗證狀態，指出這兩個認證的驗證是否成功。
  • 如果成功，數據交換就會開始。 否則，用戶必須重新驗證。

two-factor authentication

如您所見，此程式也不同於單一要素驗證，因為第二個使用者認證會傳送給使用者，而不是由使用者建立或提供。 因此，用戶無法完全控制必要的認證。 這也適用於智慧卡作為第二個認證使用時：組織負責建立並提供給使用者。

2.2.1 Azure Active Directory

Azure Active Directory （Azure AD） 是雲端式身分識別和存取管理服務，可作為單一要素或多重要素驗證中的識別提供者。 Azure AD 驗證可以搭配或不使用驗證碼使用。

雖然 Azure AD 也可以實作單一要素驗證，但企業通常需要更高的多重要素驗證安全性。 在多重要素驗證組態中，使用 Azure AD 帳戶進行驗證的使用者可以選擇將驗證碼當做簡訊傳送至其行動電話或 Azure Authenticator 行動應用程式。

此外，Azure AD 可作為 OAuth 提供者，為標準使用者提供驗證和授權機制給跨各種平台的應用程式。 若要深入瞭解，請參閱 Azure 上的 Azure Active Directory 和 Multi-Factor Authentication。

2.4 Windows Hello

在 Windows 10 和 Windows 11 中，操作系統內建了方便的多重要素驗證機制。 Windows Hello 是 Windows 10 和 Windows 11 內建的新生物特徵辨識登入系統。 因為它直接內建於操作系統中，Windows Hello 允許臉部或指紋識別來解除鎖定用戶的裝置。 Windows 安全認證存放區會保護裝置上的生物特徵辨識數據。

Windows Hello 為裝置提供健全的方式來辨識個別使用者，該用戶可解決使用者與要求之服務或數據項之間路徑的第一個部分。 裝置辨識用戶之後，仍必須驗證使用者，才能判斷是否要授與所要求資源的存取權。 Windows Hello 也提供強式雙因素驗證 （2FA），完全整合到 Windows 中，並以特定裝置的組合取代可重複使用的密碼，以及生物特徵辨識手勢或 PIN。 PIN 是由使用者指定為其 Microsoft 帳戶註冊的一部分。

不過，Windows Hello 不只是傳統 2FA 系統的替代專案。 在概念上類似於智慧卡：驗證是使用密碼編譯基本類型而不是字串比較來執行，而使用者的密鑰內容在防竄改硬體內是安全的。 Microsoft Hello 不需要智慧卡部署所需的額外基礎結構元件。 特別是，如果您目前沒有憑證，則不需要公鑰基礎結構 （PKI） 來管理憑證。 Windows Hello 結合了智慧卡的主要優點—虛擬智慧卡的部署彈性，以及實體智慧卡的強固安全性—沒有任何缺點。

裝置必須先向 Windows Hello 註冊，使用者才能向 Windows Hello 進行驗證。 Windows Hello 會使用非對稱式（公開/私鑰）加密，其中一方使用公鑰來加密另一方可以使用私鑰解密的數據。 在 Windows Hello 案例中，它會建立一組公開/私鑰組，並將私鑰寫入裝置的信任平臺模組 （TPM） 晶片。 註冊裝置之後，UWP app 可以呼叫系統 API 來擷取使用者的公鑰，這可用來在伺服器上註冊使用者。

應用程式的註冊工作流程可能如下所示：

windows hello registration

您收集的註冊資訊可能包含比這個簡單案例中更多的識別資訊。 例如，如果您的應用程式存取安全的服務，例如銀行服務，您必須要求身分識別證明和其他事項，作為註冊程式的一部分。 一旦符合所有條件，此使用者的公鑰將會儲存在後端，並在下次使用者使用服務時用來驗證。

如需 Windows Hello 的詳細資訊，請參閱 Windows Hello 指南 和 Windows Hello 開發人員指南。

3 實時數據安全性方法

數據傳輸中安全性方法適用於連線到網路之裝置之間的傳輸數據。 數據可能會在私人公司內部網路的高安全性環境系統之間傳輸，或是在 Web 不安全的環境中的用戶端和 Web 服務之間傳輸。 Windows 10 和 Windows 11 應用程式可透過其網路 API 支援 SSL 等標準，並使用 Azure API 管理 等技術，讓開發人員能夠確保應用程式的適當安全性層級。

3.1 遠端系統驗證

有兩個與遠端電腦系統進行通訊的一般案例。

  • 本地伺服器會透過直接連線來驗證使用者。 例如，當伺服器和客戶端位於公司內部網路上時。
  • Web 服務會透過因特網與通訊。

Web 服務通訊的安全性需求高於直接連線案例的安全性需求，因為數據不再只是安全網路的一部分，而且想要攔截數據的惡意攻擊者的可能性也更高。 由於不同類型的裝置會存取服務，因此它們可能會建置為 RESTful 服務，例如 WCF，這表示服務的驗證和授權也帶來了新的挑戰。 我們將討論安全遠端系統通訊的兩個需求。

第一個需求是訊息機密性：用戶端與 Web 服務之間傳遞的資訊（例如，使用者身分識別和其他個人資訊）在傳輸中時，不得由第三方讀取。 這通常是透過加密傳送訊息的連線，以及加密訊息本身來完成。 在私人/公鑰加密中，公鑰可供任何人使用，並用來加密要傳送至特定接收者的訊息。 私鑰只由接收者持有，並用來解密訊息。

第二個需求是訊息完整性：用戶端和 Web 服務必須能夠驗證接收的訊息是否為對方所要傳送的訊息，而且訊息尚未在傳輸中變更。 這可藉由使用數位簽名和憑證驗證簽署訊息來完成。

3.2 SSL 連線

為了建立和維護用戶端的安全連線，Web 服務可以使用安全套接字層 （SSL），這是安全超文本傳輸通訊協定 （HTTPS） 所支援。 SSL 藉由支援公鑰加密和伺服器憑證，提供訊息機密性和完整性。 傳輸層安全性會取代 SSL，但 TLS 通常稱為 SSL。

當用戶端要求存取伺服器上的資源時，SSL 會啟動與伺服器的交涉程式。 這稱為 SSL 交握。 加密層級、一組公用和私鑰，以及客戶端和伺服器憑證中的身分識別資訊，會同意作為 SSL 連線期間所有通訊的基礎。 伺服器也可能要求客戶端此時進行驗證。 建立連線之後，所有訊息都會使用交涉的公鑰加密，直到連線關閉為止。

3.2.1 SSL 釘選

雖然 SSL 可以使用加密和憑證來提供訊息機密性，但不會驗證用戶端通訊的伺服器是正確的伺服器。 伺服器的行為可由未經授權的第三方模擬，並攔截用戶端傳輸的敏感數據。 為避免這種情況，會使用稱為 SSL 釘選的技術來確認伺服器上的憑證是客戶端預期和信任的憑證。

有幾種不同的方式可以在應用程式中實作 SSL 釘選，每個都有各自的優缺點。 最簡單的方法是透過應用程式套件指令清單中的憑證宣告。 此宣告可讓應用程式套件安裝數字證書，並在其中指定獨佔信任。 這會導致只有應用程式與其憑證鏈結中具有對應憑證的伺服器之間才允許 SSL 連線。 此機制也可安全地使用自我簽署憑證，因為信任的公用證書頒發機構單位不需要任何第三方相依性。

ssl manifest

若要進一步控制驗證邏輯，API 可用來驗證伺服器傳回的憑證，以回應 HTTPS 要求。 請注意，此方法需要傳送要求並檢查回應，因此請務必在要求中實際傳送敏感性資訊之前，先將此新增為驗證。

下列 C# 程式代碼說明這個 SSL 釘選方法。 ValidateSSLRoot 方法會使用 HttpClient 類別來執行 HTTP 要求。 用戶端傳送回應之後，它會使用 RequestMessage.TransportInformation.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 管理 是一項服務，可協助跨 Web 公開 API，同時提供三個層級的功能。

API 的 Publishers/管理員 istrators 可透過 Azure API 管理 的發行者入口網站輕鬆地設定 API。 您可以在這裡建立 API 集合，並管理其存取權，以控制可存取哪些 API 的人員。

想要存取這些 API 的開發人員 可以透過開發人員入口網站提出要求，它可以立即提供存取權，或要求發行者/系統管理員核准。 開發人員也可以在開發人員入口網站中檢視 API 檔和範例程式代碼，以快速採用 Web 服務所提供的 API。

這些開發人員建立的應用程式接著會透過 Azure API 管理 所提供的 Proxy 存取 API。 Proxy 兩者都提供一層模糊不清、隱藏發行者/系統管理員伺服器上 API 的實際端點，也可以包含其他邏輯，例如 API 轉譯，以確保對某個 API 的呼叫重新導向至另一個 API 時，公開的 API 會保持一致。 它也可以使用IP篩選來封鎖源自特定IP網域或一組網域的API呼叫。 Azure API 管理 也會使用一組稱為 API 金鑰的公鑰來保護其 Web 服務的安全，以驗證和授權每個 API 呼叫。 授權失敗時，會封鎖對 API 及其支援的功能存取。

Azure API 管理 也可以減少對服務的 API 呼叫數目（稱為節流的程式），以優化 Web 服務的效能。 若要深入瞭解，請參閱 AzureCon 2015 的 Azure API 管理 和 Azure API 管理。

4 待用數據安全性方法

當數據抵達裝置時，我們會將其稱為「待用數據」。此數據必須以安全的方式儲存在裝置上，以便未經授權的使用者或應用程式無法存取。 Windows 10 和 Windows 11 中的應用程式模型會執行許多動作，以確保任何應用程式所儲存的數據都只能供該應用程式存取，同時提供必要的 API 來共用數據。 其他 API 也可供使用，以確保數據可以加密，並安全地儲存認證。

4.1 Windows 應用程式模型

傳統上，Windows 從未定義過應用程式。 它最常稱為可執行檔（.exe），這絕不包含安裝、狀態儲存、執行長度、版本控制、OS 整合或應用程式對應用程式通訊。 通用 Windows 平台 模型會定義應用程式模型，涵蓋安裝、運行時間環境、資源管理、更新、數據模型和卸載。

Windows 10 應用程式在容器中執行，這表示他們預設具有有限的許可權（使用者可以要求並授與額外的許可權）。 例如，如果應用程式想要存取系統上的檔案，則為 Windows.儲存體 中的檔案選擇器。選擇器命名空間必須用來讓使用者挑選檔案（未啟用檔案的直接存取權）。 另一個範例是，如果應用程式想要存取使用者的位置數據，它需要宣告位置裝置功能，在下載時提示使用者，此應用程式將要求存取使用者的位置。 除此之外，應用程式第一次想要存取使用者的位置時，會向用戶顯示額外的同意提示，要求存取數據的許可權。

請注意，此應用程式模型可作為應用程式的「監獄」，這表示他們無法聯繫，但不是無法從外部觸達的「城堡」（當然具有系統管理員許可權的應用程式仍可觸達）。 Windows 10 和 Windows 11 中的 Device Guard 可讓組織/IT 指定允許執行哪些 （Win32） 應用程式，可進一步協助限制此存取。

應用程式模型也會管理應用程式生命週期。 預設會限制應用程式的背景執行，例如：一旦應用程式進入背景，程式就會暫停– 在為應用程式提供短暫的期間來處理程式碼中暫停的應用程式，而且其記憶體已凍結。 操作系統確實提供機制，讓應用程式要求特定背景工作執行（根據排程，由因特網/藍牙 連線能力、電源變更等各種事件觸發，以及在音樂播放或 GPS 追蹤等特定案例中觸發）。

當裝置上的記憶體資源執行不足時，Windows 會藉由終止應用程式釋放記憶體空間。 此生命週期模型會強制應用程式在暫停時保存數據，因為暫停和終止之間沒有額外的時間可用。

如需詳細資訊，請參閱 通用：瞭解 Windows 10/11 應用程式的生命週期。

4.2 預存認證保護

存取已驗證服務的 Windows 應用程式通常會為使用者提供將認證儲存在本機裝置上的選項。 這是使用者方便的;當他們提供其使用者名稱和密碼時，應用程式會在後續的應用程式啟動時自動使用它們。 因為如果攻擊者取得此預存數據的存取權，Windows 10 和 Windows 11 可能會造成安全性問題，因此 Windows 應用程式能夠將使用者認證儲存在安全認證保險箱中。 應用程式會呼叫認證保險箱 API 來儲存和擷取保險箱中的認證，而不是將它們儲存在應用程式的記憶體容器中。 認證保險箱是由作業系統所管理，但存取僅限於儲存它們的應用程式，為認證記憶體提供安全管理的解決方案。

當使用者提供要儲存的認證時，應用程式會使用 Windows.Security.Credentials 命名空間中的 PasswordVault 物件取得認證保險箱的參考。 然後， 它會建立PasswordCredential 物件，其中包含Windows應用程式的標識碼和使用者名稱和密碼。 這會傳遞至 PasswordVault.Add 方法，以將認證儲存在保險箱中。 下列 C# 程式代碼範例示範如何完成此作業。

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

在下列 C# 程式代碼範例中，應用程式會呼叫 PasswordVault 物件的 FindAllByResource 方法，要求與應用程式對應的所有認證。 如果傳回多個 ，它會提示使用者輸入其用戶名稱。 如果認證不在保險箱中，應用程式會提示使用者輸入認證。 然後，使用者會使用認證登入伺服器。

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 預存數據保護

當您處理儲存的數據時，通常稱為待用數據，加密可能會防止未經授權的使用者存取儲存的數據。 用來加密數據的兩種常見機制是使用對稱密鑰或使用非對稱密鑰。 不過，數據加密無法確保數據在傳送和儲存數據的時間之間未回應。 換句話說，無法確保數據完整性。 使用訊息驗證碼、哈希和數位簽名是解決此問題的常見技術。

4.3.1 數據加密

透過對稱式加密，發件人和收件者都有相同的密鑰，並用它來加密和解密數據。 這種方法的挑戰是安全地共用密鑰，讓雙方都意識到這一點。

其中一個答案是非對稱式加密，其中會使用公開/私鑰組。 公鑰會與任何想要加密訊息的人員自由共用。 私鑰一律會保留秘密，因此您只能用它來解密數據。 允許探索公鑰的常見技術是使用數字證書，也稱為憑證。 除了使用者或伺服器的相關信息，例如名稱、簽發者、電子郵件地址和國家/地區，憑證也會保存公鑰的相關信息。

Windows 應用程式開發人員可以使用 SymmetricKeyAlgorithmProvider 和 AsymmetricKeyAlgorithmProvider 類別，在其 UWP 應用程式中實作對稱和非對稱加密。 此外， CryptographicEngine 類別可用來加密和解密數據、簽署內容及驗證數字簽名。 應用程式也可以使用 Windows.Security.Cryptography.DataProtection 命名空間中的 DataProtectionProvider 類別來加密和解密儲存的本機數據。

4.3.2 偵測訊息竄改 （MAC、哈希和簽章）

MAC 是使用對稱金鑰（稱為秘密金鑰）或訊息作為 MAC 加密演演算法輸入所產生的程式代碼（或標記）。 在訊息傳輸之前，傳送者和接收者會同意秘密密鑰和演算法。

MAC 會驗證類似這樣的訊息。

  • 傳送者會使用秘密密鑰作為 MAC 演演算法的輸入來衍生 MAC 標記。
  • 傳送者會將 MAC 標籤和訊息傳送給接收者。
  • 接收者會使用秘密金鑰和訊息作為 MAC 演演算法的輸入來衍生 MAC 標記。
  • 接收者會比較其 MAC 標籤與傳送者的 MAC 標籤。 如果它們相同，則我們知道訊息尚未遭到竄改。

mac verification

Windows 應用程式可以藉由呼叫 MacAlgorithmProvider 類別來產生密鑰和 CryptographicEngine 類別來執行 MAC 加密演算法，以實作 MAC 訊息驗證。

4.3.3 使用哈希

哈希函式是一種密碼編譯演算法，採用任意長的數據區塊，並傳回稱為哈希值的固定大小位字串。 有一系列哈希函式可以執行這項操作。

哈希值可用來取代上述訊息傳輸案例中的 MAC。 傳送者會傳送哈希值和訊息，而接收者會從寄件人的哈希值和訊息衍生自己的哈希值，並比較這兩個哈希值。 在 Windows 10 和 Windows 11 上執行的應用程式可以呼叫 HashAlgorithmProvider 類別，以列舉可用的哈希演算法，並執行其中一個演算法。 CryptographicHash 類別代表哈希值。 CryptographicHash.GetValueAndReset 方法可用來重複哈希不同的數據，而不需要針對每個用途重新建立物件。 CryptographicHash 類別的 Append 方法會將新數據新增至要哈希的緩衝區。 此整個程式會顯示在下列 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 驗證類似的方式進行驗證。 以下是數字簽名工作流程的運作方式。

  • 傳送者會使用訊息做為哈希演算法的輸入，來衍生哈希值（也稱為摘要）。
  • 寄件者會使用其私鑰來加密摘要。
  • 傳送者會傳送訊息、加密摘要，以及所使用的哈希演算法名稱。
  • 接收者會使用公鑰來解密所收到的加密摘要。 然後，它會使用哈希演算法來哈希訊息，以建立自己的摘要。 最後，接收者會比較這兩個摘要（它接收和解密的摘要，以及它所做的摘要）。 只有兩個相符專案，接收者才能確定訊息是由私鑰擁有者傳送的，因此它們是他們所說的訊息，而且訊息不會在傳輸中改變。

digital signatures

哈希演算法非常快速，因此哈希值可以快速衍生自大型訊息。 產生的哈希值是任意長度，而且可能比完整訊息短，因此使用公用和私鑰來加密和解密摘要，而不是完整訊息是優化。

如需詳細資訊，請參閱數字簽名、MAC、哈希和簽章，以及密碼編譯的文章。

5 摘要

Windows 10 和 Windows 11 中的 通用 Windows 平台 提供數種方式來利用操作系統功能來建立更安全的應用程式。 在不同的驗證案例中，例如使用 OAuth 身分識別提供者的單一因素、多重要素或代理驗證，API 存在以減輕驗證最常見的挑戰。 Windows Hello 提供新的生物特徵辨識登入系統，可辨識使用者，並積極擊敗規避適當識別的努力。 它也會提供多層的密鑰和憑證，這些金鑰和憑證永遠不會在信任的平臺模組外部顯示或使用。 此外，透過選擇性地使用證明身分識別密鑰和憑證，即可進一步提供一層安全性。

為了保護正式發行前小眾測試版中的數據，API 可以透過 SSL 安全地與遠端系統通訊，同時提供使用 SSL 釘選來驗證伺服器的真實性的可能性。 以安全且受控制的方式發佈 API 是 Azure API 管理 透過提供強大的組態選項，透過提供提供 API 端點額外混淆的 Proxy，透過 Web 公開 API 的強大設定選項來協助。 使用 API 金鑰保護這些 API 的存取權，而且可以節流 API 呼叫來控制效能。

當數據抵達裝置時，Windows 應用程式模型可更充分地控制應用程式如何安裝、更新及存取數據，同時防止它以未經授權的方式存取其他應用程式的數據。 認證保險箱可以使用 通用 Windows 平台 所提供的加密和哈希 API，在裝置上保護由操作系統管理的用戶認證，以及其他數據的安全儲存。

6 資源

6.1 操作說明文章

6.2 程式代碼範例

6.3 API 參考