共用方式為


安全性框架:通訊安全性 |風險降低

產品/服務 文章
Azure 事件中樞
Dynamics CRM
Azure Data Factory
身分識別伺服器
Web 應用程式
資料庫
Azure 儲存體
行動用戶端
WCF
Web API
Azure Cache for Redis
IoT 現場閘道
IoT 雲端閘道

使用 SSL/TLS 保護事件集線器的安全通訊

標題 詳細資訊
元件 Azure 事件中樞
SDL 階段 建造
適用的技術 一般的
屬性 N/A
引用 事件中樞驗證和安全性模型概觀
步驟 使用 SSL/TLS 保護事件中樞的 AMQP 或 HTTP 連線

檢查服務帳戶許可權,並檢查自定義服務或 ASP.NET 頁面是否遵守CRM的安全性

標題 詳細資訊
元件 Dynamics CRM
SDL 階段 建造
適用的技術 一般的
屬性 N/A
引用 N/A
步驟 檢查服務帳戶許可權,並檢查自定義服務或 ASP.NET 頁面是否遵守CRM的安全性

在將內部部署 SQL Server 連線到 Azure Data Factory 時,使用數據管理閘道

標題 詳細資訊
元件 Azure Data Factory
SDL 階段 部署
適用的技術 一般的
屬性 鏈接服務類型 - Azure 和內部部署
引用 在內部部署環境和 Azure Data Factory 之間移動數據
步驟

需要數據管理網關 (DMG) 工具,才能連線到在公司網路或防火牆後方保護的數據源。

  1. 鎖定機器可以隔離 DMG 工具,並防止故障程式對資料源機器造成損害或竊取資料。 (例如必須安裝最新的更新、啟用最低必要埠、受控帳戶布建、啟用稽核、啟用磁碟加密等)
  2. 數據閘道金鑰必須定期輪替,或每當 DMG 服務帳戶密碼更新時
  3. 必須加密透過連結服務傳輸的數據

確定所有對 Identity Server 的流量都是透過 HTTPS 連線

標題 詳細資訊
元件 身分識別伺服器
SDL 階段 部署
適用的技術 一般的
屬性 N/A
引用 N/A
步驟 根據預設,IdentityServer 會要求所有連入連線都透過 HTTPS 進行。 只有安全傳輸才能與 IdentityServer 進行通訊,這絕對是強制性的。 某些部署場景,例如 TLS 卸載,此需求可能會放寬。 如需詳細資訊,請參閱參考中的 Identity Server 部署頁面。

驗證用來驗證 SSL、TLS 和 DTLS 連線的 X.509 憑證

標題 詳細資訊
元件 Web 應用程式
SDL 階段 建造
適用的技術 一般的
屬性 N/A
引用 N/A
步驟

使用 SSL、TLS 或 DTLS 的應用程式必須完整驗證其所連線實體的 X.509 憑證。 這包括下列憑證的驗證:

  • 網域名稱
  • 有效日期(開始日期與到期日)
  • 撤銷狀態
  • 使用方式(例如伺服器驗證、用戶端驗證)
  • 信任鏈結。 憑證必須連結至平台信任的根憑證授權中心(CA),或由系統管理員明確配置。
  • 憑證公鑰的金鑰長度必須是 >2048 位
  • 哈希演算法必須是SHA256及以上版本

在 Azure App Service 中設定自訂網域的 TLS/SSL 憑證

標題 詳細資訊
元件 Web 應用程式
SDL 階段 建造
適用的技術 一般的
屬性 環境類型 - Azure
引用 在 Azure App Service 中為應用程式啟用 HTTPS
步驟 根據預設,Azure 已針對每個具有 *.azurewebsites.net 網域通配符憑證的應用程式啟用 HTTPS。 不過,就像所有通配符網域一樣,它不像使用具有自己的憑證的自定義網域一樣安全Refer。 建議為部署的應用程式存取的自定義網域啟用 TLS

透過 HTTPS 連線強制所有流量至 Azure App Service

標題 詳細資訊
元件 Web 應用程式
SDL 階段 建造
適用的技術 一般的
屬性 環境類型 - Azure
引用 在 Azure App Service 上強制執行 HTTPS
步驟

