適用於雲端原生應用程式的 Azure 安全性

提示

此內容摘錄自《建構適用於 Azure 的雲端原生 .NET 應用程式》電子書，您可以在 .NET Docs 找到此電子書，或免費下載可離線閱讀的 PDF。

下載 PDF

雲端原生應用程式比傳統應用程式更容易保護也更難保護。 在缺點方面，您需要保護更多較小的應用程式，並投入更多精力建置安全性基礎結構。 大多數服務部署之程式設計語言和樣式的異質本質，也表示您必須更加注意自許多不同提供者的資訊安全佈告欄。

另一方面，較小的服務各有自己的資料存放區，限制了攻擊範圍。 當攻擊者入侵一個系統後，想要跳到另一個系統的困難度，會比在整合型應用程式中更高。 處理序界限是強大的界限。 此外，如果資料庫備份公開了，損毀也更有限，因為該資料庫只包含一部分的資料，而且不太可能包含個人資料。

威脅模型化

無論雲端原生應用程式的優點是否多過缺點，都必須遵循相同的整體安全性思維。 開發和營運案例的每個步驟中都必須包含安全性和安全思維。 規劃應用程式時要詢問的問題包括：

• 假如此資料遺失會有何影響？
• 此服務如插入不良資料，該如何限制損毀？
• 誰應該有權存取此資料？
• 開發和發行流程有稽核原則嗎？

所有這些問題都是威脅模型化流程的一部分。 此流程會嘗試回答系統會面臨哪些威脅、威脅的可能性有多大，以及其可能帶來的損害等問題。

威脅清單建立後，您必須決定緩和這些威脅是否值得。 有時候，某個威脅發生的可能性太低，而且規劃阻擋此威脅所費不貲，實在不值得您耗費精力。 例如，某些狀態層級的動作項目可能會在數百萬部裝置所用的處理序設計中插入變更。 現在，該特定程式碼片段會在通道 0 中執行，而不是在通道 3 中執行。 此程式允許略過 Hypervisor 並在裸機機器上執行攻擊碼的惡意探索，讓其對在該硬體上執行的所有虛擬機器發動攻擊。

對處理器晶片設計欠缺深入了解且不具備進階知識，很難偵測更改過的處理器。 此案例不太可能發生且降低威脅的成本高昂，所以可能沒有任何威脅模型會建議為此建置惡意探索防護。

為更多可能發生的威脅，例如允許 Id 遞增攻擊的存取控制失效 (將 URL 的 Id=2 更換成 Id=3)或 SQL 插入，建置威脅防護的吸引力更大。 建置並防止危害公司信譽的尷尬安全性漏洞，降低這些威脅的措施相當合理。

最低權限原則

電腦安全性的創立概念之一，是最低權限原則 (POLP)。 實際上，這也是幾乎所有安全性形式的基礎概念，無論數位或實體。 簡言之，此原則就是任何使用者或處理序都應該只擁有執行工作的最少權限。

以銀行的出納員為例：使用保險箱是不尋常的舉動。 因此，一般出納員不得自行開啟保險箱。 他們若要開啟保險箱，必須透過銀行經理呈報要求，由經理執行額外的安全性檢查。

電腦系統中的絕佳範例，是使用者連線到資料庫的權限。 在許多情況下，我們只使用一個使用者帳戶來建置資料庫結構並執行應用程式。 除了極端的情況外，執行應用程式的帳戶不需要有更新結構描述資訊的能力。 所以應該有數個帳戶提供不同的權限層級。 應用程式應該只使用授與資料表資料讀寫權的權限等級。 這種保護可消除以卸載資料庫資料表或引入惡意觸發程序為目標的攻擊。

牢記最低權限原則，對建置雲端原生應用程式的每個部分皆大有助益。 您會發現在設定防火牆、網路安全性群組、角色和角色型存取控制 (RBAC) 範圍時，此原則都會起作用。

滲透測試

隨著應用程式愈益複雜，攻擊媒介的數目也以驚人的速率增加。 威脅模型化的瑕疵在於，它通常是由建置系統的同一批人執行。 和許多開發人員無法想像使用者如何互動，以致建置無用的使用者介面一樣，大部分開發人員很難看到每種攻擊媒介。 此外，建置系統的開發人員可能還不熟悉攻擊方法，以致錯過了一些重要媒介。

