Christophe Le Bot

  • Navigation rapide
Pratique de la conception numérique

Derniers commentaires

  • Une excellente thèse sur Simile Exhibit
    • Olivier Rossel | Bonjour. Malgre les annees, avez vous toujours en memoire vos usages d’Exhibit? Je serais ravi d’en discuter avec vous. Cordialement, Olivier Rossel.
  • Utiliser le planificateur de tâches OVH (crontab) avec PHP
    • Max | Bonjour, comme faire pour appeler une version de PHP qui n’est plus proposée par défaut dans le manager ? J’essaie de lancer un cron avec php 5.3 mais le log affiche No such file...
    • Christophe | @absolument Merci pour ces précisions. Je n’ai pas mis en place de tâches cron récemment, mais j’ai reçu quelques notifications étranges d’OVH il y a quelques...
  • Récupérer le dernier auto-incrément MySQL avec PHP
    • Thy | Sujet toujours *très* utile en 2015 ! Je réponds à Serge tsimba qui récupère un « Resource id ». (Et à tous ceux qui ont le même souci mais qui ne le disent pas) :)...
  • Régler l’heure de serveurs virtuels sous Debian
    • Ares_XL | Il semble que sur Débian la commande « tzconfig &ra quo; soit dépréciée et remplacée par : « dpkg-reconfigure tzdata » elle donne accès à une...
 

Archives de la catégorie
Serveurs

Utiliser le planificateur de tâches OVH (crontab) avec PHP

Site web OVH

De nombreuses applications web ont besoin d’exécuter périodiquement des scripts pour réaliser des tâches automatiques : purge de logs, traitement de données, lancement de sauvegardes… Quand vous avez la main sur votre propre serveur, tout va bien : vous utilisez les crontabs. Mais quand vos applications sont hébergées sur un serveur mutualisé, c’est déjà moins accessible !

Heureusement certains hébergeurs proposent des solutions alternatives efficaces. C’est le cas d’OVH avec son Planificateur de tâches. Une aide officielle existe, mais sans être inexacte, elle est un peu rapide. Du coup, j’ai passé plus de temps que prévu pour que tout fonctionne à merveille. Voilà comment s’y prendre.

Préparer son script PHP

Première étape : préparer le script de traitement PHP qui sera appelé par la tâche planifiée. Pour que le serveur appelle le bon interpréteur (dans notre cas PHP), le script a besoin de le définir en première ligne. Il faut donc ajouter cette ligne à votre script PHP :

#!/usr/local/bin/php

Elle se place en tout premier. On obtient donc ceci :

#!/usr/local/bin/php
<?
// La suite de mon script PHP...

Si vous avez besoin d’appeler d’autres scripts PHP ou de manipuler des fichiers, n’oubliez pas de travailler avec des chemins absolus. Par exemple en utilisant une variable qui définit l’endroit où est placé votre script :

$path = dirname(__FILE__);

Une fois votre fichier PHP placé sur le serveur, il faut lui ajouter le droit d’exécution (avec votre outil FTP, par exemple). Par défaut, les droits des fichiers sont calés en lecture + écriture (604), vous devez obtenir les droits en lecture + écriture + exécution (705).

Planifier la tâche

Côté serveur, c’est fini. Maintenant, il faut planifier la tâche. Pour cela, nous passons par le Manager OVH (ou Espace client, depuis peu). Le Planificateur de tâches est caché derrière Mutualisé > Hébergement > Services web.

Manager OVH - Crontab

Lors de l’ajout d’une tâche, nous devons définir ses propriétés :

  • Description de la tâche
  • Script à exécuter (chemin depuis la racine FTP de votre espace mutualisé)
  • Langage de script (avec le choix très important de la version de PHP à exécuter)
  • Logs par e-mail (permet de recevoir par e-mail un log de l’exécution du script)
  • Activation
  • Périodicité

L’interface est si simple que je n’ai rien à expliquer !

Propriétés d'une tâche planifiée OVH

Une fois validée, la tâche sera exécutée comme vous l’avez prévu. Enfin presque… Deux écarts constatés avec la théorie :

  • La mise en place de la tâche planifiée est parfois longue (j’ai dû attendre plus de 24h sur un de mes sites avant de la voir tourner).
  • Elle s’exécute rarement à l’heure prévue (la pile d’exécutions doit être longue, du coup j’atteins parfois des décalages de 20 à 30 minutes).

