# La sécurité informatique en entreprise William Petit - S.C.O.P. Cadoles --- ## Rappel des objectifs de la sécurité informatique 1. Maintenir l'intégrité des données 2. S'assurer du niveaux d'authentification et d'autorisation 3. Maintenir la disponibilité des services 4. Assurer la traçabilité des échanges 5. Éviter la fuite d'informations --- ## Topologie d'exemple ![center 100%](./img/intranettopologie.png) --- ## Mise en garde La topologie de cette exemple est **volontairement simplifiée**. Elle n'est là que pour vous présenter les grands principes de séparation en "zones" de l'architecture réseau d'une entreprise, les "rôles" de ces différentes zones et la manière de les traiter d'un point de vue sécurité. En réalité, la plupart des réseaux d'entreprise comportent beaucoup plus de ces zones, souvent imbriquées et multiplient les routeurs/pare-feu entre les zones. --- ## Démarrage de la maquette 1. Installer [Vagrant](https://www.vagrantup.com/downloads.html) et [VirtualBox](https://www.virtualbox.org/) sur son poste. 2. Récupérer le projet Vagrant `intranet-demo`. 3. Se placer dans le répertoire `intranet-demo` et faire dans une invite de commande ``` vagrant plugin install vagrant-reload vagrant-vbguest vagrant up ``` 4. Lorsque le programme vous le demande (2 fois), sélectionner l'interface réseau à utiliser (votre interface filaire ou wifi branchée au réseau de l'établissement). 5. Attendre la fin de l'installation. --- ## Le pare feu Première et dernière ligne de défense entre le réseau de l'entreprise et Internet. Il est en charge de filtrer les communications entre le réseau de l'entreprise et l'extérieur. Dans notre configuration d'exemple, il assure également le rôle de routeur entre les différentes zones de notre intranet. Il assure donc également le filtrage des communications internes. --- ## La zone "Services Intranet" Les services "Intranet" sont des services dédiés à l'usage **interne** de l'entreprise. Ce sont souvent des applications "métier", des applications Web de travail collaboratif, des serveurs de fichiers... Ces services ne sont normalement accessibles que depuis le réseau interne de l'entreprise (notamment les réseaux type "stations de travail"). --- ## La zone "Services Extranet" Les services "Extranet" sont des services dédiés à l'usage **externe** de l'entreprise. Ce sont souvent des sites ou des applications web dédiées à la relation clients et/ou partenaires. Des applications web telles qu'un "webmail" peuvent également être positionnées dans cette zone. Ces services sont normalement accessibles depuis Internet, très souvent derrière un "mur" d'authentification spécifique ou de type "Single Sign On" (SSO). --- ## Les zones "Stations de travail" Les stations de travail devraient **être réparties** dans leur propre zone, et si possible **dans des zones dédiées aux différents "corps de métiers"** de l'entreprise. Ainsi, le service "Comptabilité" ne devrait pas être sur le même réseau que le service "Développement". Les **règles de communication internes/externes** devraient également être **spécialisées** en fonction des contraintes/besoins des différents corps de métiers. **Exemple** Les connexions SSH vers l'extérieur ne devraient pas être possibles depuis la zone "Comptabilité" mais certainement autorisées/nécessaires depuis le réseau "Développement". --- ## Règles générales de communication inter-zones Chaque zone devrait être **notée suivant le risque d'intrusion** et **le potentiel d'impact d'une intrusion**. Une zone avec un risque d'intrusion de **niveau N ne devrait pas pouvoir initier de communication vers une zone de niveau N-1**. ![center 50%](img/communicationrules.png) L'application de cette règle générale n'est pas toujours possible et il faut parfois l'adapter aux contraintes de fonctionnement de l'entreprise. --- ## D'autres zones, d'autres usages - Imprimantes - Terminaux mobiles (BYOD) - Internet des objets - Invités - etc --- ## Sécurité et configuration d'un serveur GNU/Linux ### Installation du serveur ### Politique d'accès et configuration SSH ### Règles de pare-feu --- ## Installation du serveur 1. Télécharger l'image ISO Ubuntu Server 16.04.* 2. Créer une nouvelle machine dans VirtualBox 3. Configurer le réseau de la nouvelle machine pour utiliser une interface de type "bridge" et autoriser toutes les connexions 4. Démarrer la machine et sélectionner l'image ISO --- ## Règles générales de partitionnement (1) - Utiliser [LVM](https://wiki.ubuntu.com/Lvm) - ~300/500M pour `/boot` - Partition séparée pour `/var` ( via un volume logique) - Partition séparée pour `/home` (via un volume logique) - Partition séparée pour `/` (via un volume logique) - Garder de l'espace pour pouvoir agrandir au besoin une partition LVM --- ### Règles générales de partitionnement (2) **Exemple** Pour 10G de disque |Point de montage|Système de fichier|Taille| |:-|:-|:-| |`/boot`|ext4 (Primaire)|500M |`/`|ext4 (LVM)|4G (~30/40%) |`/home`|ext4 (LVM)|1G (10%)| |`/var`|ext4 (LVM)|3G (~30/40%)| |`swap`|swap (LVM)| round(sqrt(RAM) < swap < 2*RAM | Et garder ~10% d'espace libre pour pouvoir agrandir un volume logique au besoin. --- ## Activation des mises à jour automatiques Si à l'installation l'option n'est pas proposée (sur Debian et dérivées) ```bash apt-get install unattended-upgrades apt-listchanges ``` [Voir la documentation Debian pour plus d'informations](https://wiki.debian.org/UnattendedUpgrades) --- ## Politique d'accès et configuration SSH --- ## Installation du serveur OpenSSH ```bash apt install openssh-server ``` --- ## Désactivation de l'authentification SSH avec l'utilisateur `root` ```bash vim /etc/ssh/sshd_config # ... # PermitRootLogin no # ... systemctl restart ssh ``` --- ## Désactivation de la connexion SSH avec un mot de passe ```bash vim /etc/ssh/sshd_config # ... # PasswordAuthentication no # ... systemctl restart ssh ``` --- ## Restreindre les utilisateurs et/ou groupes autorisés à se connecter en SSH ```bash vim /etc/ssh/sshd_config # ... # AllowUsers jdoe bob # AllowGroups jdoe bob # ... systemctl restart ssh ``` --- ## Augmenter la taille des clés SSH du serveur ```bash vim /etc/ssh/sshd_config # ... # ServerKeyBits 2048 # ... rm /etc/ssh/ssh_host_* ssh-keygen -A # On régénère les clés SSH du serveur systemctl restart ssh ``` --- ## Créer des comptes utilisateurs avec un mot de passe expiré (1) ```bash adduser chage -d 0 ``` Puis penser à copier la clé SSH publique de l'utilisateur dans `/home//.ssh/authorized_keys`. --- ## Créer des comptes utilisateurs avec un mot de passe expiré (2) Attention, OpenSSH est très "chatouilleux" avec les droits sur les répertoires `.ssh` et le fichier `.ssh/authorized_keys`. En cas de doute: ```bash chmod go-w /.ssh chmod 600 /.ssh/authorized_keys chown $HOME/.ssh/authorized_keys ``` --- ## Exercice ### Objectif Créer un compte utilisateur accessible en SSH pour un de vos collègues. L'authentification par mot de passe doit être désactivée (uniquement clé SSH) et le mot de passe du compte doit être expiré. ### Consignes 1. Créer un compte utilisateur 2. Marquer son mot de passe comme étant expiré 3. Déployer la clé SSH publique de votre collègue sur ce compte utilisateur 4. Vérifier que celui ci arrive à se connecter --- ## Règles de pare-feu --- ## Installation d'UFW > Uncomplicated Firewall ```bash apt install ufw # Si il n'est pas déjà installé ``` --- ## Activation du pare-feu ```bash iptables -L # Afficher les règles iptables ufw allow 22/tcp # Pour éviter de perdre la connexion SSH actuelle ufw enable # Activer le pare-feu iptables -L # Vérifier l'application des règles ``` --- ## Vérifier le statut des règles ```bash ufw status verbose ``` --- ## Gestion des règles par défaut ```bash ufw default deny # Refuser tous les paquets par défaut ufw default allow # Accepter tous les paquets par défaut ufw default allow outgoing # Accepter les connexions sortantes par défaut ufw default allow ingoing # Accepter les connexions entrantes par défaut ``` --- ## Ajouter des règles ```bash # Connexions entrantes # Autoriser toutes les connexions depuis 192.168.0.4 sur le port 22 ufw allow from 192.168.0.4 to any port 22 # Refuser toutes les connexions depuis 207.46.232.182 ufw deny from 207.46.232.182 # Connexions sortantes # Autoriser les connexions UDP sur le port 53 (requêtes DNS) ufw allow out 53/udp # Autoriser les connexions MySQL (3306/tcp) vers l'adresse 192.168.0.43 ufw allow out to 192.168.0.43 port mysql ``` --- ## Supprimer une règle ```bash ufw status numbered # Afficher les identifiants des règles ufw delete # Supprimer une règle par son identifiant ``` --- ## Exercice Avec UFW, dans l'infrastructure Vagrant, configurer le serveur `extranet-wordpress` pour: - Refuser toutes les connexions entrantes/sortantes par défaut - Autoriser les connexions entrantes sur le port 22 depuis toutes les interfaces (accès SSH) - Autoriser les connexions entrantes sur le port 80 - Autoriser les connexions sortantes sur le port 80/443 Ressouces: - [UFW - Documentation Ubuntu Francophone](https://doc.ubuntu-fr.org/ufw) - [UFW - Documentation Arch Wiki](https://wiki.archlinux.org/index.php/Uncomplicated_Firewall) --- ## Détection des tentatives d'intrusions ## NIDS ## HIDS ## Exemple: fail2ban --- ## NIDS Un NIDS ou **Network Intrusion Detection System** est un système informatique dont l'objectif est de détecter les comportements anormaux, souvent synonymes d'intrusions, **sur un réseau**. Pour ce faire, il analyse les trames transitant sur le réseau et applique des règles de classification permettant de déclencher automatiquement des actions d'alertes ou préventives. --- ## HIDS Un HIDS ou **Host Intrusion Detection System** est un système informatique dont l'objectif est de détecter les comportements anormaux, souvent synonymes d'intrusions, **sur une machine**. Les HIDS peuvent utiliser des sources d'informations très variables en fonction de leur spécialisation: droits sur le système de fichiers, cycle de vie des processus s'exécutant sur le système, règles de pare-feu, fichiers de journalisation... --- ## Exemple: fail2ban Le projet [fail2ban](https://github.com/fail2ban/fail2ban) est un HIDS simple à mettre en place qui se base sur les fichiers de journalisation d'un serveur. Il utilise des expressions régulières en temps réels sur les fichiers de journalisation pour détecter les tentatives d'intrusion et extraire les informations nécessaires à la mise en place d'actions préventives, par exemple bloquer l'adresse IP de l'attaquant pendant un certain temps. **Exemples d'actions détectées** Échecs multiples d'authentification SSH, tentatives d'injections SQL sur une application Web, etc... --- ## Installation de fail2ban ```bash apt install fail2ban ``` --- ## Configuration ### Principaux fichiers et répertoires - `/etc/fail2ban/fail2ban.conf` - Fichier de configuration général - `/etc/fail2ban/jail.conf` - Définition des "jails" par défaut - `/etc/fail2ban/jail.d` - Définitions de "jails" additionnelles - `/etc/fail2ban/filter.d` - Filtres d'activation des "jails" - `/etc/fail2ban/action.d` - Définition des actions potentielles à exécuter en cas d'activation d'une "jail". _La personnalisation de la configuration se fait en créant des fichiers `.local`._ --- ## Exercice Configurer fail2ban pour bannir les IP à l'origine de tentatives de connexion échouées sur un site Wordpress. 1. Créer un filtre pour détecter les tentatives échouées de connexion à votre Wordpress. Quelle est la différence dans les logs entre un échec et un succès ? 3. Créer votre filtre `/etc/fail2ban/filter.d/wordpress.conf` avec votre expression régulière. Pour tester: ``` fail2ban-regex --print-all-match \ /etc/fail2ban/filter.d/.conf ``` 4. Créer votre propre section "wordpress" dans le fichier `/etc/fail2ban/jail.local` en vous inspirant des exemples déjà présents. **Ressources** - [Créer des filtres - Documentation fail2ban](https://fail2ban.readthedocs.io/en/latest/filters.html) --- ## Aller plus loin ### Détection des intrusions réseau - [Snort](https://www.snort.org/) - [Suricata](https://suricata-ids.org/) --- ## Supervision de l'infrastructure ### Les facteurs d'une bonne métrique ### Exemple d'outil: Prometheus --- ## Les facteurs d'une bonne métrique - **Concision** _Le domaine de mesure est il correctement défini ? La métrique n'essaye t-elle pas de mesurer trop de choses ?_ - **Fidélité** _La mesure est elle reproductible ? Mesure t-elle toujours la même chose ?_ - **Intégrité** _Le processus de mesure est il vulnérable à la falsification ?_ - **Utilité** _La métrique apporte elle une information utile au processus décisionnel ?_ --- ## Exemple d'outil: Prometheus ### Téléchargement https://prometheus.io/download/#prometheus --- ## Configuration générale --- ## Instrumentation de l'infrastructure ### Modèle de données ### Les différents types de métriques ### Les requêtes --- ## Modèle de données Prometheus stocke des échantillons (mesures) sous la forme de **séries temporelles**. Il créait une nouvelle série pour chaque association **(nom_métrique, label1=value, label2=value, ...)**. Chaque couple **(label, valeur)** est appelée **dimension** de la métrique. **Représentation** ``` http_total_requests{ method="POST", path="/test" } | name | labels | ``` --- ## Les différents types de métriques --- ## Compteur (1) Un compteur est une métrique dont la valeur ne peut faire qu'augmenter au cours du temps. > **Exemple** Nombre total de connexions d'un compte sur un site --- ## Jauge Une jauge est une métrique dont la valeur peut augmenter ou diminuer au cours du temps. ![center 50%](./img/jauge.jpg) > **Exemple** La température d'une pièce --- ## Histogramme (1) Un histogramme est une métrique répartissant les données dans des "seaux" (ou "buckets" en anglais) configurables et comptant le nombre total et par "paquet" d'échantillons ainsi que leur somme. ![center 70%](./img/histogram.png) > **Exemple** Le temps de réponse des requêtes HTTP --- ## Histogramme (2) ### Scénario d'exemple Soit la métrique `http_request_duration_seconds` un histogramme avec les "buckets" suivants: 0.5, 1, 2, 3, 5. 3 requêtes sont effectuées sur l'application avec des temps de 1s, 2s et 3s respectivements. On aura sur `/metrics`: ``` http_request_duration_seconds_bucket{le="0.5"} 0 http_request_duration_seconds_bucket{le="1"} 1 http_request_duration_seconds_bucket{le="2"} 2 http_request_duration_seconds_bucket{le="3"} 3 http_request_duration_seconds_bucket{le="5"} 3 http_request_duration_seconds_bucket{le="+Inf"} 3 http_request_duration_seconds_sum 6 http_request_duration_seconds_count 3 ``` --- ## Les requêtes --- ## Types de données - `scalar` _Un nombre à virgule flottante_ Exemple: `5.1` - `instant vector` _Un ensemble de séries temporelles contenant un seul échantillon pour chaque série temporelle, toutes partageant le même horodatage._ Exemple: `http_request_duration_seconds` - `range vector` _Un ensemble de séries temporelles contenant une gamme de points de données au fil du temps pour chaque série temporelle._ Exemple: `http_request_duration_seconds[5m]` - `string` _Une chaine de caratères._ Exemple: `"hello world"` --- ## Les opérateurs ### Opérateurs arithmétiques `+`, `-`, `*`, `/`, `%` (modulo), `^` (puissance) ### Opérateurs de comparaison `==`, `!=`, `>`, `>=`, `<`, `<=` ### Opérateurs d'aggrégation `sum`, `min`, `max`, `avg`, `stddev`, `stdvar`, `count`, `count_values`, `bottomk`, `topk`, `quantile` ### Opérateurs logiques `and`, `or`, `unless` _[Voir la documentation du projet](https://prometheus.io/docs/prometheus/latest/querying/operators/)_ --- ## Fonctions ### Quelques exemples - `rate(range vector)` Retourne la fréquence moyenne d'augmentation par seconde de la série temporelle dans l'espace de temps donné. À utiliser uniquement avec les compteurs. - `time()` Retourne le nombre de secondes depuis l'Epoch Unix. - `increase(range vector)` Retourne l'augmentation de la série temporelle dans l'interval de temps donné. À utiliser uniquement avec les compteurs. Et aussi [histogram_quantile()](https://prometheus.io/docs/prometheus/latest/querying/functions/#histogram_quantile), [predict_linear()](https://prometheus.io/docs/prometheus/latest/querying/functions/#predict_linear()),... _[Voir la documentation du projet](https://prometheus.io/docs/prometheus/latest/querying/functions/)_ --- ## Configuration de l'`alertmanager` ### Téléchargement https://prometheus.io/download/#alertmanager --- ## Écriture de règles d'alertes --- ## Exercice ### Objectif Prédire le remplissage d'un disque sur une machine de l'infrastructure. ### Consignes 1. Sur une des machines virtuelles de la zone "Intranet", installer l'exporteur de métriques [`Node Exporter`](https://github.com/prometheus/node_exporter/) et créer un nouveau service [`systemd`](https://doc.ubuntu-fr.org/creer_un_service_avec_systemd) pour celui ci. 2. Mettre en place une règle d'alerte sur votre instance Prometheus afin de prévenir le remplissage du disque de votre serveur via la fonction [`predict_linear()`](https://prometheus.io/docs/prometheus/latest/querying/functions/#predict_linear()) **Ressources** - [Modifier et créer des fichiers Unit pour systemd - Documentation Red Hat](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/sect-managing_services_with_systemd-unit_files) --- ## Aller plus loin ### Prometheus - [Listes des "exporters" disponibles pour Prometheus](https://prometheus.io/docs/instrumenting/exporters/) - [Créer des tableaux de bord avec Grafana et les métriques Prometheus](https://prometheus.io/docs/visualization/grafana/) ### Autres systèmes de supervision - [Monit](https://mmonit.com/monit/) - [Nagios](https://www.nagios.org/) - [Munin](http://munin-monitoring.org/) - [Sensu](https://sensuapp.org/) --- ## Politique de sauvegarde ### Règle générale "3-2-1" ### Exemple d'outil: rsnapshot --- ## La règle générale "3-2-1" - **3 sauvegardes distinctes au minimum** - **2 sauvegardes locales** sur des **supports physiques différents** - **1 sauvegarde distante** dans un centre de données éloigné du secteur géographique de la société --- ## Installation de rsync/rsnapshot ### Sur la machine à sauvegarder ```bash apt install rsync ``` ### Sur la machine de sauvegarde ```bash apt install rsnapshot rsync ``` --- ## Configuration de rsnapshot (1) ### Sur le serveur - Créer un utilisateur dédié à la sauvegarde - S'assurer que le compte de sauvegarde a les droits de lecture sur les répertoires à sauvegarder - Déployer une clé SSH pour le compte de sauvegarde (à utiliser sur le client) --- ## Configuration de rsnapshot (2) ### Sur le client ```bash # Éditer la configuration vim /etc/rsnapshot.conf # Définition de la rotation des sauvegardes # # retain hourly 24 # Une sauvegarde par heure hourly.0 -> hourly.23 # retain daily 7 # Si le rép. existe, copie hourly.23 vers daily.0 # retain weekly 4 # Si le rép. existe, copie daily.6 vers weekly.0 # retain monthly 12 # Si le rép. existe, copie weekly.3 vers monthly.0 # Vérifier la configuration rsnapshot configtest # Exécuter un "dry-run" rsnapshot -t hourly # Ou daily/weekly/monthly # Configurer les tâches CRON crontab -e # @hourly rsnapshot hourly # @daily rsnapshot daily # @weekly rsnapshot weekly # @monthly rsnapshot monthly ``` --- ## Restaurer une sauvegarde ```bash rsync -av \ /var/cache/rsnapshot/. \ user@server-host:/path/to/dest ``` --- ## Exercice ### Objectif Mettre en place la sauvegarde du poste `workstation-developer-linux` via le serveur `intranet-backup` ### Consignes 1. Créer un utilisateur dédié à la sauvegarde sur la machine `workstation-developer-linux` 2. Créer une clé SSH sur la machine `intranet-backup` et la déployer sur la machine `workstation-developer-linux` 3. Configurer `rsnapshot` sur la machine `intranet-backup` pour qu'il sauvegarde le répertoire `/home/developer` --- ## Aller plus loin - [Bareos - Système de sauvegarde avancé](https://www.bareos.org/en/) - [duplicity - Sauvegardes chiffrées via rsync](http://duplicity.nongnu.org/) --- ## Confidentialité des communications ### Éléments de base de cryptographie asymétrique ### Utilisation de GnuPG --- ## Utilisation de GnuPG ### Cryptographie à clé publique/privée ### GPG ### SSL/TLS --- ## Cryptographie à clé publique/privée (1) ### Chiffrer un message ![center](./img/publickeycryptoencryption.png) --- ## Cryptographie à clé publique/privée (2) ### Signer un message ![center](./img/publickeycryptosigning.png) --- ## GPG > GNU Privacy Gard - https://gnupg.org/ --- ## Créer une paire de clés GPG ```bash gpg2 --full-gen-key ``` --- ## Chiffrer un document ### Chiffrement ```bash gpg2 --armor --encrypt ``` Un fichier `.asc` sera généré. C'est votre fichier chiffré. ### Déchiffrement ```bash gpg2 --output \ --decrypt .asc ``` --- ## Signer un document ### Signature ```bash gpg2 --detach-sign ``` Un fichier ``.sig sera généré. C'est la signature de votre document. ### Vérification ```bash gpg2 --verify .sig ``` Le fichier original doit être dans le même répertoire et porter le nom `` pour que vous puissiez vérifier une signature. --- ## Lister les clés du trousseau local ```bash gpg2 --keyid-format long --list-keys ``` --- ## Publier une clé GPG publique sur un serveur de clés ```bash gpg2 --keyserver \ --send-key ``` Exemple de serveur de clés: [hkp://p80.pool.sks-keyservers.net:80](https://sks-keyservers.net/overview-of-pools.php) --- ## Chercher une clé GPG publique sur un serveur de clés ```bash gpg2 --keyserver \ --search-keys ``` --- ## Mettre à jour les clés de son trousseau local ```bash gpg2 --keyserver \ --refresh-keys ``` --- ## Révoquer une clé GPG ### Créer le certificat de révocation ```bash gpg2 --output \ --gen-revoke ``` Ce certificat est à sauvegarder de manière sécurisée. ### Utiliser un certificat de révocation ```bash # Importer le certificat gpg2 --import # Diffuser la révocation de votre clé gpg2 --keyserver \ --send-keys ``` Les utilisateurs de GPG verront alors votre clé comme révoquée. --- ## Exercice ### Objectif Créer votre propre paire de clés GPG et envoyer un courriel chiffré et signé. ### Consignes 1. Générer votre propre clé GPG pour votre adresse courriel. 2. Faire signer votre clé par au moins 1 de vos collègues dans la salle 3. Configurer votre client courriel pour qu'il utilise votre clé GPG . Exemple: [Thunderbird - Plugin Enigmail](https://www.enigmail.net/index.php/en/) 4. Rechercher et récupérer la clé associée à l'adresse wpetit@cadoles.com 5. Envoyer un courriel chiffré et signé par votre clé à wpetit@cadoles.com --- ## SSL/TLS --- ## Générer un certificat autosigné ```bash openssl req \ -x509 \ -newkey rsa:4096 \ -keyout key.pem \ -out cert.pem \ -days 365 \ -nodes ``` --- ## Utilisation du certificat avec Apache2 ```apache # /etc/apache2/sites-enabled/my-site.conf NameVirtualHost *:80 ServerName www.example.com Redirect / https://secure.example.com/ ServerName secure.example.com DocumentRoot /var/www/html SSLEngine On SSLCertificateFile /path/to/cert.pem SSLCertificateKeyFile /path/to/key.pem # etc... ``` --- ## Tester la configuration TLS/SSL Avec le projet [TestSSL](https://testssl.sh/) ```bash # Récupération du script wget -O- https://testssl.sh/ > testssl.sh # Rendre exécutable le script chmod +x ./testssl.sh # Tester une URL ./testssl.sh ``` --- ## Exercice ### Objectif Configurer l'application Wordpress pour qu'elle soient utilisable en HTTPS ### Consignes 1. Générer un certificat autosigné 2. Configurer le service Apache2 sur la machine `extranet-wordpress` afin qu'elle écoute sur le port 443 (HTTPS) et que le serveur utilise votre certificat 3. Mettre en place une redirection pour que les utilisateurs soient redirigés automatiquement vers l'adresse en HTTPS --- # Licence ## CC BY-NC-SA 3.0 FR [Creative Commons - Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 3.0 France](https://creativecommons.org/licenses/by-nc-sa/3.0/fr/)