(Solenne Houssay)
Loi info et libertés ⇒ obligations = 5 principes sur la collecte de données:
il existe des modeles de contrat, exp guide info et liberté pour l'ens/rech, cf reseau supCIL (cnil et cpu).
Le reponsable est tj le president d'etablissement, en cas d'externalisation il le reste et d'autant plus qu'il n'a encore moins de visibilité sur l'implementation et les données, ce dernier peut exercer un droit de regard ⇒ visite du site, procedures …
on peut imposer la façon de traiter l'information, exp refuser un serveur mutualisé, c'est a nous de rediger les clauses, pas au prestataire d'imposer sa solution
hebergement international ⇒ aux US “safe harbor” = “sphere de securité”, des entreprises y adherent, en contractant avec elles cela simplifie les demarches CNIL en terme d'autorisation de transfert de données à l'etranger. cependant cela ne remet pas en cause le “patriot act” ⇒ le gouv US aura acces aux données si necessaire !.
En terme de formalités, les etudiants sont considerés comme usagers du service public, donc CNIL Les personnels sont salariés de l'entreprise, pas necessairement CNIL. les demandes d'avis, autorisations sont faites par le CIL auprés de la CNIL, prevoir des delais de reponse ~2mois mini pour toute operation.
(D.Vandrome)
Statut Renater = maitrise d'ouvrage du reseau ens/rech, mais en pratique une partie de la maitrise d'oeuvre est également exercée. Bien qu'externalisée, Renater conserve l'Ingenierie du reseau, seule la mise en oeuvre est sous traitée. Renater = 30 personnes, la sous-traitance au NOC = 12 personnes. Renater fait figure d'exemple remarquable au niveau des autres ministeres/administrations, ces derniers ayant contractés avec des operateurs/prestataires privés qui ont completement figé les contrats ⇒ aucune flexibilité (exp demande tres difficile pour disposer d'un acces VPN dans certains ministeres où seul le 80 est ouvert). Les montants sont aussi souvent bien superieurs a ceux de l'exploitation de Renater. C'etait d'ailleurs un peu la situation de Renater en 98 avec l'oprateur historique.
A propos des penalités, teritorialité, juridictions etc … il s'agit de preocupations ultimes, si on en arrive là c'est souvent trop tard, ce qui compte c'est le service rendu .
De plus en plus de services dans Renater, à l'etude bientot un service de messagerie mutualisée, a l'image de l'anti-spam mutualisé !
Presentation sur le “cloud” computing, chronologie des techniques: mainframe (70), client-server (80), web(90), SOA (2000), Cloud (2010)
Le cloud permet une adaptation plus juste des besoins IT à la demande windows azure ⇒ plateform as a service SAAS, PAAS, IAAS (infra as a service), ces S/P/I as a service peuvent etre aussi privés ! microsoft update est un simple principe de Saas evolution = datacenter traditionel → datacenter virtualisé → private cloud → public cloud le cloud n'est pas seulement l'accumulation de datacenter virtualisés ⇒ passage à l'echelle, continuité, adaptation des appli etc …
La fédération d'identité sera necessaire pour passer d'un cloud à un autre.
Livre interessent → "Big switch" de Nicholas Carr
les sociétés pratiquants l'hebergement de datacenter pour le grand public se retrouvent sur le cloud ⇒ microsoft, google, amazon. Microsoft datacenter de dublin (100 000 machines 500 Millions de $, 26 millions de users liveMessenger en FR), autre Datacenter a Amsterdam pour l'europe.
Evolution des types de datacenter ⇒ colocation/ serveur ⇒ proprio/Rack(baie) quincy = 11 terrains de foot ⇒ classe Container/container, 4eme generation = containers (de bateau !) standardisés (froid, electric) stockés en “plein air” , deposés par grue dans un lieu surveillé.
hotmail des 1996 (+450M users), msn(97), windows update(98), live messenger(99), bing(99), Xbox live(2001), LiveMeeting (2003), M$ online service (2004) , maintenant Office 2010
exchange(mail,calendrier ⇒ outlookLive(webmail)), espace de stokage en ligne (SkyDrive), synchro file en ligne(liveMesh), messagerie instantanée avec messenger et partage de site internet, Office Web Apps(OWA) ⇒ editer en ligne un doc office quand on ne l'a pas localement, sauvegarde directe en ligne.
La base des identités reste sur l'infra d'etablissement, on les push sur live@edu afin de creer les BAL (winRM/GALSync), “Exchange web services” ⇒ API pour pusher des info en ligne vers un service ENT, celendrier existant afin de synchroniser les outils locaux et ceux en ligne.
Administration sous forme d'interface Web (exchange control panel) ou via Windows PowerShell creation/administration a distance en shell.
debut de live@edu en Mars 2005 = hotmail service grd public, depuis mars 2009 live@edu = exchange comme support de messagerie a venir ⇒ sharepoint online, ADFSv2 ⇔ interoperabilité shibboleth (SAML!)
pour tester: http://www.microsoft.com/liveatedu
Service gratuit ! ⇒ car cela permet souvent de mettre en test reel un produit, exp echange2010 sortie en nov2009, pourtant en prod dès printemps2009 sur live@edu avec 4Millions de users.
(Patrick.De Carne Disi )
externalisation de 40K boites au lettre (BAL) sur live@edu
2 IG pour gerer 45K BAL de 500Mo, clients lourds (imap/pop) sastisfaisant, en revanche webmail depassé avec IMP. Constat que 20% des BAL sont forwardés vers des BAL en ligne.
Des services deja mutualisés ⇒ RAP, podcast, CentrexIP, SMS …
Experimentation live@edu sur un nouveau nom de domaine pairsdescartes.eu → 40K BAL etudiantes.
un script powershell recupere ces 3 attributs depuis l'annuaire d'etablissement et genere un CSV à destination de live@edu de type:
action;type;name;email;password;displayname;forceUpdatePassword
Realisation en une passe de 24H pour la création de 40K comptes.
Integration de ce service live@edu dans l'ENT esup via un onglet/icone. en cliquant dessus on part sur un IIS casifié (via ISAPI), qui fournis un ASP qui recupere le remote_user via CAS et enfin redirection avec certif x509 vers live@edu. Ainsi l'etudiant n'a meme pas besoin de connaitre son password live@edu, le SSO CAS suffit. En revanche si necessité d'acces avec client lourd vers live@edu ⇒ necessité de le connaitre !.
Attention petit pb avec IE et non acceptation dans un Iframe d'un cookie ne venant pas du “parent” ⇒ solution ⇒ ouverture de live@edu dans une nouvelle fenetre plutot qu'une Iframe. De meme pas de Single Sign Out . pcc at parisdescartes.fr ow at parisdescartes.fr
(D. Lamballais)
Sous traitance et externalisation deja existante, pas d'opposition de principe
inria tres decentralisé, 8 centres 3500 comptes, strategie de mutualisation des infra et collaboratif.
constat la messagerie est utilisée comme outils collaboratif.
anti-spam et agenda deja centralisé, mais parfois basé sur des solutions qui n'evoluent plus, developpement tres important des smartphones, developpement du nomadisme.
constat: presence d'offres SAAS allechantes, gratuites !, fuites informelles d'utilisateurs vers ces services
Le besoin n'est plus simplement messagerie mais s'elargie et s'oriente vers des suites collaboratives. decorreler le choix d'une plateforme et de sa mise en oeuvre .
googleApps a été etudié mais rejeté car:
consultation ⇒ short liste: IBM Lotusdomino/notes, Microsoft exchange, Oracle beehive, Zimbra collaborative Suite
2 solutions ce sont demarquées, Microsoft exhange2010 et zimbra sur ce perimetre messagerie et agenda , choix final Zimbra ⇒ support des standards ouverts (calDAV,XMPP), integration existant (linux,ldap,postfix …), support protocoles Microsoft (MAPI,ActiveSync pour smartphone). Mais cela ne couvre pas tous les besoins, partage de docs (alfresco deja deployé). Choix d'une exploitation en interne.
Mutualiser est le maitre mot, rapellons nous des les debuts de Renater, on disait a l'epoque que les operateurs privés etaient là et rendraient le service, il n'empeche que la mutualisation operée via Renater a été un franc succés. Attention aussi ici où la question est encore plus complexe que le reseau ⇒ les données posent la question fondamentale de la reversabilité !.