Suivre l’exécution de la tâche

Une fois tout ça en place, ça devrait tourner tout seul… Je suppose que vous testerez bien votre script d’abord, mais on n’est pas à l’abri de surprises à l’exécution. OVH vous offre donc les logs par e-mail ! La fonctionnalité est proposée dans le Planificateur de tâches et limitée à 10 envois (on peut la réactiver à la demande si besoin).

Vous recevrez alors un message du genre :

Vous avez demandé l'envoi des logs pour la tâche :

Numéro            : 123456
Heure de début    : 2013-10-08 02:21:02
Heure de fin      : 2013-10-08 02:21:19
Commande exécutée : /usr/local/bin/php.ORIG.4 -c /usr/local/lib/php.ini /[path]/[file].php
Code de retour    : 0
[...]

-------------------------==  Début  ==-------------------------

X-Powered-By: PHP/4.4.9
Content-type: text/html

#!/usr/local/bin/php

-------------------------==   Fin   ==-------------------------

Si tout se passe bien, rien de plus. Sinon, vous aurez une trace d’erreur. Un exemple avec un script qui tente une opération interdite sur un fichier gunzip :

-------------------------==  Début  ==-------------------------

X-Powered-By: PHP/4.4.9
Content-type: text/html

#!/usr/local/bin/php
gzip: /[path]/toto.gz already exists;        not overwritten

-------------------------==   Fin   ==-------------------------

Et la sécurité ?

J’ai trouvé quelques didacticiels sur le Planificateur de tâches OVH. Certains sont très détaillés (encore plus qu’ici), mais aucun n’aborde le sujet de la sécurité. Pourtant, la question est vraiment capitale chez OVH. En effet, votre espace web sur le serveur mutualisé a pour objectif de diffuser des contenus publiquement sur le web. C’est sa fonction première ! Donc, si vous placez un script maladroitement sur votre serveur, d’autres pourront jouer avec.

Un exemple que j’ai vu : un dossier mysql à la racine d’un site, contenant un script backup.php qui génère un fichier dump.sql au même endroit. Autant dire qu’il y a 99% de chances qu’un hacker du dimanche récupère vos données confidentielles dans l’année ! Remarquez que ce type de didacticiels n’est pas forcément innocent… Si 2000 personnes suivent l’exemple à la lettre, c’est d’autant plus facile pour des gens mal intentionnés. Lisez les didacticiels avec un peu de recul !

Parmi les règles de protection efficaces :

  • placer votre script dans un dossier racine qui n’est pas couplé à un sous-domaine (donc inaccessible par le web)
  • si votre fichier appartient à un dossier accessible sur le web, ajouter un fichier .htaccess pour interdire sa lecture et son exécution (directive Deny from all, par exemple)

Sauvons MySQL !

Save MySQL

En janvier 2008, le rachat de MySQL AB par Sun fut un événement majeur et plutôt bien accueilli. Mais l’ambience était tout autre après le rachat de Sun par Oracle. J’émettais de fortes réserves sur la survie de MySQL dans le giron de l’ambitieuse société californienne.

Les craintes se sont confirmées et une grande bataille se joue en ce moment pour sauver MySQL. Michael « Monty » Widenius, le créateur de MySQL, a lui-même tiré la sonnette d’alarme en décembre et a anticipé les problèmes que vont rencontrer les utilisateurs de MYSQL.

Sans réponses claires et pérennes d’Oracle, la communauté s’organise et une pétition a été lancée pour convaincre les pouvoirs publics et les autorités de régulation des marchés d’étudier le cas de la fusion Oracle-Sun-MySQL. Libre à vous de décider de l’avenir de MySQL, mais le danger est, à mon avis, bien réel. J’attends d’être convaincu du contraire…

Pour en savoir plus : Save MySQL !

Barcamp PHP toulousain : la synthèse

Bacrcamp PHP Toulouse

Jeudi dernier se tenait le Barcamp PHP Cheese & Wine. Même si le vin et le fromage ont été très appréciés, nous n’étions pas venus (seulement) pour ça. Alors pour les absents qui ont eu tort de l’être, voici une petite synthèse de cette longue soirée.

