Installation d’EnergyBoard

EnergyBoard peut être déployé aussi bien dans le cloud, via une machine virtuelle Azure, que sur un serveur local compact comme un Raspberry Pi 5. Dans les deux cas, il faudra passer par quelques manipulations en ligne de commande (installation de Node.js, configuration du service, ouverture des ports, etc.) pour lancer et sécuriser le serveur. Sur Azure, vous bénéficiez de la haute disponibilité sans contrainte matérielle, mais vous resterez cantonné aux appels API cloud.

Etape 0 – Rappel des prérequis :

Pour déployer EnergyBoard sur votre environnement (Machine virtuelle Azure ou Raspberry Pi 5), il vous faudra disposer de :

  • Une machine virtuelle Azure ou Raspberry Pi 5 en local
  • Un accès SSH à l’environnement
  • Installation de Teslamate réussie sur l’environnement

Avant de configurer EnergyBoard, commençons par copier les fichiers de l’application sur l’environnement.

Etape I – Transfert des fichiers EnergyBoard :

Créez un nouveau répertoire nommé energyboard dans le répertoire courant, puis déplacez-vous dans ce répertoire :

Utilisez des outils de transfert comme WinSCP, disponible à cette adresse :

Installez l’application WinSCP sur votre poste, puis authentifiez-vous à votre environnement via le protocol SFTP :

Copiez le contenu du fichier ZIP dans le dossier energyboard créé précédemment :

Avant de pouvoir démarrer l’application EnergyBoard, d’autres composants doivent être mis à jour sur notre environnement.

Etape II – Mise à jour de l’environnement :

Téléchargez et synchronisez la liste des paquets disponibles à partir des dépôts configurés sur votre environnement, permettant ainsi à apt de connaître les versions les plus récentes des logiciels et leurs dépendances avant une installation ou mise à jour :

sudo apt update

Installez les 2 logiciels essentiels pour notre application EnergyBoard tournant sous JavaScript :

  • nodejs : C’est l’environnement d’exécution permettant d’exécuter du code JavaScript côté serveur.
  • npm (Node Package Manager) : C’est le gestionnaire de paquets associé à Node.js, qui facilite l’installation, la mise à jour et la gestion des modules et bibliothèques JavaScript.
sudo apt install nodejs npm

Affichez les versions installées :

node -v
npm -v

Installez également PM2. Ce dernier est un outil qui permet de gérer, superviser et redémarrer automatiquement vos applications Node.js en production.

sudo npm install -g pm2

Ensuite, passer la commande suivante :

PORT=8002 pm2 start server.js --name energyboard

Celle-ci définit d’abord la variable d’environnement PORT sur 8002, puis lance le script server.js avec PM2, en lui attribuant le nom energyboard pour faciliter sa gestion (surveillance, redémarrage automatique, etc.) :

Configurez votre environnement pour démarrer automatiquement PM2 au démarrage de ce dernier :

pm2 startup

Enregistrez l’état actuel de vos applications surveillées par PM2 :

pm2 save

Ouvrez un navigateur internet afin d’accéder à votre application EnergyBoard :

http://4.251.124.83:8002/

Si celle-ci démarre bien, retournez sur votre environnement pour arrêter l’application afin de terminer la configuration :

pm2 stop energyboard

Retournez sur WinSCP afin d’éditer le nouveau fichier de configuration, présent dans le dossier suivant :

energyboard/assets/conf/config.json

Double-cliquez pour modifier ce fichier :

Configurez les éléments liés à votre installation Enphase :

Si vous souhaitez communiquez à votre Tesla uniquement via BLE :

  • Suivez la procédure de configuration BLE
  • Configurez les éléments suivants :

Si vous souhaitez communiquez à votre Tesla uniquement via API :

  • Suivez la procédure de configuration API
  • Configurez les éléments suivants :

Si vous souhaitez communiquez à votre Tesla via API et BLE :

  • Suivez la procédure de configuration API
  • Suivez la procédure de configuration BLE
  • Configurez les éléments suivants :

Pensez à sauvegarder le fichier de configuration via la commande suivante :

:wq

Redémarrer une fois les conteneurs Docker :

docker compose restart

Démarrer l’application EnergyBoard :

pm2 start energyboard

Rouvrez un navigateur internet afin d’accéder à votre application EnergyBoard :

http://4.251.124.83:8002/

EnergyBoard est maintenant installé, vous pouvez passer à l’étape suivante, consistant à installer et configurer la liaison Bluetooth avec la Tesla. Cette dernière va nous permettre de :

  • Envoyer des ordres Tesla via BLE grâce l’’agent ‘application Tesla-command

Etape suivante : Création de la connexion BLE Tesla

Optionnelle : Création de la connexion API Tesla

Cette étape est probablement la plus délicate de tout le processus. Prenez le temps de bien respecter les différentes opérations pour assurer un enrôlement réussi de votre API auprès de chez Tesla.

Qu’est-ce que Fleet API ?

Fleet API est un service de données et de commande qui donne accès aux véhicules Tesla, à l’énergie et à d’autres types d’appareils. Les partenaires peuvent interagir avec leurs propres appareils ou avec les appareils auxquels un client leur a donné accès.

Suivez le processus d’intégration ci-dessous pour vous inscrire et obtenir une clé API afin d’interagir avec les points d’extrémité de l’API de Tesla. Les applications peuvent demander aux propriétaires des véhicules l’autorisation de consulter les informations du compte, d’obtenir l’état du véhicule ou même d’émettre des commandes à distance.

Les propriétaires de véhicules contrôlent les applications auxquelles ils accordent l’accès et peuvent modifier ces paramètres à tout moment.

Tesla

Quelles sont les différentes étapes pour faire fonctionner Fleet API ?

Voici la liste des étapes que nous allons faire ensemble :

Etape 0 – Rappel des prérequis :

Pour mettre en place une connexion API sur votre environnement (Azure ou Raspberry Pi 5), il vous faudra disposer de :

  • Un compte Tesla
  • Une machine virtuelle ou Raspberry Pi 5
  • Un accès SSH à votre environnement

Avant de créer notre application API chez Tesla, commençons par configurer Ngork.

Etape I – Configuration de Ngrok :

Pour pouvoir enregistrer notre application chez Tesla, nous allons avoir besoin d’un domaine internet pointant sur notre clef publique.

Ngrok est un outil de tunnellisation qui permet d’exposer de manière sécurisée un serveur local à Internet via une URL publique, sans avoir à configurer manuellement votre réseau ou à ouvrir des ports dans votre pare-feu.

Pour cela, rendez-vous sur le site de Ngrok, puis inscrivez-vous chez eux afin d’avoir un compte gratuit :

Sur leur site, téléchargez l’installateur de Ngrok selon votre OS :

Copiez la commande suivante affichée sous l’installateur pour finaliser la configuration de votre Ngrok :

Depuis votre ordinateur, ouvrez Windows PowerShell :

Lancez la commande précédemment copiée afin de terminer la configuration Ngrok :

Créez un tunnel ngrok sécurisé depuis Internet vers votre serveur local qui écoute sur le port 80, en générant une URL publique accessible depuis n’importe quel navigateur :

ngrok http http://localhost:80

Copiez le nom de domaine commençant par https et finissant par ngrok-fre.app. Ne fermez pas cette fenêtre tant que le processus d’enrôlement API pas entièrement fini :

Ngrok est maintenant correctement configuré. L’étape suivante consiste à enregistrer notre application chez Tesla.

Etape II – Création de l’application API chez Tesla :

Rendez-vous le portail Développeur de Tesla, accessible via l’URL Tesla suivante, puis cliquez en haut à droite :

Cliquez ici pour créer votre compte Développeur Tesla :

Créez un compte en renseignant les champs de base, puis cliquez sur Suivant :

Renseignez votre mail ainsi qu’un mot de passe fort, puis cliquez sur Suivant :

Vérifiez votre compte via la réception d’un code par email :

Cliquez sur le bouton de configuration de la 2FA pour sécuriser votre compte, puis cliquez sur Continuer une fois l’enrôlement de la 2FA terminé :

Acceptez les conditions, puis cliquez sur Suivant :

Choisissez le premier choix, puis cliquez sur Suivant :

Renseignez tous les champs, puis cliquez sur Suivant :

Reprenez l’URL publique donnée par Ngrok, ajoutez en URL de redirection celle en-dessous, puis cliquez sur Suivant :

http://localhost:3000/callback

Cochez les cases suivantes, puis cliquez sur Suivant :

Cliquez sur Ignorer et soumettre :

La notification Tesla vous indiquant un succès de l’approbation de votre application API Tesla apparaît alors :

Un email de confirmation vous est également envoyé :

Votre application est immédiatement visible sur le portail de votre compte Développeur Tesla, cliquez-ici pour obtenir des informations techniques sur celle-ci :

Copiez l’ID et le secret de votre application car nous nous en aurons besoin plus tard :

Nous avons besoin de mettre à disposition la clef publique Tesla que nous avons généré quelques étapes plus tôt.

Etape III – Exposition de la clef publique API Tesla :

Pour cela, sur votre poste local, créez une arborescence de dossiers dans le lieu de votre choix, tant que la fin fini comme ceci :

.well-known\appspecific\

Ouvrez une session WinSCP vers votre environnement :

Récupérez la clef publique com.tesla.3p.public-key.pem générée précédemment afin de la placer dans le dossier créé sur votre poste local :

.well-known\appspecific\

Afin d’exposer cette clef publique, installez Python sur votre poste via l’URL officielle :

Ouvrez un nouvel onglet à Windows PowerShell, puis affichez la version de Python installée sur votre système

py --version

Utilisez Python pour démarrer le module intégré http.server sur le port 80

py -m http.server 80

Ne fermez pas cette fenêtre tant que le processus d’enrôlement API pas entièrement fini :

Depuis votre poste local, testez l’URL suivante afin de vérifier le bon téléchargement de votre clef publique API Tesla :

https://YOUR_NGROK_DOMAIN/.well-known/appspecific/com.tesla.3p.public-key.pem

Cliquez sur le bouton suivant pour confirmer votre action :

Constatez le téléchargement de votre clef publique sur votre poste local :

Nous sommes maintenant prêt à finaliser l’inscription de notre application chez Tesla.

Etape IV – Génération d’un token d’authentification partenaire :

Plusieurs requêtes API doivent être faites pour arriver au bout du processus. Pour cela, je vous conseille de passer par un outil local, comme Insomnia :

Insomnia REST est un client API (interface pour tester et déboguer des API) qui permet de créer, envoyer et gérer des requêtes HTTP et REST, ainsi que des requêtes GraphQL dans une interface graphique conviviale.

Chat GPT

Téléchargez la version selon votre OS :

Une fois Insomnia installé, créez un nouveau dossier pour y mettre toutes vos requêtes API Tesla :

Nommez votre dossier Insomnia, puis cliquez sur Créer :

