L’authentification multifacteur (MFA) est une méthode qui renforce la connexion à vos comptes, applications ou VPN, car elle nécessite au minimum deux facteurs de vérification. Aujourd’hui, l’utilisation d’un identifiant et d’un mot de passe n’est pas suffisamment fiable.
Vos codes sont vulnérables d’autant plus si vous les choisissez faciles à retenir et que vous les réutilisez sur d’autres sites. Preuve en est cette étude de 2017 réalisée par SplashData, qui place «123456» et «password» en tête de liste des mots de passe les plus courants. Avec l’authentification forte ou MFA, votre identité est vérifiée de manière sécurisée sans mot de passe obligatoire.
Son fonctionnement repose sur l’utilisation d’au moins 2 facteurs parmi les suivants :
Pour une connexion plus sécurisée, Microsoft a développé Azure Active Directory, un ensemble de services permettant la gestion des identités et des accès grâce à une base de données cloud. Pour répondre aux besoins spécifiques de chacun, Azure AD offre différentes solutions d’authentification multifacteur pour sécuriser vos applications. Vous pouvez les associer à votre système d’exploitation avec ou sans mot de passe.
En cas d’oubli de mot de passe, de perte ou de vol de support physique d’authentification (badge, clé Fido 2), de problème sur un capteur biométrique, ou de batterie sur son téléphone, il existe une option de vérification simplifiée qui permet la réinitialisation de votre mot de passe : le SSPR (Self-Service Password Reset).
Pour les professionnels, Windows Hello Entreprise est la solution idéale. Une fois configurée sur l’appareil, l’authentification est biométrique, soit par reconnaissance faciale, empreinte digitale ou scanners d’iris. Pour optimiser la précision, Windows Hello combine caméras spéciales et logiciels. L’avantage de cette technique est que les données sont stockées uniquement sur le PC de l’utilisateur. En cas de vol, il n’y a aucune possibilité de pirater les informations sans empreintes biométriques. Cette option peut également être paramétrée pour chaque utilisateur d’un même appareil.
Windows Hello Entreprise peut également fonctionner avec des clés matérielles ou logicielles, ou des certificats.
La FIDO Alliance (Fast Identity Online) a développé cette méthode d’authentification par clés de sécurité dans le but d’éliminer progressivement les mots de passe. Associée à la connexion classique (nom d’utilisateur/mot de passe), les clés FIDO 2 sont générées et vérifiées, puis fournissent une base chiffrée permettant la connexion. Concrètement, après inscription auprès du service en ligne, l’utilisateur reçoit une clé privée (stockée sur son appareil) et une clé publique (FIDO 2) qui est enregistrée dans la base de données du service Web. L’authentification ne peut avoir lieu que si l’utilisateur déverrouille sa clé privée. Cette méthode peut offrir plus de facilité aux employés en entreprise pour se connecter à leur appareil Windows, notamment s’il est combiné à Azure AD.
Toujours dans le but d’offrir une méthode de connexion avec un niveau de sécurité élevé, Microsoft propose une application gratuite : Microsoft Authenticator. Ce mode permet de s’authentifier sans mot de passe lors de la connexion. L’utilisateur a deux solutions pour justifier son identité, soit grâce à une notification qu’il reçoit via l’application et qu’il doit valider, soit par un code de vérification OATH généré par Microsoft Authenticator et qu’il faut ensuite entrer dans une interface de connexion.
Ces jetons d’authentification, appelés Tokens, sont un dispositif matériel ou logiciel. Leur but est de générer un One-Time Password (OTP) qui vous permet de vous connecter après avoir rentré la combinaison classique identifiant et mot de passe personnel. Le token logiciel est un élément virtuel installé sur l’équipement de l’utilisateur (ordinateur, smartphone, tablette). Il s’obtient par des applications comme Microsoft Authenticator, FreeOTP, Google authenticator, LastPass Authenticator, Authy, etc. Le token matériel se présente le plus souvent sous forme de carte d’affichage, petit boîtier avec panneau électronique et bouton, en porte-clés ou dispositif USB (YubiKey). Ils offrent chacun différents modes de fonctionnement. Les tokens basés sur le temps (TOTP) génèrent un code OTP toutes les 30 ou 60 secondes, et les tokens basés sur les évènements (HOTP) en créent un nouveau lorsque l’utilisateur appuie sur un bouton. L’avantage des jetons logiciels par rapport aux jetons matériels pour les entreprises est qu’ils les dispensent de frais logistiques supplémentaires, et ils peuvent être régulièrement mis à jour.
Cette méthode d’authentification est plus pratique puisqu’elle n’exige aucune application ou clé, mais elle reste moins sécurisée. Le fait d’être obligé de divulguer votre numéro de téléphone sur un site vous expose à des risques, et votre SMS peut également être intercepté. Certaines applications disposent même de mécanismes d’interception des codes OTP. Vous n’êtes pas non plus à l’abri du SIM swapping, c’est-à-dire l’échange de carte SIM, certes moins répandu en France. Dans ce cas, le hacker cible sa victime, et s’il parvient à prendre le contrôle du numéro de téléphone, il s’ouvre aussi l’accès aux comptes et données personnelles associées.
Pour se protéger des cybercriminels, il est évident que la MFA est un gage de sécurité. Microsoft recommande le mode « passwordless », c’est-à-dire l’authentification sans mot de passe, cependant le choix doit être fait en fonction de vos besoins et des risques. Pour les entreprises, Window Hello Entreprise est une méthode de protection renforcée qui reste simple pour les employés. Pas de mot de passe à retenir, la prise en charge est intégrée au système d’exploitation et les informations sont stockées uniquement sur l’appareil. L’utilisation des Clés FIDO 2 offre également une excellente protection notamment contre l’hameçonnage (phishing). L’application Microsoft Authenticator est elle aussi très fiable, et elle permet également l’utilisation de Jetons OATH. La méthode basique par SMS ou appel vocal paraît plus simple, mais reste la plus vulnérable. Le risque zéro n’existant pas, la vigilance doit rester de rigueur. Pour toutes vos questions concernant la sécurité, l’analyse de risques, les pentests, ou bien si vous souhaitez évaluer la résistance de votre système informatique, Devensys Cybersecurity et son équipe d’experts sont à votre service.
*source : cybermalveillance.gouv.fr
]]>SELinux est un système de sécurité pour Linux permettant de limiter les actions possibles en fonction d’une politique de sécurité, il permet d’appliquer notamment différentes méthodes de contrôle d’accès obligatoire. SELinux a un fonctionnement différent de celui d’Apparmor, mais il est également bien plus complet (et complexe !). Il se base sur des étiquettes attribuées à des ressources en plus de politiques. Celui-ci est activé par défaut sur Red Hat Enterprise Linux (et dérivés) et il est fortement recommandé de le laisser activé.
Apparmor est un autre module de sécurité et de contrôle d’accès obligatoire pour Linux. Celui-ci repose principalement sur des chemins de fichiers. Cependant, il peut limiter l’accès à de nombreuses autres ressources et capabilities. Sa configuration est uniquement textuelle et sous forme de profils par application. Combiné avec ses outils d’administration, il est simple et rapide à mettre en place.
Ces deux outils sont capables de fonctionner en mode alerte uniquement (Complain/Permissive), ce qui permet de ne pas perturber le bon fonctionnement de vos services. Les messages générés signalent toute infraction et fournissent une trace auditable. C’est pourquoi il est vivement conseillé d’activer ces modules même s’ils ne seront jamais en mode strict/défense. (enforce)
Il est également possible d’installer des antivirus (gratuit comme ClamAV, ou commerciaux comme Microsoft Defender for Endpoint), ce qui est parfois requis par le niveau de sécurité choisi par votre entreprise (ou même la législation en vigueur)
Aujourd’hui, nous allons nous concentrer sur Apparmor, de par le niveau plus réduit de configuration requis. Dans cette optique, nous allons protéger un serveur Nginx en créant des règles de sécurité. Le nombre de règles disponibles sur internet est limité, il est donc probable que rédiger des règles propres à votre infrastructure soit nécessaire. Nous considèrerons que la distribution utilisée est Debian Linux pour toucher le plus grand nombre d’utilisateurs.
Avant de démarrer, nous allons rappeler ce que sont les capabilities sous Linux, vu que cette notion entrera en jeu un peu plus tard lors de la configuration. Historiquement, l’utilisateur administrateur ROOT possédait tous les droits sur la machine, sans aucune restriction. C’est pourquoi le système de capabilities a été introduit. Toutes les permissions de l’utilisateur root sont maintenant séparées en capabilities. Par exemple, net_bind_service permet à un programme de se positionner en écoute sur un port privilégié (en dessous de 1024), mais n’octroie aucune autre permission. Il est donc possible d’être administrateur ROOT avec aucune capabilities et donc sans les pleins pouvoirs. Inversement, un programme avec un utilisateur non privilégié peut obtenir des capabilities supplémentaires, obtenant une partie du pouvoir de ROOT.
Apparmor est administré avec différents outils de gestion, ceux-ci ne sont pas toujours installés par défaut. C’est pourquoi la première étape sera de corriger cela :
sudo apt install apparmor-easyprof apparmor-profiles apparmor-profiles-extra apparmor-utils nginx
La commande précédente a également installé le serveur Nginx s’il n’était pas déjà installé. Nginx est fourni avec une page web d’exemple qui sera suffisante pour cet article. Mais si vous possédez une application web avec sa configuration nginx associée, vous pouvez les utiliser sans problème. (Bien entendu, évitez de faire ceci en production sans avoir testé la solution au préalable)
La manière la plus simple de créer un profil Apparmor est tout simplement de prendre un profil de base ou vide et d’activer le mode « complain ». Par défaut tout est refusé, c’est donc en utilisant les messages d’infraction de ce mode qu’il est donc possible de créer notre profil par « apprentissage ». Il est essentiel que le comportement de l’application pendant ce temps d’apprentissage soit normal et correct, et que toutes les fonctionnalités de l’application soient exploitées. Dans le cas contraire, notre profil ne serait pas complet : car une fonctionnalité non explorée lors de l’apprentissage pourrait solliciter une ressource que nous n’avions pas autorisée dans notre profil AppArmor.
Les profils sont stockés dans le dossier /etc/apparmor.d, avec comme nom le chemin de l’exécutable à limiter avec les slash « / » remplacés par des points « . » . Un utilitaire existe pour créer un profil initial :
sudo aa-autodep /usr/sbin/nginx
Ensuite, activons le profil en mode « complain »
sudo aa-complain nginx
Redémarrons nginx : sudo service nginx restart
Maintenant, naviguez avec votre navigateur web sur la page par défaut d’Nginx. (http://127.0.0.1 ou l’IP du serveur) Si vous avez une application existante, utilisez un maximum de fonctionnalités. (Tout particulièrement si vous avez choisi un autre programme que Nginx Il s’agit de créer une empreinte du comportement normal de l’application.
Une fois l’apprentissage terminé, il suffit d’examiner les infractions et valider celles qui sont normales, afin de les ajouter en tant qu’exception dans notre profil Apparmor. Pour cela, nous allons utiliser aa-logprof :
sudo aa-logprof
Ce programme va parcourir tous les messages d’infraction et demander, une par une quelle action est désirée. La décision sera retranscrite dans le profil.
Nous allons passer en revue toutes les actions nécessaires, ce qui nous permettra également de voir une majeure partie des cas de figure qui seront applicables à d’autres applications. Les infractions ne seront pas obligatoirement identiques ou listées dans le même ordre sur votre terminal. Une réflexion restera tout de même nécessaire pour ajuster la politique aux besoins de votre installation.

Ce menu nous permet de choisir si l’infraction est erronée et doit être autorisée et ajoutée au profil. Celui-ci sera répété pour chaque infraction et nous allons voir ses différentes variantes.
Ici, la capability dac_override permet d’ignorer le contrôle d’accès sur les fichiers. De la même manière que les permissions sur les fichiers ne s’appliquent pas à l’utilisateur root (par défaut). Cette permission est nécessaire si le fichier de log d’Nginx n’appartient pas à un groupe ou utilisateur dont Nginx fait partie. Ce qui est le cas par défaut. Si vous changez le propriétaire du fichier à l’utilisateur d’Nginx (www-data) dans ce cas vous pouvez appuyer sur D ou I pour refuser cet accès. Sinon dans la majorité des cas, appuyez sur A pour autoriser. Notez que cette capability reste limitée par Apparmor, même en la possédant il reste impossible d’accéder à des fichiers auxquels Apparmor bloque l’accès.

Cette infraction est une tentative d’accès en écriture à un fichier. Ici, il s’agit du fichier de log d’erreur, autorisez en appuyant sur A. Faites de même pour /var/log/nginx/access.log quand demandé.

Ici, nous avons un premier exemple de multiples actions possibles. Celles-ci sont numérotées de 1 à 3. Les crochets [ et ] marquent la ligne et l’action actuellement sélectionnée. Pour en changer, appuyez sur le numéro correspondant ou tout simplement utilisez les touches fléchées du clavier.
Les lignes contenant un #include indiquent qu’Apparmor a détecté un profil de base contenant les permissions nécessaires pour autoriser cette infraction. C’est à vous de décider si la suggestion est judicieuse.
Dans ce cas, le profil /abstractions/openssl correspond parfaitement, donc gardez-le sélectionné et appuyez sur A pour l’autoriser.

L’accès à la configuration est bloqué, ce cas est similaire au cas des logs, mais l’accès est en lecture uniquement (r) . Sélectionnez A.

Ici, nous avons deux nouveautés, tout d’abord c’est une permission sur un dossier, en lecture (r). Ensuite, le profil de base détecté n’est pas correct. Totem est un lecteur multimédia, et n‘a aucun rapport avec notre application. Utiliser ce profil accorderait bien trop de permissions inutiles à Nginx. Utilisez les flèches ou la touche 2 du clavier pour sélectionner l’action owner /etc/nginx/modules-enabled/ r . owner signifie que Nginx doit être propriétaire du fichier/dossier concerné.

Même problématique ici. Le profil totem n’est pas le plus adapté. Cependant autoriser uniquement le fichier mod-http-geoip.conf semble trop restrictif, il parait plus logique d’autoriser Nginx à lire tous les fichiers de configuration des modules. Pour cela, sélectionnez G ou E. E est plus restrictif donc le plus adapté. G autorise tous les fichiers du dossier et E tous les fichiers avec l’extension indiquée (.conf). Le tout dans le monde indiqué : lecture (r). N’oubliez pas de vérifier que la nouvelle option est bien sélectionnée après avoir sélectionné G ou E et avant de confirmer avec A :


Ce fichier contient le numéro de processus. Nous pouvons lui donner la permission en lecture et écriture (rw). Sélectionnez A.

Ici, il s’agit de donner l’accès aux fichiers des pages web. En principe, il est nécessaire de donner accès à tous les fichiers récursivement dans ce répertoire du site web. Mais le profile présélectionné web-data s’en charge déjà. Validez avec A.
De la même manière, autorisez également :

Pour terminer, le profil nameservice est correct. Sélectionnez-le avec A.
Une fois à la fin des infractions, aa-logprof demande une confirmation pour sauvegarder ces changements dans le fichier du profil :

Appuyez sur S pour les sauvegarder.
Au moment de l’écriture de cet article, une fois le profil sauvegardé, une permission nécessaire n’est pas automatiquement assignée dans le profil. Nous allons donc l’ajouter manuellement.
En effet, Nginx fonctionne à l‘aide d’un processus parent et de processus enfants effectuant le travail. Le processus parent nécessite la permission d’exécuter les processus enfants en tant qu’utilisateur moins privilégié. Il a besoin des capacités (capabilities) setgid et setuid . Nous allons également ajouter deux autres capabilities, pour autoriser l’écoute sur un port privilégié. (80)
Sudo nano /etc/apparmor.d/usr.sbin.nginx

Profitons-en pour assouplir certaines permissions qui n’ont pas pu être détectées par aa-logprof, car l’installation par défaut d’Nginx sous Debian n’est pas très complexe.

Une fois que vous avez inspecté les règles pour confirmer leur cohérence, vous pouvez les sauvegarder et quitter (CTRL+S puis CTRL+X).
Voici le fichier au complet :
#include <tunables/global>
/usr/sbin/nginx {
#include <abstractions/base>
#include <abstractions/nameservice>
#include <abstractions/openssl>
#include <abstractions/web-data>
capability dac_override,
capability dac_read_search;
capability net_bind_service;
capability setgid,
capability setuid,
/usr/sbin/nginx mr,
/var/log/nginx/access.log w,
/var/log/nginx/error.log w,
owner /etc/nginx/conf.d/ r,
owner /etc/nginx/mime.types r,
owner /etc/nginx/modules-enabled/*.conf r,
owner /etc/nginx/nginx.conf r,
owner /etc/nginx/sites-available/* r,
owner /etc/nginx/sites-enabled/* r,
owner /run/nginx.pid rw,
owner /usr/share/nginx/modules-available/*.conf r,
}
Pour recharger ce profil uniquement, utilisez
Sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx
( Pour recharger toutes les règles : systemctl reload apparmor )
Passez maintenant le profil en mode bloquant/strict : sudo aa-enforce nginx
Maintenant, il suffit de redémarrer Nginx : systemctl restart nginx
Sudo aa-status devrait afficher les processus comme « confined » :

Si vous vous rendez sur la page d’exemple de Nginx (http://127.0.0.1 ou IP du serveur), la page s’affiche normalement sans problème.
Cependant, si l’on configure Nginx pour servir un dossier en dehors de /var/www/html, l’accès sera refusé au programme et celui-ci retournera une erreur HTTP 403.
Voilà, en cas de compromission du processus d’Nginx, celui-ci n’aura accès à aucun fichier du disque et ses permissions limitées rendront l’élévation de privilège très compliquée.
Pour aller plus loin :
Dans le cas ou un accès global à tous les sous-dossiers est nécessaire, il est possible de doubler le *. Par exemple, owner /etc/nginx/** r, autorise l’accès à tous les fichiers, dossiers et sous-dossiers (récursivement) possédés par l’utilisateur de Nginx dans le dossier /etc/nginx.
Apparmor est également capable de gérer les signaux Unix et les sockets Unix, si cela est nécessaire.
Ici, l’accès au réseau n’est pas limité. Au moment de l’écriture de cet article, cette fonctionnalité d’Apparmor n’est pas encore entièrement opérationnelle. Dans ce cas, d’autres modules de sécurité tels que SELinux peuvent être utilisés à la place d’Apparmor ou encore certains modules du pare-feu.
Par Jérémy LIMOUSIN
]]>Le CSIRT (Computer Security Incident Response Team) désigne l’équipe en charge de la réponse aux incidents de sécurité informatique. Cette entité est responsable de la gestion de crise cyber et de la veille autour des cybermenaces.
À la suite de la création de la première équipe CERT (comme nous l’avons vu précédemment) par l’autorité responsable du réseau Arpanet (DARPA – Defense Advanced Research Projects Agency), une structure permanente a été fondée, le CERT Coordination Center (Computer Emergency Response Team). L’appellation CERT devient alors une marque déposée aux États-Unis par l’Université Carnegie-Mellon.
Ainsi, l’appellation CSIRT est alors privilégiée dans beaucoup de pays étant libres de droits. Cependant, les CSIRT qui en font la demande et qui obtiennent l’autorisation peuvent utiliser le terme CERT au sein de leur nom, par exemple le CERT-FR.
CERT gouvernemental : CERT-FR (anciennement CERTA appartenant à l’ANSSI / SGDSN) est le CERT affecté au secteur de l’administration française
Ai CERT : CERT privé interne du Groupe Airbus
AlliaCERT : CERT de la société Alliacom ouvert à l’ensemble des entreprises et des institutions
AXA CERT : CERT privé interne du Groupe AXA
CERT-AKAOMA : CSIRT de la société AKAOMA proposant des services de cyber-surveillance et de réponse aux incidents de sécurité à l’ensemble des entreprises et institutions
CERT-AlgoSecure : CSIRT privé de la société AlgoSecure ouvert à l’ensemble des entreprises et des institutions
CERT-AG : CERT du Groupe Crédit Agricole et des filiales
CERT-AMOSSYS : CERT de la société AMOSSYS
CERT-AREVA : CERT privé interne du groupe AREVA
CERT-BDF : CERT de la Banque de France
Le CERT-FR | Agence nationale de la sécurité des systèmes d’information (ssi.gouv.fr)
Les CSIRT – CERT-FR (ssi.gouv.fr)
Morris : retour sur le premier ver informatique (informatiquenews.fr)
]]>CND est l’acronyme de Certified Netword Defender, une certification délivrée par EC-Council. La formation CND offre un cursus pratique en sécurité des réseaux, elle est composée de différents modules, incluant un programme intensif de labs animés par un formateur certifié, qui permet une réelle mise en situation de l’apprenant.
La formation CND a donc pour but d’acquérir des compétences en sécurité défensive des réseaux, elle s’adresse donc à de nombreux profils tels que :
La certification CND requiert des connaissances en infrastructures et réseau mais également en Windows et Linux afin d’être parfaitement à l’aise avec les différents modules de la formation.
Le CND est une formation certifiante qui se déroule sur 5 jours, pendant cette formation intensive en cybersécurité chez Devensys Cybersecurity à Montpellier, vous pourrez découvrir les modules suivants :
Pour rendre cette formation pratique, de nombreux labs sont intégrés aux modules de formation dans le but d’utiliser les techniques et les outils de sécurité dans un environnement pratique.
Devensys Cybersecurity est un centre de formation et d’examen officiel d’EC-Council, avec ses propres formateurs salariés (également consultants en cybersécurité) et son centre de formation basé à Montpellier dans le sud de la France.
Note : le pack de formation inclut toujours les 5 jours de formation en présentiel, le support de cours numérique et une présentation à l’examen (à passer dans les douze mois suivants la formation).
La certification CEH (Certified Ethical Hacker) est délivrée par EC-Council. Cette formation propose un cursus général en sécurité informatique afin de mieux comprendre les différentes cyber-menaces et de découvrir les techniques d’attaques des pirates pour mieux s’en protéger.
Très répandue dans le monde de la cybersécurité, la CEH est une formation avec un programme balayant de nombreuses facettes du hacking.
La CEH s’adapte donc à de nombreux types de profils comme :
Le plan de cours de la CEHv11 a été mis à jour et les modules de cours sont désormais les suivants :
Ce programme a pour but d’étudier toutes les techniques de hacking pour mieux connaître les méthodes et outils des cyber-attaquants afin de mieux les détecter et les contrer.
| Certification | CND | CEH |
| Durée de la formation | 5 jours (hors examen) | 5 jours (hors examen) |
| Examen | QCM (4h) 125 questions | QCM (4h) 100 questions |
| Score minimum | Variable selon la session d’examen | Variable selon la session d’examen |
| Prix | 3690€ | 3690€ |
| Pour qui ? | Administrateurs réseau, administrateurs sécurité réseau, ingénieurs sécurité réseau, techniciens défense réseau, analystes CND, analystes sécurité, responsables sécurité et toute personne étant impliquée dans des opérations réseau… | Responsable de la sécurité des systèmes d’informations, administrateur réseau, responsable informatique, décisionnaire… |
| Profil | Profil généraliste avec un fort attrait pour le réseau | Profil généraliste en cybersécurité |
| Compétences requises | Systèmes d’exploitation: Windows et Linux. Connaissance de l’administration des réseaux TCP/IP | Connaissances en réseau, Linux et Windows Server. |
| Formation certifiante | Oui | Oui |
Dans le monde actuel, tous les types de transactions nécessitent une authentification. Que vous soyez un patient nécessitant un traitement, un conducteur nécessitant un permis, un client payant avec une carte de crédit ou encore un passager embarquant dans un avion, vous devez toujours prouver que vous êtes bien ce que vous prétendez être. Vous devez fournir un passeport, une preuve d’assurance maladie, une carte de sécurité sociale ou une autre forme d’identification matérielle tangible pour prouver que le nom figurant sur le rendez-vous, la carte de crédit ou le billet d’avion vous appartient réellement.
Le monde de la délivrabilité fonctionne de la même manière. Afin de franchir les barrières des filtres ISP, vous devez prouver que vous êtes un expéditeur légitime. Vous devez prouver que vous n’envoyez pas au nom de quelqu’un d’autre et que votre identité n’a pas été compromise. Comment le prouver ?
En utilisant SPF, DKIM et DMARC.
Ce sont des acronymes pour les protocoles standards qui permettent de prouver l’authentification d’un expéditeur et de protéger le contenu dans le cadre d’un échange d’email.
Nous allons les décomposer.

SPF, ou Sender Policy Framework, est un protocole de validation de courrier électronique conçu pour détecter et bloquer l’usurpation de courrier électronique qui permet aux échangeurs de courrier de vérifier que le courrier entrant d’un domaine provient d’une adresse IP autorisée par les administrateurs de ce domaine. Un enregistrement SPF est un enregistrement texte trouvé dans l’enregistrement DNS (Domain Name System) qui spécifie quelles adresses IP et/ou quels serveurs sont autorisés à envoyer des messages depuis ce domaine. Cela ressemble à une adresse de retour sur une carte postale : la plupart des gens sont beaucoup plus susceptibles d’ouvrir une lettre si celle-ci a une adresse de retour fiable et reconnaissable à partir de laquelle elle a été envoyée.

Après l’envoi d’un message, les fournisseurs de services Internet vérifieront le domaine du chemin de retour. Ils compareront ensuite l’adresse IP qui a envoyé l’email à l’adresse IP répertoriée dans l’enregistrement SPF du domaine Return-Path pour voir s’il est aligné. Si tel est le cas, l’authentification SPF a été confirmée et le message sera remis.
SPF est un standard qui vous protège des spammeurs potentiels. Le spam par courrier électronique et le phishing utilisent souvent des adresses et domaines falsifiés. La publication et la vérification d’enregistrements SPF sont l’une des techniques antispam les plus fiables et les plus simples à utiliser . Si vous avez une bonne réputation en matière d’envoi, un spammeur peut tenter d’envoyer des courriers électroniques de votre domaine afin de s’affranchir de votre réputation auprès des FAI. Cependant, une authentification SPF révélera au FAI destinataire que le domaine peut vous appartenir, mais que le serveur n’autorise pas l’envoi de courrier pour votre domaine. Un enregistrement SPF dans un domaine de premier ordre (par exemple, mondomaine.com) authentifiera automatiquement tous les sous-domaines (exemple : mail.mondomaine.com) situés sous celui-ci qui ne contiendrait pas leur propre enregistrement SPF.
DKIM, ou DomainKeys Identified Mail, permet à une organisation (ou à un gestionnaire du message) d’assumer la responsabilité d’un message en transit. Selon DKIM.org , DKIM associe un nouvel identifiant de nom de domaine à un message et utilise la cryptographie pour valider l’autorisation de présence. L’identifiant est indépendant de tout autre identifiant dans le message, tel que dans le champ De: de l’auteur. DKIM est également une signature d’enregistrement TXT qui crée une relation de confiance entre l’expéditeur et le destinataire.

DKIM prouve trois choses:
DKIM utilise un algorithme de cryptage qui crée une paire de clés électroniques, une clé publique et une clé privée.
La signature se situe dans l’en-tête de chaque email envoyé. Elle est propre à votre domaine de messagerie, vous en possédez la clé privée. Cette clé privée correspond a une clé publique, qui est enregistrée dans votre DNS. Lorsque vous envoyez un message, le serveur qui le reçoit va aller regarder votre clé publique. Ainsi, il détermine si la clé privée a bien été utilisée lors de l’envoi du message afin d’y inscrire la signature cryptographique. Si la clé privée n’a pas été utilisée, alors le message est considéré comme non légitime.
Le chiffrement de la première clé ne peut être déchiffré que par l’autre clé. Un expéditeur publiera la clé «publique» dans l’enregistrement DNS et répertoriera son emplacement dans la signature DKIM avec le domaine «d =» et le sélecteur «s =». Le propriétaire du DNS garde la clé privée secrète. Si les informations contenues dans la signature décryptée correspondent aux informations reçues dans l’en-tête non crypté, le serveur considère que l’en-tête n’est pas falsifié pendant la transmission et la réception.
En d’autres termes, DKIM permet de signer un email par chiffrement numérique. Cette signature est un en-tête du message électronique. Voici un exemple de signature DKIM :
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1476054397;
s=m1; d=e.rentpath.com; [email protected];
h=Date:From:To:Subject:MIME-Version:Content-Type;
bh=Rm+zVdTj9mQiUHxMpu+O9d9OuV3cOTuaNWHONtEXYo0=;
b=oGVqGJKcS8KZ+YR8+AKzGKg2t1qpwKFXpg6jO3eU/MvQnl9hRpn9NYSR1vV20MSYvJP9ZBiG7hftTHxYUwrP/Ur4Gt4a6bzt6Q6KETOiUrksD1Jnvwt7YG/cwGqGfjfmuYU +/fk3oboohCsnvOI79hHrR8q/a0eCLnkL5BC7L1g=
Pour comprendre le fonctionnement interne de DKIM, il faudrait une connaissance approfondie de la cryptographie moderne. Retenons que DKIM est une pratique technique qui instaure une relation de confiance entre un serveur de messagerie expéditeur et un serveur de messagerie destinataire.
DMARC, ou Domain-based Message Authentication, Reporting and Conformance est une méthode d’authentification supplémentaire utilisant SPF et DKIM. Elle permet de vérifier si un courrier électronique a effectivement été envoyé par le propriétaire du domaine « Friendly-From ». Pour que les règles DMARC s’appliquent, SPF et DKIM doivent fonctionner et au moins l’un d’entre eux doit être aligné.

Les deux authentifications transmises indiquent que le courrier électronique provient d’un serveur autorisé et que les informations d’en-tête n’ont pas été altérées pour falsifier l’alignement. L’identité est validée si au moins un alignement d’authentification prouve que l’expéditeur possède l’espace DNS du «Friendly-From».
Pour que SPF s’aligne, le domaine From du message et son domaine de retour doivent correspondre. Pour que DKIM s’aligne, le domaine From du message et son domaine DKIM doivent correspondre.
Le serveur considère tout message non conforme comme un phishing. Il ne le distribuera pas. Le phishing est la pratique frauduleuse consistant à envoyer des courriels malveillants en prétendant être quelqu’un d’autre. Le but est de voler les données personnelles de l’utilisateur (carte de crédit, numéro de sécurité sociale…). En mars 2017, la Federal Trade Commission a publié une étude sur l’utilisation de DMARC par les entreprises. L’étude a révélé qu’environ 10% des 569 entreprises ayant une présence en ligne significative publient des politiques DMARC strictes.
Dans la mise en place d’un enregistrement DMARC, vous avez le choix entre 3 stratégies. Ces stratégies indiquent au serveur destinataire comment traiter le courrier envoyé, non conforme à DMARC.
Une implémentation efficace de DMARC passerait lentement de différents pourcentages de quarantaine à un rejet total. Un bon usage nécessite également que l’expéditeur surveille régulièrement les rapports DMARC. Ces rapports informent, entre autres, de toute tentative de phishing sur le domaine dans le cas d’un échec de DKIM ou de SPF.
Disons simplement que Google recommande l’utilisation de DMARC pour les expéditeurs de courrier, ce que nous suggérons fortement. De plus, Google et Microsoft sont compatibles DMARC. Cela prouve aux FAI (fournisseurs d’accès internet) que vous êtes un expéditeur sérieux et que vous êtes prêt à prendre des mesures de précaution pour protéger votre identité et votre réputation.
Ces méthodes permettent de protéger votre identité et le contenu de vos messages en amont. En mailing comme dans la vie courante, mieux vaut prévenir que guérir !
]]>Afin de comprendre la manière dont l’application Power Apps traite les données, vous pouvez vous référer à notre précédent post « Un tour d’horizon de Microsoft Power Platform« , nous vous conseillons d’en prendre connaissance avant d’aborder l’article qui va suivre.
Dans l’article qui suit, nous allons aborder 3 sujets. Dans un premier temps nous rentrerons plus en détail sur la source privilégiée de données de Power Apps « Common Data Service ». Nous vous expliquerons ensuite comment configurer une petite application. Enfin, nous reviendrons également sur les limites de l’outil afin que vous puissiez déterminer quand le mettre en place.
Pour rappel, ce post n’a pas pour but d’être un tutoriel d’utilisation de Power Apps. Nous souhaitons vous montrer l’étendue des possibilités qu’offre cette solution. Si vous comptez en apprendre davantage, vous pourrez retrouver des tutoriels sur Microsoft Learn.
Le Common Data Service est basé sur le Common Data Model. Pour résumer rapidement, il consiste à avoir un service de données unique, standardisé et simple d’accès.
Microsoft utilise déjà le Common Data Service dans un certain nombre de produit en plus de Power Platform, comme par exemple Dynamics 365. Le principal intérêt de CDS provient de la standardisation, c’est-à-dire que les entités telle que les utilisateurs, les tâches, une promotion, une commande etc. seront prédéfinies.
Les données sont au cœur des stratégies d’entreprise et sont devenues une source de revenus indispensable. Le principal problème rencontré est la mauvaise structure que l’on peut donner à ces dernières. C’est un critère important que Microsoft tente de résoudre via CDS: standardiser un maximum de choses. Lorsque l’on parle d’une « commande » dans l’application A, on doit pouvoir parler de la même chose dans l’application B en ayant la même structure. Il devient alors bien plus simple de communiquer entre les applications.
Dans Power Apps, nous pouvons créer nos propres entités, modifier certaines des entités préexistantes et manipuler les relations entre ces dernières. Il est aussi possible de créer plusieurs ‘instances’ de CDS.
Dans la suite de ce post, nous nous baserons sur CDS (plutôt qu’une base de données relationnelle classique) afin de vous montrer l’utilisation et les avantages avec Power Apps.
Pour en apprendre plus sur CDS, je vous conseille le lien suivant: Bien démarrer avec CDS


Pour démarrer une application d’exemple, nous allons commencer par créer un nouvel environnement. Un environnement est semblable à une instance de base de données. Chaque environnement contiendra une instance CDS séparée, avec un schéma et des données qui lui sont propres, ainsi que des applications liées à cet environnement.

Pour cet exemple, nous allons créer une application qui va permettre à un téléphone de rapidement charger et enregistrer des contacts sur un salon. L’entité « contact » existe déjà dans CDS.
Il va donc être intéressant de catégoriser la provenance des données que nous souhaitons collecter. Nous avons alors deux possibilités:
Ce choix va dépendre de plusieurs paramètres et notamment l’utilisation que nous souhaitons faire de nos données collectées. Nous vous conseillons fortement de privilégier les entités afin de garantir une pérennité et une modularité maximale à vos données. Cependant, il faut que vous gardiez en tête que plus le schéma de données sera complexe, plus vous serez confronté aux limites de Power Apps : une application plus « classique » sera alors à privilégier. Nous reviendrons sur ce point dans la dernière partie de cet article.
Pour des raisons de simplicité, reprenons notre exemple précédent en image:

Une fois que votre environnement CDS sera créé et personnalisé, il sera ensuite possible d’attaquer la construction de l’application.
Comme nous vous l’avons présenté dans le post précédent, Power Apps propose un grand nombre de modèles d’application répondant à un certain nombre de besoins. Afin de continuer dans la construction de notre application, nous allons continuer notre démonstration à partir d’une application canvas vierge.

Nous allons dans maintenant vous présenter l’interface de Power Apps. Comme vous allez le voir, l’interface est rapide à prendre en main. Elle se compose de 3 éléments principaux:


Lors de la création d’une application vierge, vous pouvez choisir entre plusieurs types d’écrans qui vous permettront ensuite de construire votre application autour de vos données.
Certains écrans sont très spécifiques à certaines sources de données, comme « Contacts », « Réunions » et « Calendrier » qui sont notamment fortement lié à Office 365. D’autres, tels que Liste et Formulaire sont beaucoup plus génériques.
Pour la construction de notre application, nous allons choisir l’écran liste qui va nous permettre d’afficher l’ensemble des contacts présents en base de données et de disposer d’un champ de recherche. Des données de tests ont été injectées. On peut voir dans la capture ci-dessous que nous avons bien l’écran qui apparaît sur l’arborescence à gauche, les données ont directement été chargées dans l’application en développement pour être plus « visuelle ». Enfin, dans le panneau contextuel, la « Source de données » est bien l’entité « Contacts ».

Si l’affichage des données peut être assez simple, la manipulation de ces données peut quant à elle être plus complexe. Il existe deux manières différentes selon votre niveau :
Nous allons continuer notre démonstration avec les formulaires existants. Les formulaires sont des composants liés à une source de données, ils ont un fonctionnement particulier. Un formulaire sera directement lié aux champs de votre entité et permettra l’ajout ou la modification de données de manière simplifiés. Il est possible d’ajouter de nouveaux champs à une entité depuis l’écran Power Apps si la source de données est CDS.


Tout comme pour la construction de l’application, le management du cycle de vie (application lifecycle) de cette dernière se retrouve considérablement simplifié.
Comme vu ci-dessus, Power Apps intègre vos données depuis la source directement dans la construction de l’application quand cela est possible. Ce qui permet d’avoir un rendu très rapide et de s’assurer que l’application possède le fonctionnement souhaité. Même lorsque nous travaillons sur le filtrage de vos données, cela fonctionne.
A tout moment, il est possible de démarrer l’application via le bouton « play » en haut à droite de l’écran. Nous pouvons naviguer alors dans l’application telle qu’elle sera sur le PC / tablette / téléphone, avec la possibilité de manipuler les données. Il est possible de simuler les clics sans lancer l’application via le bouton « play », et ce en utilisant le raccourci ‘alt + clic’ sur une zone d’action de Power Apps. Le test manuel d’une application est ainsi simplifié.
Cependant, il est important de noter que Power Apps n’est pas une plateforme qui produit du « code » que vous pourriez compiler, analyser ou tester de manière « traditionnelle ». Ce qui rend difficile d’effectuer des tests automatisés ou des tests de performance. Les tests se limitent aux tests manuels. Cette logique se comprend néanmoins dans la volonté de faire des applications légères, rapides, et sans code. Le périmètre étant restreint, le besoin de tests « lourds » est lui aussi plus limité.
Pour pallier à cela, Microsoft a mis en place un outil « diagnostic » performant qui se base sur des formules et qui va permettre de limiter les erreurs. L’outil de diagnostic fonctionne en arrière-plan et permet de vérifier continuellement la cohérence de vos formules. Mais également leurs bons fonctionnements ainsi que les éventuels problèmes de performances ou encore les problèmes d’UX qui pourrait être rencontré.
Pour finir, une fois que votre application est créée, testée et validée, la publication devient un jeu d’enfant. Lors de la sauvegarde, ou directement depuis le bouton de publication, il est possible de partager votre application au sein de votre entreprise. Si l’application existe déjà, une nouvelle version sera créée. Le versionning est nativement géré dans Power Apps, permettant de revenir en arrière en cas de déploiement d’une version qui contiendrait de potentielles erreurs.
Comme nous avons pu vous le démontrer, Power Apps est une excellente plateforme pour la création de petites applications. Ce qui en fait sa grande force, mais également sa faiblesse. L’outil a été conçu pour gagner du temps et permettre à tout à chacun de créer des applications basiques. Power Apps ne permettra pas de créer des applications « trop complexes ». Certains de vos projets demanderont un développement complet par des équipes de développeurs spécialisées.
Microsoft incite d’ailleurs à utiliser la plateforme afin de créer 10 micro-applications plutôt qu’une seule application monolithique. Chaque application répondant à un besoin spécifique. Power Apps possède un réel intérêt pour toute entreprise ayant de petits besoins sur lesquels on peut apporter une réponse rapide sans avoir besoin de dégager des budgets et/ou des compétences trop importantes.
Si vous avez des projets Power Apps ou Power Platform à l’étude, vous pouvez toujours nous contacter.
]]>Le principe du chiffrement symétrique reposait sur la génération d’une clef, qui allait servir autant pour le chiffrement que pour le déchiffrement. La méthode utilisée était la même, en inversé. D’où la notion de « symétrique ».
Le chiffrement asymétrique, quant à lui, va reposer sur la génération non pas d’une mais de deux clefs. Ces clefs sont appelées clef privée et clef publique. La clef privée a, comme son nom l’indique, pour principe d’être à l’usage exclusif d’une personne ou service. On va ainsi chiffrer les communications vers cette personne / ce service.
Pour reprendre le cas d’un service web en HTTPS, un couple de clefs sera généré pour son usage. Le protocole HTTPS n’est rien de plus que le protocole HTTP utilisant un chiffrement asymétrique pour protéger la communication.
Comme dit précédemment, le but est de chiffrer la communication vers le service ayant généré les clefs. Cette personne / service doit alors mettre à disposition sa clef publique. Cette clef va être utilisée pour chiffrer la communication, qui va ensuite être envoyée au service. Enfin, le service va déchiffrer la communication via sa clef privée.
Pour faire un parallèle simple, le chiffrement asymétrique fonctionne de la même façon qu’une encre invisible. La protection (l’encre) qui sera utilisée par l’émetteur ne lui sert à rien pour lire le message. Et seul le destinataire qui possède la bonne lampe peut lire le message. Pour parfaire la métaphore, la génération de clef reviendrait à avoir votre propre combinaison d’encre + lampe qui vous serait propre. Vous transmettriez alors l’encre à tout ceux qui veulent vous écrire un message, mais seuls vous avez la bonne lampe.
Le chiffrement asymétrique a pour principal avantage d’éliminer le problème de l’échange de clef. Il reste néanmoins un point crucial: la clef privée doit absolument le rester. Tout comme pour la clef symétrique, toute la sécurité repose sur cette dernière. L’endroit où elle est stockée doit donc être parfaitement sécurisé.
Un certain nombre d’attaques existe aussi, utilisant le principe d’une clef publique notamment. Tout le monde peut générer ses clefs, mais alors les clefs sont appelées « auto-signée ».

Les certificats auto-signés sont appelés ainsi car aucune autorité de certification (nommée couramment CA pour Certificate Authority) n’a délivré le certificat. Une autorité de certification est un organisme approuvé comme étant de confiance pour délivrer ces certificats.

Il est aussi possible créer dans son entreprise une PKI (Public Key Infrastructure), qui aura pour but de gérer cela. Cela peut être fait via des solutions telle que Microsoft AD CS. Pour être accompagné dans la mise en place d’une PKI, n’hésitez pas à prendre contact avec nous.
Jusqu’à présent nous avons vu comment protéger une communication vers une personne / un service via le chiffrement asymétrique. L’un des problèmes est de bien protéger sa clef privée. L’autre est qu’en l’état, il est impossible de prouver de qui provient la communication, ni que la communication n’a pas été altérée.
La signature digitale répond à ces derniers problèmes. Ce principe est couramment utilisé afin de garantir l’intégrité et la non-répudiation des messages. Elle repose elle aussi sur le chiffrement asymétrique. Mais contrairement à l’explication précédente où on cherchait la confidentialité du message, on va ici utiliser le process inverse.
Une fois le message établi, on va utiliser un algorithme de hash afin de garantir l’intégrité du message. Puis on va utiliser une fonction de signature à partir de la clef privée de l’expéditeur sur ce hash. Le résultat sera alors envoyé avec le message. Le destinataire va alors vérifier la signature via la clef publique de l’expéditeur. Si c’est valide, alors on prouve ainsi que le message n’a pas été altéré, et que c’est bien l’expéditeur qui l’a envoyé.
La signature digitale peut être utilisée sans le chiffrement asymétrique, mais le message reste alors parfaitement visible. Pour garantir à la fois confidentialité, intégrité et non-répudiation, on peut cumuler les deux principes.

Déjà évoqué plus haut dans cet article, le principal défaut du chiffrement asymétrique est la gestion de la clef. C’est la même clef qui gère le chiffrement et le déchiffrement, ce qui ne rend l’algorithme utile que dans certains contextes. De plus, il faut s’assurer qu’on puisse s’échanger la fameuse clef en toute sécurité. Or, ce n’est pas une évidence. De plus, cela complique le changement de clefs régulier.
Afin de pallier à ce genre de problème, des algorithmes ont été mis en place afin de fusionner les avantages et éliminer la plupart des problèmes de ces méthodes. Ces algorithmes reposent souvent sur la même méthode: il s’agit de mettre en place un chiffrement asymétrique (ou un « challenge ») qui va servir à générer / s’échanger les clefs privées symétriques. Une fois l’échange effectué, le chiffrement symétrique, plus rapide, est mise en place. En mettant une durée de vie suffisamment courte, la rotation régulière des clefs permet de garder une sécurité optimale.
Le principal risque de sécurité de ce type d’algorithme se situe souvent sur l’implémentation de l’échange de clef.
Les certificats sont aussi beaucoup utilisés pour éviter l’utilisation de mot de passe en entreprise.
Pour éviter les mots de passe sur les applications d’un téléphone, il est possible de déployer un certificat personnel. Si l’application le permet, c’est le certificat qui authentifie la personne, et non pas un mot de passe. Cela peut aussi servir pour la double authentification (certificat + mot de passe ou autre).
C’est aussi le principe qui est utilisé pour le protocole WebAuthn et les clefs de sécurité tels que les clefs de chez Yubico.
Pour faire une rapide synthèse, voici quelques cas courants d’utilisation de chiffrement asymétrique:

Power Automate (anciennement Microsoft Flow) est une solution proposée par Microsoft pour automatiser les tâches du quotidien. De par sa conception « algorithmique », elle se place comme concurrente du célèbre IFTTT. Power Automate possède néanmoins le grand avantage de faire partie de l’écosystème Power Platform.
A l’instar des autres outils de Power Platform, la limite sera surtout les sources de données à disposition. Et donc les connecteurs auxquels on a accès. Sachant qu’il est possible de créer ses propres connecteurs à partir d’une API REST, le champ des possibles est tout de même assez vaste.
Afin d’aider à envisager les scénarios possibles, Microsoft propose de nombreux exemples. Les usages peuvent concerner tant des tâches de la vie professionnelle que personnelle.


Microsoft Automate (anciennement Flow) s’organise à la manière d’un IFTTT (IF This Then That). Des « flux » vont être créés, composés de deux parties:

Ces actions seront organisées en algorithme comme une suite de tâche. Il est possible d’y ajouter un peu de logique via des process de boucles ou de conditions. Des exemples pour chaque type de flux sont proposés ci-dessous.
Un exemple assez simple peut être le tag et la notification sur téléphone lorsqu’un mail particulier vient d’arriver. Suite aux mails des managers par exemple, afin de ne manquer aucune communication. Sur les captures ci-dessous, l’action est déclenchée lorsqu’un mail est reçu du site web. Il est alors « flaggué » pour être sur de le traiter en plus d’envoyer une notification sur le téléphone.

D’autres cas courants peuvent inclure des demandes d’approbations pour la validation de documents ou de congés, l’insertion en base de données lorsqu’un fichier Excel est modifié… La seule limite est ce qui est permis dans les connecteurs proposés, et ceux que l’on peut créer.

Les flux planifiés sont, comme leurs noms l’indiquent, des actions automatisées qui vont s’exécuter à intervalle régulier. Cela va être très pratique notamment pour tout ce qui va être rapports et indexations.
Les choix de planification ont une unité de temps assez permissive. Elle s’étend du mois jusqu’à la seconde (pour des besoins assez spécifiques). Quelques exemples d’utilisation en vrac:
Attention: Comme pour Power Apps, il est possible de faire beaucoup de choses avec Power Automate. Cependant, ce n’est pas parce que c’est possible que c’est une bonne pratique. Power Automate peut permettre de facilement tester un process. Dans certains cas, d’autres solutions / services seront plus adaptées pour ce besoin.

Pour l’exemple, nous nous baserons sur le Common Data Service utilisé par Dynamics, pour lequel nous allons créer process de rapport journalier. Chaque matin, les contacts ajoutés dans la journée sont récupérés, insérés dans un tableau Excel vierge, puis envoyés dans un fichier en pièce jointe à l’équipe marketing.

Les boutons Power Automate ont deux usages distincts. Cela peut être des boutons accessibles directement dans l’application Power Automate. Mais ça peut aussi être une action utilisable depuis Power Apps.
L’exemple ci-dessous montre un bouton qui va récupérer la liste des contacts ajoutés ce jour sur notre application et d’envoyer une notification du nombre des nouveaux contacts.


La grande force de Power Platform, en plus de ses connecteurs, est l’interconnexion entre ses outils. Power Apps est limité par défaut à des tâches simples de présentation de l’information, voir de l’ajout / suppression. La partie « développement » n’est pas l’objectif premier de Power Apps, même si ce dernier permet néanmoins choses.
Cette partie de « process métier » est en fait plus portée par Power Automate. On va pouvoir créer un processus basé sur un déclencheur « bouton Power Apps », qui sera alors possible d’appeler dans notre application. Si on reprend l’application de contact, on peut créer un bouton « Export » qui sera chargé de générer un fichier Excel avec la liste de contact, et de l’envoyer par mail.


Côté analyse et debug, plusieurs outils sont mis à disposition. Tout d’abord, comme Power Apps, l’analyseur de flux sera chargé de surveiller constamment si vos paramètres sont opérationnels. Il consiste principalement à vérifier que tous les champs obligatoires sont remplis, et les connexions correctement paramétrées. La majorité des problèmes qui seront rencontrés dans Power Automate proviendront de connexions mal paramétrées ou de jetons de connexion ayant expiré.
La page de détail du flux possède un résumé des connexions paramétrées et nécessaires, ainsi que les exécutions du flux qui ont eu lieu précédemment. Il sera ainsi possible de voir l’historique, et d’analyser une exécution en particulier pour traquer les problèmes de performance ou les erreurs. Enfin, un tableau d’analyse Power BI donne un rapport sur les exécutions sur les 30 derniers jours ainsi qu’un état sur les erreurs survenues.


Power Automate permet d’automatiser un nombre important de process, et de répondre a plusieurs besoins fonctionnels. Il remplace, pour la partie planifiée, les « tâches cron ». Cela peut être un moyen de les centraliser et / ou de les partager. Pour les tâches automatiques, il va permettre de gagner du temps sur les traitements du quotidien. Enfin, il ouvre la possibilité d’ajouter de l’intelligence à votre application Power Apps.
Tout n’est actuellement automatisable, notamment car certains connecteurs sont encore limités sur les possibilités qu’ils proposent. Il faut aussi faire attention à la redondance des process, car si Power Automate propose de les centraliser, il est aisé d’avoir un process en doublons. Ca peut être entre deux personnes, ou entre deux outils (Power Automate et la source de donnée originelle par exemple).
Power Automate est donc un outil puissant qui peut répondre à nombre de besoins et faire gagner en productivité. Son évolution rapide est à surveiller, notamment sur des nouvelles fonctionnalités sur les connecteurs, ce qui arrive très régulièrement.
]]>Pour commencer, il faut considérer nos ordinateurs comme des personnes possédant une carte d’identité. Cette carte d’identité est un protocole qui, sur Internet ou des réseaux privés, permet aux machines de s’identifier entre elles. C’est le protocole IP. Chaque machine possède donc une adresse IP, unique, qui lui permet d’être reconnue. Elles respectent un format précis et il existe deux types d’adresses IP :
Ne tenez pas compte de cette écriture qui ne vous dit surement rien, l’idée c’est de comprendre que votre machine est reconnue par cette suite de chiffres, et qu’elle va reconnaître les autres de la même façon.
Maintenant que la base est acquise, comprenons le rôle de ce Domain Name System. Premièrement, l’Internet que nous utilisons aujourd’hui est entièrement basé sur cette manière de fonctionner.
Puisque les adresses IP sont un peu indigestes, peu faciles à retenir, et qu’en plus elles peuvent changer (si l’on change d’hébergeur, on change d’IP), il fallait un système plus simple. C’est le DNS qui est alors mis en place. Le principe, c’est que Devensys.com correspond à une adresse IP. C’est ce qu’on appelle un nom de domaine, comme il en existe aujourd’hui des milliards sur Internet.
Le nom de domaine, c’est la partie d’une adresse URL qui contient l’adresse IP avec laquelle on va retrouver le serveur qui héberge le site. Voici le détail d’une adresse pour mieux comprendre :

Avant que vous ne demandiez, si, lorsque vous effectuez une requête votre serveur (qui est votre box internet) interagit avec d’autres ordinateurs, des serveurs qui vous renvoient la page à afficher.
Tout ça c’est bien beau, un DNS correspond donc à une IP, et un DNS est plus facilement reconnaissable qu’une suite de chiffres. Mais comment nos machines font-elles pour identifier quel nom correspond à quoi, et comment les retrouver ? Lorsque vous tapez une adresse URL, pourquoi et comment cela vous amène-t-il rapidement au bon endroit ?
Votre nom de domaine est composé de plusieurs parties. Pour trouver à quoi correspond la requête que vous venez d’entrer sur internet, votre ordinateur va interroger très rapidement d’autres ordinateurs afin de retrouver l’adresse IP correspondante. Votre requête va être envoyée à un résolveur DNS, qui est présent de base sur votre système d’exploitation.
Ce résolveur va aller chercher votre requête grâce au nom de domaine. Il va aller chercher les différents éléments qui le composent, de droite à gauche.
D’abord, il accède à l’endroit où tous les Top level domain (TLD) se trouvent. Il s’agit du .com, .org, .fr etc. Il en existe plus de 600 dans le monde. Ils sont stockés dans les serveurs DNS racines, qui sont au nombre de 13. Dispatchés sur tout le globe, ce sont d’immenses Data Center et de vraies forteresses.
Le serveur racine ne connaît pas l’adresse IP finale des noms de domaine, mais il connaît l’adresse IP des DNS qui gèrent le com. Il va donc renvoyer l’information à votre ordinateur, qui va cette fois se rendre dans la base du com. Cette base connait les noms de domaines de second niveau, ce qui correspond dans notre exemple à Devensys. L’information est donc transmise à notre machine, qui va aller chercher le www, qu’on appelle un sous-domaine. Ainsi, en un rien de temps, votre ordinateur a réalisé plusieurs échanges avec ces différents serveurs pour satisfaire votre requête.
Il faut préciser que la première requête vers un nom de domaine est légèrement plus longue que les suivantes. La raison est simple : votre navigateur enregistre pendant un certain temps les adresses IP et votre ordinateur n’a pas à aller chercher à quoi correspond le DNS que vous demandez.
Pour reprendre une expression souvent utilisée, le système DNS est une sorte d’annuaire d’adresses IP. La recherche du nom de domaine fonctionne comme le jeu « Qui est-ce ? ». On pose une question, on élimine des choix, et on progresse petit à petit jusqu’à trouver la bonne personne, qui est une adresse IP.
Si le concept de DNS et de serveurs DNS est plus clair, vous comprenez sans doute pourquoi il est si important de savoir protéger les serveurs DNS. En reprenant l’exemple de l’annuaire, c’est comme si on vous donnait un annuaire certifié avec le numéro de votre banque dessus, que vous appeliez votre banque pour une question d’argent. Et si l’annuaire qu’on vous a donné est falsifié, vous ne le savez pas et vous confierez votre argent à un imposteur. Ici, c’est pareil, en cas de détournement de serveurs DNS vous allez confier vos informations à des hackers potentiels.
]]>L’email est un vecteur d’attaque classique, car il est facile à exploiter et faillible depuis sa création. L’une des premières RFC sur la définition du SMTP (simple email transfer protocol, toujours utilisé aujourd’hui), la RFC 788, date de novembre 1981. Internet a bien évolué depuis, et les menaces grandissent à la même vitesse. La priorité a donc été de protéger les échanges emails au travers de plusieurs technologies :
Le BIMI est une initiative soutenue par plusieurs grands noms des technologies emails, mais aussi des E-commerces. Parmi ceux-ci, nous trouvons notamment Yahoo, Ebay et surtout, Google qui souhaite mettre en place son pilote cette année. L’objectif est simple, le BIMI a pour but d’augmenter la visibilité des marques.
Le constat est que la RFC sur le DMARC est publié depuis 2015, mais l’adoption de ce protocole reste encore faible. Or, le nombre d’attaques par email et notamment les arnaques au président, sont en forte augmentation ces dernières années.
La norme BIMI a été créée afin d’accélérer l’adoption de la norme DMARC, tout en répondant à un besoin marketing envers les sociétés. Le « Brand Indicators for Message Identification » consiste en l’affichage du logo de l’entreprise sur les emails envoyés par cette dernière. Elle permet une identification rapide et une meilleure adoption de la marque. L’intérêt marketing pour les entreprises est indéniable.
Afin de pousser et de protéger les entreprises, le BIMI est une technologie qui vient en renforcement du DMARC. Seuls les domaines valides d’un point de vue DMARC peuvent être validés pour le BIMI.

Si votre domaine est donc valide, votre marque s’affichera au niveau de l’email de l’utilisateur pour les plateformes qui acceptent et ont intégré cette norme. Seuls les bêta testeurs ont actuellement accès à la fonctionnalité.
La norme est encore en cours d’élaboration, ce qui implique qu’elle ne soit pas d’or et déjà fonctionnelle. Il est cependant possible de préparer son adoption en étudiant le fonctionnement prévu à l’heure actuelle.
Comme signalé précédemment, la technologie BIMI vient en addition du DMARC. Il est essentiel d’être valide d’un point de vue du DMARC avant de mettre en place la partie BIMI. Si vous souhaitez être accompagné sur ce point, n’hésitez pas à prendre contact avec nos équipes.
Au même titre que le SPF, le DKIM ou encore le DMARC, l’implémentation du BIMI se veut facile et il est surtout indépendant de votre infrastructure. Il ne demande que l’ajout d’entrées DNS et n’intervient en aucun cas dans le routage de vos emails ou de quelque autre information. Le BIMI est simplement un indicateur d’où se situe le logo de l’entreprise qui doit être affiché.
Une fois le protocole DMARC validé sur votre vos domaines de messagerie, vous pourrez ajouter une entrée DNS qui déterminera l’emplacement du logotype. L’entrée est, à la manière du DKIM, ajoutée via un sélecteur. Il est possible donc d’en avoir plusieurs, selon les besoins. À l’heure actuelle, seul le format SVG est pris en charge.
Le BIMI étant une simple entrée DNS, il est très facile pour un pirate de l’usurper en l’état. La technologie repose donc sur un autre élément important: le VMC (pour Verified Mark Certificate). Au même titre que les certificats SSL EV, le VMC est fourni par une autorité de certification tierce reconnue.
Concrètement, le processus est toujours en cours d’élaboration. Un schéma global se dessine tout de même. Lorsqu’un mail passera par l’antispam, ce dernier fera plusieurs vérifications. L’antispam cherchera notamment à vérifier si les autres politiques sont OK. Puis, si une entrée BIMI existe et si son VMC est valide auprès de l’autorité de certification tierce. Seuls les emails répondants à l’ensemble de ces critères pourront alors voir le logo de l’entreprise être affiché. Ce processus intégrant une validation d’un acteur tiers permet de renforcer la sécurité en garantissant la paternité.
Si le BIMI n’apporte rien directement d’un point de vue de la sécurité. Il a l’avantage pour la communauté d’inciter à l’adoption des bonnes pratiques. Et pour les entreprises, la possibilité de faire rapidement du marketing tout en sécurisant leurs clientèles.
Le BIMI, tout comme le fameux « cadenas vert » du HTTPS, sera très certainement un indicateur de fiabilité incontournable ces prochaines années.
La norme BIMI est encore en élaboration. Cela qui implique qu’elle n’est actuellement active que pour certaines sociétés en bêta test. La norme risque d’évoluer et de changer au cours des prochains mois / années. Nous vous tiendrons informé des évolutions.
]]>