安全合規
安全管理的目的是風險管理，識別企業內部、外部的安全要求和監管訴求，在云環境中針對網絡安全、身份安全、主機安全、數據安全等全方位地進行規劃和實施，同時持續對威脅進行檢測和快速響應。
云安全的責任模型是共擔的責任模型，基于云的客戶應用，云供應商要保障云平臺自身安全并提供相應的安全能力和產品給云上的客戶。客戶則負責基于云供應商提供的服務或原子化能力構建保障應用系統或業務的安全體系。
安全設計原則
安全需要設計和規劃，應在構建基于云或本地數據中心的同時，建設安全系統和相關控制措施，建立配套安全管理流程和機制，建立安全意識管理體系等。將技術控制措施、管理流程、人員組織配套融入云基礎設施的構建、業務開發，應用上線和日常運營當中。
整體建議如下：
評估當前企業戰略目標和云業務一致性。
通過咨詢和風險評估工具的方式評估當前云計算環境下風險的類別，發生的可能性和影響。
評估架構風險，管理風險以及合規風險。
參考方法論建設安全體系，包括參考框架，技術控制措施和運營機制。
建立安全運營體系持續識別風險，推動安全框架的更新迭代和技術控制措施的優化。
通用的安全設計原則有：
最小化原則：安全最小化原則是最基本的原則之一，對外提供的服務越少，安全風險越小。其中包含網絡最小化原則、身份最小化原則、權限最小化原則。
審計可追溯原則：盡可能確保所有來自用戶端的訪問請求留有審計記錄，以便于在發生網絡攻擊事件時，能夠通過云資源操作日志、云資源訪問日志以及變更日志還原攻擊事件，追溯攻擊過程，幫助企業判斷和定位攻擊事件的等級、影響和損失。
數據安全保護原則：企業應結合實際應用和業務特性，有意識的建立數據分類分級制度和體系，通過相關技術控制手段對權限、訪問途徑進行管理，并保護數據在存儲和傳輸過程中的安全。
合規性原則：企業基于阿里云基礎設施構建的業務系統和對外提供的服務，應充分考慮當地的法律法規要求。在安全架構設計過程中，應充分分析和理解法規要求，并標記能夠滿足法規要求的相關技術控制措施，和管理控制措施。
安全風險識別和檢測
安全風險識別和檢測包含以下4個維度，通過梳理企業客戶上云面臨的整體風險，才能有針對性的對安全架構進行建議、檢測和建設。
基礎架構的風險識別和檢測：云上基礎架構包含了網絡架構和身份體系，要評估和識別當前網絡的架構設計方法，是否符合安全最小化原則和縱深防御原則。
云平臺配置風險識別和檢測：企業使用云產品創建的配置文件是否符合安全原則，需要進行識別和自動化檢測，可基于云安全最佳實踐和行業合規要求建立符合企業自身的云安全基線（Baseline），通過標準識別和檢測上云風險。
資產脆弱性的風險識別和檢測：云上的資產可分為工作負載（云服務器ECS、容器、函數）、基礎網元（EIP、NAT、SLB等）、應用（PaaS服務、域名、鏡像等），面對資產的脆弱性（包含資產基線和資產漏洞）應該進行事前的風險識別和檢測，并進行維護。
合規風險的識別：合規包含了外部合規和內部合規。外部合規指的是面向監管的合規，內部合規指的是面向內部審計、管理的合規。
安全防護
賬號規劃
云賬號是最基本的資源管理單元，它是云資源的計量、計費及資源歸屬的基本主體。云賬號不僅是資源的容器，也是資源安全隔離的邊界。一個云賬號對應了云上的一個租戶，租戶不能訪問相互之間未授權的系統資源。借助該特性，建議遵循最小化原則，按應用、環境等維度設計隔離粒度，并創建單獨的云賬號，用于區分需要完全隔離的IT環境或系統。在發生安全問題時，能夠有效縮小爆炸半徑，降低故障影響面。
因此建議在上云初期，就參考阿里云云采用框架CAF（Cloud Adoption Framework）進行體系化的上云規劃，搭建LandingZone環境。無論是初次上云還是已經上云的客戶，都可以通過阿里云云治理中心（Cloud Governance Center）快速搭建符合阿里云最佳實踐的多賬號云環境。需要創建單獨云賬號時，可以通過云治理中心賬號工廠的能力快速創建符合賬號基線定義的云賬號，加快業務交付。
身份和訪問控制
在整體的云上安全架構設計中，身份和訪問控制是云計算環境下非常重要的安全措施，良好的身份和權限的設計，能夠確保只有授權的身份才能夠在指定的條件下訪問對應的云資源。它涉及到識別用戶和身份（身份驗證），確定該身份可以訪問哪些資源（授權），以及審計相應身份的訪問和操作記錄（監控和審計）。
身份管理
身份是指在云環境中執行操作的實體。云上主要有兩種身份類型：人員身份和程序身份。
人員身份通常代表組織中的個人，比如企業中的安全管理員、運維管理員、應用開發者。通常通過阿里云的控制臺、CLI、特定場景下的客戶端等方式對云上的資源進行操作。人員身份的管理有以下最佳實踐：
避免使用Root身份：在阿里云官網注冊阿里云賬號后，即可通過用戶名和密碼的方式登錄到阿里云控制臺，登錄成功后，即獲得了Root身份。該身份具有該賬號下所有的權限，一旦賬號密碼泄漏，風險極高。應該盡可能的使用阿里云訪問控制RAM（Resource Access Management）身份進行云上資源的訪問。
實現人員身份的統一認證：通過集中化的身份提供商（Identity Provider，簡稱 IdP）來進行人員身份的統一認證，能夠簡化人員身份的管理，確保組織內在云上、云下的人員身份的一致性。阿里云支持基于 SAML 2.0 協議的單點登錄（Single Sign On，簡稱 SSO）。在阿里云上，我們建議通過云SSO或RAM SSO的方式跟組織內的IdP進行集成，實現人員身份的統一認證。
建立更安全的登錄機制：對于人員身份來說，保護好登錄憑證（如用戶名和密碼）能夠有效降低身份泄漏風險。可以從以下幾種方式提升登錄方式的安全性：提升密碼強度、避免混用憑證、定期輪轉密碼、設置多因素驗證。
程序身份則代表應用程序或服務，往往是通過阿里云的OpenAPI來訪問云上的資源和數據。程序身份的管理有以下最佳實踐：
不使用云賬號AccessKey：云賬號AccessKey等同于阿里云賬號的Root權限，一旦泄漏風險極大。對于程序訪問的場景，請使用RAM用戶的AccessKey來進行阿里云API的調用。
避免共用AccessKey：多種身份共用AccessKey，容易導致權限擴大，同時，一處泄漏會導致所有應用都受到影響，風險敞口擴大。因此，不同應用、不同環境都需要避免共用AccessKey。
定期輪轉AccessKey：AccessKey創建和使用時間越長，泄漏的風險越高。通過定期替換舊AccessKey的方式實現輪轉。在阿里云上，可以通過阿里云密鑰管理服務KMS（Key Management Service）的憑據管家功能，實現自動化的定期AccessKey輪轉。
使用臨時憑據代替固定憑據：通過給RAM用戶或云賬號的Root身份創建AccessKey供程序調用，都屬于固定憑據類型。在阿里云上，我們建議盡可能通過角色扮演的方式獲取臨時憑據STS Token，代替固定AccessKey的使用，降低因固定憑據存在周期長導致的泄漏風險。
權限管理
云上的權限管理是為了控制某個身份在什么條件下對哪些資源能夠執行哪些操作。云上的權限管理的核心原則就是權限最小化，只給身份授予必要的權限，確保權限最小夠用。基于該原則，針對不同的身份類型，在阿里云上有以下最佳實踐可以參考。
人員身份的權限管理有以下最佳實踐：
基于人員職能進行授權：針對人員所屬職能（如管理員、運維、安全等）進行權限劃分，并進行權限的抽象，簡化授權過程，降低管理成本。在對職能權限進行抽象后，可以通過將人員身份加入到指定職能用戶組的方式進行組織，提升授權效率。
按資源范圍授權：在云上，建議通過阿里云賬號或資源組兩種方式，區分不同業務應用的資源。在資源合理分類的基礎上，按照人員所管理的業務應用對應的資源范圍進行授權，能夠簡化授權邏輯，提高權限策略復用率，進而在權限最小化和管理效率中取得平衡。
針對程序身份，建議進行精細化授權。除一些特定業務場景外，應用程序所需要訪問的阿里云資源，對應進行的操作是可以預期的，盡可能的通過自定義權限策略來定義該程序身份所需要的最小權限。
另外，對于兩種身份的權限管理，建議：
定期審查權限：關注特權身份和閑置權限，確保每個身份的權限持續滿足最小夠用原則。
設置權限邊界：多賬號場景下，通過管控策略，限制成員賬號內的 RAM 身份權限范圍，禁用一些高危操作降低身份泄漏風險。
基礎設施安全
網絡安全保護
網絡安全防護中最重要的原則就是零信任。無論是云上和云下，還是VPC與VPC之間，以及VPC內部的流量，都需要設計系統化的安全防護方案。相關的設計建議如下：
合理規劃網絡分區進行網絡隔離。云上的VPC默認是互相隔離的。不同業務、不同環境、不同組件通過VPC進行分區，如數據庫往往不需要和公網通信，可以單獨放在一個無公網路由的VPC內。
在東西向、南北向進行流量控制。
在東西向（VPC內部、VPC之間）使用安全組、網絡ACL（Network Access Control List）、云防火墻（Cloud Firewall）進行流量控制。不受信任的VPC之間，可以通過PrivateLink方式提供服務。
在南北向，使用云防火墻進行流量控制。對于應用暴露公網可訪問的端口，建議使用WAF、API Gateway等產品安全暴露服務。使用DDoS防護應對未知的網絡攻擊。
工作負載安全保護
工作負載相關的安全保護主要是指計算資源的防護。根據工作負載部署的方式（如ECS、容器等），會有不同的防護方案，通用的最佳實踐如下：
構建安全的鏡像：無論對于ECS，還是容器化的部署方式，都需要關注鏡像的安全，尤其是規模化的部署場景。建議通過自動化流水線的方式定期構建黃金鏡像（Golden Image），通過云安全中心進行鏡像安全的掃描，確保應用運行環境的安全。
配置漏洞防護：針對應用運行環境，通過云安全中心定期進行部署環境漏洞、木馬、勒索軟件掃描，并進行修復。針對應用本身，在應用上線或變更之前，對代碼進行漏洞掃描和修復。
避免人員身份直接接觸計算資源：通過自動化流水線、ECS云助手等方式實現自動化運維，降低人工操作失誤導致的安全風險。在一些需要人工操作的場景下，建議使用阿里云堡壘機遠程運維，設置高危行為自動阻斷，并記錄操作日志確保能夠溯源。
數據安全
云上數據安全，是云用戶的生命線，也是云上架構安全整體水位的一個最重要具象表現。數據安全應從以下三個維度入手：
數據分類和識別
在數據創建的源頭就需要保障數據的識別和分類分級在第一時間能夠完成，這樣才能保證后續對云上數據的保護做到有的放矢。其中，第一步是對數據中的敏感信息，如個人驗證信息（Personal Identifiable Information，PII），進行發現和檢測。第二步是針對數據中的敏感信息，根據用戶的使用場景、合規需求和安全要求，對數據進行分類分級。在阿里云上，可以通過數據安全中心DSC（Data Security Center）產品實現對MaxCompute、RDS和OSS中的數據進行識別和分類。
靜態數據保護
靜態數據保護主要是指數據在存儲過程中的安全防護。建議從以下幾個方向實施防護：
數據加密：數據存儲安全主要通過數據落盤加密進行保障。阿里云上已經有不同的云產品提供了數據存儲加密功能，如塊存儲EBS、對象存儲OSS、RDS數據庫等。對于有明確的更強加密訴求（如自選密鑰、密鑰輪轉等）的用戶，可以基于阿里云密鑰管理服務KMS（Key Management Service）實現密鑰的管理，并用于數據存儲加密。
設置數據訪問控制：遵循最小化原則為相應身份設置合適的權限。對人員身份來說，建議盡可能避免直接接觸數據。對于程序身份來說，則采用精細化授權的方式來進行合理的訪問授權，確保明確定義需要訪問的數據范圍、所需要的操作以及對應的權限生效條件。對于一些特定的存儲場景，如OSS，還可以進行Bucket Policy的設置，進行更精細化的管控。
設置規則確保數據加密：在完成數據加密的配置后，通過配置審計（Cloud Config）規則，來識別未經加密的資源；對于多個云賬號的用戶，可以設置管控策略（Service Control Policy），在特定場景下實現禁止修改云產品加密配置，禁止使用未經加密磁盤等。
動態數據保護
動態數據保護指的是數據傳輸和交換過程中的安全保護。
數據傳輸安全通過數據傳輸鏈路加密進行保障。傳輸加密是指在數據傳輸過程中，通過如SSL/TLS協議或自行通過密鑰加密等方式實現傳輸過程中的數據加密。阿里云數字證書管理服務（Certificate Management Service），可以在云上簽發第三方知名CA證書頒發機構的SSL證書，幫助用戶實現其網站HTTPS化，使網站可信，防劫持、防篡改、防監聽。阿里云的網關產品（如VPN網關、智能接入網關等）也提供傳輸鏈路的加密功能，確保不同的網絡域之間的通信鏈路是加密的。
在跟第三方進行數據交換的過程中，數據脫敏尤為重要。可以使用阿里云數據安全中心DSC（Data Security Center）產品提供的內置脫敏算法或客戶自定義的脫敏算法，確保脫敏后的數據保留原有數據特征和分布，確保數據的有效性和可用性。
數據異常訪問分析及監控：用戶數據的泄露檢測，主要體現在對數據的權限控制的完整度和數據使用中的監控和檢測能力。如果想要防止數據泄露，首先需要實現對云上存儲產品和傳輸產品權限的有效管控。其次，需要對用戶數據的流轉和操作過程有全面的監控和檢測能力，及時發現數據使用中可能的異常行為。可以使用數據安全中心DSC產品針對數據流轉過程中的異常情況進行有效監控和告警，并進行及時處理。
監控和分析
對安全事件進行監控和分析首先需要對云上各個服務、資源等產生的事件進行收集，從安全角度看，同時需要保證日志完整性，不被篡改、不存在未經授權的訪問。針對日志收集，有以下最佳實踐：
收集所有使用的云服務、資源產生的日志：云服務產生的日志主要有兩種，管控平面日志和數據平面日志。管控平面日志主要通過阿里云操作審計（ActionTrail）提供，通過創建日志跟蹤，可以將日志投遞到指定的OSS存儲空間或SLS日志庫。針對云產品的數據平面，如VPC流日志、OSS的訪問日志等，SLS中提供了日志審計服務，方便的將不同的云產品的日志投遞到統一的SLS日志庫中。其他產品需要在對應云產品側單獨配置日志投遞，如容器服務集群，需要單獨為集群開啟相應的日志收集和歸檔。
設置合理的保存時間和存儲方式：根據安全要求、合規要求、不同云產品特點，設置合理的日志保存時間。較長的保存時間也意味著更多的成本支出，可以將近期日志保存在SLS方便快速查詢，將較遠期的日志歸檔到 OSS，并結合OSS的對象生命周期能力，將更久的日志存儲在歸檔存儲中，在滿足安全要求的前提下，控制成本。
保護日志完整性：對于云上企業來說，建議通過資源目錄構建多賬號體系，將日志存儲在單獨的云賬號中進行歸檔，該云賬號不用于日常的其他操作，只用于日志存儲。同時僅給必要的人（如安全團隊、審計團隊）授予該賬號的訪問權限，嚴格控制各類身份對于該日志的權限，尤其關注寫、刪類型的權限。對于存儲在OSS中的日志，可以開啟合規保留策略，實現“不可刪除、不可篡改”方式保存和使用數據。
在日志收集的基礎上，接下來需要系統化的構建日志分析能力，并構建相應的指標和告警。最佳實踐是將安全事件的發現流程深度集成到工作流系統中，如工單系統或缺陷系統，或者是安全信息與事件系統（SIEM）。在云上，通過SLS可以將存儲的事件日志通過HTTPS或Syslog等方式投遞到SIEM或第三方的日志分析系統中。接下來根據事件類型、等級進行進一步的響應。
響應和恢復
為了降低安全事件發生后對業務造成的影響，企業應該盡早構建安全應急和響應流程。可以參考業界中已有的標準和建議，如NIST SP 800-61等，結合阿里云上相關的云產品，進行流程的設計與驗證。有以下最佳實踐建議：
根據不同的安全事件等級設置合適的響應時間目標，明確標準動作。
對數據進行備份：可以參考穩定性支柱中關于數據災備的建議。
盡可能的使用自動化方式進行響應：安全事件發生后，通過自動化方式能夠更快的實現事件的處理，同時降低人為操作導致的失誤情況。
使用云產品能力實現自動化響應：利用云上的配置審計產品設置規則并自動化修復。如檢測OSS開啟公共讀后，自動修復為私有模式，提升響應效率。另外，也可以通過阿里云事件總線EventBridge產品，在安全事件觸發時，執行運維編排產品中定義的任務，或者函數計算中自定義的代碼，實現自動化的響應能力。
定期對安全流程進行演練，確保安全流程中相關干系人都能夠明確最新的響應流程以及自身職責。演練結束后，對演練過程進行復盤，尋找改進點。
阿里云也提供了安全管家的應急服務，該服務是依靠阿里巴巴多年的安全攻防實戰技術能力和管理經驗，參照國家信息安全事件響應處理相關標準，在發生安全事件后，按照預防、情報信息收集、遏制、根除、恢復流程，提供專業的7X24遠程緊急響應處理服務，幫助云上用戶快速響應和處理信息安全事件并從中恢復業務，同時事后幫助您規劃和設計最佳的云上安全管理方案，從根本上遏制安全事件的發生，降低業務影響。