Sur votre dossier Insomnia, effectuez un clique droit afin d’importer une requête API :

Collez le code ci-dessous en remplaçant en gras les valeurs par les vôtres, puis cliquez sur Importer :

curl --request POST \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'grant_type=client_credentials' \
  --data-urlencode "client_id=CLIENT_ID" \
  --data-urlencode "client_secret=CLIENT_SECRET" \
  --data-urlencode 'scope=openid vehicle_device_data vehicle_cmds vehicle_charging_cmds' \
  --data-urlencode "audience=https://fleet-api.prd.eu.vn.cloud.tesla.com" \
  'https://fleet-auth.prd.vn.cloud.tesla.com/oauth2/v3/token'

Cette commande effectue une requête HTTP POST vers un endpoint OAuth2 afin d’obtenir un access token en utilisant le flux d’authentification client_credentials. Cela doit donner :

Nommez votre requête API pour plus de clarté, revérifiez tous les champs présent dans l’onglet Body, puis cliquez sur Envoyer :

Copiez l’accès token généré par Tesla pour une utilisation ultérieure. Continuons avec l’enregistrement de notre nom de domaine temporaire généré par Ngrok.

Etape V – Enregistrement d’un domaine chez Tesla :

Comme précédemment, effectuez un clique droit afin d’importer une nouvelle requête API :

Collez le code ci-dessous en remplaçant en gras les valeurs par les vôtres, puis cliquez sur Importer :

curl --request POST \
  --url https://fleet-api.prd.eu.vn.cloud.tesla.com/api/1/partner_accounts \
  --header 'Authorization: Bearer YOUR_PARTNER_ACCESS_TOKEN' \
  --header 'Content-Type: application/json' \
  --data '{"domain": "YOUR_NGROK_DOMAIN"}'

Cette commande effectue une requête HTTP POST vers l’API de la flotte de Tesla afin d’enregistrer ou de créer un compte partenaire avec un domaine spécifique. Cela doit donner :

Nommez votre requête API pour plus de clarté, revérifiez tous les champs présent dans l’onglet Body :

Vérifiez également l’onglet Headers, puis cliquez sur Envoyer :

Constatez le succès de l’opération via le message suivant :

L’étape suivante consiste maintenant à récupérer un accès token et refresh token afin de pouvoir utiliser le proxy HTTP Tesla dans Energyboard.

Etape VI – Génération d’un refresh token :

Pour cela, nous allons utiliser une autre application temporaire afin de capter facilement ces tokens. Rendez-vous sur la page GitHub suivante, puis lancez le téléchargement de l’archive ZIP :

Extrayez le contenu de l’archive ZIP dans le dossier de votre choix :

Ouvrez un onglet Windows PowerShell, positionnez-vous dans le dossier d’archive ci-dessous, puis lancez la commande suivante pour télécharger et installer toutes les dépendances répertoriées dans le fichier package.json du projet :

pnpm install

Créez un nouveau fichier .env à la racine de ce même dossier en y indiquant les deux informations présentes en gras :

TESLA_CLIENT_ID=VOTRE_ID_CLIENT
TESLA_CLIENT_SECRET=VOTRE_SECRET
TESLA_REFRESH_TOKEN=

Cela donne le fichier .env suivant :

Lancez la commande suivante afin de démarrer l’application de captage des tokens :

pnpm get-token

Copiez l’URL donnée par l’application lancée, puis ouvrez un navigateur internet :

Authentifiez-vous cette fois avec le compte propriétaire de la Tesla, cochez les cases suivantes, puis cliquez sur Autoriser :

Le navigateur affiche alors l’URL de callback créée par l’application lancée :

Un email de confirmation vous indique l’ajout de droits API à votre application :

Retournez sur l’application lancée sous Windows PowerShell afin de récupérer le refresh token capté :

Toutes les étapes se passent bien, testons maintenant que le rafraîchissement des tokens se déroule sans souci.

Etape VII – Test du rafraîchissement des tokens :

Retournez sur Insomnia afin d’effectuer un clique droit afin d’importer une nouvelle requête API :

curl --request POST \
  --url https://fleet-auth.prd.vn.cloud.tesla.com/oauth2/v3/token \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data grant_type=refresh_token \
  --data client_id=YOUR_CLIENT_ID \
  --data refresh_token=EU_XXX

Cette commande effectue une requête HTTP POST vers l’API de la flotte de Tesla afin d’enregistrer ou de créer un compte partenaire avec un domaine spécifique. Cela doit donner :

Nommez votre requête API pour plus de clarté, revérifiez tous les champs présent dans l’onglet Body, puis cliquez sur Envoyer :

Constatez le succès de l’opération via le message suivant :

L’enregistrement de l’application est maintenant terminée ! Il ne nous reste qu’à ajouter la clef virtuelle API sur notre Tesla.

Etape VIII – Enregistrement de la clef publique API sur la Tesla :

Pour cela, ouvrez la page suivante dans votre navigateur internet en remplaçant la valeur en gras par votre domaine Ngrok approuvé par Tesla :

https://tesla.com/_ak/YOUR_NGROK_DOMAIN

Depuis votre smartphone dans lequel installée l’application Tesla et agit déjà comme une clef de votre Tesla, scanner le QR en bas de votre page web :

L’application Tesla s’ouvre alors et vous demande d’autoriser l’application à votre véhicule, cliquez sur Approuver :

Un message d’opération réussie doit alors apparaître :

Votre Tesla est maintenant prête à recevoir des ordres via API. Il ne nous reste qu’à configurer Energyboard pour activer cette fonction.

Etape IX – Configuration API pour Energyboard :

Renseignez les informations suivantes pour qu’Energyboard exploite le service de communication API avec la voiture Tesla :

Pensez à sauvegarder le fichier de configuration via la commande suivante :

:wq

Arrêter l’application Energyboard :

pm2 stop energyboard

Démarrer l’application Energyboard :

pm2 start energyboard

Conclusion

En conclusion, cette dernière étape d’enrôlement de la Fleet API Tesla clôt un parcours riche en découvertes et en défis techniques : de la configuration de Ngrok à la génération des tokens, en passant par l’exposition de votre clef publique et l’inscription de votre application, chaque phase a consolidé votre compréhension des protocoles OAuth2 et des bonnes pratiques de sécurité.

Grâce à ce processus, vous bénéficiez désormais d’une connexion API robuste, entièrement maîtrisée, qui permet à votre tableau de bord domotique de communiquer en toute confiance avec votre Tesla.

N’hésitez pas à revisiter chaque étape si besoin, et gardez à l’esprit que cet investissement initial ouvre la voie à de nombreuses automatisations avancées et à un suivi précis de vos usages énergétiques.

Félicitations pour votre persévérance et bon pilotage !

Création de la connexion BLE Tesla

Le principe de la connexion BLE (Bluetooth Low Energy) repose sur l’établissement d’un canal de communication local, sécurisé et à faible consommation, permettant à un appareil externe (souvent via un outil ou une application personnalisée) d’envoyer des commandes directement au véhicule. Cette approche est idéale entre un véhicule Tesla et l’application EnergyBoard.

Voici les points essentiels à utiliser la liaison BLE sur un véhicule Tesla :

  1. Communication à courte portée et faible consommation
    Le BLE est conçu pour des échanges de données sur de courtes distances, ce qui est idéal pour communiquer avec un véhicule à proximité (par exemple, lors de l’utilisation d’un smartphone ou d’un dispositif embarqué).
  2. Découverte des services et appariement
    Le véhicule expose des services BLE spécifiques. L’outil (comme celui proposé dans le dépôt vehicle-command) scanne ces services et procède à un appariement ou à une authentification. Pour garantir la sécurité, cette phase d’appariement repose souvent sur l’échange de clés cryptographiques.
  3. Authentification par échange de clés
    Afin de s’assurer que seules les requêtes authentifiées parviennent au véhicule, le mécanisme implique l’utilisation d’une paire de clés publique/privée. Par exemple, la commande tesla-control -vin YOUR_VIN -ble -key-file BLE-private.pem wake illustre comment une clé privée est utilisée pour signer ou authentifier une commande envoyée via BLE. Ce processus assure que seul un utilisateur autorisé peut exécuter des commandes sensibles (comme le réveil du véhicule, le verrouillage ou le démarrage de la charge).
  4. Exécution des commandes
    Une fois la connexion établie et l’authentification réussie, l’appareil externe peut envoyer des commandes spécifiques (par exemple, pour réveiller le véhicule, obtenir son état, verrouiller/déverrouiller, etc.). Ces commandes sont interprétées par le système du véhicule et traduites en actions réelles.
  5. Sécurité et contrôle
    L’utilisation du BLE dans ce contexte permet de limiter la portée de la communication et d’exploiter un protocole conçu pour être économe en énergie. De plus, la sécurisation par clé cryptographique protège contre toute tentative d’intrusion non autorisée.

En résumé, la connexion BLE sur une Tesla, telle qu’illustrée dans le projet vehicle-command, consiste à établir un lien local entre un appareil et le véhicule, authentifier cette communication via un échange de clés, puis permettre l’envoi de commandes sécurisées pour contrôler diverses fonctions du véhicule.

Ce mécanisme offre un moyen efficace et sûr de gérer certaines opérations du véhicule sans passer par les serveurs Tesla.

Quelles sont les différentes étapes pour faire fonctionner BLE ?

Voici la liste des étapes que nous allons faire ensemble :

Etape 0 – Rappel des prérequis :

Pour mettre en place la connexion BLE à votre environnement Raspberry Pi 5, il vous faudra disposer de :

  • Un Raspberry Pi 5
  • Un accès SSH à votre environnement

Commençons par récupérer le programme officiel Tesla pour le protocole BLE, et développé en Go.

Etape I – Mise à jour de Go :

Téléchargez l’archive de Go version 1.23.0 pour Raspberry Pi 5 (ARM) :

wget https://go.dev/dl/go1.23.0.linux-arm64.tar.gz

Décompressez l’archive Go téléchargée dans le répertoire /usr/local :

sudo tar -C /usr/local -xzf go1.23.*.gz

Ouvrez le fichier de configuration Bash à l’aide de l’éditeur de texte en mode terminal Vi :

vi ~/.bashrc

Descendez en bas du fichier, puis ajoutez la ligne suivante grâce à la touche i :

export PATH=$PATH:/usr/local/go/bin

Enregistrez et quitter l’éditeur vi grâce à la commande suivante :

:wq

Forcez le rechargement du fichier de configuration Bash :

source ~/.bashrc

Affichez la version de Go actuellement installée :

go version

Etape II – Installation de vehicle-command :

Créez un nouveau répertoire nommé tesla dans le répertoire courant, puis déplacez-vous :

mkdir tesla
cd tesla

Clonez le dépôt GitHub du projet vehicle-command de Tesla dans un répertoire nommé vehicle-command dans le répertoire courant :

