diff --git a/src/content/docs/reference-architecture/design-guides/zero-trust-for-saas.mdx b/src/content/docs/reference-architecture/design-guides/zero-trust-for-saas.mdx index 06d05c6c477f117..6567a1e117dc6db 100644 --- a/src/content/docs/reference-architecture/design-guides/zero-trust-for-saas.mdx +++ b/src/content/docs/reference-architecture/design-guides/zero-trust-for-saas.mdx @@ -115,13 +115,13 @@ IT teams will also benefit from a consistent and automated process for onboardin Consider a scenario where a user moves to a different group or team within an organization. As soon as the user group information is updated on the IdP, Cloudflare's ZTNA policies will dynamically enforce these changes, ensuring that the user's access to the SaaS applications is immediately adjusted based on their new role. This also helps in SaaS applications' license optimization. For example, if an employee is transferred from the sales team, which uses Salesforce, to a team that does not require access to Salesforce, the ZTNA policies will revoke their access to the application. This automated process helps in reclaiming the license that was previously assigned to the user, ensuring that only those who actually need the application have access to it. -Finally, SaaS applications are accessible over the Internet, allowing any device to access them if a user authenticates successfully. However, with Cloudflare's ZTNA service, IT teams can ensure that only managed devices access a SaaS application by enforcing device posture checks, in addition to identity checks. A common use case is [verifying the presence of an IT-deployed device certificate](/cloudflare-one/identity/devices/warp-client-checks/client-certificate/#client-certificate) before granting application access. +Finally, SaaS applications are accessible over the Internet, allowing any device to access them if a user authenticates successfully. However, with Cloudflare's ZTNA service, IT teams can ensure that only managed devices access a SaaS application by enforcing device posture checks, in addition to identity checks. A common use case is [verifying the presence of an IT-deployed device certificate](/cloudflare-one/identity/devices/warp-client-checks/client-certificate/#configure-the-client-certificate-check) before granting application access. #### Deployment guidelines For SaaS applications that do not support SSO or organizations that are already implementing IP allow lists to secure access to SaaS applications, implementing dedicated egress IPs is the most straightforward approach to enhance access security to SaaS applications, without impacting the user experience. -Organizations that would like to simplify their onboarding/offboarding of users to applications and standardize ZTNA policies should consider implementing Cloudflare's ZTNA solution for both self-hosted and SaaS applications. In such scenarios, it might still be relevant to consider dedicated egress IPs for a subset of critical SaaS applications. As egress policies operate at the network and transport layers, their enforcement is almost real-time. [For example](/cloudflare-one/tutorials/m365-dedicated-egress-ips/#protect-access-to-microsoft-365-with-dedicated-egress-ips), consider an egress policy for a specific SaaS application that accounts for posture status from an external endpoint management solution. If a device becomes compromised and its posture status becomes non-compliant, the egress policy will no longer match. This results in the user of that device losing access to the SaaS application, as traffic will no longer be sourced from the dedicated egress IP. +Organizations that would like to simplify their onboarding/offboarding of users to applications and standardize ZTNA policies should consider implementing Cloudflare's ZTNA solution for both self-hosted and SaaS applications. In such scenarios, it might still be relevant to consider dedicated egress IPs for a subset of critical SaaS applications. As egress policies operate at the network and transport layers, their enforcement is almost real-time. [For example](/cloudflare-one/tutorials/m365-dedicated-egress-ips/#_top), consider an egress policy for a specific SaaS application that accounts for posture status from an external endpoint management solution. If a device becomes compromised and its posture status becomes non-compliant, the egress policy will no longer match. This results in the user of that device losing access to the SaaS application, as traffic will no longer be sourced from the dedicated egress IP. Finally, organizations that have already integrated all their SaaS applications with an IdP for SSO can still consider adding IP allow lists with dedicated egress IPs for a subset of applications for the same reason as detailed before. @@ -138,7 +138,7 @@ To mitigate these risks, controls should be implemented for both data in transit As mentioned before, all traffic can be forced through Cloudflare using the device agent, Magic WAN (MWAN) tunnels, or the remote browser. This allows [secure web gateway](/cloudflare-one/policies/gateway/) policies to manage and protect data as it is uploaded or downloaded from SaaS applications. Common use cases include: - Restricting the ability to download [all](/cloudflare-one/policies/gateway/http-policies/common-policies/#block-google-drive-downloads) or a [subset of files](/cloudflare-one/policies/gateway/http-policies/common-policies/#block-file-types) from managed SaaS applications to specific groups of users within the organization. -- Using [Data Loss Prevention (DLP)](/cloudflare-one/policies/data-loss-prevention/#data-loss-prevention) profiles to limit the download of data containing sensitive information from managed SaaS applications. +- Using [Data Loss Prevention (DLP)](/cloudflare-one/policies/data-loss-prevention/#_top) profiles to limit the download of data containing sensitive information from managed SaaS applications. For more information about securing data in transit, refer to our [reference architecture center](/reference-architecture/diagrams/security/securing-data-in-transit/). @@ -222,7 +222,7 @@ Data protection for unmanaged SaaS applications is similar to that for managed S - Restricting the ability to [upload certain file types](/cloudflare-one/policies/data-loss-prevention/dlp-policies/common-policies/#block-file-types) to SaaS applications, limiting this capability to specific groups of users within the organization. - Using Data Loss Prevention (DLP) profiles to block the upload of data containing sensitive information. -In addition to these measures, [remote browser isolation](/cloudflare-one/policies/browser-isolation/#browser-isolation) can be considered for unmanaged SaaS applications. This approach allows users to access certain unmanaged SaaS applications while [restricting their actions within those applications](/cloudflare-one/policies/browser-isolation/isolation-policies/#policy-settings) to prevent misuse. +In addition to these measures, [remote browser isolation](/cloudflare-one/policies/browser-isolation/#_top) can be considered for unmanaged SaaS applications. This approach allows users to access certain unmanaged SaaS applications while [restricting their actions within those applications](/cloudflare-one/policies/browser-isolation/isolation-policies/#policy-settings) to prevent misuse. ![Figure 10: DLP policies can be combined with browser isolation, to protect company data.](~/assets/images/reference-architecture/zero-trust-for-saas/zero-trust-saas-image-10.svg "Figure 10: DLP policies can be combined with browser isolation, to protect company data.")