2025年2月12日:這篇文章重新發布,包含自2020年6月11日原始發布日期以來推出的新服務和功能。
加密是深度防禦安全策略的重要組成部分,該策略使用多種防禦機制來保護工作負載、數據和資產。當組織尋求創新並與客戶建立信任時,他們需要滿足關鍵的合規要求並提高數據安全性。正確使用加密時,可以增加一層防止未經授權訪問的保護,幫助您加強數據保護、遵守法規和標準,並增強通信安全。
加密如何運作及其原因
加密通過使用一個算法和密鑰將數據轉換為不可讀的數據(密文),只有使用正確的密鑰才能再次變得可讀。例如,簡單的短語“Hello World!”在加密後可能看起來像“1c28df2b595b4e30b7b07500963dc7c”。有幾種不同類型的加密算法,所有這些算法都使用不同類型的密鑰。強大的加密算法依賴於數學屬性來生成密文,這些密文在沒有必要的密鑰的情況下,使用任何實際可用的計算能力都無法解密。因此,保護和管理密鑰成為任何加密解決方案的重要部分。
加密作為安全策略的一部分
有效的安全策略始於嚴格的訪問控制和不斷努力定義訪問數據的人員或系統所需的最低權限。在使用AWS雲時,您採用共享責任模型。您負責管理自己的訪問控制策略。加密是深度防禦策略的重要組成部分,因為它可以減輕主要訪問控制機制中的弱點。如果訪問控制機制失效,允許訪問磁盤上的原始數據或沿著網絡鏈路傳輸的數據怎麼辦?如果數據使用強密鑰加密,只要解密密鑰不在與您的數據相同的系統上,對於惡意行為者來說,計算上是不可能解密您的數據的。
為了展示這一點的不可能性,讓我們考慮使用256位密鑰的高級加密標準(AES-256)。它是業界採用的最強大且政府批准的加密數據的算法。AES-256是我們用來加密AWS數據的技術,包括Amazon簡單存儲服務(S3)服務器端加密。使用當前(和可預見的未來)計算技術破解它至少需要一萬億年。目前的研究表明,即使未來量子計算的可用性也不足以顯著減少破解AES-256加密所需的時間。
但是,如果您錯誤地為數據創建了過於寬鬆的訪問策略怎麼辦?設計良好的加密和密鑰管理系統也可以幫助防止這成為問題,因為它將解密密鑰的訪問與數據的訪問分開。
加密解決方案的要求
要充分利用加密解決方案,您需要考慮兩件事情:
保護靜態密鑰:使用加密密鑰的系統是否安全,以便密鑰永遠不能在系統外部使用?此外,這些系統是否正確實施加密算法以生成強大的密文,這些密文在沒有正確密鑰的情況下無法解密?
獨立的密鑰管理:加密的授權是否獨立於如何控制對底層數據的訪問?
您可以將第三方解決方案帶到AWS,以幫助滿足這些要求。然而,這些系統在大規模運行時可能很難且昂貴。AWS提供了一系列選項來簡化加密和密鑰管理。
保護靜態密鑰
當您使用第三方密鑰管理解決方案時,很難評估您的明文密鑰洩露並在解決方案外部使用的風險。密鑰必須存儲在某個地方,您無法總是知道或審核這些存儲系統防止未經授權訪問的所有方式。技術複雜性與在不降低性能或可用性的情況下使加密可用的必要性相結合,意味著選擇和運行密鑰管理解決方案可能會帶來困難的權衡。最大化密鑰安全的最佳做法是使用硬件安全模塊(HSM)。這是一種專門的計算設備,內置了多種安全控制,以幫助防止加密密鑰以可能允許對手訪問和使用這些密鑰的方式離開設備。
現代HSM中的一種控制是防篡改響應,設備檢測到未經授權的物理或邏輯訪問明文密鑰的嘗試,並在攻擊成功之前銷毀密鑰。由於您無法在AWS數據中心安裝和運行自己的硬件,AWS提供了兩項使用具有防篡改響應的HSM來保護客戶密鑰的服務:AWS密鑰管理服務(AWS KMS),代表客戶管理一個HSM艦隊,以及AWS CloudHSM,讓客戶能夠管理自己的HSM。每項服務都可以代表您創建密鑰,或者您可以從本地系統導入密鑰以供每項服務使用。
AWS KMS或AWS CloudHSM中的密鑰可以直接用於加密數據,或者用於保護分發給直接加密數據的應用程序的其他密鑰。加密加密密鑰的技術稱為信封加密,它使加密和解密可以在存在明文客戶數據的計算機上進行,而不是每次都將數據發送到HSM。對於非常大的數據集(例如,數據庫),在數據集和HSM之間移動數千兆字節的數據以進行每次讀/寫操作是不切實際的。相反,信封加密允許在需要時將數據加密密鑰分發給應用程序。HSM中的“主”密鑰用於加密數據密鑰的副本,以便應用程序可以將加密密鑰與在該密鑰下加密的數據一起存儲。一旦應用程序加密數據,數據密鑰的明文副本可以從其內存中刪除。數據解密的唯一方法是將加密的數據密鑰(僅幾百字節大小)發送回HSM並解密。
信封加密過程在AWS服務中使用,其中數據代表客戶加密(這稱為服務器端加密)以最小化性能下降。如果您希望在自己的應用程序中加密數據(客戶端加密),建議您使用AWS KMS或AWS CloudHSM進行信封加密。兩項服務都提供客戶端庫和SDK,以將加密功能添加到其應用程序代碼中並使用每項服務的加密功能。AWS加密SDK是一個可以在任何地方使用的工具示例,不僅限於在AWS中運行的應用程序。為了使客戶更容易在像Amazon DynamoDB這樣的數據庫中加密數據,我們構建了AWS數據庫加密SDK。AWS數據庫加密SDK是一組軟件庫,使您能夠在數據庫設計中使用客戶端加密,包括數據庫項目的記錄級加密。今天,AWS數據庫加密SDK支持Amazon DynamoDB的屬性級加密。
由於實施加密算法和HSM至關重要,所有HSM供應商都應該讓他們的產品通過可信第三方的驗證。AWS KMS和AWS CloudHSM中的HSM均根據國家標準與技術研究院的FIPS 140計劃進行驗證,這是評估加密模塊的標準。這驗證了加密模塊的安全設計和實施,包括與端口和接口、身份驗證機制、物理安全和防篡改響應、操作環境、加密密鑰管理以及電磁干擾/電磁兼容性(EMI/EMC)相關的功能。使用FIPS 140級3驗證的加密模塊進行加密通常是其他與安全相關的合規計劃的要求,例如美國的FedRamp和HIPAA-HITECH,或國際支付卡行業標準(PCI-DSS)。
獨立的密鑰管理
雖然AWS KMS和AWS CloudHSM可以代表您保護明文主密鑰,但您仍然負責管理訪問控制,以確定誰可以在何種條件下使用哪些加密密鑰。使用AWS KMS的一個優勢是您用於定義密鑰訪問控制的策略語言與您用於定義對所有其他AWS資源的訪問的語言相同。請注意,語言是相同的,而不是實際的授權控制。您需要一種管理密鑰訪問的機制,這與您用於管理數據訪問的機制不同。AWS KMS通過允許您分配一組只能管理密鑰的管理員和另一組只能管理對底層加密數據的訪問的管理員來提供該機制。以這種方式配置您的密鑰管理過程有助於提供您需要的職責分離,以避免意外升級特權以解密數據給未經授權的用戶。為了進一步分離控制,AWS CloudHSM提供了一個獨立的策略機制來定義對密鑰的訪問。
2022年,AWS KMS推出了對外部密鑰存儲(XKS)的支持,這是一項允許您在本地或您選擇的位置上運行的HSM上存儲AWS KMS客戶管理密鑰的功能。在高層次上,AWS KMS將加密和解密請求轉發到您的HSM。您的密鑰材料永遠不會離開您的HSM。這可以幫助您解鎖少數高度受監管的工作負載的用例,這些工作負載的加密密鑰應存儲和使用在AWS數據中心之外。然而,XKS在共享責任模型中強制進行重大轉變——您現在對KMS密鑰的持久性、吞吐量、延遲和可用性負責。如果該密鑰丟失或被銷毀,您可能會永久失去對數據的訪問權,如果XKS密鑰不可用,所有依賴該XKS密鑰的AWS工作負載將無法訪問。
即使能夠將密鑰管理與數據管理分開,您仍然可以驗證您已正確配置了對加密密鑰的訪問。AWS KMS與AWS CloudTrail集成,您可以審核誰在何時使用了哪些密鑰,對哪些資源進行了操作。這提供了對您的加密管理過程的詳細視角,通常比本地審核機制更深入。來自AWS CloudHSM的審核事件可以發送到Amazon CloudWatch,這是AWS服務,用於監控和警報您在AWS中運行的第三方解決方案。
靜態和傳輸中的數據加密
處理客戶數據的AWS服務,加密從一個系統發送到另一個系統的數據——稱為傳輸中的數據——提供選項來加密靜態數據。使用AWS KMS或AWS CloudHSM進行靜態加密的AWS服務使用AES-256。這些服務都不會存儲靜態的明文加密密鑰——這是一項只有AWS KMS和AWS CloudHSM可以使用其FIPS 140級3驗證的HSM執行的功能。這種架構有助於最小化密鑰的未經授權使用。
在加密傳輸中的數據時,AWS服務使用傳輸層安全(TLS)協議在您的應用程序和AWS服務之間提供加密。大多數商業解決方案使用一個名為OpenSSL的開源項目來滿足其TLS需求。OpenSSL大約有500,000行代碼,其中至少70,000行實現了TLS。代碼庫龐大、複雜且難以審核。此外,當OpenSSL存在漏洞時,全球開發者社區面臨的不僅是修復和測試更改的挑戰,還要確保所產生的修復本身不會引入新的缺陷。
AWS對OpenSSL中TLS實現挑戰的回應是開發我們自己的TLS實現,稱為s2n,或信號到噪聲。我們於2015年6月發布了s2n,我們設計它以小巧和快速為目標。s2n的目標是為您提供更易於理解且完全可審核的網絡加密。我們在Apache 2.0許可下發布並託管在GitHub上。
我們還設計s2n以使用自動推理進行分析,使用數學邏輯測試安全性和正確性。通過這一過程,稱為形式方法,我們每次更改代碼時都會驗證s2n代碼庫的正確性。我們還自動化了這些數學證明,並定期重新運行,以確保所需的安全屬性在代碼的新版本中保持不變。正確性的自動數學證明是安全行業的一個新興趨勢,AWS在我們的多種關鍵任務軟件中使用這種方法。
同樣,在2022年,我們發布了s2n-quic,一個開源Rust實現的QUIC協議,這是我們AWS加密開源庫的一部分。QUIC是一種為性能設計的加密傳輸協議,是HTTP/3的基礎。它在一組IETF標準中指定,這些標準於2021年5月獲得批准。Amazon CloudFront HTTP/3支持基於s2n-quic,因為它強調性能和效率。您可以在這篇安全博客文章中了解有關s2n-quic的更多信息。
實施TLS需要使用加密密鑰和數字證書來聲明這些密鑰的所有權。AWS證書管理器和AWS私有證書機構是兩項服務,可以簡化需要提供TLS端點的基礎設施中數字證書的發行和輪換。這兩項服務使用AWS KMS和AWS CloudHSM的組合來生成和/或保護它們發行的數字證書中使用的密鑰。
使用中的數據加密
您可能還有需要保護由聯邦學習模型或其他應用程序積極使用的數據的用例。密碼計算——一組允許在加密數據上執行計算的技術,以便不暴露敏感數據——是一種保護使用中數據的方法。
考慮一個保險公司與其他公司合作開發保險欺詐檢測機器學習模型的例子。您可能需要使用有關客戶的敏感數據作為模型的訓練數據,但您不想以明文形式與其他公司共享客戶數據。密碼計算為組織提供了一種協作訓練模型的方法,而不會將有關其客戶的明文數據暴露給彼此或像AWS這樣的雲提供商。您可以在這篇AWS安全博客文章中閱讀有關密碼計算的更多信息。
今天,您可以在AWS Clean Rooms中看到密碼計算的應用,這是一項服務,幫助公司及其合作夥伴更輕鬆和安全地分析和協作處理他們的集體數據集——所有這些都不會共享或複製彼此的底層數據。AWS Clean Rooms有一個名為AWS Clean Rooms密碼計算(C3R)的功能,即使在AWS Clean Rooms協作處理數據時也能以密碼方式保護您的數據。
端到端加密在安全通信中的作用
端到端加密(E2EE)是一種安全通信方法,結合傳輸中的加密和靜態加密,以防止未經授權的訪問、攔截或篡改。解密僅發生在您打算通信的各方,並且不涉及中間的服務提供商。每次通話、消息和文件都用唯一的私鑰加密,並在傳輸中保持保護。未經授權的各方無法訪問通信內容,因為他們沒有解密數據所需的私鑰。
AWS Wickr是一項端到端加密的消息和協作服務,使用256位加密保護一對一和群組消息、語音和視頻通話、文件共享、屏幕共享和位置共享。使用Wickr,每條消息都獲得一個唯一的AES私有加密密鑰和一個唯一的橢圓曲線Diffie–Hellman(ECDH)公鑰,以與接收者協商密鑰交換。消息內容——包括文本、文件、音頻或視頻——使用消息特定的AES密鑰在發送設備(例如您的iPhone)上加密。然後使用ECDH密鑰交換機制交換此密鑰,以便只有預期的接收者可以解密消息。
量子計算和後量子密碼學
量子計算是一個使用量子力學比傳統計算機更快地解決複雜問題的技術領域。量子計算機能夠通過利用量子力學效應(如疊加和量子干涉)更快地解決某些類型的問題。對於密碼學,這對傳統加密機制(如非對稱密鑰加密)產生影響,這通常用於保護傳輸中的數據(TLS)或創建基於哈希的簽名以驗證消息或文件的完整性和真實性。如果量子計算機性能和穩定性足夠,它們理論上可以破壞非對稱密鑰算法(如RSA、橢圓曲線密碼學(ECC)或Diffie-Hellman密鑰協議)的安全性。根據當前的研究,對稱密鑰算法(如AES)不被認為會受到量子計算機的威脅,因為256位的密鑰長度已經足夠補償量子算法帶來的密碼強度下降。
AWS為客戶提供了使用混合方案評估後量子算法和傳統算法的選擇,這些混合方案利用經典密碼學和設計為抵抗量子計算機威脅的較新後量子密碼學(PQC)算法。AWS通過在AWS-LC中實施ML-KEM(一種基於模塊格的密鑰封裝機制)來採取部署PQC的第一步,AWS-LC是我們的開源FIPS-140-3驗證的加密庫。AWS-LC是AWS中使用的核心加密庫。具體來說,AWS-LC用於s2n-tls,我們的開源TLS實現,跨AWS服務使用HTTPS端點。
我們還在AWS KMS、AWS證書管理器(ACM)和AWS Secrets Manager TLS端點中部署了後量子s2n-tls,將後量子密碼學的好處帶給那些在其AWS SDK中啟用混合後量子TLS以連接到這些服務的客戶。AWS Transfer Family也支持後量子混合SFTP文件傳輸。您可以在這篇AWS安全博客文章中閱讀有關我們將更多AWS管理服務端點遷移到PQC over TLS的努力。您還可以在Amazon Science Blog上找到有關Amazon和AWS在密碼學研究和改進方面的工作的信息。
加密一切,無處不在
AWS為客戶提供了加密一切、無處不在的能力。客戶可以在AWS管理控制台中點擊幾下或通過AWS API調用來加密靜態、傳輸中和內存中的數據。像Amazon簡單存儲服務(Amazon S3)這樣的服務默認加密新對象,並支持使用客戶管理的AWS KMS密鑰,讓客戶對其加密密鑰有更多控制。重要的是,AWS KMS使用信封加密和高度可擴展的密鑰管理基礎設施等技術,使AWS服務(如Amazon S3或Amazon Elastic Block Store(Amazon EBS))能夠以最小的性能影響加密數據。
AWS還在不斷努力提高客戶數據在網絡或設備之間移動時的性能和安全性。截至2024年6月,所有AWS API端點支持TLS 1.3,並至少需要TLS 1.2或更高版本。通過使用TLS 1.3,您可以通過為每個連接請求刪除一個網絡往返來減少連接時間,並可以受益於當今可用的一些最現代和安全的加密套件。
需要內存加密的客戶可以使用AWS Graviton,我們基於ARM的定制處理器系列。AWS Graviton2、AWS Graviton3和AWS Graviton3E支持始終開啟的內存加密。加密密鑰在主機系統中安全生成,不會離開主機系統,並在主機重啟或關機時被銷毀。內存加密也支持其他實例類型;有關更多詳細信息,請參閱EC2文檔。
作為我們AWS數字主權承諾的一部分,我們承諾繼續創新和投資於加密功能的額外控制,以便我們的客戶可以使用在AWS雲內外管理的加密密鑰加密一切,無處不在。
總結
在AWS,安全是我們的首要任務。我們致力於幫助您控制數據的使用方式、誰可以訪問它以及如何保護它。通過構建和支持在雲內外工作的加密工具,我們幫助您保護數據並在整個環境中實現合規。我們將安全放在我們所做的一切的中心,以確保您可以使用最先進的安全技術以具有成本效益的方式保護您的數據。
如果您對這篇文章有反饋,請在下方的評論部分提交評論。如果您對這篇文章有疑問,請在AWS KMS論壇或AWS CloudHSM論壇上開始一個新的線程,或聯繫AWS支持。
本文由 AI 台灣 運用 AI 技術編撰,內容僅供參考,請自行核實相關資訊。
歡迎加入我們的 AI TAIWAN 台灣人工智慧中心 FB 社團,
隨時掌握最新 AI 動態與實用資訊!