滲透測試或 "pen testing" 涉及帶入外部動作項目嘗試攻擊系統。 這些攻擊者可能是外部的顧問公司，或公司其他部門中擁有高深安全性知識的其他開發人員。 他們獲得全權委託，嘗試破壞系統。 他們經常能找出需要修補的大量安全性漏洞。 有時候攻擊媒介是非常出人意表的，例如惡意探索對 CEO 的網路釣魚攻擊。

Azure 本身持續受到 Microsoft 內部駭客小組的攻擊。 多年來，這群人都是最早發現數十個潛在的重大攻擊媒介，在它們遭受外部入侵前先行予以關閉。 目標愈吸引人，永久動作項目嘗試入侵目標的可能性就愈高，而全球有幾個目標比 Azure 更吸引人。

監視

如果攻擊者嘗試滲透應用程式，一定會有一些先兆。 檢查服務記錄經常可以發現攻擊的痕跡。 攻擊成功之前會留下可被發現的痕跡。 例如，嘗試猜測密碼的攻擊者會向登入系統提出多次要求。 監視登入系統可偵測到與一般存取模式不一樣的奇怪模式。 此監視可轉換成警示，進而警示作業人員啟用一些因應措施。 高度成熟的監視系統甚至可以根據這些偏差採取行動，主動新增規則來封鎖要求或節流回應。

保護組建的安全

安全性經常被忽略的其中一個位置，是組建流程。 組建不僅要執行安全性檢查，例如掃描不安全的程式碼或簽入的認證，還要保護組建本身的安全。 如果組建伺服器遭到入侵，就會成為絕佳的媒介，將任意程式碼引入產品。

假設攻擊者想要竊取登入 Web 應用程式的人員密碼。 他們可以引入一個建置步驟，修改簽出的程式碼，將任何登入要求鏡像到其他伺服器。 下次程式碼通過組建時，就會以無訊息方式更新。 建置前執行的原始程式碼弱點掃描，不會追捕此弱點。 同樣地，沒有人會在程式碼檢閱中追捕此弱點，因為建置伺服器上的建置步驟是即時的。 惡意探索程式碼會移至實際執行環境，以便收集密碼。 建置流程變更可能沒有稽核記錄，或至少沒有人會監視稽核。

這個絕佳的案例，充分展示如何利用看似沒什麼價值的目標打入系統。 一旦攻擊者攻破系統外圍，他們就可以開始尋找提升權限的方法，直到他們能在任何想要的地方造成實質傷害。

建置安全的程式碼

.NET Framework 已是相當安全的架構。 其可避免非受控程式碼的一些陷阱，例如從陣列結尾離開。 工作會主動完成，在發現安全性漏洞時修正。 甚至還有錯誤懸賞計劃，為找出並回報架構問題，而不是利用它們的研究人員支付報酬。

有許多方法可讓 .NET 程式碼變得更安全。 遵循 .NET 安全程式碼撰寫指導方針等文章的指導，是確保程式碼從一開始就安全無虞的合理步驟。 OWASP 十大風險 (英文) 是建置安全程式碼的另一份寶貴指南。

建置處理序是放置掃描工具的絕佳位置，在實際執行環境發生問題前，先行在原始程式碼中偵測到問題。 幾乎每個專案都有某些其他套件的相依性。 可掃描過期套件的工具會在每晚的組建中追捕問題。 即使建置 Docker 映像，檢查並確定基底映像沒有已知的弱點也很有幫助。 另一件要檢查的事，是沒有人不小心簽入了認證。

內建安全性

Azure 旨在平衡大部分使用者的易使用程度和安全性。 不同的使用者有不同的安全性需求，因此他們需要微調自己的雲端安全性方法。 Microsoft 會在信任中心發佈大量的安全性資訊。 這項資源應該是有志了解內建攻擊風險降低技術運作方式之專業人員的第一站。

在Azure 入口網站中，Azure Advisor 是持續掃描環境並提出建議的系統。 有些建議旨在節省使用者成本，有些則是要識別可能不安全的組態，例如向全世界開放儲存體容器，而且不使用虛擬網路保護。

Azure 網路基礎結構

在內部部署環境中，大量精力投入在設定網路。 設定路由器、交換器等等，是很複雜的工作。 網路允許某些資源與其他資源交流，並防止某些情況下的存取。 常見的網路規則是限制從開發環境存取實際執行環境，讓半開發完成的程式碼沒有機會出錯，以及刪除資料群集。

