身分識別管理涵蓋使用身分識別和存取管理系統建立安全身分識別和訪問控制的控件,包括針對應用程式使用單一登錄、強身份驗證、受控識別(和服務主體)、條件式存取和帳戶異常監視。
IM-1:使用集中式身分識別和驗證系統
CIS 安全控制 v8 ID | NIST SP 800-53 r4 識別碼 | PCI-DSS 標識碼(s) v3.2.1 |
---|---|---|
6.7、12.5 | AC-2、AC-3、IA-2、IA-8 | 7.2, 8.3 |
安全性原則:使用集中式身分識別和驗證系統來管理貴組織的雲端和非雲端資源的身分識別和驗證。
Azure 指引:Azure Active Directory (Azure AD) 是 Azure 的身分識別和驗證管理服務。 您應該在 Azure AD 上進行標準化,以控管貴組織的身份識別和驗證:
- Microsoft雲端資源,例如 Azure 記憶體、Azure 虛擬機(Linux 和 Windows)、Azure Key Vault、PaaS 和 SaaS 應用程式。
- 貴組織的資源,例如 Azure 上的應用程式、在公司網路資源上執行的第三方應用程式,以及第三方 SaaS 應用程式。
- 同步 Active Directory 的企業身分識別至 Azure AD,以確保一致且集中管理的身分識別策略。
針對套用的 Azure 服務,請避免使用本機驗證方法,而改用 Azure Active Directory 來集中您的服務驗證。
注意:一旦技術上可行,您應該將內部部署 Active Directory 應用程式移轉至 Azure AD。 這可能是 Azure AD 企業目錄、企業對企業設定,或企業對消費者設定。
Azure 實作和補充背景資訊:
AWS指引:AWS IAM(身分識別與存取管理)是 AWS 的預設身分識別和驗證管理服務。 使用 AWS IAM 來管理 AWS 身分識別和存取管理。 或者,透過 AWS 和 Azure 單一 Sign-On (SSO),您也可以使用 Azure AD 來管理 AWS 的身分識別和存取控制,以避免在兩個雲端平臺中個別管理重複的帳戶。
AWS 支援單一 Sign-On,可讓您使用 AWS 身分識別來橋接公司的第三方身分識別(例如 Windows Active Directory 或其他身分識別存放區),以避免建立重複的帳戶來存取 AWS 資源。
AWS 實作和其他內容:
GCP指引:Google Cloud 的身分識別和存取管理 (IAM) 系統是 Google Cloud 的預設身分識別和驗證管理服務,用於 Google Cloud 身分識別帳戶。 使用Google Cloud IAM來管理您的 GCP 身分識別和存取管理。 或者,透過Google Cloud Identity 和 Azure Sigle Sign-On (SSO),您也可以使用 Azure AD 來管理 GCP 的身分識別和存取控制,以避免在 Mutli-cloud 環境中個別管理重複的帳戶。
Google Cloud Identity 是所有 Google 服務的識別提供者。 它支援單一 Sign-On,可讓您使用Google Cloud身分識別來橋接公司的第三方身分識別(例如 Windows Active Directory 或其他身分識別存放區),以避免建立重複帳戶來存取 GCP 資源。
注意:使用Google Cloud Directory Sync。Google 提供連接器工具,可與大部分的企業LDAP管理系統整合,並依排程同步處理身分識別。 藉由設定雲端身分識別帳戶並唱 Google Cloud Directory Sync,您可以設定哪一個使用者帳戶,包括使用者、群組和使用者配置檔、別名等,將會在本機身分識別管理系統與 GCP 系統之間的排程同步處理。
GCP 實作和額外背景資訊:
客戶安全利害關係人 (瞭解更多):
IM-2:保護身分識別和驗證系統
CIS 安全控制 v8 ID | NIST SP 800-53 r4 識別碼 | PCI-DSS 標識碼(s) v3.2.1 |
---|---|---|
5.4, 6.5 | AC-2、AC-3、IA-2、IA-8、SI-4 | 8.2, 8.3 |
安全性原則:在貴組織的雲端安全性實務中,將您的身分識別和驗證系統視為高優先順序。 常見的安全性控制包括:
- 限制具有特權的角色和特權帳戶
- 所有特權存取皆需強式驗證
- 監視和稽核高風險活動
Azure 指引:使用 Azure AD 安全性基準和 Azure AD 身分識別安全分數來評估您的 Azure AD 身分識別安全性狀態,並補救安全性和設定缺口。 Azure AD Identity Secure Score 會針對下列設定評估 Azure AD:
- 使用受限的系統管理角色
- 啟用用戶風險政策
- 指定多個全域管理員
- 啟用原則以封鎖舊版驗證
- 確定所有使用者都可以完成多重要素驗證,以進行安全存取
- 要求系統管理角色的 MFA
- 啟用自助式密碼重設
- 不要讓密碼過期
- 開啟登入風險原則
- 不允許使用者授與非受控應用程式的同意
使用 Azure AD Identity Protection 來偵測、調查及補救以身分識別為基礎的風險。 若要同樣地保護您的內部部署 Active Directory 網域,請使用適用於身分識別的 Defender。
注意:請遵循所有其他身分識別相關元件的已發佈最佳做法,包括您的內部部署 Active Directory 和任何第三方功能,以及裝載它們的基礎結構(例如作業系統、網路、資料庫)。
Azure 實作和補充背景資訊:
- 什麼是 Azure AD 中的身分識別安全分數
- 保護 Active Directory 的最佳做法
- 什麼是 Identity Protection?
- 什麼是 Microsoft Defender for Identity?
AWS 指引:使用下列安全性最佳做法來保護 AWS IAM:
- 設定 AWS 帳戶根使用者存取金鑰以進行緊急存取,如 PA-5 中所述(設定緊急存取權)
- 遵循存取指派的最低許可權原則
- 利用 IAM 群組來套用原則,而不是個別使用者。
- 遵循 IM-6 中的強身份驗證指引(針對所有使用者使用強身份驗證控制項)
- 使用 AWS 組織 SCP (服務控制原則) 和許可權界限
- 使用 IAM Access Advisor 檢查服務存取
- 使用 IAM 認證報告來追蹤使用者帳戶和認證狀態
注意:如果您有其他身分識別和驗證系統,請遵循已發佈的最佳做法,例如,如果您使用 Azure AD 來管理 AWS 身分識別和存取,請遵循 Azure AD 安全性基準。
AWS 實作和其他內容:
GCP 指引:使用下列安全性最佳做法來保護組織的 Google Cloud IAM 和 Cloud Identity 服務:
- 遵循PA-5中的建議來設定緊急存取的進階系統管理員帳戶(「設定緊急存取權」)。
- 建立超級系統管理員電子郵件位址(如 Google 工作區或雲端身分識別進階系統管理員帳戶),而且此帳戶在需要緊急復原時,不應特別針對特定使用者。
- 遵循最低許可權和職責分離原則
- 避免將超級系統管理員帳戶用於每日活動
- 利用Google Cloud Identity 群組來套用原則,而不是將原則套用至個別使用者。
- 遵循 IM-6 中所述的強式驗證指引(針對具有更高許可權的所有使用者使用強身份驗證控件)。
- 使用 IAM 原則來限制資源的存取
- 使用組織原則服務來控制和設定資源的條件約束
- 使用雲端稽核記錄內的IAM稽核記錄來檢閱特殊許可權活動
注意:如果您有其他身分識別和驗證系統,請遵循已發佈的最佳做法,例如,如果您使用 Azure AD 來管理 GCP 身分識別和存取,請遵循 Azure AD 安全性基準。
GCP 實作和額外背景資訊:
- 超級系統管理員帳戶最佳做法
- 系統管理員帳戶的安全性最佳做法
- 安全地使用 IAM
- 管理其他資源的存取權
- 組織原則服務 簡介
客戶安全利害關係人 (瞭解更多):
IM-3:安全地且自動管理應用程式身分識別
CIS 安全控制 v8 ID | NIST SP 800-53 r4 識別碼 | PCI-DSS 標識碼(s) v3.2.1 |
---|---|---|
N/A | AC-2、AC-3、IA-4、IA-5、IA-9 | N/A |
安全性原則:使用受控應用程式身分識別,而不是為應用程式建立人類帳戶來存取資源並執行程序代碼。 受控應用程式識別可提供優點,例如減少認證曝光。 自動輪替認證,以確保身分識別的安全性。
Azure 指引:使用 Azure 受控識別,可向支援 Azure AD 驗證的 Azure 服務和資源進行驗證。 受控識別認證完全受平臺管理、輪替及保護,避免原始程式碼或組態檔中的硬式編碼認證。
對於不支援受控識別的服務,請使用 Azure AD 來建立具有資源層級限制許可權的服務主體。 建議使用憑證認證來設定服務主體,並回復至用戶端密碼以進行驗證。
Azure 實作和補充背景資訊:
- Azure 受管身分識別
- 支援 Azure 資源受控識別的服務
- Azure 服務主體 (部分內容可能是機器或 AI 翻譯)
- 使用憑證建立服務主體
AWS指引:使用 AWS IAM 角色,而不是為支援此功能的資源建立用戶帳戶。 IAM 角色是由後端的平臺所管理,而且認證是暫時的,而且會自動輪替。 這可避免為原始碼或組態檔中的應用程式和硬式編碼認證建立長期存取密鑰或使用者名稱/密碼。
您可以使用附有預先定義權限原則的服務連結角色來存取 AWS 服務,而不需為 IAM 角色自訂角色權限。
注意:對於不支援 IAM 角色的服務,請使用存取密鑰,但遵循安全性最佳做法,例如 IM-8 限制公開認證和秘密以保護密鑰。
AWS 實作和其他內容:
- AWS IAM 角色 (英文)
- 提供 AWS 服務的存取權
GCP指引:使用 Google 管理的服務帳戶,而不是針對支援這項功能的資源建立使用者管理的帳戶。 Google 管理的服務帳戶是由後端平臺所管理,且服務帳戶密鑰是暫時的,且會自動輪替。 這可避免為應用程式建立長期的存取金鑰或使用者名稱/密碼,以及在原始程式碼或組態檔中硬編碼認證資訊。
使用原則智慧來瞭解及辨識服務帳戶的可疑活動。
GCP 實作和額外背景資訊:
客戶安全利害關係人 (瞭解更多):
IM-4:驗證伺服器和服務
CIS 安全控制 v8 ID | NIST SP 800-53 r4 識別碼 | PCI-DSS 標識碼(s) v3.2.1 |
---|---|---|
N/A | IA-9 | N/A |
安全性原則:驗證來自客戶端的遠端伺服器和服務,以確保您連線到受信任的伺服器和服務。 最常見的伺服器驗證通訊協定是傳輸層安全性(TLS),其中用戶端(通常是瀏覽器或用戶端裝置)會藉由驗證伺服器憑證是由受信任的證書頒發機構單位簽發來驗證伺服器。
注意:當伺服器和客戶端同時驗證彼此時,可以使用相互驗證。
Azure 指引:許多 Azure 服務預設支援 TLS 驗證。 對於預設不支援 TLS 驗證或支援停用 TLS 的服務,請確定一律啟用支援伺服器/客戶端驗證。 用戶端應用程式也應該設計為在交握階段驗證伺服器/用戶端身分識別(藉由驗證受信任的證書頒發機構單位所簽發的伺服器憑證)。
注意:API 管理和 API 閘道等服務支援 TLS 相互驗證。
Azure 實作和補充背景資訊:
AWS指引:許多 AWS 服務預設都支援 TLS 驗證。 對於預設不支援 TLS 驗證或支援停用 TLS 的服務,請確定一律啟用支援伺服器/客戶端驗證。 用戶端應用程式也應該設計為在交握階段驗證伺服器/用戶端身分識別(藉由驗證受信任的證書頒發機構單位所簽發的伺服器憑證)。
注意:API 閘道等服務支援 TLS 相互驗證。
AWS 實作和其他內容:
GCP指引:根據預設,許多 GCP 服務都支援 TLS 驗證。 對於預設不支援此功能或支援停用 TLS 的服務,請確定一律啟用它以支援伺服器/客戶端驗證。 用戶端應用程式也應該設計為在交握階段驗證伺服器/用戶端身分識別(藉由驗證受信任的證書頒發機構單位所簽發的伺服器憑證)。
注意:雲端負載平衡等服務支援 TLS 相互驗證。
GCP 實作和額外背景資訊:
- 傳輸中加密 (簡體中文)
客戶安全利害關係人 (瞭解更多):
IM-5:使用單一登錄 (SSO) 進行應用程式存取
CIS 安全控制 v8 ID | NIST SP 800-53 r4 識別碼 | PCI-DSS 標識碼(s) v3.2.1 |
---|---|---|
12.5 | IA-4、IA-2、IA-8 | N/A |
安全性原則:使用單一登錄 (SSO) 來簡化用戶體驗,以驗證資源,包括跨雲端服務和內部部署環境的應用程式和數據。
Azure 指引:透過 Azure AD 單一登錄(SSO)使用 Azure AD 進行工作負載應用程式存取(客戶面向)存取,減少重複帳戶的需求。 Azure AD 提供 Azure 資源的身分識別和存取管理(在管理平面中,包括 CLI、PowerShell、入口網站)、雲端應用程式和內部部署應用程式。
Azure AD 也支援企業身分識別的 SSO,例如公司使用者身分識別,以及來自受信任第三方和公用使用者的外部使用者身分識別。
Azure 實作和補充背景資訊:
AWS指引:使用 AWS Cognito 透過單一登錄管理客戶面向應用程式工作負載的存取權,讓客戶能夠橋接來自不同身分識別提供者的第三方身分識別。
如需 AWS 原生資源的 SSO 存取權(包括 AWS 控制台存取或服務管理和數據平面層級存取),請使用 AWS Sigle Sign-On 以減少重複帳戶的需求。
AWS SSO 也可讓您使用 AWS 身分識別來橋接公司身分識別(例如來自 Azure Active Directory 的身分識別),以及來自受信任第三方和公用使用者的外部使用者身分識別。
AWS 實作和其他內容:
GCP指引:使用 Google Cloud Identity 透過 Google Cloud Identity 單一登錄來管理客戶面向工作負載應用程式的存取權,減少重複帳戶的需求。 Google Cloud Identity 提供 GCP 的身分識別和存取管理(在管理平面中,包括 Google Cloud CLI、控制台存取)、雲端應用程式和內部部署應用程式。
Google Cloud Identity 也支援 SSO 企業身分識別,例如來自 Azure AD 或 Active Directory 的公司使用者身分識別,以及來自受信任第三方和公用使用者的外部使用者身分識別。 GCP 實作和額外背景資訊:
客戶安全利害關係人 (瞭解更多):
IM-6:使用強身份驗證控件
CIS 安全控制 v8 ID | NIST SP 800-53 r4 識別碼 | PCI-DSS 標識碼(s) v3.2.1 |
---|---|---|
6.3, 6.4 | AC-2、AC-3、IA-2、IA-5、IA-8 | 7.2, 8.2, 8.3, 8.4 |
安全性原則:使用集中式身分識別和驗證管理系統強制執行強式驗證控制(強密碼驗證或多重要素驗證),以取得所有資源的存取權。 僅基於密碼認證的驗證被認為是傳統的驗證方式,因為它不安全,而且無法抵禦流行的攻擊方法。
部署強身份驗證時,請先設定系統管理員和特殊許可權使用者,以確保強式驗證方法的最高層級,然後快速向所有使用者推出適當的強身份驗證原則。
注意:如果舊版應用程式和案例需要舊版密碼型驗證,請遵循密碼安全性最佳做法,例如複雜度需求。
Azure 指引:Azure AD 支援透過無密碼方法和多重要素驗證 (MFA) 的強身份驗證控制。
- 無密碼驗證:使用無密碼驗證作為預設驗證方法。 無密碼驗證有三個選項:Windows Hello 企業版、Microsoft Authenticator 應用程式電話登入,以及 FIDO2 安全性密鑰。 此外,客戶可以使用內部部署驗證方法,例如智慧卡。
- 多重要素驗證:Azure MFA 可根據登入條件和風險因素,對所有使用者、選擇的使用者或每名使用者層級強制執行。 啟用 Azure MFA,並遵循 Microsoft Defender for Cloud 的身分與存取管理建議來設定您的 MFA。
如果舊版密碼型驗證仍用於 Azure AD 驗證,請注意,僅限雲端帳戶(直接在 Azure 中建立的用戶帳戶)具有預設的基準密碼原則。 混合式帳戶(來自內部部署 Active Directory 的用戶帳戶)遵循內部部署密碼原則。
對於可能有預設識別碼和密碼的第三方應用程式和服務,您應該在初始服務設定期間停用或變更它們。
Azure 實作和補充背景資訊:
AWS指引:AWS IAM 支援透過多重驗證(MFA)的強身份驗證控制。 您可以對所有用戶強制執行 MFA、選取使用者,或根據定義的條件,在每個用戶層級強制執行 MFA。
如果您使用來自第三方目錄(例如 Windows Active Directory)的公司帳戶搭配 AWS 身分識別,請遵循個別的安全性指引來強制執行強身份驗證。 如果您使用 Azure AD 來管理 AWS 存取,請參閱此控件的 Azure 指引。
注意:對於可能有預設標識符和密碼的第三方應用程式和 AWS 服務,您應該在初始服務設定期間停用或變更它們。
AWS 實作和其他內容:
- 在 AWS 中使用多重要素驗證 (MFA)
- IAM 支援的 MFA 板型規格
GCP指引:Google Cloud Identity 透過多重要素驗證 (MFA) 支援強身份驗證控制。 您可以對所有用戶強制執行 MFA、選取使用者,或根據定義的條件,在每個用戶層級強制執行 MFA。 若要保護雲端身分識別(和工作區)超級系統管理員帳戶,請考慮使用安全性密鑰和 Google 進階保護計劃,以達到最高安全性。
如果您使用來自第三方目錄(例如 Windows Active Directory)的公司帳戶搭配 Google Cloud 身分識別,請遵循個別的安全性指引來強制執行強身份驗證。 如果您使用 Azure AD 來管理 Google Cloud 存取,請參閱此控件的 Azure 指引。
使用 Identity-Aware Proxy 為 HTTPS 存取的應用程式建立中央授權層,因此您可以使用應用層級訪問控制模型,而不是依賴網路層級防火牆。
注意:對於可能有預設標識符和密碼的第三方應用程式和 GCP 服務,您應該在初始服務設定期間停用或變更它們。
GCP 實作和額外背景資訊:
客戶安全利害關係人 (瞭解更多):
IM-7:根據條件限制資源存取
CIS 安全控制 v8 ID | NIST SP 800-53 r4 識別碼 | PCI-DSS 標識碼(s) v3.2.1 |
---|---|---|
3.3, 6.4, 13.5 | AC-2、AC-3、AC-6 | 7.2 |
安全性原則:明確驗證信任的訊號,以允許或拒絕使用者存取資源,做為零信任存取模型的一部分。 要驗證的訊號應包括使用者帳戶的強式驗證、使用者帳戶的行為分析、裝置可信度、使用者或群組成員資格、位置等等。
Azure 指引:根據使用者定義條件使用 Azure AD 條件式存取,以取得更細微的訪問控制,例如要求特定 IP 範圍(或裝置)的使用者登入才能使用 MFA。 Azure AD 條件式存取可讓您根據特定條件,對組織的應用程式強制執行訪問控制。
定義工作負載中 Azure AD 條件式存取適用的條件和準則。 請考慮下列常見使用案例:
- 具有系統管理角色的使用者需要多重要素驗證
- 需要針對 Azure 管理任務進行多重因素驗證
- 封鎖嘗試使用舊版驗證通訊協議的使用者登入
- 需要在信任的位置完成 Azure AD 多因素驗證的註冊
- 封鎖或開放特定地點的存取權
- 封鎖具風險的登入行為
- 需要組織管理的裝置來運行特定應用程式
注意:細微的驗證會話管理控件也可以透過 Azure AD 條件式存取原則來實作,例如登入頻率和持續性瀏覽器會話。
Azure 實作和補充背景資訊:
AWS指引:建立 IAM 原則,並根據使用者定義條件定義更細微的訪問控制,例如要求特定IP範圍的使用者登入(或裝置)使用多重要素驗證。 條件設定可能包含單一或多個條件以及邏輯。
原則可以從六個不同的維度定義:身分識別型原則、資源型原則、許可權界限、AWS 組織服務控制原則 (SCP) 、訪問控制清單(ACL) 和會話原則。
AWS 實作和其他內容:
- IAM 中的原則和權限 (英文)
- 條件鍵表
GCP指引:根據使用者定義條件建立及定義 IAM 條件,以取得更細微的屬性型訪問控制,例如要求特定 IP 範圍(或裝置)的使用者登入才能使用多重要素驗證。 條件設定可能包含單一或多個條件以及邏輯。
條件是在資源允許原則的角色繫結中指定。 條件屬性是以要求的資源為基礎,例如,其類型或名稱,或要求的詳細數據,例如其時間戳或目的地IP位址。
GCP 實作和額外背景資訊:
客戶安全利害關係人 (瞭解更多):
IM-8:限制認證和秘密的公開
CIS 安全控制 v8 ID | NIST SP 800-53 r4 識別碼 | PCI-DSS 標識碼(s) v3.2.1 |
---|---|---|
16.9, 16.12 | IA-5 | 3.5, 6.3, 8.2 |
安全性原則:確保應用程式開發人員安全地處理認證和秘密:
- 避免將認證和秘密內嵌至程式代碼和組態檔
- 使用金鑰保存庫或安全金鑰存放區服務來儲存認證和秘密
- 掃描原始碼中的認證。
注意:這通常會透過安全軟體開發生命週期 (SDLC) 和 DevOps 安全性程式來管理並強制執行。
Azure 指引:使用受控識別不是選項時,請確定秘密和認證會儲存在安全的位置,例如 Azure Key Vault,而不是將它們內嵌到程式代碼和組態檔中。
如果您使用 Azure DevOps 和 GitHub 進行程式碼管理平臺:
- 實作 Azure DevOps 認證掃描器,以識別程式代碼內的認證。
- 針對 GitHub,使用原生秘密掃描功能來識別程式代碼中的認證或其他形式的秘密。
Azure Functions、Azure Apps 服務和 VM 等用戶端可以使用受控識別安全地存取 Azure Key Vault。 請參閱與使用 Azure Key Vault 進行秘密管理相關的數據保護控件。
注意:Azure Key Vault 為支持的服務提供自動輪替。 對於無法自動輪替的機密資料,請確保定期手動輪替,並在不再使用時進行清除。
Azure 實作和補充背景資訊:
AWS指引:使用 IAM 角色進行應用程式存取不是選項時,請確定秘密和認證會儲存在安全的位置,例如 AWS Secret Manager 或 Systems Manager 參數存放區,而不是將它們內嵌到程式代碼和組態檔中。
使用 CodeGuru 檢閱者進行靜態程式代碼分析,以偵測原始程式碼中硬式編碼的秘密。
如果您使用 Azure DevOps 和 GitHub 進行程式碼管理平臺:
- 實作 Azure DevOps 認證掃描器,以識別程式代碼內的認證。
- 針對 GitHub,請使用原生秘密掃描功能來識別程式代碼中的認證或其他形式的秘密。
注意:秘密管理員會為支持的服務提供自動秘密輪替。 對於無法自動輪替的機密資料,請確保定期手動輪替,並在不再使用時進行清除。
AWS 實作和其他內容:
GCP指引:使用 Google 管理的服務帳戶進行應用程式存取時不是選項,請確定秘密和認證會儲存在安全的位置,例如 Google Cloud 的秘密管理員,而不是將它們內嵌到程式代碼和組態檔中。
使用 IDE(整合開發環境)上的 Google Cloud Code 擴充功能,例如 Visual Studio Code,將 Secret Manager 所管理的秘密整合到您的程式碼中。
如果您使用 Azure DevOps 或 GitHub 進行程式代碼管理平臺:
- 實作 Azure DevOps 認證掃描器,以識別程式代碼內的認證。
- 針對 GitHub,請使用原生秘密掃描功能來識別程式代碼中的認證或其他形式的秘密。
注意:為秘密管理工具中儲存的秘密設定輪替排程,做為最佳做法。
GCP 實作和額外背景資訊:
客戶安全利害關係人 (瞭解更多):
IM-9:保護使用者對現有應用程式的存取
CIS 安全控制 v8 ID | NIST SP 800-53 r4 識別碼 | PCI-DSS 標識碼(s) v3.2.1 |
---|---|---|
6.7、12.5 | AC-2、AC-3、SC-11 | N/A |
安全性原則:在混合式環境中,您有使用舊版驗證的內部部署應用程式或非原生雲端應用程式,請考慮使用雲端存取安全性代理程式 (CASB)、應用程式 Proxy、單一登錄 (SSO) 等解決方案,以控管這些應用程式的存取,以取得下列優點:
- 強制執行集中式強身份驗證
- 監視和控制有風險的終端用戶活動
- 監視和補救有風險的舊版應用程式活動
- 偵測並防止敏感數據傳輸
Azure 指引:使用舊版驗證保護您的內部部署和非原生雲端應用程式,方法是將它們連線到:
- Azure AD 應用程式代理和設定基於標頭的驗證,以允許遠端使用者對應用程式進行單一登錄(SSO),並利用 Azure AD 條件式存取,明確驗證遠端使用者及其裝置的可信度。 如有需要,請使用第三方 Software-Defined Perimeter (SDP) 解決方案,以提供類似的功能。
- Microsoft Defender for Cloud Apps 提供雲端存取安全代理程式(CASB)服務,以監控並阻止使用者訪問未經授權的第三方 SaaS 應用程式。
- 您現有的第三方應用程式傳遞控制器和網路。
注意:VPN 通常用來存取舊版應用程式,而且通常只有基本的訪問控制和有限的會話監視。
Azure 實作和補充背景資訊:
AWS 指引:遵循 Azure 的指引,使用舊版驗證來保護內部部署和非原生雲端應用程式,方法是將它們連線到:
- Azure AD 應用程式 Proxy,並設定以標頭為基礎的存取,以便於遠端使用者對應用程式進行單一登入(SSO),同時透過 Azure AD 條件式存取明確驗證遠端使用者與裝置的可信度。 如有需要,請使用第三方 Software-Defined Perimeter (SDP) 解決方案,以提供類似的功能。
- Microsoft Defender for Cloud Apps 作為雲端存取安全代理服務,用於監控並封鎖使用者存取未經核准的第三方 SaaS 應用。
- 您現有的第三方應用程式傳遞控制器和網路
注意:VPN 通常用來存取舊版應用程式,而且通常只有基本的訪問控制和有限的會話監視。
AWS 實作和其他內容:
GCP指引:使用 Google Cloud Identity-Aware Proxy (IAP) 來管理對 Google Cloud 外部 HTTP 型應用程式的存取,包括內部部署應用程式。 IAP 可在 App Engine 標準環境中使用已簽署的標頭或使用者 API。 如有需要,請使用第三方 Software-Defined Perimeter (SDP) 解決方案,以提供類似的功能。
您也可以選擇使用 Microsoft Defender for Cloud Apps,作為雲端存取安全代理程式 (CASB) 服務,以監視並封鎖使用者存取未核准的第三方 SaaS 應用程式。
注意:VPN 通常用來存取舊版應用程式,而且通常只有基本的訪問控制和有限的會話監視。
GCP 實作和額外背景資訊:
客戶安全利害關係人 (瞭解更多):