Un vrai barcamp

Premier bon point : c’est un vrai barcamp où les participants se présentent et définissent le contenu des ateliers. Tous les barcamps ne respectent pas cette règle de base… Xavier Gorse, président de l’AFUP, a donc joué le rôle de « maître de cérémonie » pour établir le programme d’après les souhaits de chacun  :

  • PHP et sécurité
  • PHP 5.3
  • Déploiement d’applications PHP
  • PHP et les bases de données « NoSQL »
  • Outillage PHP
  • PHP et testing
  • Frameworks PHP

Pour ma part, j’ai participé aux ateliers :

  • Déploiement d’applications PHP
  • PHP et les bases de données « NoSQL »
  • PHP et testing

Je limite donc mon article à ces sujets, sachant que d’autres synthèses ont déjà été publiées :

Déploiement d’applications PHP

Cet atelier a mis en évidence la difficulté de déployer des applications web en général (technologies nombreuses et environnement hétérogène). Tous les outils existants ont été passés en revue, du paquet Linux (.deb) aux outils spécifiques à PHP (PEAR, Phing, Phar) en passant par des intermédiaires parfois plus adaptés (makefile, Puppet, Capistrano, Ant). Deux groupes de participants étaient clairement représentés, avec des besoins très différents :

  • Déploiement d’une solution sur un parc important et hétérogène (cas des éditeurs de solutions, comme Linagora avec OBM)
  • Déploiement d’un projet sur-mesure sur un ou quelques serveurs, mais très fréquemment et avec des contraintes d’intégration de contenus externes (cas des agences web, avec plusieurs déploiements par jour).

Dans le premier cas, la difficulté est d’identifier la configuration des serveurs cibles et de préparer les paquets d’installation correspondants (.deb pour chaque distribution Linux, .msi pour chaque version de Windows, etc.), tout en assurant la compatibilité des données sans toujours les connaître (tests de régression).

Dans le second cas, il faut savoir intégrer pendant le déploiement les données du site en exploitation (base de données, templates gérés par un web designer externe, etc.), avec d’éventuelles transformations (ETL, Extract Transform Load).

J’ai ajouté qu’un déploiement ne se limite pas à la livraison de la partie applicative mais doit aussi savoir traiter la mise à jour des outils liés au projet (plate-forme de gestion de tickets, extranet, feuille de route, tests, sauvegardes, alertes, etc.).

En dehors de PEAR, trés utilisé et qui est un outil de déploiement à l’origine, j’ai une préférence pour Ant + Phing et Capistrano.

Bases de données « NoSQL »

Là, on entre dans une autre dimension. Les bases « NoSQL » sont des bases de données non relationnelles. En gros, on ne retrouve pas le schéma habituel « tables contenant des champs et étant reliées entre elles ». L’avantage est d’obtenir des performances exceptionnelles sur des entrepôts de données énormes. Parmi les acteurs majeurs qui développent et utilisent des bases « NoSQL », on peut citer : Google (projet Big Table qui a inspiré le projet Cassandra), Facebook ou Linkedin.

Si on revient à la dure réalité d’un acteur de dimension modeste, on constate que ces technologies émergentes et prometteuses sont encore très spécifiques. Les bases relationnelles ont de beaux jours devant elles. La difficulté est notamment de réintégrer dans l’application PHP ce qui fait la force des systèmes SQL : sélection, jointures, intégrité référentielle, etc. Le volet testing des projets en prend un coup…

PHP et testing

Atelier en petit comité (6 personnes), en concurrence déloyale avec l’atelier Frameworks qui a fait le plein ! Nous avons tenté de lister les types de tests liés à une application web, en dépassant autant que possible la simple vue du développeur :

  • Tests unitaires (PHP et Javascript)
  • Tests fonctionnels
  • Tests d’IHM (via Selenium Core, Selenium RC et Selenium IDE)
  • Tests de recette
  • Tests de non régression
  • Tests de performance
  • Tests de charge
  • Tests de conformité (normes, W3C, accessibilité, etc.)
  • Tests ergonomiques (tri par cartes, paper prototyping, tests utilisateurs, etc.)
  • A/B testing