開節即用，大部分的 PaaS Azure 資源只有最基本且寬鬆的網路設定。 例如，網際網路上的所有人都可以存取應用程式服務。 新的 SQL Server 執行個體通常會受到限制，所以外部對象無法存取它們，但 Azure 本身使用的 IP 位址範圍可以通過。 因此，雖然 SQL 伺服器受到保護免於外部威脅，但攻擊者只需要設定一個 Azure 攻擊據點，即可在此對 Azure 所有 SQL 執行個體發動攻擊。

幸運的是，大部分的 Azure 資源都可以放入允許更精細存取控制的 Azure 虛擬網路。 與內部部署網路建立不受外界干擾之私人網路的方式類似，虛擬網路是位在 Azure 網路內的私人 IP 位址小島。

圖 9-1. Azure 的虛擬網路。

與內部部署網路以防火牆控管網路存取權的方式相同，您可以在虛擬網路的邊界建立類似的防火牆。 虛擬網路上的所有資源預設仍可與網際網路交流。 它只是需要以某種形式明確防火牆例外狀況的連入連線。

建立網路之後，您就可以設定儲存體帳戶之類的內部資源，僅供也在虛擬網路中的資源存取。 此防火牆提供多一層的安全性，如果該儲存體帳戶的金鑰外洩，攻擊者也無法連線到該帳戶利用外洩的金鑰。 此案例也是最低權限原則的範例之一。

就和其他更近似 Azure 原生的資源一樣，Azure Kubernetes 叢集中的節點可以參與虛擬網路。 此功能稱之為 Azure 容器網路介面。 實際上，它會在虛擬機器和容器映像所在的虛擬網路內配置子網路。

繼續說明最低權限原則，不是虛擬網路內的每項資源都必須和所有其他資源交流。 例如，在透過儲存體帳戶和 SQL 資料庫提供 Web API 的應用程式中，資料庫和儲存體帳戶彼此不太可能交流。 它們之間共用任何資料都是通過 Web 應用程式。 因此，網路安全性群組 (NSG) 可用來拒絕兩項服務之間的流量。

拒絕資源間通訊的原則可能不利實作，特別是來自使用 Azure 的無流量限制背景的通訊。 在某些其他雲端上，網路安全性群組的概念更為普遍。 例如，AWS 上的預設原則是被 NSG 的規則啟用前，彼此間無法通訊的資源。 雖然開發速度較慢，但更嚴格的環境會提供更安全的預設值。 使用適當的 DevOps 做法，特別是使用 Azure Resource Manager 或 Terraform 管理權限，可讓控制規則變得更輕鬆。

設定內部部署與雲端資源之間的通訊時，虛擬網路也很有用。 您可以使用虛擬私人網路，順暢地將兩個網路連結在一起。 此方法允許當所有使用者都在現場時，不需要任何閘道即可執行虛擬網路。 有數種技術可用來建立此網路。 最簡單的方式是使用站對站 VPN，其可在許多路由器與 Azure 之間建立。 流量會透過網際網路加密和傳送，成本和所有其他流量一樣，按每位元組計費。 至於需要更多頻寬或更多安全性的案例，Azure 會提供稱為 Express Route 的服務，在內部部署網路與 Azure 之間使用私人線路。 成本更高且更難建立，但也更安全。

限制 Azure 資源存取權的角色型存取控制

RBAC 系統可為在 Azure 中執行的應用程式提供身分識別。 應用程式使用此身分識別即可存取資源，不需要/另行使用金鑰或密碼。

安全性主體

RBAC 中的第一個元件是安全性主體。 安全性主體可以是使用者、群組、服務主體或受控識別。

圖 9-2： 不同類型的安全性主體。

• 使用者 - 只要在 Azure Active Directory 中擁有帳戶的使用者都是使用者。
• 群組 - Azure Active Directory 中的使用者集合。 群組成員的使用者除了自己的角色外，還擔任群組的角色。
• 服務主體 - 執行服務或應用程式的安全性身分識別。
• 受控識別 - 由 Azure 管理的在 Azure Active Directory 身分識別。 開發管理 Azure 服務驗證所需認證的雲端應用程式時，會用到受控識別。

