Twingate:新的Linux客户端&为开发人员设计远程访问

2020-08-20 02:41:26

我们很高兴地宣布我们针对Linux的Twingate客户端应用程序发布了!在此版本中,Twingate现在支持所有主要的桌面和移动操作系统,包括Android、iOS、MacOS和Windows。

我们对此特别兴奋,因为它与我们开始构建Twingate时脑海中的用户群(开发人员)相关。

我们想分享一下我们为开发人员设计安全、远程访问的想法。虽然公司已经趋向于为每个人提供远程工作-新冠肺炎疫情加速了这一趋势-但远程访问对于工程组织来说并不新鲜。我们关注开发人员有几个原因:

他们是组织中经常最依赖远程访问来执行其工作的群体。

随着越来越多的开发人员工作负载转移到云上,开发人员基本上总是远程工作,并且经常有跨多个云平台的复杂访问需求。

我们自己也是开发人员,希望以后再也不用和VPN争吵了!

在设计Twingate时,我们采访了50多名IT、安全和网络专业人员,以了解远程访问的现有痛苦。虽然我们采访的每个人都认为远程访问体验是失败的,但我们一直听说开发人员的体验特别痛苦。与通常主要与面向公众的SaaS应用程序交互的非开发人员不同,开发人员访问的大多数资源都在封闭的专用网络后面受到保护。这是有充分理由的:这些资源是公司中最敏感的资产之一。数据库、服务器、生产网络等都需要更高级别的保护。然而,挑战在于提供对这些资源的安全远程访问的现有VPN+基于边界的模型已被打破,正如我们在之前的帖子中所述。

终端用户体验差,连接速度慢,客户端不可靠VPN主要设置为“全通道”,这意味着当VPN打开时,来自您设备的所有流量都通过中央VPN网关进行路由。当您的VPN强制视频会议等高带宽应用程序(如Zoom、Google Meet)通过VPN隧道连接到您的中心网络时,这尤其有问题,从而增加了不必要的延迟和网络拥塞。某些VPN客户端可以设置为“拆分隧道”流量,但是设置起来过于复杂。此外,VPN客户端通常是不可靠的,当你移动WiFi网络,合上笔记本电脑盖等时,经常会断开连接。这就像是被千刀割伤致死一样。

由于网络重组要求,设置和维护起来很复杂设置远程访问很复杂,因为它需要您重组网络以启用远程访问:创建非军事区、专用子网、路由规则、防火墙设置等。许多开发人员花费数小时或数天的时间为VPN的正常工作争论不休,解析设置说明可能是单调乏味、容易出错和耗时的。此外,如果网络发生变化,或者需要添加新的私有网络或网段,则需要重新添加。对于即使只有一小部分开发人员的组织来说,这也会成为一个很大的负担。

考虑到这种复杂性,很难实现现代安全实践由于所有这些摩擦,要实现重要的安全实践(如正确的网络和资源分段、最低特权的用户访问权限以及开发人员资源的SSO/MFA策略)是极具挑战性的。大多数开发团队最终过度提供访问权限,因此用户拥有比实际需要更广泛的访问权限,并且必须管理多个持有凭据、密钥等的系统。这对入职和下岗用户来说尤其具有挑战性,许多公司最终花费了大量时间来为用户提供帐户和设置设备。

当我们设计Twingate时,我们的使命是为用户创建“只需工作”的现代远程访问解决方案,降低IT/DevOps的管理开销,并显著升级您的开箱即用安全状态。我们的主要产品目标之一是设计在15分钟或更短的时间内设置Twingate,我们还设计了丰富的功能集来解决开发人员的特定痛点。

Twingate在您现有的网络上作为“远程访问”覆盖层运行,它授权每个连接请求并将其直接路由到正确的目的地。这意味着Twingate不需要更改您的网络基础设施,不需要更改您的应用程序和服务,也不需要更改您的设备即可启动和运行。只需将我们的网络连接器添加到任意数量的网段(本地、云、多云,不要紧!),按目的地地址定义用户访问权限,然后安装Twingate客户端应用程序即可访问。没有复杂的防火墙规则、路由规则更改或复杂的代理设置。

此外,与其他“网状”专用网络产品不同,我们不需要您将每个目的地资源重新映射到新的IP地址。用户使用他们一直使用的现有目的地地址连接到他们的资源,Twingate在后台执行所有繁重的任务,以便将流量适当地路由到正确的目的地。

我们投资了许多专门为消除开发人员工作流程的摩擦而设计的功能:

始终在线的智能路由,可自动隔离流量我们的客户端应用程序旨在以最小的延迟将流量自动路由到正确的目的地。发往私有资源的授权连接被直接路由到目的地网络,未经授权的访问尝试甚至从未离开设备,并且公共互联网流量通过设备的默认路由退出,以最大限度地减少对用户的任何性能影响。我们的客户端是轻量级的,CPU和内存占用极少,我们花了多年的研发和现场测试我们的客户端技术,几乎涵盖了每种类型的网络环境,以确保高性能。

协议不可知,因此每项服务都开箱即用有了Twingate,每项服务都可以开箱即用。RDP、SSH和(当然)HTTPS都可以工作,而不需要对设备或目标服务进行任何配置更改。不需要代理设置、SAML配置或PAM模块配置。无论应用程序是什么,Twingate都会智能地将任何授权连接转发到正确的目的地。即使是私有DNS名称也可以正确解析,而无需更改本地设备DNS设置!

部署自动化以集成到现有的CI/CD流水线中我们知道,现代开发团队将所有事情自动化(或至少尝试这样做),Twingate被设计为与“基础设施即代码”过程无缝集成。Twingate可以通过我们的API完全管理,该API允许在服务和资源上下旋转时应用访问策略。我们的网络连接器也是完全集装式的,可以集成到Terraform模板和头盔图表中。

将SSO&;MFA检查扩展到任何任意服务Twingate将身份验证委托给您现有的身份提供者,并根据定义的访问策略为每个连接提供额外的授权层。由于Twingate作为IDP策略的网络授权扩展运行,因此允许您设置绑定到中央IDP的基于身份的访问策略,而无需对最终资源进行任何修改。这对于数据库、服务器和集群这样的资源特别有用,这些资源不能很好地处理您的IdP,或者在某些情况下根本不提供用户身份验证接口。Twingate可以使您的IDP充分发挥中心服务的作用,该服务可用于轻松地让开发人员入职/下岗,并减少管理多个身份验证系统以访问开发人员资源的开销。

没有麻烦的“零信任”安全最后,Twingate提供了实现“零信任”安全姿态的最简单途径。最低权限访问策略可以根据角色和组的资源进行狭义定义,用户永远不会“加入网络”,从而防止潜在攻击者的横向移动,并且缺少公共VPN网关消除了攻击的主要入口点。详细的分析还提供对访问模式的新可见性,以确定潜在的安全问题。Twingate旨在恢复安全性和可用性之间的平衡,并与传统的基于VPN的远程访问方法相比,提供严格改进的安全状态。

作为开发人员,我们知道保护远程访问的痛苦。我们之所以要解决这个问题,是因为市场上的每一种解决方案都在安全性和可用性之间进行了权衡。我们认为这是一个错误的选择,因为安全实践和产品只有在用户接受的情况下才有效!

如果您是正在考虑部署VPN或已经在使用VPN的开发人员,我们希望您尝试一下Twingate,亲身体验一下。在这里免费注册。