资讯中心

  • 首页 i(name 发烧:为企业访问构建一个无VPN的安全网络 网络与内容交付

发烧:为企业访问构建一个无VPN的安全网络 网络与内容交付

2026-01-27 13:21:41

Fever 建立无需 VPN 的安全企业网络

重点摘要

Fever 是全球领先的现场娱乐发现平台,自 2014 年以来帮助数百万用户发现城市中的最佳体验。为了支持远程办公团队,Fever 需要一个安全的、无 VPN 的接入解决方案,最终选择了 AWS Verified Access。此解决方案简化了用户管理,并提高了访问速度和安全性。

Fever 是全球领先的现场娱乐发现平台,自2014年以来一直在帮助数百万用户发现所在城市的最佳体验。其使命是通过平台使人们能够民主化地接触文化和娱乐,从沉浸式展览、互动戏剧到分子鸡尾酒快闪活动,让用户享受独特的本地体验,并利用数据和技术赋能创作者,以便在全球范围内创建和扩展这些体验。

在 Fever,我们每天使用不同的跨职能工具和服务。这些服务必须保持私密性,但必须可供我们在远程工作的企业团队全球访问。

quickq加速器下载

我们最初使用基于 OpenVPN 软件的自定义虚拟私人网络VPN解决方案来满足这一需求。然而,随着公司的扩展,用户证书的管理变得复杂且耗时。因此,我们决定寻找一个可扩展、安全且易于维护的解决方案,以便为我们的用户提供访问。这一解决方案还应与我们现有的单点登录体验兼容,该体验通过与 Google Workspace 集成的 AWS IAM 身份中心 实现。

我们发现 AWS Verified Access 满足所有要求。Verified Access 提供无 VPN 的安全企业应用接入,减少远程连接的风险。该服务基于 AWS 零信任原则构建,仅在用户及其设备符合指定的安全要求时才能访问应用。我们在少量用户中进行了测试,取得了成功经验后,决定在生产环境中推广该解决方案,以支持更广泛的应用。部署成功后,这些应用实现了安全的单点登录集成。

在这篇文章中,我们将详细介绍在采用 Verified Access 过程中的各个步骤及其对 Fever 的价值。

证书及用户管理

我们已经使用 OpenVPN 多年,拥有两台 OpenVPN 服务器,一台为大部分用户访问内部工具提供服务,另一台用于特殊情况,以便允许第三方服务连接一些需要白名单的公共 IP 地址。下图图 1展示了这一架构。

图 1 AWS 上的传统 OpenVPN 架构

这个解决方案在少量用户中运作良好,但随着我们的业务发展,遇到了以下问题:

越来越多的用户需要签发证书。我们需要逐个撤销不再需要访问这些内部应用的用户的证书。这些用户未与单点登录同步。服务器和客户端都需要更新和安全补丁,有时导致意外停机。由于所有连接均由一台 亚马逊弹性计算云Amazon EC2 实例处理,因此没有高可用性。

所有这些任务都耗时且分散了我们的精力,让我们无法专注于更重要的业务活动。我们为每位用户签发和撤销证书,协助解决连接问题,并排查不同操作系统上的客户端配置问题。此外,操作系统的强制性更新,如将这些服务器升级到新版本,必须在低活动的时段内进行。由于我们的用户基础遍及全球,这一过程十分困难,VPN 必须保持在线状态。

转向 AWS Verified Access

为了评估采用 Verified Access 的可行性,我们选择了一个开发环境中的小型应用进行测试。该应用具有无访问控制的用户界面任何人均可执行任何操作,并以内部 应用负载均衡器 作为入口如图 2 所示。唯一活跃的权限范围是 OpenVPN 服务器,允许拥有有效 VPN 证书的任何人访问。此外,此应用不支持任何类型的单点登录访问。

图 2 用于测试 AWS Verified Access 的应用传统 OpenVPN 架构

首先,我们在身份提供者IdP上创建了一个新客户端,实施 OAuth 20 的凭据授权类型。此客户端由客户端 ID 和密钥标识。接下来,在 Verified Access 信任提供程序 中,我们创建了一个新的 OpenID ConnectOIDC提供者。信任提供者维护和管理与请求一起发送的用户和设备身份信息,Verified Access 在允许或拒绝请求之前会对这些信息进行评估。这些信息被称为信任上下文。它可以包括基于用户身份的属性,如电子邮件地址或销售组织的成员资格,或设备信息,如已安装的安全补丁或杀毒软件版本。

创建信任提供者时需要提供的信息取决于您的 OIDC 提供者。在我们的案例中,所有相关字段均按 Google Workspace API 和我们之前创建的客户端 ID 和密钥填写完毕。

之后,我们为新创建的 Verified Access 信任提供者创建了 Verified Access 实例。接着,我们创建了一个 Verified Access 组 用于测试。一个组是一组 Verified Access 端点 和一个组级策略。端点是一个区域性资源,指定 Verified Access 将提供访问的应用。

Verified Access 策略 允许您为托管在 亚马逊网络服务AWS 中的应用定义访问规则。它们使用 Cedar,这是 AWS 开发的开源策略语言。我们创建了以下策略:

permit(principal action resource)when { [ exampleemail@examplecom ]contains(contextGoogleSSOemail) ampamp contextGoogleSSOemailverified == true}

该策略测试了两个条件:

电子邮件必须在组织内验证。电子邮件必须匹配 exampleemail@examplecom。

然后,我们将用户组附加到先前的 Verified Access 实例上。

最后一个需要配置的部分是 Verified Access 端点。每个端点与一个 Verified Access 组关联,并继承该组的访问策略。该端点必须是公共的,因此我们使用开放的安全组配置端口 443。这里有几个需要注意的字段:

发烧:为企业访问构建一个无VPN的安全网络 网络与内容交付Verified Access 实例 ID 使用之前创建的实例。Verified Access 组 ID 使用附加策略的组。附加类型 VPC。端点类型 负载均衡器。我们将使用图 2 中的应用程序负载均衡器作为应用的入口。安全组 ID 我们允许通过 TCP 443HTTPS端口访问的安全组。应用域名 这一点很重要,因为我们将为内部用户使用一个友好的域名。对于这篇文章,我们将使用 testappexamplecom。域名证书 ARN 用于 testappexamplecom 的 AWS 证书管理器ACM 证书的亚马逊资源名称ARN。

下图图 3总结了新架构:

图 3 使用 AWS Verified Access 访问应用程序

成果

在使用 OpenVPN 解决方案时,每当我们收到有关添加新 VPN 用户的请求时,我们需要收集用户信息、签发证书、更新 OpenVPN 服务器证书存储并与用户测试连接。我们还需要解决用户侧的本地客户端或操作系统配置错误问题。

整个过程耗时为每个用户从 15 分钟到 1 小时不等。在采用 AWS Verified Access 后,我们将这一时间降低到 5 分钟,以用于现有应用。实际上,我们可以在几分钟内将大组用户甚至整个公司进行接入允许组织中任何经过身份验证的用户访问应用。

用户还反馈称,访问我们内部工具的速度更快。这是因为我们过去使用的是运行 OpenVPN 的单一 EC2 实例,现在在使用 Verified Access 后,我们为每个应用配备了自动扩展的专用负载均衡器。

此外,我们还取消了 OpenVPN 服务器所需的所有操作系统打补丁、升级和维护,因为 Verified Access 是一项完全托管的服务,使我们免于承担所有这些无差异的操作任务。

下一步

我们将记录每个 AWS Verified Access 端点上的所有活动,以便能够根据我们的内部政策执行安全审计。我们将开始将日志传送到 亚马逊简单存储服务Amazon S3,随后使用 亚马逊 Athena 提交查询,正如我们在 AWS CloudTrail 等其他领域所做的,以分析用户活动和 API 使用情况。

我们的安全团队想了解各个端点上谁正在访问资源,以及在这些活动上所花费的时间。Verified Access 日志 提供了所有请求的信息和更多内容。这些日志将与现有的 Google Workspace 访问日志汇总,以全面了解操作情况。

此外,由于端点面向公众,我们还将将 AWS WAF 集成到我们的 Verified Access 实例中,以减少攻击面。我们正在使用 Athena 分析所有 AWS WAF 日志,并且已经为常见攻击模式开发了自定义查询。借助这些日志,我们可以识别我们的端点是否受到外部攻击者或机器人的攻击。

总结

在 Fever,AWS Verified Access 简化了我们如何公开和管理企业应用中的权限。该服务允许我们在几分钟内为每个部署的应用提供组织范围内的安全访问,同时在需要时仍能创建更为细致的授权规则。

关于作者

Gabriel Rodrguez (嘉宾)

Gabriel Rodrguez 是 Fever 的高级解决方案架构师,拥有超过 10 年的云解决方案设计和实施经验,为各类规模和行业的公司提供服务。他的职业生涯始于开发者,后来转向 DevOps/SRE 角色,最终深入了解云计算及其在推动创新和数字化转型中的潜力。他曾帮助多家公司改善其云基础设施并优化运营,通过使用亚马逊网络服务和 DevSecOps 最佳实践,他领导了多个复杂的云迁移项目并推动了不同公司的数字化转型工作。

Jess Bernal

Jess Bernal 是亚马逊网络服务的高级解决方案架构师,现居马德里,负责帮助初创企业实现其商业目标。与客户一起构建安全、高可用且可扩展的解决方案,同时保持最短的市场发布时间。工作之外,他曾是一位热心的足球爱好者,总是会观看每一场比赛,但现在他将时间和精力投入到陪伴两个女儿的日常冒险中。

Pablo Snchez Carmona

Pablo 是 AWS 的高级网络专家解决方案架构师,帮助客户设计安全、具韧性且具成本效益的网络。在谈论网络之外,Pablo 常常出现在篮球场上或玩视频游戏。他拥有瑞典皇家技术学院 (KTH) 的电气工程硕士学位以及加泰罗尼亚理工大学 (UPC) 的电信工程硕士学位。