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