Home > Cloud Computing, Cloud Security, Google > Google’s Updated App Engine – “Secure” Data Connector: Your Firewall Means Nothing (Again)

Google’s Updated App Engine – “Secure” Data Connector: Your Firewall Means Nothing (Again)

This will be a quickie.  

This is such a juicy topic and really merits a ton more than just a mention, but unfortunately, I’m out of time.

Google’s latest updates to the Google App Engine Platform has all sorts of interesting  functionality:

  • Access to firewalled data: grant policy-controlled access to your data behind the firewall.
  • Cron support: schedule tasks like report generation or DB clean-up at an interval of your choosing.
  • Database import: move GBs of data easily into your App Engine app. Matching export capabilities are coming soon, hopefully within a month.

To me, the most interesting is the boldfaced item above…Google Apps access to information behind corporate firewalls*

From a Cloud interoperability and integration perspective, this is fantastic.  From a security perspective, I am as intrigued and concerned as I am about anytime I hear “access internal data from an external service.”

The capability to gain access to internal data is provided by the Secure Data Connector.  You can find reasonably detailed information about it here.

Here’s how it works:

SDC forms an encrypted connection between your data and Google Apps. SDC lets you control who in your domain can access which resources using Google Apps.

SDC works with Google Apps to provide data connectivity and enable IT administrators to control the data and services that are accessible in Google Apps. With SDC, you can build private gadgets, spreadsheets, and applications that interact with your existing corporate systems.

The following illustration shows SDC connection components.

Secure Data Connector Components

The steps are:

  1. Google Apps forwards authorized data requests from users who are within the Google Apps domain to the Google tunnel protocol servers.
  2. The tunnel servers validate that a user is authorized to make the request to the specified resource. Google tunnel servers are connected by an encrypted tunnel to SDC, which runs within a company’s internal network.
  3. The tunnel protocol allows SDC to connect to a Google tunnel server, authenticate, and encrypt the data that flows across the Internet.
  4. SDC uses resource rules to validate if a user is authorized to make a request to a specified resource.
  5. An optional intranet firewall can be used to provide extra network security.
  6. SDC performs a network request to the specified resource or services.
  7. The service verifies the signed requests and if the user is authorized, returns the data.

From a security perspective, access control and confidentiality are provided by filters, resource rules, and SSL/TLS encrypted tunnels.  We’ll take this apart in detail (as time permits) later.

In the mean time, here’s a link to the SDC Security guide for developers.

…and no, you’re firewall likely won’t help save you (again.) 

At least I won’t be bored now.


* The database import/export is profound also. Craig Balding followed up with his OAuth-focused commentary here.

Categories: Cloud Computing, Cloud Security, Google Tags:
  1. April 8th, 2009 at 08:45 | #1

    Don't need no stinkin' networking or security guys in this! Just build it and gogogo!

  2. TheRealJobe
    April 9th, 2009 at 04:28 | #2

    I feel like we might be pounding the panic button.

    An attacker would have to present a valid Google app engine and get past the policy control, which is mentioned in the bullet, if they wanted to attack head on.

    I suppose they could try to play man-in-the-middle…. but, I don’t see how a man-in-the-middle here would be any less secure than other applications, that already have access to back-end data, corporations tunnel across the net…

    I think more realistically all this means is that when you fire up Google mail and it asks if you would like to import any contacts from your corporate Outlook, that when you hit yes, (policy based control,) it will import selected contacts for you.

    My real concern would be assuring the integrity of the policy controls.

  3. April 10th, 2009 at 05:25 | #3


    To be fair, there's no sense of "panic" in my post.

    However, I'm less interested in the direct "attack" vectors and more interested in the thing you allude to in your last sentence: "My real concern would be assuring the integrity of the policy controls."

    We've already seen control failures with Google Docs. In the case of SDC it allows DEVELOPERS to directly expose my internal data/databases to an external service through the firewall. This isn't particularly new in concept, but the implementation is…as is the target.

    Again, this isn't a "PANIC!" post — never was. Just raising visibility.


  1. April 9th, 2009 at 08:43 | #1
  2. April 9th, 2009 at 13:43 | #2
  3. August 26th, 2009 at 00:57 | #3