git clone https://github.com/teslamotors/vehicle-command.git
cd vehicle-command

Téléchargez l’ensemble des dépendances requises :

go get ./...

Compilez l’ensemble des package :

go build ./...

Installez l’ensemble des packages :

go install ./...

Exécutez la commande suivante pour vérifier le bon lancement du programme :

tesla-control -h

Etape III – Création de la clef virtuelle BLE :

Remontez dans le répertoire parent, créez un dossier nommé secrets, puis accédez -y :

cd ..
mkdir secrets
cd secrets/

Utilisez OpenSSL pour générer une clé privée EC à l’aide de la courbe prime256v1 :

openssl ecparam -genkey -name prime256v1 -noout > BLE-private.pem
openssl ec -in BLE-private.pem -pubout > BLE-public.pem

Attribuez à l’exécutable tesla-control la capacité réseau d’administration :

sudo setcap 'cap_net_admin=eip' "$(which tesla-control)"

Exécutez tesla-control en mode Bluetooth pour le véhicule identifié par le VIN afin de lancer la commande add-key-request en utilisant le fichier BLE-public.pem pour envoyer une requête d’ajout de clé associée à l’identité ou au rôle « owner » et à la clé identifiée par cloud_key :

tesla-control -vin YOUR_VIN -ble add-key-request BLE-public.pem owner cloud_key

Confirmez l’action d’association en couchant la carte NFC Tesla sur la console centrale de la voiture.

Etape IV – Test de la clef virtuelle BLE :

Pour tester le bon fonctionnement d’un ordre à la voiture, envoyez la commande de réveil au véhicule, en utilisant le fichier BLE-private.pem pour l’authentification.

tesla-control -vin YOUR_VIN -ble -key-file BLE-private.pem wake

L’absence de retour de la part de l’application équivaut à un succès de l’opération :

Dans votre navigateur internet, accédez à l’adresse http://ADRESSE_IP:4000 afin de constater une actualisation du statut de la voiture réveillée :

Testez au besoin d’autres commandes sur la Tesla parmi les commandes disponibles :

add-keyAdd PUBLIC_KEY to vehicle whitelist with ROLE and FORM_FACTOR
add-key-requestRequest NFC-card approval for a enrolling PUBLIC_KEY with ROLE and FORM_FACTOR
auto-seat-and-climateTurn on automatic seat heating and HVAC
autosecure-modelxClose falcon-wing doors and lock vehicle. Model X only.
body-controller-stateFetch limited vehicle state information. Works over BLE when infotainment is asleep.
charge-port-closeClose charge port
charge-port-open Open charge port
charging-scheduleSchedule charging to MINS minutes after midnight and enable daily scheduling
charging-schedule-addSchedule charge for DAYS START_TIME-END_TIME at LATITUDE LONGITUDE. The END_TIME may be on the following day.
charging-schedule-cancel Cancel scheduled charge start
charging-schedule-remove Removes charging schedule of TYPE [ID]
charging-set-ampsSet charge current to AMPS
charging-set-limit Set charge limit to PERCENT
charging-start Start charging
charging-stopStop charging
climate-offTurn off climate control
climate-on Turn on climate control
climate-set-temp Set temperature (Celsius)
driveRemote start vehicle
erase-guest-data Erase Guest Mode user data
flash-lights Flash lights
frunk-open Open vehicle frunk. Note that there's no frunk-close command!
getGET an owner API http ENDPOINT. Hostname will be taken from -config.
guest-mode-off Disable Guest Mode.
guest-mode-onEnable Guest Mode. 
honk Honk horn
list-keysList public keys enrolled on vehicle
lock Lock vehicle
media-set-volume Set volume
media-toggle-playbackToggle between play/pause
ping Ping vehicle
post POST to ENDPOINT the contents of FILE. Hostname will be taken from -config.
precondition-schedule-addSchedule precondition for DAYS TIME at LATITUDE LONGITUDE.
precondition-schedule-remove Removes precondition schedule of TYPE [ID]
product-info Print JSON product info
remove-key Remove PUBLIC_KEY from vehicle whitelist
rename-key Change the human-readable metadata of PUBLIC_KEY to NAME, MODEL, KIND
seat-heaterSet seat heater at POSITION to LEVEL
sentry-modeSet sentry mode to STATE ('on' or 'off')
session-info Retrieve session info for PUBLIC_KEY from DOMAIN
software-update-cancel Cancel a pending software update
software-update-startStart software update after DELAY
stateFetch vehicle state over BLE.
steering-wheel-heaterSet steering wheel mode to STATE ('on' or 'off')
tonneau-closeClose Cybertruck tonneau.
tonneau-open Open Cybertruck tonneau.
tonneau-stop Stop moving Cybertruck tonneau.
trunk-closeCloses vehicle trunk. Only available on certain vehicle types.
trunk-move Toggle trunk open/closed. Closing is only available on certain vehicle types.
trunk-open Open vehicle trunk. Note that trunk-close only works on certain vehicle types.
unlock Unlock vehicle
valet-mode-off Disable valet mode
valet-mode-onEnable valet mode
wake Wake up vehicle
windows-closeClose all windows
windows-vent Vent all windows

Testez au besoin d’autres commandes sur votre Tesla via BLE :

Votre Tesla est maintenant prête à recevoir des ordres via BLE. Il ne nous reste qu’à configurer EnergyBoard pour activer cette fonction.

Etape V – Configuration BLE pour EnergyBoard :

Renseignez les informations suivantes pour qu’EnergyBoard exploite le service de communication BLE avec la voiture Tesla :

Pensez à sauvegarder le fichier de configuration via la commande suivante :

:wq

Arrêter l’application EnergyBoard :

pm2 stop energyboard

Démarrer l’application EnergyBoard :

pm2 start energyboard

La connexion Bluetooth entre EnergyBoard et la Tesla est maintenant fonctionnelle. Si vous le souhaitez, vous pouvez passer à l’étape facultative suivante, consistant à configurer le lien API entre EnergyBoard et le serveurs Tesla. Ce dernier va nous permettre de :

  • Envoyer des ordres Tesla via API grâce au conteneur Proxy HTTP quand la liaison Bluetooth n’est pas disponible.

Etape suivante : Création de la connexion API Tesla

Installation de Teslamate

Installer Teslamate se fait en quelques commandes simples, à l’image d’un projet DIY accessible à tous. Teslamate, un datalogger open-source, récupère en local les données de votre Tesla (trajets, consommations, charge…) et les présente via une interface web riche en graphiques et statistiques.

L’ensemble tourne sur Docker, ce qui évite d’installer manuellement chaque composant, et reste sécurisé tant qu’il n’est pas exposé à l’extérieur par défaut. Le mode opératoire décrit ci-dessous est inspiré de celui déjà disponible à cette adresse.

Etape 0 – Rappel des prérequis :

Pour installer Teslamate sur votre environnement (machine virtuelle Azure ou Raspberry Pi 5), il vous faudra disposer de :

  • Une machine virtuelle Azure ou Raspberry Pi 5
  • Un accès SSH à votre environnement

Avant d’installer Teslamate, commençons par mettre à jour notre environnement.

Etape I – Mise à jour de l’environnement :

Une fois connecté en SSH à votre environnement (Azure ou Raspberry Pi 5), effectuez les commandes suivantes, une par une, afin de préparer ce dernier

Téléchargez et exécutez automatiquement le script d’installation de Docker depuis le site officiel :

curl -sSL https://get.docker.com | sh

Ajoutez l’utilisateur spécifié au groupe « docker » pour permettre l’exécution des commandes Docker sans utiliser sudo :

sudo usermod -aG docker VOTRE_NOM_UTILISATEUR

Rechargez les paramètres de groupe de l’utilisateur dans la session en cours afin d’appliquer la nouvelle appartenance au groupe « docker » :

newgrp docker

Lancez un conteneur de test (hello-world) pour vérifier que Docker est correctement installé et opérationnel :

docker run hello-world

Installez les bibliothèques de développement libffi et libssl, nécessaires pour certaines compilations et dépendances, notamment pour des outils Python :

sudo apt-get install -y libffi-dev libssl-dev

Installez Python 3 ainsi que pip, le gestionnaire de paquets pour Python 3 :

sudo apt-get install -y python3 python3-pip

Désinstallez le paquet python-configparser, souvent redondant ou source de conflits avec la version intégrée dans Python 3 :

sudo apt-get remove python-configparser

Etape II – Installation de Teslamate :

Créez un nouveau répertoire nommé teslamate dans le répertoire courant, puis déplacez-vous dans celui-ci :

mkdir teslamate
cd teslamate/

Créez le fichier docker-compose.yml depuis l’éditeur de texte vi pour permettre son édition :

vi docker-compose.yml

Dans l’éditeur de texte vi, appuyez sur la touche i pour passer en mode édition, puis collez le manifeste ci-dessous. Avant de le copier, pensez à modifier les secrets suivants :

  • Secretkey de ENCRYPTION_KEY par 12 caractères ou plus, pour sécuriser votre connexion. Utilisez si besoin Key Generator.
  • Mot de passe de DATABASE_PASS (à 3 endroits) par le mot de passe de votre choix.
version: "3.8"

services:
  teslamate:
    image: teslamate/teslamate:latest
    restart: always
    environment:
      - ENCRYPTION_KEY=secretkey #replace with a secure key to encrypt your Tesla API tokens
      - DATABASE_USER=teslamate
      - DATABASE_PASS=#insert your secure database password!
      - DATABASE_NAME=teslamate
      - DATABASE_HOST=database
      - MQTT_HOST=mosquitto
    ports:
      - "4000:4000"
    volumes:
      - ./import:/opt/app/import
    cap_drop:
      - all

  tesla_http_proxy:
    image: tesla/vehicle-command:latest
    restart: always
    ports:
      - "4443:4443"
    environment:
      - TESLA_HTTP_PROXY_TLS_CERT=/config/tls-cert.pem
      - TESLA_HTTP_PROXY_TLS_KEY=/config/tls-key.pem
      - TESLA_HTTP_PROXY_HOST=0.0.0.0
      - TESLA_HTTP_PROXY_PORT=4443
      - TESLA_HTTP_PROXY_TIMEOUT=10s
      - TESLA_KEY_FILE=/config/fleet-key.pem
      - TESLA_VERBOSE=true
    volumes:
      - ./tesla_http_proxy/config:/config

  database:
    image: postgres:16
    restart: always
    environment:
      - POSTGRES_USER=teslamate
      - POSTGRES_PASSWORD=#insert your secure database password!
      - POSTGRES_DB=teslamate
    volumes:
      - teslamate-db:/var/lib/postgresql/data

  grafana:
    image: teslamate/grafana:latest
    restart: always
    environment:
      - DATABASE_USER=teslamate
      - DATABASE_PASS=#insert your secure database password!
      - DATABASE_NAME=teslamate
      - DATABASE_HOST=database
    ports:
      - "3000:3000"
    volumes:
      - teslamate-grafana-data:/var/lib/grafana

  mosquitto:
    image: eclipse-mosquitto:2
    restart: always
    command: mosquitto -c /mosquitto-no-auth.conf
    ports:
      - "1883:1883"
    volumes:
      - mosquitto-conf:/mosquitto/config
      - mosquitto-data:/mosquitto/data