Les échanges sur nos expériences ont été très instructifs. Nous étions tous d’accord pour insister sur la définition précise des cas d’utilisation qui facilite la gestion des tests pendant toute la durée du projet avec le client. D’où une phase de spécifications sérieuse qui conditionne la qualité du travail livré. Certains tests peuvent faire l’objet de validation contractuelle, comme les wireframes issus de tests ergonomiques qui servent ensuite de feuille de route aux intégrateurs et développeurs.

La difficulté avec les tests, c’est de savoir placer le curseur pour ne pas s’y noyer. Il n’est pas réaliste d’appliquer les tests de façon exhaustive. C’est un idéal en contradiction avec les budgets et les délais imposés en pratique. Il faut donc savoir réaliser les bons tests, au bon endroit et au bon moment. Par exemple, sur le calcul des prix d’un panier de site e-commerce, sur l’intégration des données lors d’un couplage entre deux systèmes, sur l’ergonomie d’une interface riche, etc.

En résumé

Une excellente soirée qui a largement dépassée les 5 heures prévues ! L’accueil de Linagora et de l’AFUP était parfait, l’ambiance très sympathique et le niveau des échanges très pointu. Il y a des gens qui savent faire des choses avec PHP en Midi-Pyrénées ! Je pense qu’on remettra ça sous peu. Prochaine étape : le Bargento, lundi 9 novembre à Paris. Je serai présent avec l’équipe de l’AFUP pour organiser et animer cette journée qui s’annonce exceptionnelle. Et à la suite, le Forum PHP 2009, tout aussi exceptionnel. Sur ce coup-là, je déclare forfait. Il faut bien travailler un peu !

Oracle acquiert Sun

Oracle acquiert Sun

Le rachat de MySQL par Sun était déjà un événement pour moi l’an dernier. Alors je ne sais plus quels mots utiliser après le rachat de Sun par Oracle aujourd’hui…

Sachant comment finissent les entreprises qui passent entre les mains d’Oracle, il reste une sacrée incertitude sur certains projets (Java et MySQL pour commencer).

Panique sur les DNS !

Hier, c’était la panique chez tous les hébergeurs : une faille majeure a été découverte dans bind, l’application la plus utilisée dans le monde pour gérer les serveurs de noms de domaine. Une faille tellement critique qu’elle permet de prendre le contrôle des domaines et donc d’en rediriger le trafic vers des serveurs pas très honnêtes !

Même s’ils sont ultra-surveillés et protégés, les 13 serveurs racines qui gèrent tous les noms de domaine d’internet, étaient également potentiellement concernés.

Au fait, à quoi sert un serveur de noms de domaine ? Tout simplement à faire le lien entre un nom de domaine et une adresse IP (et inversement). Chaque machine branchée sur internet possède une adresse IP qui permet de la rendre unique sur le réseau mondial. Cependant, utiliser une adresse IP ne suffit pas. D’abord, elle n’est pas facile à retenir. Et puis, comment feraient les utilisateurs de Google qui exploitent 450.000 serveurs ? Il est plus simple de taper www.google.com dans son navigateur que 64.233.167.99. Même si ça marche, évidemment (si, si, essayez !).

Le serveur de noms de domaine est donc un maillon indispensable d’internet. Quand il s’arrête, vos services internet aussi…

Bref, hier, tout le monde était sur le pont… et moi avec ! Si vous gérez un serveur DNS, n’attendez plus, mettez à jour votre installation, c’est vital ! Le correctif est publié et disponible pour pratiquement tous les systèmes.

Installer Drupal 6 sur un serveur mutualisé OVH

Drupal + OVH

ATTENTION ! Cette astuce n’est plus valable sur les hébergements OVH à partir de septembre 2015. La surcharge de configuration PHP par fichier .htaccess n’est plus autorisée. Le fichier .ovhconfig le remplace dès maintenant. Pour plus d’information, voir la page FAQ – Migration sur les dernières versions de PHP du site OVH.

Les contraintes des serveurs mutualisés sont souvent agaçantes, mais rarement insurmontables. C’est le cas chez OVH quand on veut installer Drupal 6.

Drupal ne s’installe pas si register_globals est activé, ce qui est le cas par défaut chez OVH (ce serait trop simple…). Mais il est permis de modifier le comportement du serveur, grâce à quelques directives qu’il faut ajouter au début du fichier .htaccess inclus dans le package Drupal :