安全性主體可以套用至大部分的資源。 這表示您可以將安全性主體指派給在 Azure Kubernetes 內執行的容器，讓其存取儲存在 Key Vault 中的祕密。 Azure 函式可能會接受權限，允許其與 Active Directory 執行個體交流，以驗證呼叫使用者的 JWT。 使用服務主體啟用服務之後，您就可以使用角色和範圍，以細微的方式管理服務權限。

角色

安全性主體可以身兼數職，用裁縫術語類比，就是戴很多帽子。 每個角色都會定義一系列的權限，例如「讀取 Azure 服務匯流排端點的訊息」。 安全性主體的有效權限集合是指派給安全性主體擁有之所有角色的所有權限組合。 Azure 有大量的內建角色，且使用者可以定義自己的角色。

圖 9-3。 RBAC 角色定義。

Azure 也內建有許多高階角色，例如擁有者、參與者、讀者和使用者帳戶系統管理員。 有擁有者角色的安全性主體可以存取所有資源，並將權限指派給其他人。 參與者有同等級的存取權，其可存取所有資源，但無法指派權限。 讀者只能檢視現有的 Azure 資源，而使用者帳戶系統管理員則可以管理 Azure 資源的存取權。

更細微的內建角色，例如 DNS 區域參與者，其權限僅限於單一服務。 安全性主體可擔任任意數目的角色。

範圍

角色可以套用至 Azure 內的一組有限資源。 例如，將範圍套用至前例的讀取服務匯流排佇列，您可以將權限縮小至單一佇列：「讀取 Azure 服務匯流排端點 blah.servicebus.windows.net/queue1 的訊息」

範圍可以窄到單一資源，也可以套用至整個資源群組、訂閱，甚至是管理群組。

測試安全性主體是否有特定權限時，要將角色和範圍的組合納入考慮。 此組合提供強大的授權機制。

拒絕

過去，RBAC 只允許「允許」規則。 此行為讓某些範圍複雜到難以建置。 例如，允許安全性主體存取所有儲存體帳戶，但要求明確將權限授與可能有無限儲存體帳戶清單的帳戶除外。 每次建立新的儲存體帳戶時，都必須在此帳戶清單中新增帳戶。 這會增加絕對不受歡迎的管理額外負荷。

拒絕規則優先於允許規則。 現在，表示「全部允許，一個除外」的相同範圍，可以用兩個規則表示：「全部允許」以及「拒絕這一個特定規則」。 拒絕規則不僅可簡化管理，還允許因為拒絕每個人存取而更加安全的資源。

檢查存取

您可想見，大量的角色和範圍會讓找出服務主體有效權限變得相當困難。 將拒絕規則疊放在最上方，只會增加複雜度。 幸運的是，有一個權限計算機可以顯示所有服務主體的有效權限。 它通常位於入口網站的 [IAM] 索引標籤下，如圖 9-3 所示。

圖 9-4。 應用程式服務的權限計算機。

保護祕密

密碼和憑證是攻擊者常用的攻擊媒介。 密碼破解硬體可以發動暴力密碼破解攻擊，嘗試每秒猜測數十億個密碼。 因此，存取資源的密碼請務必使用具有各種不同字元的強式密碼。 這些密碼是那種幾乎完全不可能記住的密碼。 幸運的是，Azure 的密碼其實不需要被任何人知道。

許多安全性專家建議，使用密碼管理員保存您自己的密碼是最好的方法。 雖然它會將密碼集中在一個位置，但也允許使用高度複雜的密碼，並確保每個帳戶都有唯一的密碼。 Azure 有相同的系統：祕密的中央存放區。

Azure Key Vault

Azure Key Vault 提供集中式位置來儲存資料庫、API 金鑰和憑證等項目的密碼。 祕密一旦輸入保存庫，就永遠不會再顯示，而擷取及檢視祕密的命令會故意複雜化。 此保險箱中的資訊會使用軟體加密或 FIPS 140-2 層級 2 驗證的硬體安全性模組保護。

金鑰保存庫的存取權是透過 RBAC 提供，這表示不是任何使用者都可以存取保存庫中的資訊。 假設 Web 應用程式想要存取儲存在 Azure Key Vault 中的資料庫連接字串。 應用程式必須使用服務主體執行，才能取得存取權。 在此承擔的角色下，它們可以讀取保險箱中的祕密。 有很多不同的安全性設定可以進一步限制應用程式對保存庫的存取權，使其只能讀取但無法更新祕密。

