在我们当前的项目中，IT规则禁止从Internet公开访问非PROD的任何内容。必须严格限制对开发和审查环境的访问。也就是说，该项目还包括与云托管API层一起开发的移动应用。
总的来说，使用移动应用保护DEV / REVIEW阶段API的常用方法有哪些？我们提出了以下想法：
每种方法都需要解决多个问题，但是我想在了解任何一种方法之前先了解全局。
答案 0 :(得分：2)
API入口处的IP白名单（最不安全，但最易于使用）
如果您将不是公司办公室专有的IP列入白名单和/或该IP是公司专有的，但由公司中的公共WI-fi使用，则我认为这是最不安全的。
另外，如果您需要将对可能位于公共IP中或不在公共IP中的远程开发人员和测试人员的访问权限列入白名单，则此解决方案将存在风险，因为人们总是在安全性面前放方便，他们可能会要求将IP列入白名单。来自他们想工作的咖啡店，购物中心，女朋友家等等。
因此，除非您在小型办公室中拥有公共WI-fi（供客户使用的那台）的IP地址与主要互联网连接的IP地址不同，否则我将放弃此选项。
通往托管环境的VPN网关，具有相应的DEV /测试设备配置
这种方法似乎是非常明智的做法，只有被授予访问VPN权限的人才能使用其背后隐藏的资源，并且VPN甚至可以用于公共WI-fi。
相互TLS身份验证（最难实现和操作）
尽管难以实现和操作，但它们也遭受证书钉扎可能绕过的问题。
在this article中，关于在移动应用程序中进行固定的情况，我们可以了解实现证书固定的容易程度：
// simplified android example
CertificatePinner certificatePinner = new CertificatePinner.Builder()
.add("publicobject.com", "sha256/afwiKY3RxoMmLkuRW1l7QsPZTJPwDS2pdDROQjXw8ig=")
.add("bikewise.org", "sha256/x9SZw6TwIqfmvrLZ/kz1o0Ossjmn728BnBKpUFqGNVM=")
.build();
OkHttpClient client = OkHttpClient.Builder()
.certificatePinner(certificatePinner)
.build();
在同一篇文章中，我们还可以看到钉扎是一场噩梦……就像您所说的那样，很难操作！！！
固定的主要困难不是技术而是操作。通过将有关服务器（证书）的固定信息嵌入到应用程序中，您将在两者之间创建依赖关系（如固定一词所指）。这意味着每当您（或您的运维团队）计划在服务器上更改证书时，都必须：
- 提前生成证书
- 使用新证书和旧证书来构建，测试和发布该应用程序的新版本。
- 等待大多数（80％，90％，99％？）的用户升级到新版本
- 更改服务器上的证书
- 在删除旧证书的情况下，构建，测试和发布新版本的应用程序。
如果这还不够，可以使用自省框架通过证书固定，就像我上面链接的同一篇文章所指出的那样：
即使您成功解决了实施固定所固有的操作困难，房间中仍然存在巨大的粉红色大象正在固定。诸如Xposed之类的挂钩框架的开发已经达到了如此复杂的程度，以至于存在着丰富的模块生态系统，可针对Android应用程序的各个方面，包括HTTP库的固定功能。使用它们非常简单。
也就是说，该项目还包括与云托管API层一起开发的移动应用程序。
在移动应用程序的上下文中，您可以使用一种设计为“移动应用程序证明”的技术，该技术可以在所有环境中使用，以保护该移动应用程序的API服务器，使其免受非正版请求的响应您为该特定环境发布，签名和注册的移动应用二进制文件。
移动应用程序证明服务的作用是在运行时保证您的移动应用程序未受到篡改或未在有根设备中运行。它包含一个集成在您的移动应用程序中的SDK，该SDK在后台运行，而不会影响用户体验，并且与在云中运行的服务进行通信以证明移动应用程序和设备在运行的完整性。
在成功证明移动应用程序完整性之后，将发布并使用一个秘密的短期生存JWT令牌进行签名，该秘密只有云中的API服务器和移动应用程序证明服务可以识别。如果移动应用程序证明失败，则会使用API服务器不知道的秘密对JWT令牌进行签名。
移动应用必须在请求的标头中发送JWT令牌，以进行API调用。这样一来，API服务器仅在可以验证JWT令牌中的签名和到期时间时才处理请求，而在验证失败时拒绝请求。
任何试图在运行时验证由Mobile App Attestation发行的JWT令牌有效还是无效的人都不会成功，因为它们之间的唯一区别是用于对其进行签名的秘密，并且该秘密仅移动应用证明服务和API服务器随时都可以知道。这意味着即使移动应用也不拥有该机密，因此也不知道是否正在向API服务器发送有效或无效的JWT令牌。
从您的3种解决方案中，我将采用VPN方法，如果您想加倍努力，则应考虑实施自己的移动应用证明服务，以确保适用于任何环境的移动API仅与该特定环境的移动应用进行通信环境/阶段，并拒绝任何其他来源的请求。此解决方案甚至允许将您的移动API托管在公共域上，而不会冒任何数据泄漏的风险，因此不需要在其前面使用VPN。