情况
我们在 Amazon EC2 上托管了一个 Web 应用程序。它仅供公司中的少数用户使用。
我们如何应对
- 我们与用户共享实例的（弹性）IP 地址。
- 我们会根据需要将每个用户的 IP 地址添加到实例的安全组。
当我说当需要时，我的意思是用户发来的电子邮件，抱怨 Web 门户显示错误页面。他们忘记了将 IP 纳入安全组这一步是必需的（我不怪他们；他们是最终用户）。
为了回答这个问题，我们假设公司里总共有 5 个用户需要此访问权限。User-1 和 User-2 的 IP 地址已添加到安全组中。
问题
- 用户 3 直接访问该 IP 地址，但无法访问，因为该用户的 IP 地址尚未添加到安全组。
- 如果用户 1 或用户 2 重新启动互联网，他们的 IP 地址可能会发生变化（ISP 提供的动态 IP），并且必须将新的 IP 地址添加到安全组（并且必须撤销旧 IP 地址以避免其他人访问）。
我正在考虑的其他选择
- 仅提供对其办公室 VPN 的访问权限并要求所有用户通过它进行连接。
- （对用户来说非常麻烦）要求用户登录 AWS 管理控制台，转到 EC2 服务，转到安全组部分并手动添加他们的 IP 地址（用户已经拥有 AWS IAM 用户和执行此操作的适当权限）。
- 创建一个脚本，将用户的当前 IP 添加到安全组（使用 AWS CLI / SDK） - 听起来非常危险且不合适，因为我们必须在脚本中包含某人的 API 凭证。
答案1
选项 4 - 停止通过安全组控制访问，而是实施一些合适的身份验证机制。
例如应用程序负载均衡器在 Web 应用程序前面，并配置 ALB 以要求Cognito 身份验证。只有经过身份验证的用户才能通过 ALB 进入您的 Web 应用程序 - 问题解决了。Cognito 可以拥有本地用户，也可以与您的 Azure AD 一起使用，或者如果您在组织中使用 Office365。这是一种非常透明的方式，不需要对应用程序进行任何更改。
或者，如果您的 Web 应用程序支持它，您应该将其配置为要求对您的组织正在使用的任何用户目录（Office365、G-Suite 等）进行 SAML 身份验证。
希望有帮助:)
答案2
选项 5 - 停止管理安全组（本质上是基于 IP 的防火墙）并使用 TLS 客户端证书。
如果您使用的是 Azure AD 或 LDAP 等现代用户管理系统，那么您已经拥有了颁发和分发证书的正确工具。您将设置一个私有 CA 并配置 HTTP 服务器（Nginx、Apache2 或 AWS ALB）以通过证书进行身份验证。没有证书或证书无效（包括过期证书）的人将无法通过 HTTP 服务器。这需要零更改为 Web 应用程序本身，您甚至可以放弃应用程序中的任何身份验证，因为除了访问控制之外，证书还可以用于该目的。
一个加分点是，这是有效的到处- 无论是 AWS、Azure 还是您的本地基础设施。您甚至可以重复使用完全相同的凭证和配置堆栈（AWS ALB 除外）。