volumes:
  teslamate-db:
  teslamate-grafana-data:
  mosquitto-conf:
  mosquitto-data:

Une fois le manifeste collé, appuyez sur Echap pour quitter le mot édition de vi, puis sauvegardez votre fichier avec la commande suivante, suivie de la touche Entrée :

:wq

Etape III – Création de certificats pour Tesla Proxy :

Sous le dossier teslamate, créez arborescence suivante, puis déplacez-vous-y :

mkdir ./tesla_http_proxy
mkdir ./tesla_http_proxy/config
cd tesla_http_proxy/config/

Créez un certificat auto-signé à l’aide d’OpenSSL :

openssl req -x509 -nodes -newkey ec \
    -pkeyopt ec_paramgen_curve:secp521r1 \
    -pkeyopt ec_param_enc:named_curve  \
    -subj '/CN=localhost' \
    -keyout tls-key.pem -out tls-cert.pem -sha256 -days 3650 \
    -addext "extendedKeyUsage = serverAuth" \
    -addext "keyUsage = digitalSignature, keyCertSign, keyAgreement"

Modifiez les permissions des fichiers PEM pour que le propriétaire et le groupe puissent le lire et l’écrire (6), tandis que les autres utilisateurs n’ont qu’un droit de lecture (4) :

sudo chmod 664 *.pem

Générez une clé privée, avec sa clef publique, pour assurer une authentification des commandes via API émises vers la Tesla :

openssl ecparam -name prime256v1 -genkey -noout -out fleet-key.pem
openssl ec -in fleet-key.pem -pubout -out com.tesla.3p.public-key.pem

Etape IV – Démarrage des conteneurs Docker

Depuis le dossier teslamate, démarrez en mode détaché (en arrière-plan) tous les services définis dans le fichier docker-compose.yml :

docker compose up -d

Docker commence par télécharger toutes les images nécessaires aux services définis dans votre fichier docker-compose.yml, afin de s’assurer qu’elles soient disponibles localement pour créer et démarrer les conteneurs :

Attendez et vérifiez le bon démarrage de tous les conteneurs :

Ouvrez le fichier de configuration du service Systemd, nommé teslamate.service, dans l’éditeur de texte vi avec des privilèges administrateur afin de définir comment lancer, arrêter et gérer le service Teslamate.

sudo vi /etc/systemd/system/teslamate.service

En mode édition, collez le code suivant afin d’automatiser la gestion de Teslamate en s’assurant que Docker est prêt avant de lancer l’ensemble des conteneurs en cas de problème, en n’oubliant pas de modifier USER par votre nom d’utilisateur :

[Unit]
Description=TeslaMate Docker Compose Service
Requires=docker.service
After=docker.service

[Service]
WorkingDirectory=/home/USER/teslamate
ExecStart=/usr/local/bin/docker compose up -d
ExecStop=/usr/local/bin/docker compose down
Restart=always
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Appuyez sur Echap pour quitter le mot édition, puis sauvegardez votre fichier avec la commande suivante, suivie de la touche Entrée :

:wq

Demandez à systemd de recharger tous ses fichiers de configuration :

sudo systemctl daemon-reload

Configurez systemd pour démarrer automatiquement le service Teslamate au prochain démarrage du système, en créant les liens symboliques nécessaires dans les répertoires d’unités.

sudo systemctl enable teslamate.service

Démarrez et affichez l’état actuel du service Teslamate :

sudo systemctl start teslamate.service
sudo systemctl status teslamate.service

Listez l’ensemble des conteneurs Docker qui sont actuellement en cours d’exécution, en affichant des informations telles que l’ID du conteneur, l’image utilisée, l’état, les ports exposés et le nom du conteneur :

docker ps

Etape V – Configuration de Teslamate :

Dans votre navigateur internet, accédez à l’adresse http://ADRESSE_IP:4000 :

Pour générer les tokens, utilisez un outil comme tesla_auth, téléchargeable sur GitHub :

Lancez l’exécutable tesla_auth.exe, puis authentifiez-vous avec votre compte Tesla :

Entre le code de votre méthode 2FA, si cette dernière est configurée :

Copiez les deux tokens affichés dans l’application tesla_auth :

  • Les access tokens servent à authentifier et autoriser directement l’accès aux API et ressources protégées (et sont généralement de courte durée).
  • Les refresh tokens permettent d’obtenir de nouveaux access tokens lorsque ceux-ci expirent, assurant ainsi une continuité de session sans nécessiter une réauthentification manuelle.

Collez dans Teslamate les 2 tokens, puis cliquez-ici pour vous authentifier :

Si l’accès est confirmé, Teslamate devrait alors vous afficher la ou les voitures Tesla rattachées à votre compte Tesla :

Bonus : accédez à votre tableau de bord Teslamate via l’adresse http://ADRESSE_IP:3000, dont les identifiants par défaut sont admin/admin :

Une fois connecté pour la première fois, personnalisez le mot de passe de votre compte admin :

Une grande quantité de tableaux de bord y sont disponibles :

Teslamate est maintenant installé, vous pouvez passer à l’étape suivante, consistant à installer et configurer EnergyBoard. Ce dernier va nous permettre de :

  • Remonter les informations liées à la production solaire Enphase
  • Remonter les informations liées à la charge Tesla
  • Envoyer des ordres Tesla via BLE grâce l’application Tesla-control
  • Envoyer des ordres Tesla via API grâce au conteneur Tesla Proxy HTTP

Etape suivante : Installation d’EnergyBoard

Alternative : EnergyBoard sur une machine virtuelle Azure

Installer EnergyBoard sur une machine virtuelle Azure présente plusieurs atouts : vous vous affranchissez des contraintes liées à un serveur dédié ou à un Raspberry Pi, et bénéficiez de la scalabilité et de la haute disponibilité du cloud. En contrepartie, le pilotage Bluetooth local n’est pas possible depuis Azure, ce qui vous limite aux seuls appels API Tesla pour la gestion du véhicule.

Cette architecture cloud peut toutefois s’avérer très intéressante pour centraliser votre dashboard et automatiser les mises à jour, à condition de prévoir l’ouverture des ports nécessaires (HTTP/8002, TCP…) afin de relayer les requêtes vers votre passerelle Enphase, qui elle reste sur votre réseau domestique.

Etape 0 – Rappel des prérequis :

Pour installer votre application EnergyBoard sur Azure, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Commençons par créer la machine virtuelle Linux.

Etape I – Création de la machine virtuelle Linux :

Depuis le portail Azure, commencez par rechercher le service des machines virtuelles :

Cliquez-ici pour créer votre machine virtuelle :

Renseignez tous les champs, en prenant soin de bien sélectionner les valeurs suivantes :

Choisissez une taille de machine virtuelle de petite puissance :

Renseignez les informations d’administration, puis cliquez sur Suivant :

Adaptez la performance du disque, puis cliquez sur Suivant :

Conservez les options réseaux, puis lancez la validation Azure :

Une fois la validation réussie, lancez la création des ressources Azure :

Quelques minutes plus tard, cliquez-ici pour voir votre machine virtuelle :


Ensuite, cliquez-ici pour déployer une règle entrante de réseau :

Ajoutez la configuration suivante pour autoriser les connexions depuis votre adresse IP publique, visible sur cette page, puis cliquez sur Ajouter :

Retournez sur la page principale de votre machine virtuelle afin de copier l’adresse IP publique de celle-ci :

Depuis votre ordinateur, ouvrez Windows PowerShell :

Connectez-vous en SSH à votre machine virtuelle Azure via son adresse IP publique précédemment copiée :

ssh VOTRE_NOM_UTILISATEUR@ADRESSE_IP_PUBLIQUE

Une fois connecté à votre machine virtuelle Azure, vous pouvez passer à l’étape suivante, consistant à installer et déployer Teslamate. Ce dernier va nous permettre de :

  • Stocker les données MQTT émises par la voiture Tesla
  • Consulter les données MQTT depuis EnergyBoard
  • Envoyer des ordres API via l’agent Proxy HTTP (facultatif)

Etape suivante : Installation de Teslamate

EnergyBoard sur Raspberry Pi 5

Installer EnergyBoard sur un Raspberry Pi 5 offre l’avantage d’un serveur compact, économe en énergie et directement relié à votre installation 100% locale : vous avez accès nativement au Bluetooth local pour piloter votre Tesla et la passerelle Enphase sans passer par le cloud. Cette approche vous garantit une réactivité maximale et un contrôle complet de votre infrastructure.

Pour écrire cet article, j’ai donc acheté ce kit de démarrage Raspberry Pi 5 de 8Go, dont il en existe beaucoup sur internet :

Le mode opératoire décrit ci-dessous est inspiré de celui déjà disponible à cette adresse :

Etape 0 – Rappel des prérequis :

Pour installer l’application EnergyBoard sur votre Raspberry Pi 5, il vous faudra disposer de :

  • Un Raspberry Pi 5
  • Un poste local connecté en réseau au Raspberry Pi 5
  • Une connexion internet
  • une carte Micro-SD (dans le kit Raspberry Pi 5 acheté était fournie une carte Micro-SD de 64 Go avec un adaptateur USB-A/C)

Commençons par préparer l’OS du Raspberry Pi 5 à l’aide de notre poste local.

Etape I – Préparation de l’OS du Raspberry Pi 5 :

Branchez l’adaptateur contenant la carte Micro-D sur un port USB-A/C de votre poste local.

Sur votre poste, téléchargez le gestionnaire d’image OS pour Raspberry Pi depuis la page officielle :

Lancez l’exécutable téléchargé afin de l’installer l’outil de gestion d’image OS sur votre poste :

Une fois l’outil Raspberry Pi Image installé, lancez celui-ci, renseignez les 3 informations comme ceci, puis cliquez sur Suivant :

Cliquez sur le bouton suivant afin de personnaliser quelques réglages :

Sur le premier onglet, définissez le compte administrateur de votre choix, et si besoin la configuration wifi à utiliser :

Sur le second onglet, autorisez l’accès SSH (protocole qui permet d’établir une connexion chiffrée pour accéder et administrer un système à distance), puis cliquez sur Sauvegarder :

Cliquez cette fois sur Oui :

Confirmez l’écrasement des données en cliquant sur Oui :

Le traitement d’écriture sur la carte Micro-SD commence alors :

Attendez la fin des phases d’écriture et de vérification de la carte Micro-SD :

Une fois le processus terminé, retirer la carte Micro-SD, puis cliquez sur Continuez :

