SFH - Réécriture du coeur des SFH en RFC

Portrait de Lab Reseaux Et Techniques
Document de travail
Tag(s) :

Lors du premier BarCamp du Lab Réseaux et Techniques, l'idée de réécrire le coeur des SFH en tant que RFC a fait l'unanimité. Les fonctionnalités coeur des SFH étant de faire remonter des notifications en accord avec les profils utilisateurs définit par le titulaire de l'abonnement et des bases de connaissances extérieures : 

  • des listes noires d'entités informatiques (mot clés, sites web, plage d'adresses IP, plage de ports, protocoles,…)

  • des listes blanches d'entités informatiques

  • un ensemble de règles de sécurité

  • un ensemble de définitions des notifications  

Cette réécriture en RFC permettra de toucher un plus large public et pourra également servir de base au cahier des charges nécessaire à la labellisation. Cette analyse permettra aux membres du Lab Réseaux et Techniques de rédiger cette RFC.

Pour vous inscrire au Lab, cliquez ici : http://labs.hadopi.fr/user/register. 

Réécriture en RFC

RFC est l'acronyme pour « Requests For Comments » signifiant « demande de commentaires ». Les RFC sont des documents officiels décrivant les spécifications  des protocoles, méthodes, fonctionnalités applicables au fonctionnement de l'Internet et les systèmes connectés à Internet. La réécriture du coeur des SFHs en RFC permettra de toucher un plus large public et pourra également servir de base au cahier des charges nécessaire à la labellisation.

Coeur des SFH

Chers membres, à vos claviers...

Commentaires

Portrait de Erebuss

Avant d'avoir accès à ce système collaboratif, j'ai commencé à faire un brouillon du plan de cette "SFH-Base". Il est accessible et demande collaboration à l'URL http://pad.1x4x.net/SFH-base

Je vous le soumets comme base de travail, pour avis et éventuellement inspiration.

  • Description Basique
    A quoi cela sert et la logiquement de fonctionnement de cette base.
  • Profils Utilisateur
    Comment sont-ils gérés ? Quelles options permettent-ils à l'utilisateur (i.e.: Un profil donné ne pourrait  pas permettre à l'utilisateur concerné d'ajouter  des exceptions à ses listes etc.)
    Devons-nous nous contenter des profils de base décrits dans les SFH originelles ? Les profils autorisent-ils un héritage => Un utilisateur est un profil "type" + un profil individualisé ?
  • Listes
    Quelles sont les informations portées par une liste : catégorisation comme pour les filtres parentaux, description ? Comment sont définies les entités les constituantes ? Ces listes sont elles standardisées pour éventuellement que la récupération puissent se faire au travers de différents fournisseurs ? etc.
    Cette partie sera le résultat des discussions menées ici vraisemblablement.
  • Règles
    Les règles s'appliqueront par rapport aux listes  liées à un profil. C'est elles qui lèveront des notifications. Sont-elles standardisées (Je sauvegarde mes règles pour pouvoir les passer de mon PC à mon MAC etc ...)
    Elles risquent/devront être abordées dans la discussion avec les listes.
  • Notifications
    Quelles informations doivent transmettre une notification pour pouvoir être interprété par un Interface Graphique, un service de Monitoring etc. Utilisation d'un format standardisé  ?
  • Analyse
    Comment les données seront amenées à être traitées par la corrélation des listes avec les règles. Comment lèveront-elles des notifications ?
  • Journalisation.
    Qu'est ce qui doit être journalisé? Où doivent être ces journaux (possibilité de les externaliser avec l'accord de l'utilisateur ? )? Existent-ils plusieurs journaux (un pour le fonctionnement de l'applicatif, un pour les notifications etc.) Cette partie sera traitée vraisemblablement ici

 

Les parties Liste/Règles peuvent sans doute être fusionnées. Ce qui nous donnerait comme plan :

  • Description
  • Profil Utilisateur
  • Listes/Règles
  • Notifications
  • Analyse
  • Journalisation

Je crois que cela correspond à notre philosophie de "base", c'est-à-dire sans question de système d'exploitation, d'interface graphique, contextes d'utilisation (foyer, entreprise, CROUS...), etc., qui eux pourront  être traités dans des recommandations  supplémentaires (des RFC liées ? ).
Cette distinction permettra une évolution rapide de ces spécificités sans pour autant impacter la base fonctionnelle.

Qu'en pensez-vous ?