AlcionTech

Aller au contenu | Aller au menu | Aller à la recherche

Tag - Protocoles internet

Fil des billets - Fil des commentaires

jeudi 14 décembre 2006

6 erreurs fréquentes en sécurité informatique

Même si les attaques arrivent en général par le réseau, ce sont les outils que nous choisissons et nos pratiques de développement logiciel qui déterminent la résistance des systèmes aux attaques, et non pas l'intervention a priori ou a posteriori d'un ingénieur sécurité. Que de responsabilités !
Voici le résumé d'un guide de survie, "les 6 idées stupides en sécurité informatique", l'expérience montrant que ce sont les idées les plus séduisantes et/ou sensées qui conduisent aux pire catastrophes :

  • Permissions par défaut : une expression à bannir. Le défaut doit être l'interdiction. Le firewall d'un site web qui rejette les URLs malicieuses ? Non, il ne laisse passer que les URLs autorisées.
  • Liste des attaques : mauvaise approche, puisqu'il en arrive de nouvelles tous les jours (80000 virus identifiés). Il est plus facile de lister les utilisations légitimes d'un réseau ou d'une application, et de bannir tout le reste.
  • Pénétration/correction : refuser la logique qui voudrait qu'un logiciel / un système puisse être amélioré au fur et à mesure que ses vulnérabilités sont découvertes. Si c'était le cas, IE serait devenu sûr et le nombre de vulnérabilités découvertes diminuerait. L'alternative ? Concevoir le logiciel avec la sécurité en tête. Des exemples : QMail, Postfix...
  • Les hackers sont cool, il faut les excuser : non, ce sont des sociopathes qui détruisent volontairement.
  • Former les utilisateurs : nécessaire mais insuffisant. Si ça marchait, personne n'ouvrirait plus de pièce jointe exécutable.
  • Agir plutôt qu'attendre : non, car agir vite fait prendre les mauvaises décisions. Mieux vaut attendre d'avoir des retours d'expérience que d'installer la nouvelle passoire juste parce qu'elle est à la mode.
  • un septième point ? A lire directement dans l'article, avec les exemples, assez savoureux.

Autre sujet, même question, celle de la confiance que l'ingénieur peut avoir dans le résultat de ce qu'il produit : les "Observations personnelles sur la sûreté de la navette spatiale" du (grand) physicien Richard Feymann.

lundi 4 décembre 2006

Concevoir des services Web facilement en Java : XFire, la solution ?

Les services Web sont utilisés depuis plusieurs années, mais ils présentent toujours des inconvénients majeurs. Il ne sera pas question ici de limitation d’ordre fonctionnel, mais plutôt de difficultés de mise en œuvre. Tout d’abord, dans le monde Java, sont proposés de nombreux – et même de trop nombreux – environnements d’exécution pour services Web, ce qui ne facilite pas toujours le choix de l’architecte logiciel. Citons, parmi les plus connus, Axis du projet Apache, JWSDP de Sun, WebLogic de BEA, WebSphere d’IBM, etc. XFire est un projet Open ayant pour objectif d'offrir une implémentation SOAP en Java aussi performante que simple d’utilisation. Le framework XFire est disponible à l’adresse http://xfire.codehaus.org.

vendredi 17 novembre 2006

<billet title="XML a 10 ans">

Thinking XML: The XML decade

mercredi 21 juin 2006

Développer en AJAX avec Google

AJAX (Asynchronous javascript and XML) désigne un ensemble de technologies permettant la réalisation d'interfaces utilisateurs utilisables dans un simple navigateur, mais au rendu bien plus dynamique que le HTML. De plus en plus utilisé sur le web grand public (maps.google.com...), AJAX s'étend aujourd'hui aux applications intra/extranet, en mal d'ergonomie. Dès 2002/2003, Alcion a mené un grand forfait pour la réalisation d'une plate-forme de téléconférence couplée téléphone/web, qui reposait sur les principes AJAX.
desktopclone.jpg Depuis quelques semaines, le développement AJAX est entré dans l'age adulte grâce à la décision de Google de distribuer gratuitement le framework utilisé en interne le Google Web Toolkit (GWT). Une des qualités majeures de cette solution est qu'elle est J2EE et épargne l'essentiel du développement HTML/Javascript au réalisateur de l'application. Cela tombe bien, c'était le plus délicat et sujet aux bugs et aux incompatibilités entre navigateurs.
L'assemblage des widgets graphiques est déclaratif et n'est pas sans rappeler Swing, jusqu'aux mécanismes de listeners pour la gestion événementielle :

public class Hello implements EntryPoint {
  public void onModuleLoad() {
    Button b = new Button("Click me", new ClickListener() {
      public void onClick(Widget sender) {
        Window.alert("Hello, AJAX");
      }
    });
    RootPanel.get().add(b);
  }
}


http://code.google.com/webtoolkit/

Corba, les leçons de l'echec d'un standard

En 1998, CORBA a failli devenir le standard de communication pour les applications distribuées. En 2006, Corba n'occupe plus que quelques niches dans un écosystème qui s'est à présent enrichi de RMI, des Webservices, et de l'EAI. Cet article pointe comment les déficiences du processus de standardisation ont conduit à cette situation. Une leçon à retenir quand nous faisons des choix technologiques : privilégier les principes éprouvés, qui marchent, qui ont été testés. http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=396