Insérer la carte Micro-SD dans votre Raspberry Pi 5, puis démarrez ce dernier.

En fonction de votre moyen de connexion de votre Raspberry Pi 5, ce dernier devrait disposer d’une adresse IP locale attribuée automatiquement par votre box (cette information est à vérifier et à obtenir sur la page de configuration réseau de votre box internet) :

Depuis votre ordinateur, ouvrez Windows PowerShell :

Connectez-vous en SSH à votre Raspberry Pi 5 via son adresse IP locale :

ssh VOTRE_NOM_UTILISATEUR@ADRESSE_IP_LOCALE

Une fois connecté à votre Raspberry Pi 5, vous pouvez passer à l’étape suivante, consistant à installer et déployer Teslamate. Ce dernier va nous permettre de :

  • Stocker les données MQTT émises par la voiture Tesla
  • Consulter les données MQTT depuis EnergyBoard
  • Envoyer des ordres API via l’agent Proxy HTTP (facultatif)

Etape suivante : Installation de Teslamate

Microsoft Cloud : tout savoir sur les certifications

Microsoft Learn | Microsoft Docs

La certification est une démarche personnelle et doit avant tout servir son propre intérêt. De mon point de vue, les bénéfices des certifications informatiques vont bien au-delà du fait de posséder une plaquette de badges sur le torse, ils sont multiples :

  • Montrer les compétences acquises dans un domaine technique précis
  • Gagner crédibilité auprès de son employeur
  • Augmenter sa confiance personnelle et son estime de soi
  • Valoriser son parcours professionnel
  • Et bien plus encore !
Why Certification is Important for IT Professionals? - Whizlabs Blog

Dans cet article, nous allons parler des caractéristiques propres aux différentes certifications Microsoft, mais surtout des facilités mises en place pour passer les certifications de type Fondamental.

Les familles de certifications Microsoft

Pour faire simple, il existe plusieurs classifications pour les certifications Microsoft Cloud :

  • Classification par thème (Azure, Microsoft 365, Dynamics 365, Power Platform)
  • Classification par niveau (Fondamental, Associé, Expert)
  • Classification par nature (Général, Rôle, Spécialité)
Poster des certifications Microsoft.
Cliquez sur l’image pour consulter la dernière version.

Comme vous pouvez le voir dans le poster ci-dessus, le choix est assez large sur les certifications possibles. Vous devez donc tenir compte d’un certain nombre de paramètres pour choisir la bonne certification adaptée à votre objectif. Prenez également en compte que certaines certifications sont liées à d’autres, tandis que certaines « imposent » des certifications préalables pour valider le titre associé.

Que signifient les niveaux de certification Microsoft ?

Microsoft a introduit les niveaux de certification durant l’année 2019 et les a répartis en trois niveaux. Cela a été mis en œuvre pour de nombreuses raisons, qui bénéficient à la fois au participant et à l’employeur de plusieurs façons :

  • Rendre les cours Microsoft plus accessibles aux débutants comme aux habitués de l’informatique
  • Encourager les personnes de tous niveaux à obtenir une certification
  • Faciliter le recrutement pour les employeurs en sélectionnant des professionnels en fonction des connaissances dont ils ont besoin
  • Clarifier le niveau de compétence de la certification

Les Certifications Microsoft de niveau « Fondamental »

Afin de démarrer le cloud dans les meilleurs conditions, Microsoft a mis en place des certifications de niveau « Fondamental ». Ces certifications sont conçues pour valider un niveau de connaissances de base des services du cloud. Elle aide également les candidats non techniques à comprendre les services tels que la vente, l’achat et le marketing. Par principe, elles n’exigent pas de prérequis antérieurs.

Les Certifications Microsoft de niveau « Associé »

De niveau intermédiaire, les certifications de niveau Associé vérifieront vos connaissances de manières approfondies. Plus question ici de valider si vous maîtrisez les grands principes du domaine concerné. Il est nécessaire ici de mettre en pratique vos connaissances dans des contextes techniques précis. A l’inverse des certifications de niveau Fondamental, où seul un apprentissage théorique serait suffisant, la validation d’une certification de niveau Associé devra s’appuyer sur une expérience professionnelle réelle.

Les Certifications Microsoft de niveau « Expert »

Comme son nom l’indique, les examens du niveau Expert sont beaucoup plus difficiles que celles de niveau Associé. Dans certains cas, il faut passer plusieurs examens de niveau Expert pour obtenir une certification. Il arrive aussi que, pour être validées, elles nécessitent des certifications de niveau inférieur.

Comment se préparer à passer une certification ?

Quels sont les avantages des formations en digital learning ? - Digiformag

Peu importe le niveau de certification désiré, le rituel de préparation reste globalement identique :

Microsoft Learn : Conçu pour aider quiconque à apprendre les concepts informatiques de base à son propre rythme, Microsoft Learn est une immense bibliothèque offrant un accès gratuit à des supports de formation, des échantillons de code et même la possibilité de tester certains logiciels Microsoft.

Formation dispensée par un instructeur : Le choix d’une formation dirigée par un instructeur est également une excellente option, car il vous permet d’interagir avec un professionnel expérimenté, vous donnant l’occasion de poser des questions et de travailler sur vos faiblesses, ainsi que de développer vos points forts.

Découverte de la solution : Microsoft propose de tester ses solutions de plusieurs manières. Il est possible de souscrire à des périodes d’évaluation sans frais ou de profiter de crédits gratuits pendant une certaine durée. Par exemple, il est donc possible de tester Office 365 ou Azure sans devoir payer pour ces services.

Parcours d’apprentissage : Chaque certification Microsoft s’accompagne d’un parcours d’apprentissage, en relation avec les sujets abordés pendant l’examen. Il vous permet d’aborder à votre rythme toutes les connaissances requises et vous évalue par de petits questionnaires.

YouTube : Le célèbre site de vidéos en ligne regorge de passionnés du cloud Microsoft qui vous transmettrons leurs connaissances techniques au travers d’explications claires et visuelles. Pourquoi s’en priver ?

GitHub : Microsoft Learning dispose de son propre GitHub. C’est l’occasion ici de travailler vos connaissances techniques grâce à des exercices ou des labs orientés sur la certification choisie.

Microsoft Virtual Training Days : Webinaires Microsoft gratuits et animés par des experts qui vous apporteront toutes les bases en rapport avec la certifications. Ces évènements sont orientés pour les certifications de niveau Fondamental ou pour certains thèmes spécifiques. Dans tous les cas, ils nécessitent une inscription préalable.

Microsoft Virtual Training Days

Que vous fassiez vos premiers pas dans le Cloud Microsoft ou que vous souhaitiez valider vos connaissances, Microsoft Virtual Training Days est fait pour vous.

Microsoft Virtual Training Days regroupe les principaux thèmes du Cloud Microsoft et vous propose plusieurs sessions dédiées :

Peu importe le Training Day choisi, le webinaire vous montre tous les chapitres de la certification et les aborde de manière claire et progressive. Vous pouvez donc les suivre sans avoir la crainte de pas comprendre les concepts et les idées présentés.

Enfin et ce n’est pas des moindres, Microsoft récompense les participants à ces webinaires en offrant gratuitement un bon d’examen. Vous avez bien lu, l’examen facturé initialement 99 euros hors taxes ne vous coûtera pas un centime si vous assistez au webinaire, lui-même gratuit !

Bien évidemment, passer l’examen en ne suivant que ce webinar s’avère fortement risqué. Je vous recommande donc de compléter vos connaissances par les autres sources listées dans la section précédente.

Une fois la certification réussie

Tout d’abord, félicitations !!! C’est une petite victoire personnelle sur ses propres capacités. Cela montre que ce challenge était à votre portée et qu’il récompense les efforts fournis. Il ne faut pas rougir de son succès, et le partager sur les réseaux est mérité. Cela peut aussi encourager d’autres connaissances à choisir cette voie ou provoquer un déclic sur leur orientation professionnelle.

Bouteille de champagne 75cl - Le Moulin de Ducey

Conclusion

Comme à chaque fois, pensez à partager dans les commentaires vos propres expériences sur les certifications, Microsoft ou autres ????

Microsoft Security Operations Analyst (SC-200)

On continue notre apprentissage sur la sécurité Azure avec cette nouvelle certification Azure SC-200, sortie il y a peu. Pour rappel, cette dernière fait partie d’un ensemble de 4 certifications dédiées à la sécurité au sein du Cloud Microsoft. J’ai déjà détaillé plusieurs d’entre-elles sur ce blog :

Nul doute que Microsoft n’a pas encore fini de nous en apprendre sur la sécurité en 2021, et je m’attends comme d’autres à de nouvelles certifications dans ce domaine. Mais focalisations-nous maintenant sur cet examen, passé ce jour par votre serviteur 🙂

Comme toujours, voici les liens fort utiles pour toutes les informations associées :

Contenu de l’examen

Plus sérieusement, le contenu de l’examen est assez clair puisque 3 grandes thématiques sont listées ci-dessous, à savoir :

  • Microsoft 365 Defender (25-30%)
  • Azure Defender (25-30%)
  • Azure Sentinel (40-45%)

Comme on le comprend assez vite à l’aide des différents pourcentages associés à chaque rubrique, Azure Sentinel prend une place de premier ordre dans le nombre des questions que vous aurez à répondre pendant cet examen. Autant donc commencer par lui.

Azure Sentinel

Qu’est-ce qu’Azure Sentinel ?

Microsoft Azure Sentinel est une solution native cloud et scalable de type SIEM (Security Information and Event Management) et SOAR (Security Orchestrated Automated Response) . Azure Sentinel assure une analyse de sécurité intelligente et fournit des informations sur les menaces dans l’ensemble de l’entreprise. Elle constitue une solution unique pour la détection des alertes, la visibilité des menaces, la chasse proactive et la réponse face aux menaces.

La réponse complète de Microsoft ici
What's the difference between Azure Security Center, Azure Defender and  Azure Sentinel? - Microsoft Tech Community

Autrement dit, cette solution s’intègre parfaitement avec les différents outils du Cloud Microsoft dédiés à la sécurité. Il ne faut surtout pas donc voir Azure Sentinel comme un énième et redondant outil de sécurité, mais bien comme un véritable système avec des moyens concrets pour les membres de l’équipe SOC.

Ce slide met en évidence les rôles et les attentes entre Azure Security center et Azure Sentinel. D’un côté il va être question de collecter et de prévenir le risque, tandis que de l’autre il sera question de détecter, d’investiguer et de répondre aux menaces.

Si on doit résumer Azure Sentinel en quelques mots pour vous faire une idée, voici ce qu’Azure Sentinel est capable d’apporter pour votre sécurité :

  • Compilation de données via de nombreux connecteurs (plus d’une centaine à date)
  • Détection des menaces
  • Outils d’investigation des menaces
  • Moyens de réponses rapides