SetEnv PHP_VER 5
SetEnv REGISTER_GLOBALS 0
SetEnv ZEND_OPTIMIZER 1

En gros, je passe en PHP5, je désactive register_globals et j’en profite pour obtenir les avantages de Zend Optimizer.

Il faut également décommenter la ligne RewriteBase / dans le même fichier pour que la réécriture des adresses par Apache fonctionne correctement :

# If your site is running in a VirtualDocumentRoot at http://example.com/,
# uncomment the following line:
RewriteBase /

# Rewrite URLs of the form 'index.php?q=x'.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]

Et là, miracle, Drupal s’installe. Enfin, pas pour tout le monde : sur les anciens hébergements, MySQL est encore en version 4.0, incompatible avec Drupal. Pour s’en sortir, il faut migrer votre base de données vers un autre serveur SQL OVH.

Attention, l’opération est très critique… et n’a pas fonctionné pour moi ! En fait, elle consiste à détruire la base pour la reconstruire à partir de vos sauvegardes. Donc premier point : vérifier que vos sauvegardes sont intègres. Ensuite, il faut suivre la procédure OVH.

Sauf que lorsque j’ai voulu reconstruire la base via le manager OVH, elle n’apparaissait plus dans la liste ! Résultat : plus de base de données ! C’est pratique…

Piloter et sécuriser ses bases de données avec MySQL Proxy

MySQL Proxy

MySQL Proxy, proposé par MySQL AB, est le genre d’outils dont le rôle semble si évident qu’on se demande pourquoi il n’existait pas avant. Comme tout proxy, il récupère les requêtes destinées à la base de données, effectue des traitements et adresse une requête modifiée au serveur MySQL. Bien entendu, l’opération inverse est aussi gérée : MySQL Proxy sait récupérer un résultat de requête et le transformer avant de l’adresser au client initial.

Fonctionnalités

Après cette petite présentation, on peut se demander pourquoi on aurait besoin d’un proxy, puisque les services applicatifs (s’ils sont correctement architecturés et codés…) devraient envoyer une requête optimisée au serveur MySQL. Une petite liste des fonctionnalités finit par convaincre de son intérêt :

  • Analyse des requêtes
  • Filtrage et modification des requêtes et des résultats
  • Injection de requêtes
  • Load balancing
  • Exécution de scripts (basés sur le langage LUA)

Cas d’utilisation

Dans la pratique, on peut imaginer les situations suivantes :

  • Corriger les erreurs de syntaxe communes.
  • Garantir le fonctionnement d’anciennes applications utilisant des requêtes non supportées.
  • Supprimer du résultat un mot de passe demandé dans la requête.
  • Récupérer et fusionner avec le résultat des données externes à la base de données (fichiers, flux XML, RPC…)
  • Router les requêtes vers un autre serveur MySQL ou vers une autre base de données du même serveur.
  • Empiler un lot de requêtes et les contrôler avant de mettre à jour les tables.
  • Dupliquer les requêtes en temps réel sur deux bases différentes.
  • Exécuter un script shell avant ou après des modifications dans la base de données.
  • Interdire certains motifs de requêtes.
  • Verrouiller des tables selon le contexte.
  • Contrer les injections SQL non désirées.

On le voit, les possibilités sont infinies et ne dépendent que des contextes de production et de l’imagination des développeurs. MySQL Proxy permet surtout d’éviter d’intégrer la gestion de l’exploitation des bases de données MySQL dans les services applicatifs. Voilà enfin une saine séparation du travail du développeur métier et de l’administrateur MySQL !

Mise en oeuvre

MySQL Proxy est encore en version alpha et son fonctionnement n’est garanti que pour les versions MySQL 5.0.x et ultérieures.

Pour découvrir ses possibilités, O’Reilly Network propose un didacticiel clair et très fourni : Getting Started with MySQL Proxy.

Source : Linuxfr.org

Je vénère l’indispensable Ultimate Boot CD !

C’est chouette, l’informatique ! Sauf quand on oublie de sécuriser son versant matériel… Je ne parle pas seulement de parer les attaques en tous genres (réseau, code applicatif, vols, etc.), mais aussi de se prémunir des défaillances des composants internes. Une alimentation qui grille ou un disque dur qui flanche, ce n’est pas une légende, même pour du matériel haut de gamme.