您可以監視金鑰保存庫的存取權，確保只有預期的應用程式得以存取保存庫。 記錄可以整合回 Azure 監視器，在發生非預期狀況時，解除鎖定設定警示的能力。

Kubernetes

Kubernetes 中有類似的服務可維護小段的祕密資訊。 Kubernetes 祕密可透過一般的 kubectl 可執行檔設定。

建立祕密就像尋找要儲存的 base64 版本值一樣簡單：

echo -n 'admin' | base64
YWRtaW4=
echo -n '1f2d1e2e67df' | base64
MWYyZDFlMmU2N2Rm

然後將它新增至名為例如 secret.yml 的祕密檔案中，類似以下的範例：

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
  password: MWYyZDFlMmU2N2Rm

最後，執行下列命令，將此檔案載入 Kubernetes：

kubectl apply -f ./secret.yaml

這些祕密接著可以掛接到磁碟區，或透過環境變數公開至容器處理序。 建置應用程式的十二法則應用方法建議使用最低共同點將設定值傳輸至應用程式。 環境變數是最低的共同點，因為所有作業系統或應用程式都支援。

使用內建 Kubernetes 祕密的另一個方法，是從 Kubernetes 存取 Azure Key Vault 中的祕密。 執行這項作業的最簡單方式，是將 RBAC 角色指派給想要載入祕密的容器。 應用程式接著可以使用 Azure Key Vault API 來存取祕密。 不過，此方法需要修改程式碼，而且不遵循使用環境變數的模式。 但卻可以將值插入容器中。 此方法實際上比直接使用 Kubernetes 祕密更安全，因為叢集上的使用者可以存取 Kubernetes 祕密。

傳輸中加密和待用加密

無論資料在磁碟上或在各種不同服務間傳輸，保護資料安全都很重要。 防止資料外洩的最有效方式，就是使用他人無法輕易讀取的格式加密資料。 Azure 支援各種不同加密選項。

傳輸中

Azure 有數種方式可加密網路中的流量。 存取 Azure 服務一般都是透過使用傳輸層安全性 (TLS) 的連線。 例如，所有的 Azure API 連線都需要有 TLS 連線。 同樣地，您也可以限制 Azure 儲存體端點的連線只能透過 TLS 加密的連線運作。

TLS 是很複雜的通訊協定，只知道連線使用 TLS 並不足以確保安全性。 例如，TLS 1.0 長久以來並不安全，TLS 1.1 也好不到那裡去。 即使在 TLS 版本內，也有各種設定可讓連線更容易被解密。 最好的方法是檢查伺服器連線是否使用最新且設定良好的通訊協定。

此檢查可由外部服務完成，例如 SSL 實驗室的 SSL Server Test。 執行測試的一般 Azure 端點，在此案例中是服務匯流排端點，會產生近乎完美的分數 A。

即使是 Azure SQL 資料庫之類的服務，也會使用 TLS 加密來隱藏資料。 有關使用 TLS 加密傳輸中資料的有趣部分是，即使 Microsoft 也不可能接聽執行 TLS 之電腦間的連線。 這應該可讓擔心 Microsoft 本身或擁有更多資料的國家行為者對資料造成的風險比一般攻擊者更高的公司安心。

圖 9-5。 SSL 實驗室報告顯示服務匯流排端點的分數為 A。

雖然這個加密層級不足以應付所有狀況，但應該能激發對 Azure TLS 連線相當安全的信心。 Azure 的安全性標準會隨著加密改善而持續發展。 很高興知道有人注意著安全性標準，並會在此標準改善時更新 Azure。

待用

任何應用程式都有很多地方，其資料會佔據磁碟。 應用程式的程式碼本身是從某些儲存機制載入。 大部分的應用程式也會使用某種資料庫，例如 SQL Server、Cosmos DB，或甚至是性價比非常棒的表格儲存體。 這些資料庫全都使用高度加密的儲存體，以確保除了具有適當權限的應用程式以外，沒有人可以讀取您的資料。 即使是系統操作員也無法讀取已加密的資料。 因此，客戶可以確信其祕密資訊仍保持機密。

儲存體

Azure 大部分的基礎是 Azure 儲存體引擎。 虛擬機器磁碟會掛接在 Azure 儲存體最上層。 Azure Kubernetes Service 會在裝載於 Azure 儲存體上的虛擬機器上執行。 即使是無伺服器技術，例如 Azure Functions 應用程式和 Azure Container Instances，也會耗盡 Azure 儲存體的磁碟空間。