Quels seraient alors les bénéfices que vous pouvez retirer d’Azure Sentinel ?

  • Mise en place de tableaux de bord intuitifs
  • Possibilités infinies de requêtage
  • Mise en place d’automatisation des réponses face aux menaces
  • Exploitation de Microsoft Machine Learning pour accroitre les capacités de détection
  • Intégration complète de Microsoft Intelligent Security Graph
  • Installation « facile » selon les besoins de sécurité
Comme à chaque fois, merci à John pour ses vidéos plus que claires

Pour vous aider à « maîtriser » Azure Sentinel, Microsoft a découpé son parcours d’apprentissage en 5 parties :

Comme à chaque fois, j’ai pris le temps de suivre le parcours d’apprentissage afin de me faire une idée précise sur le contenu abordé et sur la qualité.

Comme pour la SC-300, je suis assez content du résultat, même si je trouve que les exercices donnés à travers les différentes parties se ressemblent énormément et ne vont pas assez loin dans les manipulations utilisateurs. J’aurais aimé avoir plus de cas variés à réaliser dans Azure Sentinel pour donner plus de sens à certaines fonctionnalités.

Principaux connecteurs du monde Azure avec leur périmètre.

A quoi s’attendre dans cet examen ?

Malheureusement pas de mystère, une maîtrise de la solution est attendue afin de voir que vous avez bien passé du temps dans la solution ! Il faut donc comprendre ses mécanismes, son utilisation au quotidien dans la gestion des rules / alertes / incidents / workbooks.

Categorizing Microsoft alerts across data sources in Azure Sentinel -  Microsoft Tech Community
On ne vous demandera pas de sortir la liste de tous les connecteurs ! Mais certains propres à l’environnement du Cloud Microsoft sont bien évidement à connaître.

Il faut donc s’attendre à coup sûr à :

  • Des questions sur Kusto Query Language (KQL). Prenez donc le temps pour le tester et vous familiariser au maximum avec les opérateurs
  • Des questions sur les principaux connecteurs de données (Azure et éventuellement AWS). Mettez en place un certain nombre de connecteurs afin comprendre leur intérêt et les données remontées
  • Des questions sur les relations entre rules / alertes / incidents / workbooks
  • Des questions sur la gestion automatisée d’une alerte avec les automations / playbooks
  • Des questions sur les rôles propres à Azure Sentinel
  • Des questions sur l’architecture d’Azure Sentinel ( X logs Analytics Workspaces + Azure Sentinel)

Bref pas mal de sujets à connaître, et il en reste encore d’autres qui peuvent aussi tomber :

  • Notebooks
  • Hunting
  • Workbooks
  • Entities

Cela peut représenter beaucoup, mais ne vous découragez pas ! 🙂

Azure Defender

Qu’est-ce qu’Azure Security Center ?

Azure Security Center est un système de gestion de la sécurité de l’infrastructure unifié qui renforce la posture de sécurité de vos centres de données et fournit une protection avancée contre les menaces pour vos charges de travail hybrides dans le cloud (dans Azure ou non), ainsi qu’en local.

Source Microsoft
Si Azure Security Center est quelque chose de nouveau pour vous, je vous conseille cette vidéo d’Adam.

Qu’est-ce qu’Azure Defender ?

Azure Defender offre une détection et une réponse étendues pour les charges de travail exécutées dans Azure, localement et dans d’autres clouds. Intégré à Azure Security Center, Azure Defender protège vos données hybrides, vos services cloud natifs ainsi que vos serveurs contre les menaces.

Les fonctionnalités d’Azure Security Center couvrent les deux piliers de la sécurité cloud :

Combien d’outils composent Azure Security Center ?

Voici donc comment cela s’articule entre ces deux outils qui au final n’en sont qu’un seul.

CSPM (gestion de la posture de sécurité cloud) – Security Center est disponible gratuitement pour tous les utilisateurs Azure. L’expérience gratuite comprend des fonctionnalités CSPM telles que le degré de sécurisation, la détection des erreurs de configuration de sécurité dans vos machines Azure, l’inventaire des ressources et bien plus encore. Utilisez ces fonctionnalités CSPM pour renforcer la posture de votre cloud hybride et suivre la conformité avec les stratégies intégrées.

Protection de charge de travail cloud (CWP) – La plateforme de protection de charge de travail cloud (CWPP), Azure Defender, garantit une protection avancée et intelligente de vos ressources et charges de travail Azure et hybrides. L’activation d’Azure Defender offre un large éventail de fonctionnalités de sécurité supplémentaires, tel que décrit sur cette page. Outre les stratégies intégrées, lorsqu’un plan Azure Defender est activé, vous pouvez ajouter des stratégies et des initiatives personnalisées. Vous pouvez ajouter des normes réglementaires, telles que NIST et Azure CIS, ainsi que le Benchmark de sécurité Azure pour un aperçu véritablement personnalisé de votre conformité.

Source Microsoft
Une fois Azure Defender activé, on retrouve un tableau de bord des ressourcées protégées ou non par type.
Seconde vidéo dédiée à Azure Defender.

Un seul chapitre est uniquement présent pour Azure Defender, il va falloir chercher plus loin et passer du temps dans la solution :

A quoi s’attendre dans cet examen ?

Je ne vais pas le répéter, mais toujours une connaissance précise de la solution 😉

Voici quelques pistes à explorer pour se sentir à l’aise dans l’examen :

  • Des questions sur les résultats des polices compliances
  • Des questions sur la gestion des alertes / recommandations ouvertes par Azure Defender
  • Des questions sur le traitement des vulnérabilités découvertes par Azure Defender
  • Des questions sur l’activation de contre-mesures sur les ressources surveillées par Azure Defender (Machines virtuelles, Key Vaults, Comptes de stockage, Bases SQL, …)
  • Des questions sur les rôles nécessaires pour les opérateurs d’Azure Defender
  • Des questions sur les processus d’on-boarding et les contrôles associés

Cela peut représenter beaucoup, mais ne vous redécouragez pas ! 🙂

Microsoft 365 Defender

Qu’est-ce que Microsoft 365 Defender ?

Microsoft 365 Defender unifie votre processus de réponse aux incidents en intégrant des fonctionnalités clés dans Microsoft Defender pour le point de terminaison, Microsoft Defender pour Office 365, Microsoft Cloud App Security et Microsoft Defender pour l’identité. Cette expérience unifiée ajoute des fonctionnalités puissantes auxquelles vous pouvez accéder dans le Centre de sécurité Microsoft 365.

Source Microsoft
Microsoft Defender pour point de terminaison, Microsoft 365
On parle donc ici d’une solution unifiée au travers d’un nouveau portail.
  • Points de terminaison avec Microsoft Defender pour Endpoints– Microsoft Defender pour Endpoints est une plateforme de point de terminaison unifiée pour la protection préventive, la détection post-violation, l’examen automatisé et la réponse.
  • E-mail et collaboration avec Microsoft Defender pour Office 365 – Defender pour Office 365 protège votre organisation contre les menaces malveillantes posées par les messages électroniques, les liens (URL) et les outils de collaboration. Identités avec
  • Microsoft Defender pour l’identité et Azure AD Identity Protection – Microsoft Defender pour l’identité utilise les signaux Active Directory pour identifier, détecter et examiner les menaces avancées, les identités compromises et les actions internes malveillantes dirigées contre votre organisation.
  • Applications avec sécurité Microsoft Cloud App : la sécurité de Microsoft Cloud App est une solution SaaS complète qui apporte une visibilité approfondie, des contrôles de données forts et une protection renforcée contre les menaces à vos applications cloud.

Attention à ne pas vous perdre avec certaines anciennes dénominations :

  • Microsoft 365 Defender (précédemment Microsoft Threat Protection)
  • Microsoft Defender for Endpoint (précédemment Microsoft Defender Advanced Threat Protection)
  • Microsoft Defender for Office 365 (précédemment Office 365 Advanced Threat Protection)
  • Microsoft Defender for Identity (précédemment Azure Advanced Threat Protection)
Encore une fois, il ne s’agit pas de solutions qui ne se chevauchent, mais bien complémentaires.
Merci Jean-Sébastien 😉

Deux chapitres sont présents pour Microsoft 365 Defender. Encore une fois il va falloir chercher plus loin et passer du temps dans la solution pour avoir une idée de tous ces outils :

A quoi s’attendre dans cet examen ?

  • Des questions sur Cloud App Security et des polices mises en place
  • Des questions sur le shadow IT, mettant en évidence les applications découvertes via Cloud App Security
  • Des questions sur Azure Information Protection dans le cadre de la politique d’Office365
  • Des questions sur les périphériques surveillés par la partie Defender for Endpoints et les risques détectés
  • Des questions sur le risques liés aux identités et donc gérés par Defender for Identity

Conclusion

Cette certification comble un espace non occupé jusqu’à présent, car elle apporte de vraies réponses techniques à un grand nombre de défis de sécurité qui touchent les entreprises. La sécurité est bien une affaire multicouche et multidirectionnelle. Comme toujours, pensez à partager dans les commentaires vos autres sources d’apprentissage, ou votre feedback sur l’examen ????

AVD – Démarrage des VMs à la demande

Annoncé fin mars 2021 pour les environnements personnels Azure Virtual Desktop, Azure Preview propose maintenant cette même fonction pour les environnements AVD mutualisés (Pooled).

Voici un petit rappel de la solution par Dean d’Azure Academy.

La vidéo de Dean met en oeuvre la solution sur un environnement AVD personnel, qui fonctionne aussi pour les environnements mutualisés, et applique les point suivants :

  • Activation de l’option « Start VM On Connect » sur le Host Pool
  • Création d’un rôle custom pour donner le droit à AVD de démarrer les VMs
  • Affectation du rôle custom à la souscription ou au groupe de ressources
  • Déconnexion des sessions inactives via GPO
  • Activation de l’arrêt automatique des machines virtuelles à une heure fixe

Mise en place : La mise en place de cette solution est bien expliquée dans la vidéo de Dean, vous pouvez aussi suivre la documentation de Microsoft juste ici.

Rappel : La fonction est encore en public preview pour les environnements AVD mutualisés, il faut donc utiliser le portail adéquat.

Testez vous-même

De mon côté, j’ai souhaité tester la solution sur différents cas de figure :

  • Test sur un AVD en mode personnalisé : OK
  • Test sur un AVD en mode mutualisé (Windows 10 multisession) : OK
  • Test sur un AVD en mode mutualisé (Windows Server 2019) : OK

J’ai aussi fait un test plus poussé dans le cadre d’un environnement AVD mutualisé comprenant plusieurs machines virtuelles :

  • Nombre de machines virtuelles : 2
  • Algorithme d’équilibrage de charge : Breadth-first
  • Nombre maximal de sessions : 5

Voici ce qui s’est passé au niveau des machines virtuelles :