Tout serveur qui se respecte doit donc être entouré de quelques précautions :

  • composants sélectionnés pour leur qualité
  • double-alimentation stabilisée
  • installation en salle blanche climatisée
  • gestion des disques sécurisée (avec RAID par exemple)
  • sauvegardes complètes et incrémentales
  • ubiquité des données
  • sécurisation des accès
  • surveillance et alertes
  • procédures d’urgence et de récupération
  • tests et validation des applications et services
  • etc.

Ce qui est moins marrant, c’est quand vous avez presque tout prévu et que le « presque » casse la machine. Comme dirait le marketing d’IBM, « la sécurité de votre système d’information repose sur son maillon le plus faible ».

Pourquoi je vous explique tout ça ? Parce que, malgré toutes les précautions (enfin presque…), j’ai vécu un scénario catastrophe ce week-end. L’objet du stress : un joli serveur dual-core sous Windows Server 2003 monté en RAID 1 qui gère l’informatique de 65 personnes. Une belle bête, donc.

Sauf que la machine a eu une faiblesse et que les procédures d’intervention n’étaient pas adaptées. Résultat : perte de la partition système… et aucune sauvegarde exploitable !

C’est alors qu’entre en scène Ultimate Boot CD et sa panoplie d’outils incroyables. Grâce à lui, j’ai pu récupérer la partition perdue, la cloner sur un autre disque, en vérifier le fonctionnement, puis recréer le master boot record.

Comme les données étaient sensibles et qu’on ne peut pas se permettre d’utiliser autre chose que des outils professionnels réalisés par des professionnels, j’ai aussi tenté l’aventure avec les outils et procédures de Microsoft (notamment la console de récupération du CD d’installation). Résultat : échec total…

Polémique sur l’application de la LCEN

Un petit mémo pour garder trace de la polémique qui enfle autour du décret d’application de la loi pour la confiance dans l’économie numérique (LCEN). J’ajouterai peut-être du contenu si les tremblements perdurent…

Dossier du Journal du Net

Un projet de décret pour surveiller le Web participatif et contributif :

FAI, hébergeurs et éditeurs de site ou auteurs d’un blog ouvert aux contributions des internautes devront bientôt stocker une multitude d’informations concernant les internautes. Adresses IP, informations bancaires et civiles, mais aussi pseudos utilisés sur les forums, mots de passe et questions secrètes devront être collectées et laissées à disposition des juges et de l’Etat. Surtout, les hébergeurs, éditeurs de site et blogueurs pourraient être obligés de conserver la trace de chaque version de contenus créés et modifiés par les internautes.

[…]

Objectif : permettre à l’autorité judiciaire ou administrative de remonter jusqu’à l’auteur d’un propos délictueux, ou suspecté, par exemple, de représenter un risque pour la sécurité de l’Etat.

[…]

Un hébergeur aura obligation de connaître la nature de chaque modification faite sur un site.

[…]

Le Groupement des éditeurs de services en ligne (Geste) s’en inquiète. […] L’association a fait valoir que les coûts de stockage, s’il tant est qu’il est possible techniquement, entraîneraient entre plusieurs centaines de milliers et un million d’euros de perte nette à chaque éditeur.

[…]

Un internaute pourra être poursuivi, en théorie, 4 ans après avoir publié un contenu sur Internet, sans même connaître les raisons pour lesquelles ces informations ont été recueillies.

Le dossier comporte un document PDF avec le texte du décret.

Le Monde.fr

Polémique sur la rétention des données informatiques par Stéphane Foucart :

La version de travail, que Le Monde a pu consulter, fédère contre elle les associations de défense des libertés et les industriels du secteur.

[…]

Le texte semble trop vague aux acteurs économiques du secteur, qui redoutent d’avoir à conserver l’intégralité des modifications apportées à un contenu.

[…]

L’association Iris rappelle que ces données peuvent être demandées dans le cadre « d’enquêtes administratives et non judiciaires » – c’est-à-dire menées hors du contrôle d’un magistrat.

L’Etat veut-il tuer Internet en France ? par Philippe Jannet (président du Geste) :