如果 Azure 儲存體已妥善加密，則可為其他大部分項目也提供加密的基礎。 Azure 儲存體使用符合 256 位元 AES 規範的 FIPS 140-2加密。 這是過去 20 餘年經過廣泛學術審查，廣獲好評的加密技術。 目前沒有已知的實際攻擊，可讓不知道金鑰的人員讀取經 AES 加密的資料。

加密 Azure 儲存體所用的金鑰預設由 Microsoft 管理。 已備妥廣泛的保護，確保防止惡意存取這些金鑰。 不過，有特定加密需求的使用者也可以提供自己 (使用 Azure Key Vault 管理) 的儲存體金鑰。 您可以隨時撤銷這些金鑰，以有效轉譯使用金鑰無法存取的儲存體帳戶內容。

虛擬機器使用加密的儲存體，但無法使用 Windows 的 BitLocker 或 Linux 的 DM-Crypt 等技術提供另一層加密。 這些技術表示，即使磁碟映像從儲存體外洩，仍幾乎無法讀取。

Azure SQL

裝載在 Azure SQL 上的資料庫使用稱為透明資料加密 (TDE) 的技術，以確保資料保持加密。 所有新建立的 SQL 資料庫都預設啟用此功能，但舊版資料庫必須手動啟用。 TDE 不僅即時加密與解密資料庫，也會即時加密與解密備份和交易記錄。

加密參數儲存在 master 資料庫中，並會在啟動時讀入記憶體供其餘作業使用。 這表示 master 資料庫必須保持未加密狀態。 實際的金鑰由 Microsoft 管理。 不過，具有確切安全性需求的使用者可以提供自己在 Key Vault 的金鑰，就像對 Azure 儲存體的方式差不多。 Key Vault 提供金鑰輪替和撤銷等服務。

TDS 之所以「透明」，是因為沒有用戶端變更需要使用加密資料庫。 雖然這種方法提供了良好的安全性，但洩漏資料庫密碼即足以讓使用者解密資料。 另有一種方法可以加密資料庫中的個別資料行或資料表。 Always Encrypted 可確保加密的資料永遠不會以純文字形態出現在資料庫內。

設定此加密層需要在 SQL Server Management Studio 中透過精靈執行，才能選取加密的排序，以及儲存相關聯金鑰的 Key Vault 位置。

圖 9-6。 選取要使用 Always Encrypted 加密的資料表資料行。

讀取這些加密資料行資訊的用戶端應用程式，需要有特別許可才能讀取加密的資料。 您必須使用 Column Encryption Setting=Enabled 更新連接字串，而且必須從 Key Vault 擷取用戶端認證。 然後，SQL Server 用戶端必須備有資料行加密金鑰。 完成後，其餘動作會使用 SQL 用戶端的標準介面。 也就是說，建置在 SQL Client 上的 Dapper 和 Entity Framework 等工具將會繼續運作，不會變更。 Always Encrypted 現未全面提供每種語言的每個 SQL Server 驅動程式使用。

TDE 和 Always Encrypted 的組合，兩者都可以與用戶端特定金鑰搭配使用，確保即使最精確的加密需求也能獲得支援。

Cosmos DB

Cosmos DB 是 Microsoft 在 Azure 中提供的最新資料庫。 它從建置之初，即考慮到安全性和密碼編譯。 AES-256 位元加密是所有 Cosmos DB 資料庫的標準，無法停用。 結合用於通訊的 TLS 1.2 需求，會加密整個儲存體解決方案。

圖 9-7。 Cosmos DB 內的資料加密流程。

雖然 Cosmos DB 不提供客戶加密金鑰，但團隊已完成大量工作，以確保其不提供金鑰仍符合 PCI-DSS 規範。 Cosmos DB 也尚未支援類似 Azure SQL Always Encrypted 的任何單一資料行加密。

保持安全

Azure 有發行高度安全產品所需的全部工具。 不過，鏈條的堅固程度取決於其最薄弱的一環。 如果部署在 Azure 上的應用程式未以適當的安全性思維和良好的安全性稽核開發，其將成為鏈條薄弱的一環。 有許多絕佳的靜態分析工具、加密程式庫和安全性做法，可用來確保安裝在 Azure 上的軟體與 Azure 本身一樣安全。 例如靜態分析工具、加密程式庫和安全性做法。

上一個下一個