Environnement de départ, toutes les VMs sont OFF.
Connexion du premier utilisateur, une seule VM s’allume.
Connexion du second utilisateur, la seconde VM ne s’allume pas car l’utilisateur se retrouve connecté à la première VM.

J’ai donc refait un autre test en modifiant le nombre maximal de sessions :

  • Nombre de machines virtuelles : 2
  • Algorithme d’équilibrage de charge : Breadth-first
  • Nombre maximal de sessions : 1

Les premières étapes n’ont pas changé, mais j’ai bien eu autre chose lorsque le second utilisateur a tenté de se connecter :

Le second utilisateur doit bien attendre le démarrage de la seconde VM pour s’y connecter.
Les deux VMs sont bien allumées dans ce cas.

Conclusion

Au final, la fonctionnalité est bien opérationnelle et s’adapte bien à différents cas d’architecture Azure Virtual Desktop. Seul petit bémol concernant la fonction Breadth-first qui demande encore quelques ajustements pour bien allumer les autres VMs afin de répartir les utilisateurs ????

Certification Microsoft Identity and Access Administrator (SC-300)

Preparing for the SC-300: Microsoft Identity and Access Administrator exam  (May 2021) – intunedin.net

Voici un nouvel article sur les dernières certifications de sécurité sur le Cloud Azure de Microsoft. Pour rappel, vous pouvez retrouver mon article sur la certification fondamentale SC-900 ici, ainsi que sa page officielle Microsoft juste .

Que dire sur ce nouvel examen SC-300 ?

Là encore, vous pouvez retrouver tous les détails de cette dernière sur sa page officielle Microsoft.

J’ai passé cette certification de niveau Associate cette semaine. Pendant et juste après cet examen, j’ai trouvé la certification assez difficile, car elle exigeait beaucoup de mises en situation, requérant des connaissances assez précises sur les sujets que je vais essayer vous détailler tout au long de cet article.

Finalement aucun doute, la SC-300 est bien une certification de niveau Associate. Pour un peu moins la moitié des questions environ, j’avais encore un petit doute entre 2 réponses sur 4.

Dans cet examen, attendez-vous donc à :

  • Beaucoup de questions contextualisées avec 4 choix possibles
  • Des questions groupées avec OUI / NON
  • Peu de questions sur la restitution des grands principes (points faciles à ne pas négliger)
  • Un ou deux use-cases portant sur des architectures hybrides
  • Et toujours pas de labs

Que retrouve-t-on dans le Parcours d’apprentissage de la SC-300?

Le parcours d’apprentissage reprend de manière méthodique les principaux chapitres rattachés à cette certification. Une fois n’est pas coutume, j’ai suivi tous les modules de formations proposés par Microsoft.

Pourquoi cela ? Car le contenu trouvé sur internet est encore assez variable à date ou incomplet.

Au final, j’ai trouvé le parcours très bien construit autour de cette certification. Beaucoup de schémas explicatifs, de copies d’écran d’Azure et de vidéos d’introduction. De plus, les exercices pratiques avaient toujours du sens sur le thème abordé.

En revanche, ne vous faites pas avoir en ne vous basant que sur celui-ci ! Pour avoir être sûr d’avoir plus de points que les 700 nécessaires, il vous faudra avoir :

  • Les connaissances acquises par l’expérience dans Azure AD
  • A défaut de tout connaitre dans les moindre détails, une bonne dose déduction pour ne garder que les « réponses possibles »

Voici un rappel des modules du parcours avec leurs liens :

Voici également quelques blogs qui pourront vous aider dans votre apprentissage de cette SC-300 :

Rien à voir ici, mais je suis en train de manger une pizza maison 😉

Implémenter une solution de gestion des identités

Mettre en œuvre la configuration initiale d’Azure Active Directory

On arrive ici dans le cœur du sujet de cette certification :

L’identité est au centre d’Azure Active Directory et vous devez la comprendre et la maîtriser sous tous ses aspects

Plus question ici de restituer la « simple » compréhension du service ou de ses fonctionnalités. Il faut savoir l’utiliser selon différents cas de figure. Attendez-vous donc à avoir des questions sur les identités dans un contexte très précis. Peu de pièges, mais on attend des connaissances.

Par exemple, la question pourrait porter sur un type d’identité particulier avec un scénario de droits spécifiques de manière combinée. Rien de tel alors que de se refaire un passage sur les identités Azure :

Merci à John Savill 🙂

L’autre exemple serait de devoir choisir le rôle ayant le moins de privilège pour faire telles ou telles actions dans Azure AD. Ce point-ci est assez difficile car la connaissance globale des rôles sera nécessaire pour être vraiment sûr de la bonne réponse. Voici liste complète et quelques rôles pris au hasard :

La gestion des domaines personnalisés revient souvent dans beaucoup de certifications sur Azure. C’est l’occasion de marquer des points facilement en connaissant bien le processus d’ajout de domaines personnalisés :

  • Ajout du domaine personnalisé dans Azure AD
  • Modification des enregistrements DNS
  • Vérification du domain dans Azure AD
  • Utiliser le nom de domaine pour les utilisateurs, adresses mails ou autres besoins

Même si la gestion des appareils est plutôt une tache dédiée à Endpoint admin center, certaines actions et donc certaines questions peuvent vous être posées ici.

Who are you ?

Il faut avant tout bien maîtriser les concepts de jointures des devices dans Azure, comme par exemple l’hybrid join :

Appareils joints Azure AD hybrides.
Dans Windows Virtual Desktop, l’hybrid join va permettre le SSO pour une meilleure expérience utilisateur.

Les unités administratives dans Azure AD est un concept intéressant, car elles limitent les autorisations d’un rôle en fonction du service auquel il appartient au sein de l’organisation :

Azure Administrative Units and MyStaff for delegated management | Marius  Sandbu
Principe de délégation des rôles selon des unités organisationnelles dans Azure AD.
Sécurité par défaut d’Azure AD

Azure AD propose un mode de gestion de sécurité par défaut. Sa mise en place est des plus simple, mais il n’autorise aucune personnalisation.

Les paramètres de sécurité par défaut facilitent la protection de votre organisation contre ces attaques avec des paramètres de sécurité préconfigurés :

  • Exige que tous les utilisateurs s’inscrivent à Azure AD Multi-Factor Authentication
  • Exige des administrateurs qu’ils effectuent l’authentification multifacteur
  • Restreint les anciens protocoles d’authentification
  • Exige des utilisateurs qu’ils effectuent l’authentification multifacteur
  • Restreint des activités, telles que l’accès au Portail Azure

Gestion des utilisateurs, des groupes et des licences

Quoi de mieux comme question que celle ci-dessous :

Des licences sont attribuées à un groupe d’utilisateurs et celui-ci contient des utilisateurs et d’autres groupes. Combien de licences seront attribuées ?

Un début de réponse dans cette article !

De manière générale et hormis des questions de ce type, il s’agit de points faciles.

Mettre en œuvre et gérer les identités externes

Les identités externes font parties de beaucoup de scénarios d’Azure AD, il faut donc maîtriser leur intégration et les options de sécurités les concernant :

Je ne vous dis pas d’aller pas jusqu’à connaitre les en-têtes du fichier CSV d’import bulk 😉

  • Email address to invite
  • Redirection url
  • Send invitation message
  • Customized invitation message

Mettre en œuvre et gérer l’identité hybride

On cherche donc à savoir si les différentes méthodes de synchronisation entre un environnement on-premise et le Cloud n’ont plus de secrets pour vous. Ce module comporte donc les grands sujets ci-dessous :

Pas de mystère ici, le mieux étant d’avoir pu installer soi-même AD Connect sur un environnement on-premise (Active Directory), et d’avoir testé plusieurs scénarios afin d’en mesurer les impacts (avantages – inconvénients) :

Tour d’horizon d’Azure AD Connect par l’Azure Academy

C’est typiquement lors des use-cases que vous devrez maîtriser ces concepts pour proposer la solution la plus attendue :

Mettre en œuvre une solution d’authentification et de gestion des accès

Planifier et mettre en œuvre l’authentification multifactorielle Azure (MFA)

L’authentification multifacteur est un processus dans lequel l’utilisateur est invité pendant le processus de connexion à suivre une forme d’identification supplémentaire, consistant par exemple à entrer un code sur son téléphone portable ou à scanner son empreinte digitale.

Illustration conceptuelle des éléments de MFA

Les 3 piliers de la MFA 🙂

  • Quelque chose que vous connaissez – Il pourrait s’agir d’un mot de passe ou de la réponse à une question de sécurité
  • Quelque chose que vous possédez – Il pourrait s’agir d’une application mobile qui reçoit une notification ou un d’appareil de génération de jetons
  • Quelque chose que vous êtes – En général, il s’agit d’une propriété biométrique, comme la détection du visage ou des empreintes digitales utilisée sur de nombreux appareils mobiles
Cette vidéo explique étape par étape le processus de mise en place de la MFA

Quelles seraient les questions possibles dans cette certification ? Il faut voir la MFA comme un point combiné avec d’autres facteurs, comme par exemple son impact dans un accès conditionnel, ou alors son rôle dans Azure AD Identity Protection.

Close the gap. Azure AD Identity Protection & Conditional Access. -  JanBakker.tech
Deux facteurs sont représentés ici : sign-in risk et user risk.
la MFA va jouer un rôle de sécurité important.

Gérer l’authentification des utilisateurs

Dans Azure Active Directory, l’authentification implique plus que la simple vérification d’un nom d’utilisateur et d’un mot de passe. Pour améliorer la sécurité et réduire le recours à l’assistance du support technique, l’authentification Azure AD comprend les composants suivants :

Tableau des avantages et des méthodes d’authentification préférées dans Azure AD
Les méthodes d’authentification sans mot de passe telles que Windows Hello, les clés de sécurité FIDO2 et l’application Microsoft Authenticator permettent les événements de connexion les plus sécurisés.

Attendez-vous donc à des question sur les méthodes possibles pour les utilisateurs lors d’un processus de réinitialisation de mot de passe libre-service :

  • Notification sur l’application mobile
  • Code de l’application mobile
  • E-mail
  • Téléphone mobile
  • Téléphone de bureau
  • Questions de sécurité

Ou sur les différentes méthodes possibles pour enregistrer une MFA :

Comment les composants de protection par mot de passe Azure AD fonctionnent ensemble
Password Protection : j‘avais fait une blague sur ce schéma pour la SC-900.
Ici c’est bien un concept à connaitre, et idéalement de l’avoir essayé pour différencier les rôles et les agents à installer
.

Planifier, mettre en œuvre et administrer l’accès conditionnel

Vous pouvez utiliser des stratégies d’accès conditionnel pour appliquer des contrôles d’accès tels que l’authentification multifacteur (MFA). Vous aurez à coup sûr des questions impliquant la MFA. le cas classique est d’identifier quel facteur modifier pour activer une MFA, selon les exigences données par le contexte.

