免费上推特的加速器_推特用什么加速器免费( 二 )

Progressive Insurance ——个人身份信息与个人健康信息，也包括一部分付款信息

Chevron Phillips Chemical ——这是一家知名化工企业，其他的应该不用多谈了

简单一翻，就找到了这么多大公司直接暴露在互联网上的 VPN 。问题确实很严重。那么，有没有可靠的解决办法？
如何保证 VPN 的安全性？零信任Matthew 给出的首个解决方法是“零信任” 。
零信任的基本概念是对所有连接操作进行独立授权，也就是尽可能避免对网络之内的任何内容做出可信假设。
为了轻松实现对生产服务器的零信任登录，他给出了选择对应解决方案的三个理由：
1. 以 OpenSSH 核心完善而来从底层来看，解决方案平台最好是一套拥有良好管理配置的 OpenSSH（即计算机上的 ssh 命令）部署方案。OpenSSH 经过严格测试，是一款相当安全的远程管理解决方案。自 2003 年以来，OpenSSH 从未因默认配置中的漏洞而遭遇未经授权的远程访问。
该网络入口点本身相当于一个基于 Amazon Linux 2 的单功能 EC2 实例，简单的结构意味着其攻击面非常有限。请注意：VPN 设备的一大问题，在于需要匹配专有软件 / 操作系统配置——这类配置正是阻碍自动修复程序的元凶。只要能够对网络入口点以及其他基础设施实现自动修复，就能在这场安全对抗当中占得先机。
2. 不存在网络桥接之前提到过，大多数 VPN 在配置中都会将网络设备（例如笔记本电脑）桥接至互联网上规模更大的服务器网络当中。关于 VPN，Matthew 表示，他个人最接受不了的一点就是它劫持掉了用户的所有网络流量。虽然可以通过配置分出部分流量，但客户以及 NIST 800-53 SC-7(7) 等安全控制条款往往要求采取这种全流量转发的方式。
可以看到，这里的安全控制思路已经远远落后于行业实际情况。在过去，VPN 可能是唯一的流量加密解决方案。审计人员往往认为，如果没有 VPN 的保护，用户可能会通过未经加密的通道发布保密信息。但在另一方面，这也意味着最终用户的普通 Slack 流量也会通过生产 VPC 进行传递。
好在还有更合理的办法。在 OASA（一种可行的解决方案）模式下，用户与服务器之间的连接拥有独立代理。例如，提交“我想加入 EC2 实例 i-028d62efa6f0b36b5”这条请求，会让系统首先跳至网络入口点，而后再次跳转至目标服务器。OASA 还会在单点登录供应商完成身份验证之后，再验证请求发出方是否在受信内部设备上预先注册并获得批准。最后，OASA 发布客户端凭证，在接下来的 10 分钟之内持续保护这些跃点。
这让接入后的活动空间变得非常有限。管理员可以登录至网络入口点，再根据需要将端口转至另一目标——但在建立任何连接时，操作者都需要明确请求，且系统在默认情况下会拒绝一切请求。最重要的是，因为这套体系跟 VPN 没关系，所以不需要通过生产 VPC 来路由一切有必要和没必要的网络流量。
3. 网络访问范围与随机 IP这些网络入口点基于各个 VPC 进行部署（例如某个 VPC 用于生产、某个用于分段、某个用于开发等）。此外，主机保护解决方案会对每个应用程序进行严密监控，记录应用的所有活动并执行流量过滤。如此一来，即使攻击者成功侵入网络入口点位置，其实也没有什么后续空间可以利用。无论如何，这套安全模式都不会因为访问者已经进入 VPC 而允许其随意访问一切受保护资源。
企业端口敲门实际应用场景中，几乎没人会使用端口敲门，但设置起来却非常有趣。简而言之，端口敲门是对各个封闭的网络端口建立命中序列，只有按正确顺序进行操作，才会打开“真实”端口供您的 IP 使用。听起来挺好，但在实际应用中缺乏可行性。
但端口敲门的基本原理给了 Matthew 启发，让他开始考虑如何对这个概念进行迭代，他将这种解决方法称为“企业端口敲门” 。
Matthew 说，想创建一种机制，确保网络入口点与互联网防火墙始终保持隔离，直到有用户发起访问。这种机制必须易于使用、可靠性高，而且能够通过现有身份提供程序执行身份验证。
于是他草拟出这套机制的基础架构，然后把结果提交给工程技术团队。几周之后，方案就被投入生产环境。
这项服务非常简单，可通过 AWS API Gateway 访问 AWS Lambda 函数（无服务器架构），整个使用体验简单可靠。下面来看该机制的基本原理：

用户通过单点登录成功完成身份验证
应用遍历已经配置完成的 AWS 账户，找到带有特定标签的安全组（安全组，即 AWS 中的防火墙规则）
- 上一页
- 1
- 2
- 3
- 下一页