雖然 Azure 已針對網域 *.azurewebsites.net 啟用具有通配符憑證的 Azure 應用程式服務的 HTTPS,但不會強制執行 HTTPS。 訪客仍然可以使用 HTTP 存取應用程式,這可能會危害應用程式的安全性,因此必須明確強制執行 HTTPS。 ASP.NET MVC 應用程式應該使用 RequireHttps 篩選條件 ,強制透過 HTTPS 重新傳送不安全的 HTTP 要求。

或者,Azure App Service 隨附的 URL Rewrite 模組可用來強制執行 HTTPS。 URL Rewrite 模組可讓開發人員定義規則,這些規則會先套用至傳入要求,再將要求交給您的應用程式。 URL 重寫規則定義於儲存在應用程式根目錄中的 web.config 檔案中

範例

下列範例包含基本 URL 重寫規則,強制所有連入流量使用 HTTPS

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Force HTTPS" enabled="true">
          <match url="(.*)" ignoreCase="false" />
          <conditions>
            <add input="{HTTPS}" pattern="off" />
          </conditions>
          <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" appendQueryString="true" redirectType="Permanent" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

當使用者使用 HTTP 要求頁面時,此規則的運作方式是傳回 HTTP 狀態代碼 301 (永久重新導向)。 301 會將要求重新導向至訪客所要求的相同 URL,但會將其中的 HTTP 部分替換為 HTTPS。 例如, HTTP://contoso.com 會重新導向至 HTTPS://contoso.com

開啟 HTTP 嚴格傳輸安全性 (HSTS)

標題 詳細資訊
元件 Web 應用程式
SDL 階段 建造
適用的技術 一般的
屬性 N/A
引用 OWASP HTTP Strict Transport Security 速查表
步驟

HTTP Strict Transport Security (HSTS) 是一種選擇加入安全性增強功能,透過使用特殊回應標頭,由 Web 應用程式指定。 一旦支援的瀏覽器收到此標頭,瀏覽器就會防止任何透過 HTTP 傳送至指定網域的通訊,並改為透過 HTTPS 傳送所有通訊。 它還會阻止瀏覽器中的 HTTPS 點擊跳過提示。

若要實作 HSTS,必須在程式碼或 config 中針對全域網站設定下列回應標頭。Strict-Transport-Security:max-age=300;includeSubDomains HSTS 可解決下列威脅:

  • 使用者可能透過書籤保存或手動輸入 https://example.com ,因此遭受中間人攻擊者的攻擊:HSTS會自動將HTTP請求重新導向至目標網域的HTTPS。
  • 原本純粹為 HTTPS 的 Web 應用程式不小心包含 HTTP 連結,或透過 HTTP 提供內容:HSTS 會自動將 HTTP 要求重新導向至目標網域的 HTTPS
  • 中間人攻擊者嘗試使用無效憑證攔截來自受害者使用者的流量,並希望使用者接受不正確的憑證:HSTS 不允許使用者覆寫無效的憑證訊息

確定 SQL Server 連線加密和憑證驗證

標題 詳細資訊
元件 資料庫
SDL 階段 建造
適用的技術 SQL Azure
屬性 SQL 版本 - V12
引用 撰寫 SQL Database 安全連接字串的最佳做法
步驟

SQL Database 與用戶端應用程式之間的所有通訊在任何時候都使用傳輸層安全性(TLS)進行加密,此技術以往稱為安全套接字層(SSL)。 SQL Database 不支援未加密的連線。 若要使用應用程式程式代碼或工具驗證憑證,請明確要求加密的連線,且不信任伺服器憑證。 如果您的應用程式程式代碼或工具未要求加密的連線,它們仍然會收到加密的連線

不過,它們可能不會驗證伺服器證書,因此容易受到「中間人」攻擊。 若要使用 ADO.NET 應用程式程式代碼來驗證憑證,請在資料庫連接字串中設定 Encrypt=TrueTrustServerCertificate=False 。 若要透過 SQL Server Management Studio 驗證憑證,請開啟 [連接到伺服器] 對話方塊。 點選 「連線內容」 索引標籤上的 [加密連線]

強制加密與 SQL Server 的通訊