Conditional Access overview
Les stratégies d’accès conditionnel vous permettent d’inviter des utilisateurs à l’authentification multifacteur lorsque cela est nécessaire pour la sécurité et à ne pas le leur demander lorsque cela n’est pas nécessaire.

L’accès conditionnel est un premier outil que l’on met en place pour augmenter la sécurité sur Azure. Par exemple, la gestion des localisation peut être un point très important pour améliorer l’expérience utilisateur :

  • En évitant « d’harceler » les utilisateurs avec un contrôle MFA lorsque l’on se trouve au bureau
  • En imposant la MFA si l’utilisateur se connecte depuis un appareil non compliant

L’infrastructure d’accès conditionnel vous offre une grande flexibilité de configuration. Toutefois, une grande flexibilité implique également que vous examiniez soigneusement chaque stratégie de configuration avant de la mettre en œuvre, afin d’éviter des résultats indésirables.

Image de l’écran affichant un accès aux ressources bloqué en raison d’une stratégie d’accès conditionnel activée
Message issu de l’accès conditionnel, bloquant pour l’utilisateur

Gérer Azure AD Identity Protection

Identity Protection est un outil qui permet aux organisations d’accomplir trois tâches principales :

  • Automatiser la détection et la correction des risques liés à l’identité
  • Examiner les risques à l’aide des données disponibles sur le portail
  • Exporter les données de détection des risques vers des utilitaires tiers pour une analyse plus approfondie

Ici encore, des questions seront possible pour savoir ce qui se passera si l’utilisateur déclenche une alerte :

  • Réinitialisation du mot de passe ?
  • Demande de vérification MFA ?
Azure AD utilise l’apprentissage automatique pour détecter les anomalies et les activités suspectes, en utilisant à la fois des signaux détectés en temps réel pendant les ouvertures de session et des signaux en temps différé liés aux utilisateurs et à leurs activités d’ouverture de session.

Implement Access Management for Apps

Il s’agit ici du chapitre de la certification le plus faiblement noté. Il s’agissait aussi de celui que je maîtrisais le moins :D. Je n’ai pas eu beaucoup de questions, mais c’est toujours bon d’éviter de perdre des points dessus.

Planifier, mettre en œuvre et surveiller l’intégration des applications d’entreprise pour l’authentification unique (SSO)

Je ne vais pas trop m’étendre sur cette section.

Autre sujet de sécurité œuvrant sur les applications d’entreprise : Cloud App Security

Cloud App Security intègre la visibilité à votre cloud pour mapper et identifier votre environnement cloud et les applications cloud utilisées par votre organisation en utilisant des connecteurs faciles à déployer :

Schéma de l’architecture Cloud App Security.

Mettre en œuvre les enregistrements d’applications

Je n’ai rien de trouvé de plus explicatif que cette très bonne vidéo de John Savill :

A regarder en entier ! 🙂

Planifier et implémenter une stratégie de gouvernance des identités

On arrive au dernier chapitre … Aussi je vous conseille de ne pas négliger cette section car le pourcentage est assez important pour cette dernière sur cet examen.

De plus, je me rappelle avoir eu plusieurs questions dessus. Rien de vraiment compliqué ici, mais une bonne connaissances des outils devrait faire l’affaire.

Planifier et mettre en œuvre la gestion des droits

Il s’agit ici d’un sujet que je n’avais jamais abordé avant cette certification. J’ai pu donc découvrir et tester ce principe par le biais de la révision, et j’ai eu plusieurs questions portant sur la stratégie d’attribution des droits.

All about CIAM
Finalement le concept est assez simple car il apporte plus de clarté dans l’approvisionnement des services pour les employées et le déprovisionnement pour ces derniers quand leur mission est terminée.

La gestion des droits d’utilisation introduit sur Azure AD le concept de package d’accès. Un package d’accès regroupe toutes les ressources avec l’accès dont un utilisateur a besoin pour travailler sur un projet ou accomplir sa tâche. Les packages d’accès permettent de régir l’accès de vos employés et utilisateurs internes en dehors de votre organisation. Vous pouvez gérer l’accès des utilisateurs aux ressources suivantes avec la gestion des droits d’utilisation.

What is entitlement management? - Azure AD | Microsoft Docs
Le diagramme suivant montre un exemple des différents éléments en matière de gestion des droits d’utilisation.

Une connaissances des termes et de leurs rapports entre eux est donc fort utile :

TermeDescription
package d’accèsBundle de ressources dont une équipe ou un projet a besoin et qui est régi par des stratégies. Un package d’accès est toujours contenu dans un catalogue. Vous créez un package d’accès pour un scénario dans lequel les utilisateurs doivent demander l’accès.
demande d’accèsDemande d’accès aux ressources dans un package d’accès. Cette demande transite généralement par un flux d’approbation. Si elle est approuvée, l’utilisateur demandeur reçoit une affectation de package d’accès.
affectationL’affectation d’un package d’accès à un utilisateur garantit que l’utilisateur dispose de tous les rôles de ressources de ce package d’accès. Les affectations de package d’accès ont généralement une durée limite avant leur expiration.
catalogueConteneur de ressources connexes et de packages d’accès. Les catalogues sont utilisés pour la délégation, si bien que les non-administrateurs peuvent créer leurs propres packages d’accès. Les propriétaires de catalogue peuvent ajouter les ressources qu’ils possèdent à un catalogue.
créateur de catalogueRegroupement d’utilisateurs autorisés à créer des catalogues. Lorsqu’un utilisateur non-administrateur, autorisé à être créateur de catalogue, crée un catalogue, il devient automatiquement le propriétaire de ce catalogue.
organisation connectéeDomaine ou annuaire Azure AD externe avec lequel vous avez une relation. Les utilisateurs provenant d’une organisation connectée peuvent être spécifiés dans une stratégie comme étant autorisés à demander l’accès.
policeEnsemble de règles définissant le cycle de vie d’un accès, telles que le mode d’accès des utilisateurs, les approbateurs et la durée d’accès par le biais d’une affectation. Une stratégie est liée à un package d’accès. Par exemple, un package d’accès peut avoir deux stratégies de demande d’accès : l’une pour les employés, l’autre pour les utilisateurs externes.
ressourceRessource (un groupe Office, un groupe de sécurité, une application ou un site SharePoint Online, par exemple) dotée d’un rôle pour lequel un utilisateur peut obtenir des autorisations.
répertoire de ressourcesRépertoire comprenant une ou plusieurs ressources à partager.
rôle de ressourceCollection d’autorisations associées à une ressource et définies par elle. Un groupe a deux rôles : membre et propriétaire. Les sites SharePoint ont généralement trois rôles, mais peuvent avoir des rôles personnalisés supplémentaires. Les applications peuvent avoir plusieurs rôles personnalisés.

Planifier, implémenter et gérer la révision d’accès

Les révisions d’accès Azure Active Directory permettent aux organisations de gérer efficacement les appartenances à des groupes, les accès aux applications d’entreprise et les attributions de rôles. Je vous confirme avoir eu des questions sur la revue d’accès. Le processus n’est pas très compliqué. Quelques petits rappels :

  • Aucun résultat n’est appliqué avant la fin de la période de revue ou si le créateur stoppe et applique les résultats lui-même
  • Un accès pour un utilisateur (révoqué ou conservé) peut être changé plusieurs fois pendant la période de revue d’accès. Seul le dernier statut sera conservé et appliqué
L’accès des utilisateurs peut être passé en revue régulièrement pour vérifier que seules les personnes appropriées continuent de bénéficier d’un accès.
Plan an Azure Active Directory Access Reviews deployment | Microsoft Docs
Process de revue d’accès en 3 étapes : tout commence par la création de la revue, puis la validation et enfin l’application des résultats.

Planifier et mettre en œuvre l’accès privilégié

Privileged Identity Management est un service dans Azure Active Directory (Azure AD) qui vous permet de gérer, de contrôler et de superviser l’accès aux ressources importantes de votre organisation :

Je me souviens avoir eu une question sur un rôle devant passer sous attribution via Privileged Identity Management. Connaître les différentes étapes est donc important pour mettre en œuvre le processus et son utilisations par les demandeurs de droits.

Comment PIM fonctionne ?

Surveiller et gérer les Azure Active Directory

Les journaux d’audit et de diagnostic d’Azure Active Directory fournissent une vue détaillée de la façon dont les utilisateurs accèdent à votre solution Azure. Découvrez comment surveiller, dépanner et analyser les données de connexion.

L’architecture de création de rapports dans Azure AD comprend les composants suivants :

  • Activité
    • Connexions : Il s’agit d’informations sur l’utilisation des applications managées et les activités de connexion des utilisateurs.
    • Journaux d’audit : Fournissent des informations sur les activités du système liées aux utilisateurs et à la gestion des groupes, les applications gérées et les activités de répertoire.
    • Les journaux de provisionnement : permettent aux clients de superviser l’activité effectuée par le service de provisionnement, telle que la création d’un groupe dans ServiceNow ou l’importation d’un utilisateur à partir de Workday.
  • Sécurité
    • Connexions risquées : une connexion risquée correspond à un indicateur de tentative de connexion d’un utilisateur autre que le propriétaire légitime d’un compte d’utilisateur.
    • Utilisateurs avec indicateur de risque : il s’agit d’un compte d’utilisateur susceptible d’être compromis.

Des questions sur la rétention peuvent tomber, gardez donc en tête ces durées de rétention :

Rapports d’activité
RapportAzure AD GratuitAzure AD Premium P1Azure AD Premium P2
Journaux d’audit7 jours30 jours30 jours
Connexions7 jours30 jours30 jours
Utilisation d’Azure AD MFA30 jours30 jours30 jours

Signaux de sécurité

RapportAzure AD GratuitAzure AD Premium P1Azure AD Premium P2
Les utilisateurs à risque7 jours30 jours90 jours
Connexions risquées7 jours30 jours90 jours

Conclusion

Cette certification apporte donc un véritable tour d’horizon sur la sécurité dans Azure Active Directory. Je peux dire avec certitude qu’il y n’y pas beaucoup de notions croisées avec les certifications AZ-500 et MS-500. Elle permettra donc de valider vos connaissances sur la gestion des identités dans le Cloud.

Mes derniers conseils

  • Prenez surtout le temps de bien tester chaque module dans un environnement de test pour en connaître le fonctionnement et en mesurer les impacts
  • Etant souvent dans des environnements de tests, on néglige assez régulièrement les rôles préconstruit dans Azure Active Directory. La sécurité passe par une gestion mesurée des droits des administrations. Lisez donc leurs droits et testez-les !

Aujourd’hui, nous sommes le 1er mai, il faut donc lâcher un peu ses révisions et se vider l’esprit 😀

Pensez à partager dans les commentaires vos autres sources d’apprentissage, ou votre feedback sur l’examen. ????