Google Secure Data Connector (SDC) helps form an encrypted connection between your data and Google Apps.
This section describes the details of the Google Apps security package provided with SDC.
- Use Cases
- SDC Initialization
- SDC Tunnel
- Resource Rules
- Filtering Requests by User
- Authentication Requests
- Security Analysis
- Frequently Asked Security Questions
SDC helps let you set rules for what resources your users can access using Google Apps. These rules are uploaded to Google Apps and enforced there, so that specified users in your domain can access resources behind the company's firewall.
Previously, a major barrier to cloud computing was the inability to integrate with existing resources inside a company's firewall. With SDC, administrators can enable connectivity between an enterprise network and the hosted services in Google Apps.
SDC works with Google Apps to provide data connectivity and helps IT administrators control what data and services are accessible in Google Apps--and who can use them. After you download and install SDC, you can activate SDC from the Google Apps Domain control panel. The password you specify when you activate SDC goes in the configuration file that you use to connect your domain's SDC agent to Google Apps.
For more information on Google Apps security, see the Google Apps Security white paper (PDF).
This section discusses best practice setups for enabling the SDC on your internal network
Use Case 1: Accessing resources in a public intranet
For SDC, the use of "public intranet" refers to internal network services that do not require authentication. Depending on your security policies, this may be most of your network or a fraction of it. You can easily allow SDC to access these resources by creating resource rules that specify the internal URLs of these services and the applications that can access those URLs. For sensitive data, you should specify which specific applications can access that data. If you do not do restrict the applications that can access sensitive data, then it is possible that one of your users could install a malicious gadget that forwards information outside of your Google Apps domain.
Use Case 2: Accessing resources protected by an internal authentication system
In this case, the recommended approach is to use OAuth Signed Fetch. For Signed Fetch, Google identifies the user who requests data and the ID of the application, gadget, or spreadsheet that requests on behalf of the user. For information on decoding signed requests and sample code, see the OpenSocial guide for Validating Signed Requests.
If you build an application in Google App Engine, you may also implement your own non-OAuth based method for authentication. In gadgets, the only method to achieve secure authentication is with OAuth signed fetch.
A system administrator enables SDC for the domain in the Google Apps control panel. The administrator specifies a password that authenticates SDC to Google.
The administrator then downloads SDC from the open source SDC project, and installs SDC on a corporate server.
SDC software downloads are available at http://code.google.com/securedataconnector/download.html
To configure SDC, an administrator specifies the following:
- Connection parameters:
- Google Apps domain to which the administrator belongs.
- Password that you used to activate SDC in the Google Apps control panel.
- Resource rules allow specific resources inside the company's network to share data with Google Apps. To grant maximum access control, administrators can adjust the rules with a great degree of granularity, similar to how firewall rules are defined. When SDC connects to the Google tunnel servers, SDC copies and stores the resource rules for use by Google Apps. If the rules change, SDC is restarted.
The SDC tunnel protocol connects SDC and Google Apps. The tunnel is established through the following mechanism, based on open standard protocols:
- SDC starts up, connects to the Google tunnel servers, undergoes an SSL/TLS handshake that authenticates the server through standard X.509 certificates, and establishes a TLS encrypted tunnel if everything succeeds.
- Through the TLS connection, SDC sends a request to Google for authentication. The user name and password are verified by Google, and Google checks that the domain is authorized to use SDC.
- SDC sends the resource rules that have been established by the system administrator, and these are saved at Google.
- After registration, a TCP port forwarder is created to allow traffic to traverse the TLS connection from Google to the SOCKS 5 server running on the SDC agent. SDC uses SSH for multiplexing purposes, not for authentication or encryption - these are the responsibility of the outer TLS layer. SOCKS allows requests from Google Apps to appear inside the firewall as native TCP connections originating from SDC, which is inside the IP and DNS context of the corporate network.
SDC uses resource rules to determine which resources users can access. Resource rules operate on a deny-all default. Resource requests that do not conform to any of the allowed set of resource rules are routed over the regular internet.
Requests from Google Apps that match one of the resource rules, follow the SOCKS protocol to make a request to SDC. SDC then transforms requests so that they are initiated from inside the domain of the enterprise. Consequently, DNS resolves work within the environment of the corporate network, so that internal names or private addresses can be used in the requests without problems.
Resource rules are checked against an incoming request before the request enters the tunnel. Google servers check the requested resource against the resource rules, and block the request if it does not conform to them.
If SDC can satisfy these two access control points, the SDC agent can return the requested data to the user.
The following example rule grants access to an internal web service:
<resourceRules> <rule repeatable="true"> <ruleNum>1</ruleNum> <agentId>sdc42-agent</agentId> <viewerEmail>email@example.com</viewerEmail> <url>http://corp.example.com/unitteststatus.php</url> <urlMatch>URLEXACT</urlMatch> <apps> <service>AppEngine</service> <appId>hellosdc</appId> </apps> </rule> </resourceRules>
This rule allows access to the intranet web service
Google Accounts user
firstname.lastname@example.org. If no other rules exist,
access to other internal URLs or for other users, are rejected.
http://hellosdc.appsspot.comcan make requests to the web service. Finally the
URLEXACTtag will match the specified URL with query parameters. For example, a request to
http://corp.example.com/unitteststatus.php?q=test7would match this rule.
Filtering Requests By User
The following table shows how each Google Apps application differs in its security profile for how to it decides to make requests over SDC.
|Access to SDC
On Behalf Of
|Google Sites Gadgets||Viewer of the gadget||Domain of viewer||No||gadgets.io.makeRequest()|
|Google App Engine||Viewer of the application||Domain of viewer||No||
urlfetch.fetch() function and
|Google Docs Spreadsheets||User who issues the
||Domain of user who issues the
||Yes||importData(), importXML(), importHtml(), importFeed()|
Important: Because gadgets can contain code written by third parties it is important to use resource rules to control exactly which gadgets should be able to access your corporate data.
SDC enables data sources inside an enterprise to perform authentication for incoming requests before serving back data.
For use with SDC, Google Gadgets perform authenticated requests that follow the OpenSocial specification and use OAuth signatures. You can create an end point inside the enterprise, which is compatible with the OAuth specification. The end point authenticates requests using a previously agreed key and only returns information for users who are authorized to perform requests.
Google Spreadsheets and App Engine do not currently perform a SignedFetch authenticated request. These features are being actively worked on.
The sections that follow provide information about how Google protects data from external and internal attacks.
Enhanced Protection Against External Attacks
Google helps provides security that protects data transmissions against external attacks as follows:
- Connections from SDC to Google through the Internet are always inside a standard SSL/TLS connection with server authentication based on X.509 certificates. TLS protects against eavesdropping, a man-in-the-middle attack, and provides authentication of the server. SDC uses RSA/128-bit or higher AES CBC/SHA, which is considered secure by current industry standards.
- Google tunnel servers authenticate to the incoming SDC connection through a server-side X.509 certificate inside the SSL handshake.
- SDC authenticates to the Google tunnel server through a user name and password pair, which is established through the domain administration page.
Note: When developing gadgets it is always important to protect them against cross-site scripting (XSS) attacks.
A complete discussion of securing gadgets is outside the scope of this article, but there are many web resources available which cover these topics in-depth, and they should be considered a required read before developing gadgets.
Protecting Against Internal Misuse
Because many employees inside an enterprise can create Google Spreadsheets or other applications that use SDC APIs to pull data from the tunnel, it is important to establish the right access rules to help limit the data that is shared between the enterprise and Google Apps.
The resource rules help enterprises enforce that only allowed requests are accepted. The resource rules are checked so only requests that conform to the rules are allowed. If requests don't match, they are routed over the internet.
Security controls exist inside Google Apps to help ensure that the relevant services that use the SDC are limited to authorized applications and personnel. For more information, see the Google Apps Security white paper (PDF).
Data Inside Google
The data protection policy inside Google data centers is detailed in the Google Apps Security and Privacy FAQ. Data that is accessed through an SDC tunnel and cached in our servers follows the same security principles.
The examples in this overview use resource rules that help enforce protection on who can access the data within the corporate network. For best practice security the end points within the network should also authenticate the user. In gadgets, this can be done with makeRequest calls, which make use of OAuth to assert the identity of the user.
Frequently Asked Security Questions
- How do I know that this product won't introduce new vulnerabilities into my environment?
- We understand that this product needs special security scrutiny, and consequently have taken a number of security precautions.
- Can Google log into SDC from Google Apps or change the SDC configuration?
- No. There is no way for Google to log in or otherwise get access into the computer on which SDC is installed, no way to change the SDC configuration, and no way to change the firewall rules - this is locally controlled by the system administrator.
- How do I know that SDC is only talking to the systems/data I specified and is not crawling my environment?
- The system administrator specifies the resource rules that encode what URLs and resources are accessed inside the firewall. Anything that is not explicitly allowed is rejected.
These resource rules are checked inside Google Apps, just before the request hits the Google tunnel servers.
In addition to this, the code of SDC is maintained as the open source Google SDC project, so it can be inspected if necessary by interested parties in order to ensure that the behavior corresponds to Google's claims.
- What data is being sent back to Google? Is it encrypted during the entire transmission?
- The only data that is sent back is a reply to incoming requests that conform to the Resource Rules that the system administrator set up in SDC. The data is encrypted in the transmission between the SDC and Google tunnel servers. The tunnel is encrypted using vanilla TLS with server authentication using a 128-bit or higher AES with SHA cipher suite.
- How is the data being transmitted? What ports do I need to open? Is that data transmission live or in batch?
- Since all traffic is passed through the TLS tunnel, the only port that needs to be opened in the Enterprise perimeter firewall is outgoing port 443, and this will be already opened in 99% of companies. The data transmission is live, although we may cache some content in Google Apps for performance purposes.
- Is the data being transmitted read-only? Is there an ability to write back the data from Google or SDC to the data sources? What prevents that?
- If the connection is allowed, SDC enforces URL patterns and socket parameters. If that is not enough to ensure that access is read-only, then access control needs to be enforced by the end point data source. Authorized users within Google Apps have the same restrictions as SDC inside the firewall.
- How is data being stored at Google? For how long?
- The data storage policy for data accessed through Secure Data Connector is the same as the policy described in the Google Apps Security and Privacy FAQ. For other security and data information, please consult the Google Apps Security white paper (PDF).
- Who has access to that data at Google?
- Security precautions are enforced inside Google so that only authorized personnel have access to the data in certain circumstances. The data protection policy inside Google data centers is detailed in the Google Apps Security and Privacy FAQ.
- How are communications between Google Apps and SDC logged?
- SDC logs transactions using Log4j logs, which customers can inspect to see what has been transmitted and other events - for example URLs, failures, socket connections. Different logging levels allow for more or less verbosity, and external utilities developed for Log4j can be used to process the logs.
- Could someone with access to my internal network and who owns a separate Google Apps domain, download SDC and open up the internal network but within a separate Google Apps domain?
- This is possible, but OAuth mitigates this situation, because someone with this capability must be registered with Google Apps for Business or Education and leave an audit trail in Google. Also, this type of access does not change the fact that an intranet is vulnerable to an adversarial insider - put it another way, an insider can already steal information inside a firewall and publish it to the outside world. This could be done by setting up a reverse SSH proxy in an external server and establishing an outbound SSH connection, which would be authorized by most corporate firewalls. An insider who uses Google Apps to set up an unwelcome tunnel would need a Google Apps for Business or Education account and would leave a record inside Google.
- What prevents SDC from authenticating to a different server? How does SDC ensure that a man-in-the-middle attack is not possible in communicating with the tunnel servers
- SDC uses TLS-based server authentication to help avoid the possibility of a man-in-the-middle attack. The TLS authentication helps confirm that:
- The certificate presented in the TLS handshake evaluates to a trusted Certificate Authority (CA)
- The certificate is valid
- The common name of the subject of the certificate is an exact match to the domain name that SDC accesses.
--sslKeyStoreFile, or the Java property
javax.net.ssl.trustStore. See the JSSE reference guide for more information.
- How often is Google going to give me updates for SDC? Security patches? How are those patches going to get pushed/communicated to me? If there is a security issue/event with SDC, will Google notify me?
- Google endeavors to notify customers of security vulnerabilities and make patches available for download regularly in the Google Code project site. Third party applications and libraries which are used by SDC but not bundled with our code distribution (for example OpenSSH), should be patched and maintained by the customer.
- Could similar functionality be achieved from the client side, with a browser that accesses both Google Apps and the internal sites, and aggregates the application functionality?
- We believe that our solution is more comprehensive:
- A browser solution could not work in absence of a user - for batch or scheduled jobs, for example.
- A browser solution would not work outside the firewall or VPN.
- Application sharing would be much more complex.
- Client-side data access and aggregation inside a browser is experimental and has been not proven.
To help prevent an unauthorized user from setting up their own SDC and connecting to a different Google Apps domain, administrators can use a proxy to block unauthorized machines from connecting to