標題 詳細資訊
元件 資料庫
SDL 階段 建造
適用的技術 OnPrem
屬性 SQL 版本 - MsSQL2016、SQL 版本 - MsSQL2012、SQL 版本 - MsSQL2014
引用 啟用 Database Engine 的加密連線
步驟 啟用 TLS 加密,可提高 SQL Server 執行個體和應用程式之間跨網路傳輸資料的安全性。

確定與 Azure 記憶體的通訊是透過 HTTPS

標題 詳細資訊
元件 Azure 儲存服務
SDL 階段 部署
適用的技術 一般的
屬性 N/A
引用 Azure 儲存體 Transport-Level 加密-使用 HTTPS
步驟 若要確保 Azure 記憶體資料傳輸中的安全性,請在呼叫 REST API 或存取記憶體中的物件時,一律使用 HTTPS 通訊協定。 此外,可用來委派對 Azure 記憶體物件的存取權的共用存取簽章,包括一個選項,指定在使用共用存取簽章時,只能使用 HTTPS 通訊協定,確保傳送具有 SAS 令牌連結的任何人員都會使用適當的通訊協定。

如果無法啟用 HTTPS,請在下載 Blob 之後驗證 MD5 哈希

標題 詳細資訊
元件 Azure 儲存服務
SDL 階段 建造
適用的技術 一般的
屬性 儲存類型 - Blob
引用 Windows Azure Blob MD5 概觀
步驟

Windows Azure Blob 服務提供機制,以確保應用程式和傳輸層的數據完整性。 如果因任何原因需要使用 HTTP 而不是 HTTPS 協定,且您正在處理區塊 Blob,可以使用 MD5 檢查來協助驗證正被傳輸的 Blob 的完整性。

這有助於防止網路/傳輸層錯誤,但不一定能防止中間人攻擊。 如果您可以使用 HTTPS 來提供傳輸層級安全性,則使用 MD5 檢查是多餘的,而且不必要。

使用SMB 3.x 相容客戶端來確保將數據加密傳輸至 Azure 檔案共用

標題 詳細資訊
元件 行動用戶端
SDL 階段 建造
適用的技術 一般的
屬性 StorageType - 檔案
引用 Azure 文件, Azure 文件的 SMB 支援適用於 Windows 用戶端
步驟 Azure 檔案服務在使用 REST API 時支援 HTTPS,但更常用做為連結至 VM 的 SMB 檔案共用。 SMB 2.1 不支援加密,因此只有在 Azure 中的相同區域內才允許連線。 不過,SMB 3.x 支援加密,並可搭配 Windows Server 2012 R2、Windows 8、Windows 8.1 和 Windows 10 使用,允許跨區域存取,甚至是桌面上的存取。

實施憑證固定

標題 詳細資訊
元件 Azure 儲存服務
SDL 階段 建造
適用的技術 通用、Windows Phone
屬性 N/A
引用 憑證和公鑰固定
步驟

憑證釘選可防禦The-Middle(MITM)攻擊。 綁定是將主機與其預期的 X509 憑證或公鑰產生關聯的過程。 當取得或識別到主機的憑證或公鑰時,該憑證或公鑰就會與主機關聯,或「釘選」至主機。

因此,當攻擊者嘗試進行 TLS 中間人(MITM)攻擊時,在 TLS 握手過程中,攻擊者伺服器的密鑰會與釘選憑證的密鑰不同,這將導致該請求被丟棄,從而防止 MITM 攻擊。可以透過實作 ServicePointManager 的 ServerCertificateValidationCallback 委派來達成憑證釘選。

範例

using System;
using System.Net;
using System.Net.Security;
using System.Security.Cryptography;

namespace CertificatePinningExample
{
    class CertificatePinningExample
    {
        /* Note: In this example, we're hardcoding the certificate's public key and algorithm for 
           demonstration purposes. In a real-world application, this should be stored in a secure
           configuration area that can be updated as needed. */

        private static readonly string PINNED_ALGORITHM = "RSA";

