参考体系结构：合并和收购
概述
CompanyA 是一家位于美国北部平原的食品制造商。为了继续发展和扩展到新类型的食品，CompanyA 计划在不同气候下收购更多食品制造商。作为收购流程的一部分，CompanyA 需要一个可重复的策略，将收购的公司系统集成到单一的统一体验中。
跨多个独立组织的集成带来了许多技术挑战。这些挑战主要集中在授予外部用户（CompanyA 用户）访问由独立身份提供商授权的私有资源（CompanyB 应用程序）的权限。
CompanyA 决定使用 Citrix Workspace 作为其兼并和收购战略的基石。他们希望使用同样的策略来收购 CompanyC、CompanyD 和 CompanYE。
成功标准
作为收购策略的一部分，CompanyA 需要一种能够快速安全地允许用户访问 CompanyA 和 CompanyB 资源的解决方案。为了取得成功，CompanyA 定义了一系列成功标准，这些标准构成了总体设计的基础。
用户体验
并购解决方案的第一个方面是满足用户的需求。CompanyA 为成功设计确定了以下与用户相关的标准。
| 成功标准 | 说明 | 解决方案 |
|---|---|---|
| 应用程序库 | 来自 CompanyA 和 CompanyB 的用户需要一种集中的方式来访问另一家公司的资源。 | Citrix Workspace |
| Web 应用程序单点登录 | 从其他公司访问私有 Web 资源时，用户无需记住并输入其他用户帐户或密码。 | Citrix Secure Private Access 服务 |
| 虚拟应用程序单点登录 | 从其他公司访问虚拟 Windows 应用程序时，用户无需记住和输入其他用户帐户或密码。 | Citrix DaaS — 联合身份验证服务 |
| 统一体验 | 无论用户的原始公司如何，所有用户都具有相同的身份验证体验。 | Citrix Application Delivery Controller — nFactor 身份验 |
安全性
兼并和收购解决方案的第二个方面是满足安全需求。CompanyA 为成功设计确定了以下与安全相关的标准。
| 成功标准 | 说明 | 解决方案 |
|---|---|---|
| 身份提供商 | 每个收购的组织都维护一个单独的身份提供商，直到它可以与 CompanyA 的主要身份提供商集成为止。 | Citrix Application Delivery Controller |
| 多因素身份验证 | 考虑到安全性，需要 MFA 来确保企业资源的另一层身份验证保护。 | 使用 Push 集成当前部署的解决方案或需要基于时间的 |
| 无 VPN 访问 | 必须保护公司资源免受不受信任和不安全的位置的影响。为帮助防止恶意软件入侵，不允许设备直接访问内部网络。 | Citrix Secure Private Access 服务和 Citrix DaaS |
| 内部威胁 | 有记录在案的案例中，对收购不满意的内部用户窃取客户数据和知识产权。必须限制捕获和存储数据 | 增强的安全策略、应用程序保护策略和 Security Analytics |
| 外部威胁 | 为了处理多目录身份验证，Citrix Application Delivery Controller 向 Workspace 提供了身份验证 Web 应CompanyA 必须为面向公众的 Web 应用程序添加额外的保护层。 | 带有计算机人管理和 Web App Firewall 的 Citrix Application Delivery Controller |
概念体系结构
根据他们定义的要求，CompanyA 为其收购策略创建了以下高级概念架构。概念体系结构不仅满足所有要求，而且还为 CompanyA 提供了扩展到未来确定的其他用例所需的基础。
体系结构框架分为多个层。该框架为了解兼并和收购情景的技术架构奠定了基础。所有层一起流动，创建完整的端到端解决方案。
在高级别上：
用户层：用户层描述了用于连接资源的最终用户环境和终端设备。
- 无论设备如何，用户都可以从 Workspace 应用程序访问资源，从而在各种外形规格和设备平台上提供一致的体验。
访问层：访问层描述了有关用户如何对其 Workspace 和辅助资源进行身份验证的详细信息。
- 用户继续使用其获取前的主要身份进行身份验证。
- 用户继续使用其获取前的多因素身份验证解决方案。如果公司目前没有使用多因素身份验证，CompanyA 将提供支持基于推送的身份验证的基于电话的 TOTP 令牌。
资源层：资源层为定义的用户和组以及与资源关联的安全策略授权特定的 SaaS、Web 和虚拟资源。
- 无论用户的原始公司如何，必须允许用户无缝访问其他公司托管的任何授权资源。
- 为了更好地保护数据，CompanyA 要求禁用从托管资源中打印、下载和复制/粘贴内容到终端节点的策略。CompanyA 还要求限制屏幕抓取\ 捕获应用程序和键盘记录恶意软件。
- 由于端点安全状态的未知性质，CompanyA 要求通过使用隔离浏览器或虚拟化会话对资源进行无 VPN 访问。
控制层：控制层定义底层解决方案如何根据用户的底层活动进行调整。
- 有了保护用户和公司数据的政策，仍然存在风险。CompanyA 使用 Security Analytics 服务来识别受攻击的用户或内部威胁，并自动采取措施来维护安全的环境。
- 必须保护统一多目录身份验证的平台免受外部威胁和攻击。CompanyA 启用集成的 Web App Firewall 和计算机人管理来保护环境中的身份验证点。
托管层： 托管层详细说明了如何在硬件上部署组件，无论是本地、云还是混合云。
- Citrix Workspace 必须能够通过单个工作区站点访问每家公司的身份提供商，无论是本地 Active Directory 域还是 Okta 提供的基于云的产品。
后面的章节将更详细地介绍 CompanyA 的兼并和收购战略参考体系结构的具体设计决策。
访问层
身份验证
CompanyA 在之前的收购中遇到的挑战之一是如何整合身份提供商。合并身份提供商的过程可能需要相当长的时间。借助新策略，CompanyA 使用 Citrix Application Delivery Controller 来处理所有身份验证请求。
身份验证过程由 Application Delivery Controller 对用户的公司进行评估，然后应用正确的身份验证请求。由于 CompanyA 已在 Okta 上标准化进行主身份验证，请求将转发给 Okta。Okta 完成用户身份验证后，Okta 会用标识成功身份验证的令牌回复 Application Delivery Controller。
但是，并非公司收购的每家公司都使用 Okta。相反，如果 Application Delivery Controller 识别用户来自 CompanyB，则会要求用户输入其 Active Directory 用户名和密码。这些凭据将根据 CompanyB 的 Active Directory 域进行验证。如果 CompanyB 已经集成了多因素身份验证解决方案，则用户将继续使用其注册的令牌。
由于强身份验证是安全的关键第一步，CompanyA 希望为当前未使用多重身份验证的组织准备好解决方案。在这种情况下，在用户使用其公司的 Active Directory 域进行身份验证后，Application Delivery Controller 将使用基于时间的本机一次性密码引擎为用户提供多因素身份验证。注册到用户的设备后，用户可以手动输入代码或使用推送通知服务。推送通知只需要用户从注册的移动设备中选择“是”即可完成多因素身份验证。
nFactor 策略
对于主身份验证，Citrix Application Delivery Controller 起着关键作用。为了做出身份验证决策，Application Delivery Controller 使用 nFactor 策略。
要正确处理身份验证请求，nFactor 策略必须知道用户所属的公司。选择正确的公司标识符后，nFactor 会将请求转发到身份验证策略的正确分支。
一旦定义了 nFactor 策略，CompanyA 就可以继续扩展它以包含未来获得的其他组织。nFactor 策略允许 CompanyA 利用身份验证标准创建额外的流程，这些标准包括 LDAP、RADIUS、SAML、客户端证书、OAuth OpenID Connect、Kerberos 等。nFactor 策略引擎为 CompanyA 提供了继续集成额外收购的灵活性，而无需重新设计。
零信任网络访问
为了提供对私有 Web 应用程序、虚拟应用程序和虚拟桌面等内部资源的访问权限，CompanyA 计划使用 Secure Private Access 服务和 Citrix DaaS。这两项服务使用零信任网络访问解决方案，这是传统 VPN 更安全的替代方案。
Secure Private Access 服务和 Citrix DaaS 使用由 Cloud Connector 和连接器设备建立的出站控制通道连接。这些连接允许用户远程访问内部资源。但是，这些连接具有以下特点
- 范围有限，因此只有定义的资源可以访问
- 基于用户的主要安全身份
- 仅适用于禁止网络遍历的特定协议
资源层
联合认证服务
用户使用主身份向 Citrix Workspace 进行身份验证。主要身份基于其公司的身份提供商。合并和收购的挑战之一是获得基于次要身份的次要资源。例如，CompanyA 允许来自 CompanyB 和 CompanyC 的某些用户访问虚拟 Windows 应用程序。要访问虚拟 Windows 应用程序，用户必须在包含虚拟资源的域中拥有用户帐户（辅助身份）。CompanyB 用户的帐户（主身份）不会对 CompanyA 资源（次要身份）进行身份验证。为了在主身份和辅助身份之间转换凭据并向虚拟 Windows 应用程序提供单点登录，CompanyA 使用 Citrix Cloud 中的联合身份验证服务。
Workspace 单点登录技术简介 包含与联合身份验证服务相关的其他信息。
资源安全策略
CompanyA 希望限制由于内部人士威胁导致的数据丢失风险。在不同的应用程序类型中，CompanyA 包含了许多限制，以防止用户复制、下载或打印数据。
作为基准策略，CompanyA 定义了以下内容（能够根据用户和应用程序根据需要放松策略）。
| 类别 | SaaS 应用 | Web 应用程序 | 虚拟应用程序/桌面 |
|---|---|---|---|
| 剪贴板访问 | 已拒绝 | 已拒绝 | 仅限客户端到服务器 |
| 打印 | 已拒绝 | 已拒绝 | 已拒绝 |
| 导航 | 已拒绝 | 已拒绝 | 不适用 |
| 下载 | 已拒绝 | 已拒绝 | 已拒绝 |
| 水印 | 已启用 | 已启用 | 已启用 |
| 键盘记录预防 | 已启用 | 已启用 | 已启用 |
| 截图预防 | 已启用 | 已启用 | 已启用 |
应用程序保护政策技术简报 包含有关键盘记录和屏幕截图防护策略的其他信息。
控制层
Web App Firewall
当用户向 Citrix Workspace 进行身份验证时，他们将访问支持合并和收购策略的自定义身份验证表单。托管在 Citrix Application Delivery Controller 上的身份验证表单是必须保护免受计算机人和攻击的公共网页。为了更好地保护公共 Web 应用程序，CompanyA 使用 Citrix Application Delivery Controller 解决方案的计算机人管理和 Web 应用程序防火墙
第一道防线是计算机人管理。计算机人通过欺诈性请求压倒服务，很容易使公共网络应用程序崩溃或减慢。Application Delivery Controller 的计算机人管理组件能够检测计算机人请求并防止其淹没系统。
第二道防线是 Web App Firewall。使用 Web App Firewall，处理已提交凭据的策略引擎可以免受攻击。这些类型的攻击通常是缓冲区溢出、SQL 注入和跨站脚本。Web App Firewall 检测并拒绝这些攻击影响身份验证策略引擎。
Security Analytics
CompanyA 需要在影响太大之前识别并阻止对环境的内部威胁。
为了帮助保护环境，CompanyA 使用 Citrix Security Analytics 来识别内部威胁、受损的用户和受损的终端节点。在许多情况下，单一威胁实例并不需要采取严厉行动，但是一系列威胁可能表明存在安全漏洞。
CompanyA 制定了以下初始安全策略：
| 名称 | 条件 | 操作 | 原因 |
|---|---|---|---|
| 异常访问 | 从可疑 IP 登录并从异常位置访问 | 锁定用户 | 如果用户从异常位置和可疑 IP 登录，则会有强烈的迹象表明该用户受到威胁。 |
| 异常的应用行为 | 应用程序使用和从异常位置访问的异常时间 | 开始会话录制 | 如果用户在奇怪的时间和地点访问虚拟应用程序，则该用户有可能受到攻击。Security Analytics 记录会话以让管理员验证合法性。 |
| 潜在的凭证漏洞 | 过多的身份验证失败和从异常位置访问 | 添加到播放列表 | 如果用户来自异常位置的许多身份验证失败，则可能表示有人正在尝试进入系统。但是，攻击者尚未成功。只需将用户添加到监视列表中即可。 |
Citrix 用户风险指标文档包含有关提供给 Citrix Security Analytics 的各种风险指标的其他信息。
Citrix 策略和操作页面包含有关 Citrix Security Analytics 可以执行的修复步骤的信息。
来源
为了便于您规划兼并和收购战略，我们希望为您提供可以调整的 源图 。