英文:
Secure requests between different apps
问题
假设在App Engine上有两个不同的应用程序,一个由Go驱动,另一个由PHP驱动。
它们各自需要能够在后端网络上进行特定请求(即这些是唯一需要进行这些特定请求的服务-其他远程请求应该被阻止)。
那么,最佳实践是什么?我首先想到了3种可能的解决方案,以及我对它们的一些担忧:
1)不将它们作为单独的应用程序,而是作为模块
这种方法的问题在于使用模块会引入其他一些麻烦,比如在通道存在报告方面的困难。此外,从概念上讲,这两个请求实际上是它们唯一接触的地方,如果它们被分开,就可以更清楚地看到数据库使用等方面的情况。但是通道存在问题可能会成为一个阻碍。
2)在请求中附加一些硬编码的长秘钥,并且只允许通过SSL进行响应
依赖这种方法似乎有点奇怪,因为秘钥永远不会改变...从理论上讲,唯一可能知道它的方式是如果账户上的管理员或者源代码的某人泄露了它...但是我不知道,这种方法似乎有点奇怪。
3)只允许特定IP范围的请求(可能与#2结合使用)
这种方法似乎有些靠不住,IP范围能否确定?
4)发布/订阅
App Engine似乎允许发布/订阅机制,但这并不符合我的用例,因为我希望立即获得响应,而不是在订阅者处理后通过回调获得响应。
所有方法
-- 另外一点,假设这是一种https请求,那么每种语言是否都使用Socket API来实现?
英文:
Assume there are two different apps on appengine- one powered by Go and another by PHP
They each need to be able to make specific requests to eachother, purely over the backend network (i.e. these are the only services that need to make these specific requests- other remote requests should be blocked).
What is the best-practices way of doing this? Off the top of my head, here are 3 possible solutions and why I am a bit worried about them
1) Do not keep them as separate apps, but rather modules
The problem with this is that using modules introduces some other annoyances- such as difficulties with Channel Presence reporting. Also, conceptually, these 2 requests are really the only places they touch and it will be clearer to see what's going on in terms of database usage etc. if they are separated. But the presence issue is more of a show-stopper
2) Append the request with some hardcoded long secret key and only allow response if via SSL
It seems a bit strange to rely on this, since the key would never change... theoretically the only way it could be known is if an administrator on the account or someone with the source revealed it... but I don't know, just seems strange
3) Only allow via certain IP ranges (maybe combined with #2)
This just seems iffy, can the IP ranges be definitively known?
4) Pub/Sub
So it seems AppEngine allows a pub/sub mechanism- but that doesn't really fit my use case since I want to get the response right away - not via a postback once the subscriber processes it
All of them
-- As a side point, assuming it is some sort of https request, is this done using the Socket API for each language?
答案1
得分: 2
HTTPS在一般情况下当然是一个很好的想法(不仅仅适用于两个GAE应用之间的通信)。
但是,对于特定的用例,我建议依赖于X-Appengine-Inbound-Appid
请求头:App Engine的基础设施确保该请求头不能在不是来自GAE应用的请求上设置,并且对于来自GAE应用的请求(通过不遵循重定向的url-fetch),该请求头被设置为应用程序ID。
这在Go的文档中有说明,网址是https://cloud.google.com/appengine/docs/go/urlfetch/,在PHP的文档中也有说明,网址是https://cloud.google.com/appengine/docs/php/urlfetch/(顺便说一下,Java和Python也是一样的)。
英文:
HTTPS is of course an excellent idea in general (not just for communication between two GAE apps).
But, for the specific use case, I would recommend relying on the X-Appengine-Inbound-Appid
request header: App Engine's infrastructure ensures that this cannot be set on requests not coming from GAE apps, and, for requests that do come from GAE apps (via a url-fetch that doesn't follow redirects), the header is set to the app-id.
This is documented for Go at https://cloud.google.com/appengine/docs/go/urlfetch/ , for PHP at https://cloud.google.com/appengine/docs/php/urlfetch/ (and it's just the same for Java and Python, by the way).
答案2
得分: 1
这些要求在应用引擎基础设施中很难或几乎不可能实现,因为您无法控制物理网络路由。根据应用引擎的常见问题解答:
应用引擎目前没有提供将静态 IP 地址映射到应用程序的方法。为了优化终端用户与应用引擎应用程序之间的网络路径,不同的互联网服务提供商或地理位置的终端用户可能会使用不同的 IP 地址访问同一个应用引擎应用程序。
因此,始终假设您的通信是通过开放网络进行的,并且不要对 IP 地址做任何假设。
将请求附加上一些硬编码的长秘钥
硬编码的长秘钥并不提供额外的安全性,只是混淆安全性。
只允许通过 SSL 进行响应
这是一个更好的想法;使用强大的算法对所有内部流量进行加密。例如,如果可用的话,可以使用ECDHE-RSA或ECDHE-ECDSA。
英文:
> * purely over the backend network
> * Only allow via certain IP ranges
These requirement are difficult to impossible to fulfill with app engine infrastructure because you're not in control of the physical network routes. From the app engine FAQ:
> App Engine does not currently provide a way to map static IP addresses to an application. In order to optimize the network path between an end user and an App Engine application, end users on different ISPs or geographic locations might use different IP addresses to access the same App Engine application.
Therefore always assume your communication happens over the open network and never assume anything about IPs.
> Append the request with some hardcoded long secret key
The hard coded long secret does not provide any added security, only obscurity.
> only allow response if via SSL
This is a better idea; encrypt all of your internal traffic with a strong algorithm. For example, ECDHE-RSA or ECDHE-ECDSA if available.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论