        private static readonly string PINNED_PUBLIC_KEY = "3082010A0282010100B0E75B7CBE56D31658EF79B3A1" +
            "294D506A88DFCDD603F6EF15E7F5BCBDF32291EC50B2B82BA158E905FE6A83EE044A48258B07FAC3D6356AF09B2" +
            "3EDAB15D00507B70DB08DB9A20C7D1201417B3071A346D663A241061C151B6EC5B5B4ECCCDCDBEA24F051962809" +
            "FEC499BF2D093C06E3BDA7D0BB83CDC1C2C6660B8ECB2EA30A685ADE2DC83C88314010FFC7F4F0F895EDDBE5C02" +
            "ABF78E50B708E0A0EB984A9AA536BCE61A0C31DB95425C6FEE5A564B158EE7C4F0693C439AE010EF83CA8155750" +
            "09B17537C29F86071E5DD8CA50EBD8A409494F479B07574D83EDCE6F68A8F7D40447471D05BC3F5EAD7862FA748" +
            "EA3C92A60A128344B1CEF7A0B0D94E50203010001";


        public static void Main(string[] args)
        {
            HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://azure.microsoft.com");
            request.ServerCertificateValidationCallback = (sender, certificate, chain, sslPolicyErrors) =>
            {
                if (certificate == null || sslPolicyErrors != SslPolicyErrors.None)
                {
                    // Error getting certificate or the certificate failed basic validation
                    return false;
                }

                var targetKeyAlgorithm = new Oid(certificate.GetKeyAlgorithm()).FriendlyName;
                var targetPublicKey = certificate.GetPublicKeyString();
                
                if (targetKeyAlgorithm == PINNED_ALGORITHM &&
                    targetPublicKey == PINNED_PUBLIC_KEY)
                {
                    // Success, the certificate matches the pinned value.
                    return true;
                }
                // Reject, either the key or the algorithm does not match the expected value.
                return false;
            };

            try
            {
                var response = (HttpWebResponse)request.GetResponse();
                Console.WriteLine($"Success, HTTP status code: {response.StatusCode}");
            }
            catch(Exception ex)
            {
                Console.WriteLine($"Failure, {ex.Message}");
            }
            Console.WriteLine("Press any key to end.");
            Console.ReadKey();
        }
    }
}

啟用 HTTPS - 安全傳輸通道

標題 詳細資訊
元件 WCF(Windows Communication Foundation)
SDL 階段 建造
適用的技術 NET Framework 3
屬性 N/A
引用 MSDNFortify Kingdom
步驟 應用程式組態應確保 HTTPS 用於所有敏感性資訊的存取。
  • 解釋: 如果應用程式處理敏感性資訊,且未使用訊息層級加密,則應該只允許透過加密傳輸通道進行通訊。
  • 建議: 請確定 HTTP 傳輸已停用,並改為啟用 HTTPS 傳輸。 例如,將<httpTransport/>標記取代為<httpsTransport/>標記。 請勿依賴網路組態(防火牆)來保證應用程式只能透過安全通道存取。 從哲學的觀點來看,應用程式不應依賴網路的安全性。

從實際的觀點來看,負責保護網路的人員不一定會在應用程式發展時追蹤應用程式的安全性需求。

WCF:將訊息安全性保護層級設定為 EncryptAndSign

標題 詳細資訊
元件 WCF(Windows Communication Foundation)
SDL 階段 建造
適用的技術 .NET Framework 3
屬性 N/A
引用 MSDN
步驟
  • 解釋: 當 [保護層級] 設定為 [無] 時,將會停用訊息保護。 機密性和完整性是透過適當的設定層級來達成。
  • 建議:
    • when Mode=None - 停用訊息保護
    • when Mode=Sign - 簽署但不加密訊息;當數據完整性很重要時,應該使用
    • when Mode=EncryptAndSign - 簽署並加密訊息

當您只需要驗證資訊的完整性而不需要擔心機密性時,請考慮關閉加密,並只簽署您的訊息。 這對於您需要驗證原始發件者但不會傳輸敏感數據的作業或服務合約很有用。 減少保護層級時,請小心訊息不包含任何個人資料。

範例

設定服務及操作,以僅簽署訊息,如以下範例所示。 服務合約範例 ProtectionLevel.Sign:以下是在服務合約層級使用 ProtectionLevel.Sign 的範例:

