Suport technique et veille technologique
Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.
C’est alors la barrière de la prise en main qui fait peur, et pourtant...
Les logiciels libres
L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.
Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.
Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.
Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.
- Septembre 2017 -
Le groupe de travail SACM de
l'IETF bosse sur une architecture, un
modèle de données, et des protocoles pour suivre l'état de la
sécurité de ses machines. Ceci est son deuxième RFC, qui
vise à définir le cahier des charges de la future solution.
Le cœur de cette idée est l'évaluation de la sécurité sur
chaque machine du réseau. Il faut la déterminer, et acheminer le
résultat jusqu'aux responsables de la sécurité. Cela nécessite
donc un modèle de données (comment on décrit « la sécurité d'une
machine » ?) puis un protocole permettant de gérer un très grand
nombre de machines. Parmi les informations à récolter sur chaque
machine, on trouvera évidemment la liste des logiciels installés,
les logiciels serveurs en activité qui écoutent sur le réseau,
l'état de la mise à jour (« pas pu joindre le dépôt officiel de
logiciels depuis N jours »), etc. Le cahier des charges décrit
dans ce RFC part des scénarios d'usage du
RFC 7632. Ce sont souvent de grandes généralités. On est loin de
mécanismes concrets.
La section 2 forme l'essentiel de ce RFC, avec la liste des
exigences du cahier des charges. Je ne vais en citer que
quelques unes. La première, nommée G-001 (« G » préfixe les exigences
générales sur l'ensemble du système SACM), demande que toute la solution
SACM soit extensible, pour les futurs besoins. G-003 est la
possibilité de passage à l'échelle. Par
exemple, les messages échangés peuvent aller de quelques lignes à,
peut-être plusieurs gigaoctets si on fait une analyse détaillée
d'une machine. Et il peut y avoir beaucoup de machine avec des
échanges fréquents (le RFC n'est pas plus précis sur les
chiffres).
Les données traitées sont évidemment sensibles, et G-006
demande que la solution permette évidemment de préserver la
confidentialité des données.
Les exigences sur l'architecture de la future solution sont
préfixées de « ARCH ». Ainsi, ARCH-009 insiste sur l'importance
d'une bonne synchronisation temporelle de toutes les machines. Un
journal des connexions/déconnexions des utilisateurs, par exemple,
n'aurait guère d'intérêt si l'horloge qui sert à l'estampiller
n'est pas exacte.
D'autres sections décrivent les exigences pour le modèle de
données et pour les protocoles, je vous laisse les découvrir.
RFC 9562: Universally Unique IDentifiers (UUIDs)
- 12 mai -
Ce RFC normalise les UUID, une famille d'identificateurs uniques, obtenus sans registre central. Il remplace l'ancienne norme, le RFC 4122, avec (...)
RFC 9490: Report from the IAB Workshop on Management Techniques in Encrypted Networks (M-TEN)
- 9 mai -
Aujourd'hui, l'essentiel du trafic sur l'Internet est chiffré, et pour d'excellentes raisons. Pas question de revenir là-dessus, mais, ceci dit, il (...)
RFC 9557: Date and Time on the Internet: Timestamps with Additional Information
- 29 avril -
Ce RFC modifie légèrement le format des estampilles temporelles du RFC 3339, changeant à la marge une définition et, surtout, permettant d'y attacher (...)
RFC 9567: DNS Error Reporting
- 27 avril -
Lorsqu'un résolveur DNS détecte un problème avec une zone, l'empêchant de résoudre les noms dans cette zone, il n'avait pas de moyen simple et (...)
RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)
- 8 avril -
Ces deux nouveaux types d'enregistrement DNS, SVCB et sa variante HTTPS, permettent de donner des informations supplémentaires à un client réseau (...)