Cette mesure ne pourrait que déclencher une défiance immédiate des Français à l’égard de leur téléphone mobile ou fixe, comme à l’égard des acteurs français d’Internet, assassinant instantanément l’économie numérique française.

[…]

De l’avis unanime des spécialistes, c’est économiquement et techniquement impossible. Même les Etats-Unis de George W. Bush et leur « Patriot Act » post-11-Septembre n’ont jamais envisagé pareille conservation ou réglementation, qui soulèverait sans doute l’opinion publique américaine d’aujourd’hui, mais s’opère sans bruit en France.

[…]

Des données récoltées sur la base de requêtes administratives initialement motivées par la prévention du terrorisme pourraient se retrouver dans le dossier d’un juge d’instruction en charge d’une affaire de droit à l’image, de diffamation ou de contrefaçon, par exemple, sans que les personnes mises en cause par des traces informatiques vieilles de 4 ans, puissent connaître – ni contester – l’origine ou la pertinence de ces données, ni le contexte dans lequel elles avaient été recueillies, en dehors de toute procédure judiciaire, sans magistrat ni contradictoire, quatre ans auparavant.

[…]

Sous prétexte de lutter contre la menace réelle du terrorisme, l’Etat français prend – comme aucun autre – le risque de tuer une part non négligeable de l’avenir du pays, sans aucun état d’âme et dans le silence assourdissant d’une campagne présidentielle omniprésente sur Internet, mais muette sur le développement de l’Internet.

Une synthèse

Christian Fauré :

Ce qui émeut le plus Philippe Jannet, en tant que président du GESTE (TF1, Google France, M6, Skyrock, la presse en ligne, etc.), c’est que ces acteurs français de l’Internet vont devoir financer cette traçabilité pour le compte de l’État. L’article du Monde pourrait laisser croire que le GESTE s’inquiète de la confidentialité des données et des pratiques de ses clients : il n’en est rien.

L’État français crée sa propre autorité de certification racine

Voilà une nouvelle que j’attendais depuis 6 ans ! Avant d’expliquer pourquoi, voici la définition d’une autorité de certification (selon le site de sécurité de Teamlog) :

Une Autorité de Certification appelée aussi AC ou CA (Certificate Authority) est chargée d’émettre et de gérer des certificats numériques.

Elle est responsable de l’ensemble du processus de certification et de la validité des certificats émis. Une Autorité de Certification doit définir une Politique de certification qui va établir l’ensemble des règles de vérification, de stockage et de confidentialité des données appartenant à un certificat ainsi que la sécurité de stockage de sa propre clef privée nécessaire à la signature des certificats.

Les certificats émis par ces autorités permettent d’accéder à des services web sécurisés (paiement en ligne, consultation de comptes bancaires, services administratifs), mais aussi de signer des documents numériques pour en certifier l’origine et le contenu (e-mails, contrats, certificats de déclaration). Ils garantissent donc l’authenticité, la sécurité et la confidentialité des informations.

Le problème, c’est que les autorités de certification racine (celles qui certifient les autorités de certification, dites « autorités de certification déléguées ») sont toutes des sociétés de droit privé étrangères (pour ne pas dire américaines…). Dès lors, comment garantir le contrôle, la confidentialité et la fiabilité des échanges sécurisés de l’État français ? Pourquoi dépenser des sommes importantes dans la sécurisation des échanges, si la base est faillible ? J’ai souvent été confronté à ce dilemne lors de mes interventions dans des institutions publiques… sans avoir d’autre choix que d’installer des certificats américains sur des serveurs de l’administration française !

En devenant lui-même autorité de certification racine (grâce au RGS, Référentiel Général de Sécurité, qu’il vient de créer), l’État français gagne enfin son indépendance. Dorénavant, les services administratifs pourront obtenir des certificats du RGS pour permettre aux agents et aux administrés d’échanger des données en toute confiance.

Cependant, il reste deux zones d’ombre :

  • Les navigateurs web vont devoir intégrer la reconnaissance du certificat racine du RGS (pour Firefox, ce sera vite fait, pour Internet Explorer, je suis beaucoup moins sûr…).
  • Les entreprises privées et les particuliers doivent toujours assurer la sécurité de leurs informations sur des certificats racine délivrés par des sociétés américaines.

Source : linuxfr.org