Le Secure Data Connector est un service proposé par Google pour permettre à certaines applications Google d’accéder à des données qui sont dans un domaine restreint, comme l’intranet d’une entreprise protégée derrière un firewall.

La solution consiste à ouvrir un tunnel sécurisé depuis une machine se trouvant dans le domaine restreint et les serveurs de Google.

Les applications Google qui peuvent utiliser ce services sont Google AppEngine, Google Spreadsheets et les Gagdgets privés pour Google Sites. Notons aussi par ailleurs que le Secure Data Connector ou SDC ne peut être utilisé que par les détenteurs de Google Apps Premier Edition ou Education Edition.

Une fois mise en place, les applications Google pourront faire des appels HTTP à des services qui sont dans ce domaine et récupérer le résultat si l’utilisateur utilisant l’application y est autorisé.

Installation et fonctionnement de SDC

Pour installer un SDC il faut:

  • Disposer d’une machine Linux dans le domaine restreint avec le runtime Java et openSSH installés,
  • Configurer le domaine Google Apps pour autoriser les connexions vers le SDC,
  • Installer l’application SDC sur la machine Linux

Les règles d’autorisations sont décrites dans un fichier de configuration au format XML. Chaque règle précise notamment:

  • Les utilisateurs à autoriser en précisant les email Google Apps
  • Les services concernées par la règle (Spreadsheet, App Engine, Gadget)
  • Les identifiants des applications si besoin
  • L’URL du service à acceder (un URL exact ou bien le domaine et un répertoire racine)

Après avoir configuré le SDC et défini les premières règles d’autorisation, vous pourrez lancer le client SDC. Celui-ci établit une connexion permanente vers le serveur Google, sur le port 443 de l’URL https://apps-secure-data-connector.google.com.

Le client SDC établit un tunnel chiffré TLS et s’authentifie en utilisant le couple username/password défini dans la configuration Google Apps. Puis, le client SDC envoie les règles d’authentifications au serveur SDC. Désormais, c’est le serveur SDC qui reroutera les appels aux URLs définis dans les règles vers le serveur Web dans le domaine restreint. Pour ce faire, il retransmet les requêtes au serveur SOCKS 5 créé par SSH sur la machine SDC Client.

Utilisation du SDC avec Google Spreadsheets

Un utilisateur Google spreedsheets pourra importer des données se trouvant dans une machine dans l’intranet en appelant une fonction de type ImportData(« http://intranet.monentreprise.com/contacts.csv »). Il pourra utiliser aussi une URL comme dans ImportData("http://monintranet/contacts.csv") car la résolution DNS se fait par l’application hébérgée dans l’intranet et non par les serveurs de Google.

Utilisation du SDC avec Google App Engine

Pour Google App Engine version Java, l’appel se fait via le service URL Fetch, comme pour tout autre appel Web. Par contre, il est nécessaire d’ajouter une entête HTTP à la requête pour que celle-si soit reroutée via le serveur SDC:

fetchreq.setHeader(new HTTPHeader("use_intranet","yes"));

Notez que l’utilisation du SDC est soumise aux mêmes restrictions et quotas que le service URL Fetch. Notamment, la requête ainsi que la réponse ne peuvent dépasser 1 Mo en taille.

Utilisation du SDC avec Private Gadget for Google Sites

Enfin, pour utiliser le SDC avec les Gadgets privés de Google Sites, il faut ajouter certains paramètres à la requêtes pour que l’appel JavaScript utilise OAuth, comme dans la fonction JavaScript getData() :

function getData() {   var params = {};   params[gadgets.io.RequestParameters.CONTENT_TYPE] =   gadgets.io.ContentType.TEXT;   params['AUTHORIZATION'] = 'SIGNED';   params['OAUTH_ADD_EMAIL'] = 'true';   params['OAUTH_ENABLE_PRIVATE_NETWORK'] = 'true';   var url = "YOUR_URL";   gadgets.io.makeRequest(url, function(response){log(response);}, params); }

OAUTH_ADD_EMAIL est un paramètre optionnel qui ajoute l’adresse email de l’utilisateur authentifié à la requete. Ceci permet au service accédé de connaître l’identité de l’appelant.

Le paramètre AUTHORIZATION = SIGNED indique que la requête doit être signé par le conteneur de Gadget, soit Google Sites.

Bien que le client SDC vérifie la signature et ne redirige la requête vers l’application dans l’intranet que si la signature est valide, rien n’empêche un utilsiatuer dans l’intranet d’accèder au service avec les paramètres de son choix. Dans ce cas, l’application accédée a aussi la responsabilité de vérifier la signature en utilisant la clé publique de Google Sites (https://opensocialresources.appspot.com/certificates/).

Sécurité

Concernant la sécurité, il ne faut pas non plus oublier que n’importe qui dans le domaine de l’entrprise peut installer un client SDC, du moment où il a une machine Linux à disposition. Evidemment, le SDC n’introduit pas de nouvelle faille dans le système, car un utilisateur pouvait déjà, via un tunnel SSH par exemple, faire ce genre de manipulation. Mais il faut être vigilant, et peut être instaurer de nouvelles règles de firewall pour restreindre les appels sortants vers les serveurs Google SDC.

Cache

Les appels aux services sont mis en cache par le serveur SDC Google pour des raisons de performances. Des appels successifs retourneront donc les mêmes résultats. Vous pouvez d’ailleurs constater via la console de log du client SDC que les requêtes successives n’engendrent pas de nouveaux appels. Google nous garantit par contre que les données mises en cache dans les serveurs Google sont protégées et non exploitées.

Pour éviter l’utilisation du cache et provoquer un appel réél au service dans le domaine de l’entreprise, vous pouvez modifier l’URL à chaque appel. Par exemple:

  • 1er appel: http://monintranet/contacts.csv?appel=1
  • 2eme appel: http://monintranet/contacts.csv?appel=2 etc.

Mise à jour des règles d’autorisations

Les règles d’autorisations sont censés être re-envoyés vers le serveur SDC régulièrement. La documentation Google préconise d’attendre au moins une minute pour voir les modifications. Mais nous avons constaté que tel n’etait pas le cas. Après avoir supprimé une règle dans le fichier de configuration, la règle était toujours en vigueur: le serveur SDC reroutait toujours la requête désormais interdite vers le client SDC, et le client SDC transmettait la requête au service Web associé. Nous avons du redémarrer le client SDC pour forcer la réinterprétation des nouvelles règles.

Load balancing

Mettre en place un SDC pour accéder à l’ensemble des services internes peût être un goulot d’étranglement pour vos applications. Un service de load balancing peut être obtenu en démarrant plusieurs client SDC dans le domaine. Ces clients peuvent avoir des règles différentes ou identiques. Le serveur SDC trouve toutes les instances des clients SDC qui satisfont à une demande d’URL et reroute vers un des SDCs, en essayant d’equilibrer la charge. Par contre, il est impossible de préciser explicitement dans la requête l’instance SDC à utiliser.

Pour conclure

Bien que très utile pour intégrer les services Google avec l’existant des entreprises, le service SDC est à utiliser avec prudence. Attention donc à la sécurité, et à la montée en charge.