雲端原生應用程式比傳統應用程式更容易且更難保護。 缺點是，您需要保護較小的應用程式，並投入更多精力來建置安全性基礎結構。 大部分服務部署中程式設計語言和樣式的異質本質也表示您需要更加注意來自許多不同提供者的安全性布告欄。
另一方面，較小的服務，每個服務都有自己的數據存放區，限制攻擊的範圍。 如果攻擊者入侵一個系統，攻擊者可能比在整合型應用程式中更難跳到另一個系統。 程序邊界是強邊界。 此外，如果資料庫備份公開，則損害會更加有限，因為該資料庫只包含數據子集，而且不太可能包含個人資料。
威脅分析模型
無論優點是否超過雲端原生應用程式的缺點，都必須遵循相同的整體安全性思維。 安全性和安全思維必須是開發和作業案例中每個步驟的一部分。 規劃應用程式時會詢問問題，例如：
- 此數據遺失的影響為何？
- 我們如何限制插入此服務中不良數據的損害？
- 誰應該能夠存取此數據？
- 開發和發佈流程中是否有稽核政策？
所有這些問題都是稱為 威脅模型化的程式的一部分。 此程式會嘗試回答系統有哪些威脅、威脅的可能性，以及威脅的潛在損害的問題。
建立威脅清單之後，您必須決定它們是否值得緩和。 有時某些威脅是如此不可能發生且需要昂貴準備，以至於不值得花費精力。 例如，某些狀態層級動作專案可能會將變更插入數百萬個裝置所使用的程序設計中。 現在，該程式代碼會在 Ring 0 中執行，而不是在 Ring 3 中執行特定程式代碼。 此過程允許漏洞利用略過 Hypervisor，並在裸機上執行攻擊程式，允許攻擊在該硬體上運行的所有虛擬機器。
在沒有顯微鏡和對該處理器矽片設計進階知識的情況下，要偵測到被更改的處理器非常困難。 此情境不太可能發生，且成本高昂，因此可能沒有任何威脅模型會建議防範其利用的保護措施。
更可能的威脅包括允許遞增攻擊的中斷訪問控制標記，例如在 URL 中用Id取代Id=2，或 SQL 插入攻擊，這些威脅對於構建保護措施更具吸引力。 這些威脅的緩解措施相當合理，可以有效建立安全防護並防止出現令公司聲譽受損的尷尬安全漏洞。
最低權限原則
計算機安全性的創始想法之一是最低許可權原則（POLP）。 它實際上是一個基礎的理念，應用於各種形式的安全性，無論是數位安全還是實體安全。 簡言之，原則是任何使用者或進程都應該擁有可執行其工作的最小許可權數目。
例如，想想銀行的出納員：進入保險庫是不常進行的活動。 一般出納員無法自行開啟保險箱。 若要取得存取權，他們需要透過執行其他安全性檢查的銀行經理呈報其要求。
在電腦系統中，一個絕佳的範例是使用者連接到資料庫的權限。 在許多情況下，有單一使用者帳戶可用來建置資料庫結構並執行應用程式。 除了極端情況下，執行應用程式的帳戶不需要更新架構資訊的能力。 應該有數個帳戶提供不同層級的許可權。 應用程式應該只使用許可權等級，授與數據表中數據的讀取和寫入存取權。 這種保護可消除旨在卸除資料庫數據表或引入惡意觸發程序的攻擊。
建置雲端原生應用程式的幾乎每個部分都可以受益於記住最低許可權原則。 設定防火牆、網路安全組、角色和範圍時，您可以在角色型訪問控制 （RBAC） 中找到它。
滲透測試
隨著應用程式變得越來越複雜，攻擊向量會以驚人的速度增加。 威脅模型化有缺陷，因為它往往由建置系統的相同人員執行。 與許多開發人員無法想像使用者互動，然後建置無法使用的使用者介面一樣，大部分開發人員都很難看到每個攻擊媒介。 此外，建置系統的開發人員可能不太熟悉攻擊方法，而且遺漏了重要專案。
滲透測試或「Pen Testing」涉及引入外部人員來嘗試攻擊系統。 這些攻擊者可能是來自企業其他部分的外部諮詢公司或其他具有良好安全性知識的開發人員。 他們得到完全的自由去嘗試顛覆系統。 他們經常會發現需要修補的廣泛安全性漏洞。 有時候攻擊途徑會完全出人意料，例如針對 CEO 發動網路釣魚攻擊。
Azure 本身正持續遭受來自Microsoft內部駭客小組的攻擊。 多年來，他們一直是第一個發現數十種潛在的災難性攻擊向量，並在它們被外部利用之前將其關閉。 目標越誘人，外部動作專案越有可能嘗試利用目標，而且世界上很少有目標比 Azure 更誘人。
監測
如果攻擊者嘗試滲透應用程式，應該會有一些警告。 經常會藉由檢查服務的記錄來發現攻擊。 攻擊會留下在成功之前可以發現的跡象。 例如，嘗試猜測密碼的攻擊者會對登入系統提出許多要求。 監視登入系統可能會偵測出與一般存取模式不一致的奇怪模式。 此監視可以變成警示，進而警示作業人員以啟用某種對策。 高度成熟的監控系統甚至可能會根據這些偏差，主動採取措施，新增規則以封鎖請求或限制回應速度。
保護建置
通常會忽略安全性的其中一個環節是建置流程。 組建不僅應該執行安全性檢查，例如掃描不安全的程式代碼或簽入認證，而且組建本身應該安全。 如果建置伺服器遭到入侵，則會提供絕佳的向量，以將任意程式代碼引入產品。
假設攻擊者想要竊取登入 Web 應用程式的人員密碼。 他們可能會引入一個建置步驟，來修改檢出的程式碼，以鏡像任何登入要求到另一伺服器。 下一次程式代碼通過組建時，會以無訊息方式更新。 原始碼弱點掃描不會在建置前執行時攔截此弱點。 同樣地，沒有人會在程式碼審核中攔截它，因為編譯步驟位於編譯伺服器上。 被利用的程式代碼將會移至能夠收集密碼的生產環境。 可能沒有任何建置程式變更的稽核記錄，或至少沒有監視稽核的人。
此情境是一個看似價值低的目標卻可以用來攻破系統的完美範例。 一旦攻擊者入侵系統的周邊，他們就可以開始尋找提升其許可權的方法，使其在想要的任何位置造成真正的傷害。
建置安全程序代碼
.NET Framework 已經是相當安全的架構。 它可避免未受管控的程式碼的一些陷阱，例如超出陣列邊界。 當發現安全漏洞時，會主動修正問題。 甚至還有一個漏洞賞金計畫，向研究人員支付費用，以找出並報告架構中的問題，而不是利用這些問題。
有許多方法可讓 .NET 程式代碼更安全。 遵循 如 .NET 安全程式代碼撰寫指導方針 一文等指導方針，是確保程式代碼從頭開始安全的合理步驟。 OWASP top 10 是建置安全程式代碼的另一個寶貴指南。
建置過程是一個理想的時機，可以使用掃描工具偵測原始碼中的問題，避免問題進入生產環境。 大部分的每個專案都相依於一些其他套件。 可掃描過期套件的工具，會在夜間組建中攔截問題。 即使建置 Docker 映射，檢查並確定基底映射沒有已知的弱點也很有用。 另一件事是檢查沒有人不小心提交了憑證。
內建安全性
Azure 的設計目的是要平衡大部分使用者的可用性和安全性。 不同的使用者將有不同的安全性需求，因此他們需要微調其雲端安全性的方法。 Microsoft在 信任中心發佈大量安全性資訊。 此資源應該是那些有興趣瞭解內建攻擊風險降低技術運作方式的專業人員的第一站。
在 Azure 入口網站中， Azure Advisor 是持續掃描環境並提出建議的系統。 其中一些建議是設計來節省使用者成本，但有些則設計用來識別可能不安全的組態，例如讓記憶體容器開放給世界，而不會受到虛擬網路的保護。
Azure 網路基礎結構
在內部部署環境中，大量的能源專門用來設定網路。 設定路由器、交換器及這類工作很複雜。 網路允許某些資源與其他資源交談，並在某些情況下防止存取。 常見的網路規則是限制從開發環境存取到生產環境，以避免半開發的程式代碼意外執行並刪除大量數據。
開箱即用，大部分的 PaaS Azure 資源只有最基本且允許性較高的網路設定。 例如，因特網上任何人都可以存取應用程式服務。 新的 SQL Server 實例通常會受到限制，因此外部合作對象無法存取它們，但 Azure 本身所使用的 IP 位址範圍是允許透過的。 因此，雖然 SQL Server 受到外部威脅的保護，但攻擊者只需要從中設定 Azure 網橋頭堡，以便針對 Azure 上的所有 SQL 實例發動攻擊。
幸運的是，大部分的 Azure 資源都可以放入 Azure 虛擬網路，以允許更細緻的訪問控制。 與內部部署網路建立受保護的專用網的方式類似，虛擬網路是位於 Azure 網路內的私人 IP 位址島。
圖 9-1。 Azure 中的虛擬網路。
與內部部署網路具有控管網路存取權的防火牆相同，您可以在虛擬網路的界限建立類似的防火牆。 根據預設，虛擬網路上的所有資源仍然可以與因特網通訊。 只有連入連線需要某種形式的防火牆例外狀況。
建立網路之後，記憶體帳戶等內部資源可以設定為只允許虛擬網路上的資源存取。 此防火牆會提供額外的安全性層級，如果該儲存體帳戶的密鑰遭到外泄，攻擊者將無法連線到該帳戶來利用洩露的密鑰。 此案例是最低許可權原則的另一個範例。
Azure Kubernetes 叢集中的節點可以參與虛擬網路，就像 Azure 更原生的其他資源一樣。 此功能稱為 Azure Container Networking Interface。 實際上，它會在虛擬網路內配置虛擬機和容器映像的子網。
接續闡述最小權限原則，在虛擬網路中，每個資源不必都需要與其他資源進行交流。 例如，在透過記憶體帳戶和 SQL 資料庫提供 Web API 的應用程式中，資料庫和記憶體帳戶不太可能彼此通訊。 它們之間的任何數據共享都會通過 Web 應用程式。 因此， 網路安全組 （NSG） 可用來拒絕兩個服務之間的流量。
禁止資源之間通信的政策可能會令人惱火，尤其當你來自於沒有流量限制的 Azure 使用背景時。 在其他一些雲端上，網路安全組的概念更為普遍。 例如，AWS 上的預設原則是資源在 NSG 中的規則啟用之前，無法彼此通訊。 雖然開發速度較慢，但較嚴格的環境會提供更安全的預設值。 使用適當的 DevOps 做法，特別是使用 Azure Resource Manager 或 Terraform 來管理許可權，可讓控制規則變得更容易。
在設定內部部署與雲端資源之間的通訊時，虛擬網路也很有用。 虛擬專用網可用來順暢地將兩個網路連結在一起。 此方法允許針對所有使用者在站臺上的情況執行虛擬網路，而不需要任何種類的網關。 有許多技術可用來建立此網路。 最簡單的方式是使用可在許多路由器與 Azure 之間建立的 站對站 VPN 。 流量會加密並透過網際網路進行隧道傳輸，每位元組的成本與其他流量相同。 針對需要更多頻寬或更多安全性的案例，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 金鑰保管庫
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 秘密更安全，因為叢集上的使用者可以存取它們。
傳輸中和靜止時加密
保護數據安全很重要，無論是在磁碟上，還是在不同的服務之間傳輸。 防止數據外洩的最有效方式是將數據加密為其他人無法輕易讀取的格式。 Azure 支援各種不同的加密選項。
運送中
有數種方式可將 Azure 中網路上的流量加密。 Azure 服務的存取通常是透過使用傳輸層安全性 （TLS） 的連線來完成。 例如，所有對 Azure API 的連線都需要 TLS 連線。 同樣地，Azure 記憶體中端點的連線可以限制為只能透過 TLS 加密連線運作。
TLS 是複雜的通訊協定，只要知道連線使用 TLS 並不足以確保安全性。 例如，TLS 1.0 是長期不安全，TLS 1.1 並不更好。 即使在 TLS 版本內，也有各種設定可讓連線更容易解密。 最佳動作是檢查伺服器連線是否使用 up-to-date 和設定良好的通訊協定。
此檢查可由外部服務來完成，例如 SSL 實驗室的 SSL 伺服器測試。 針對一般 Azure 端點進行的一次測試運行，在此案例中為服務總線端點，產生了近乎完美的 A 分數。
即使是 Azure SQL 資料庫之類的服務也會使用 TLS 加密來隱藏數據。 有趣的是，使用 TLS 來加密傳輸中的數據，甚至連 Microsoft 也無法監聽執行 TLS 的電腦之間的連線。 這應該能讓擔心數據風險的公司感到安心，緩解他們對於數據可能因Microsoft本身，或是擁有比一般攻擊者更多資源的國家行為者造成風險的顧慮。
圖 9-5。 SSL Labs 的報告顯示服務匯流排端點獲得 A 級評分。
雖然這一層級的加密不會隨時都足夠，但它應該激發對 Azure TLS 連線相當安全的信心。 隨著加密的改善，Azure 將繼續發展其安全性標準。 知道有人在監控安全標準並隨著安全標準的改善而更新 Azure，這是令人放心的。
靜止狀態
在任何應用程式中，有多個位置的數據存放在磁碟上。 應用程式程式代碼本身會從某些儲存機制載入。 大部分的應用程式也會使用某種資料庫，例如 SQL Server、Cosmos DB，甚至是價格驚人划算的 Table Storage。 這些資料庫全都使用高度加密的記憶體，以確保除了具有適當許可權的應用程式之外，沒有人可以讀取您的數據。 即使是系統作員也無法讀取已加密的數據。 因此，客戶可以確信其秘密資訊仍然是秘密。
存儲
大部分 Azure 的基礎是 Azure 記憶體引擎。 虛擬機磁碟會掛接在 Azure 記憶體之上。 Azure Kubernetes Service 會在 Azure 記憶體上裝載的虛擬機上執行。 即使是無伺服器技術，例如 Azure Functions Apps 和 Azure 容器實例，也會用盡屬於 Azure 記憶體的磁碟。
如果 Azure 記憶體已妥善加密，則會為大部分其他專案提供加密的基礎。 Azure 記憶體會使用符合 FIPS 140-2 規範的 256 位 AES 進行加密。 這是一種備受推論的加密技術，在過去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 Client。 也就是說，建置在 SQL 用戶端之上的 Dapper 和 Entity Framework 等工具將繼續運作，而不會變更。 每個語言上的每個 SQL Server 驅動程式可能尚未提供 Always Encrypted。
TDE 和 Always Encrypted 的組合，這兩者都可以與用戶端特定密鑰搭配使用，可確保即使是最精確的加密需求也受到支援。
Cosmos DB（宇宙資料庫）
Cosmos DB 是 Azure 中Microsoft提供的最新資料庫。 它已從頭開始建置，並考慮到安全性和密碼編譯。 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 本身一樣安全。 範例包括 靜態分析工具 和 加密連結庫。