[ServiceContract(Protection Level=ProtectionLevel.Sign] 
public interface IService 
  { 
  string GetData(int value); 
  } 

範例

作業合約範例 ProtectionLevel.Sign (適用於細微控制):以下是在 OperationContract 層級使用 ProtectionLevel.Sign 的範例:

[OperationContract(ProtectionLevel=ProtectionLevel.Sign] 
string GetData(int value);

WCF:使用最低許可權的帳戶來執行 WCF 服務

標題 詳細資訊
元件 WCF(Windows Communication Foundation)
SDL 階段 建造
適用的技術 .NET Framework 3
屬性 N/A
引用 MSDN
步驟
  • 解釋: 請勿在系統管理員或高許可權帳戶下執行 WCF 服務。 如果服務遭到入侵,將會造成高影響。
  • 建議: 使用最低許可權的帳戶來裝載 WCF 服務,因為它會減少應用程式的受攻擊面,並降低遭受攻擊的潛在損害。 如果服務帳戶需要 MSMQ、事件記錄檔、性能計數器和文件系統等基礎結構資源的額外訪問許可權,則應將這些資源授與適當的許可權,讓 WCF 服務能夠順利執行。

如果您的服務需要代表原始呼叫者來存取特定資源,請使用模擬和委派來傳遞呼叫者的身分以進行下游授權檢查。 在開發場景中,使用本地網路服務帳號,這是一個具有降低權限的特殊內建帳戶。 在生產案例中,建立最低許可權的自定義網域服務帳戶。

將所有流量強制透過 HTTPS 連線至 Web API

標題 詳細資訊
元件 網路應用程式介面
SDL 階段 建造
適用的技術 MVC5、MVC6
屬性 N/A
引用 在 Web API 控制器中強制執行 SSL
步驟 如果應用程式同時具有 HTTPS 和 HTTP 系結,用戶端仍然可以使用 HTTP 來存取網站。 若要避免這種情況,請使用動作篩選器來確保受保護 API 的要求一律是透過 HTTPS。

範例

下列程式代碼顯示檢查 TLS 的 Web API 驗證篩選器:

public class RequireHttpsAttribute : AuthorizationFilterAttribute
{
    public override void OnAuthorization(HttpActionContext actionContext)
    {
        if (actionContext.Request.RequestUri.Scheme != Uri.UriSchemeHttps)
        {
            actionContext.Response = new HttpResponseMessage(System.Net.HttpStatusCode.Forbidden)
            {
                ReasonPhrase = "HTTPS Required"
            };
        }
        else
        {
            base.OnAuthorization(actionContext);
        }
    }
}

將此篩選新增至任何需要 TLS 的 Web API 動作:

public class ValuesController : ApiController
{
    [RequireHttps]
    public HttpResponseMessage Get() { ... }
}

確定與 Azure Cache for Redis 的通訊是透過 TLS

標題 詳細資訊
元件 Azure Cache for Redis(Azure Redis 緩存)
SDL 階段 建造
適用的技術 一般的
屬性 N/A
引用 Azure Redis TLS 支援
步驟 Redis 伺服器不支援現用的 TLS,但 Azure Cache for Redis 則支援。 如果您要連線到 Azure Cache for Redis,且客戶端支援 TLS,例如 StackExchange.Redis,則您應該使用 TLS。 根據預設,新的 Azure Cache for Redis 實例會停用非 TLS 埠。 請確保安全預設值不會更改,除非 Redis 用戶端需要依賴 TLS 支援。

請注意,Redis 的設計目的是要由受信任環境中的受信任用戶端存取。 通常不建議將 Redis 執行個體直接公開至網際網路,或一般而言,公開至不受信任的用戶端可以直接存取 Redis TCP 連接埠或 UNIX 套接字的環境。

裝置到現場閘道的安全通訊

標題 詳細資訊
元件 IoT 現場閘道
SDL 階段 建造
適用的技術 一般的
屬性 N/A
引用 N/A
步驟 針對IP型裝置,通訊協定通常可以封裝在SSL/TLS通道中,以保護傳輸中的數據。 對於不支援 SSL/TLS 的其他通訊協定,調查是否有在傳輸或訊息層提供安全性的安全通訊協定版本。

使用 SSL/TLS 加密裝置到雲端網關的通訊

標題 詳細資訊
元件 IoT 雲端閘道
SDL 階段 建造
適用的技術 一般的
屬性 N/A
引用 選擇您的通訊協定
步驟 使用 SSL/TLS 保護 HTTP/AMQP 或 MQTT 通訊協定。