Vue d'ensemble de la sécurité de Reacts

1. CONNEXION CHIFFRÉE
2. CHIFFREMENT DES ÉCHANGES PAR VIDÉO, AUDIO ET TEXTE
3. AUTHENTIFICATION À DEUX FACTEURS ET MOT DE PASSE ROBUSTE
4. SÉCURITÉ DES DONNÉES AU REPOS
5. CHIFFREMENT DU STOCKAGE LOCAL
6. REDONDANCE
7. SAUVEGARDES DE DONNÉES
8. JOURNAUX D’AUDIT
9. AUDITS INDÉPENDANTS
10. CARTE DE FLUX DE DONNÉES
11. AUTHENTIFICATION UNIQUE (SSO)
12. HÉBERGEMENT

1. Connexion chiffrée

Conditions de chiffrement

Tous les points d’accès externes aux API et aux services Reacts nécessitent des connexions sécurisées à l’aide de TLS (Transport Layer Security).

Tous les points d’accès internes entre les services Reacts nécessitent des connexions sécurisées
utilisant des méthodes de chiffrement conformes aux normes de l’industrie.

Ports et protocoles
Site Web / Service  Port  Protocole
www.iitreacts.com 443 TLS 1.2
svc.iitreacts.com 443 TLS 1.2
signaling.iitreacts.com 443 TLS 1.2
proxy.iitreacts.com 443 TLS 1.2
streaming2.iitreacts.com 443 DTLS-SRTP
relay.iitreacts.com 443 DTLS-SRTP
Codes de chiffrement et protocoles refusés

Protocoles explicitement bloqués : SSL 2, SSL 3, TLS 1.0, TLS 1.1

Codes de chiffrement explicitement bloqués : 3DES, RC2, RC4 et DES56

2. Chiffrement des échanges par vidéo, audio et texte

Les communications audio-vidéo sont établies via WebRTC et utilisent le contexte de sécurité DTLSSRTP pour chiffrer et déchiffrer leurs flux de bout en bout.

Les canaux de signalisation sont complètement séparés de ceux du transport des flux audios vidéos et sont sécurisés par TLS. Les empreintes des certificats sont envoyées via cette connexion sécurisée, réduisant ainsi le risque d’attaques de type « MITM » (attaque de l’intermédiaire). Les connexions et les sessions utilisent chacune des clés uniques.

Dans les environnements où les connexions de type pair à pair (« P2P ») ne sont pas possibles en raison de restrictions d’infrastructure et de pare-feu, TII fournit un accès à ses services hébergés TURN. TURN agit à titre de service de relais pour connecter des parties dans des endroits où seules les connexions sortantes sont autorisées. DTLS-SRTP permet de sécuriser de bout en bout les sessions protégées, soit sur UDP ou TCP. Compte tenu que le protocole UDP offre de meilleures performances et demande moins de bande passante, il s’agit de l’alternative privilégiée.

La messagerie texte est toujours transmise via le service de signalisation et est donc sécurisée avec TLS. L’implémentation par TII de WebRTC hiérarchise les connexions de flux audio-vidéo de la manière suivante :

1. P2P UDP;
2. P2P TCP;
3. TURN UDP;
4. TURN TCP.

Conséquemment, si le pare-feu d’une institution autorise le P2P via UPD et/ou le P2P via TCP, la connexion de flux sera établie en P2P. Si le pare-feu d’une institution bloque les connexions P2P, le flux sera établi via TURN UDP ou TCP avec un chiffrement TLS.

3. Authentification à deux facteurs et mot de passe robuste

Reacts permet l’utilisation d’une authentification à deux facteurs. La mise en œuvre actuelle utilise les principes de « Quelque chose que vous connaissez » et « Quelque chose que vous possédez ».

  • Quelque chose que vous connaissez : Nom d’utilisateur et mot de passe. Le mot de passe devrait demeurer confidentiel et être difficile à deviner.
  • Quelque chose que vous possédez : TII a implémenté l’algorithme standard TOTP de « Quelque chose que vous possédez ».

De nombreuses applications gratuites peuvent être utilisées pour calculer un jeton en fonction d’un secret qu’un utilisateur stoke dans son appareil. Le jeton est requis si cet utilisateur configure son compte Reacts pour une authentification à deux facteurs. L’authentification à deux facteurs réduit énormément les chances de succès de nombreux types d’exploitations. Pour ne citer que les types les plus courants, l’ingénierie sociale, la force brute et les attaques par dictionnaire deviennent extrêmement difficiles à réussir lorsque l’authentification à deux facteurs est activée. Dans le cas où une personne malveillante aurait accès à un mot de passe, la « chose que vous savez », il sera très difficile pour cet individu de produire le bon jeton, « la chose que vous possédez ». Dans le cas contraire, si l’utilisateur malveillant accède au dispositif en utilisant « quelque chose que vous possédez », il devra tout de même déterminer le facteur « quelque chose que vous connaissez ».
Lors de son inscription, l’utilisateur doit fournir les informations de sécurité suivantes :

  • Une adresse courriel;
  • Un mot de passe robuste (8 caractères minimum, dont une majuscule, une minuscule et un chiffre);
  • Lorsque l’utilisateur aura choisi l’authentification à deux facteurs, il devra également enregistrer Reacts dans une application capable de générer les jetons TOTP dans son appareil.

Pour pouvoir accéder à Reacts la première fois, l’utilisateur recevra une clé d’activation par courriel lui permettant de valider la propriété du compte de ce courriel.

4. Sécurité des données au repos

  • Les bases de données et ses copies de sauvegarde sont cryptées au repos par « TDE » (Transparent Data Encryption) avec un chiffrement en bloc AES 256.
  • Les serveurs utilisés pour le stockage sont situés dans un sous-réseau non exposé à Internet. Seuls les ordinateurs et services Reacts qui le nécessitent ainsi qu’un groupe restreint d’utilisateurs ont accès à ce réseau.
  • Les fichiers des utilisateurs qui sont stockés sont cryptés à l’aide d’un chiffrement en mode bloc AES 256. Les clés symétriques utilisées pour déchiffrer les données sont stockées séparément dans le serveur de base de données. Ces clés ne sont jamais exposées à des utilisateurs humains et sont uniquement mises à la disposition des services fournissant un accès à ces fichiers conformément aux demandes de leurs propriétaires.
  • Chaque fichier est chiffré à l’aide de sa propre clé et par différents vecteurs d’initialisation (VI) (par exemple, deux fichiers appartenant au même utilisateur sont chiffrés à l’aide de deux clés différentes).
  • L’accès aux informations chiffrées par TII ou ses fournisseurs est strictement interdit par des politiques de sécurité et d’accès ainsi que par des mécanismes de sécurité en place.
  • L’accès aux serveurs de stockage est strictement réglementé par des politiques internes de TII et des contrats de service.

5. Chiffrement du stockage local

La sécurité du dispositif d’un utilisateur incombe principalement au propriétaire de ce dispositif. Cependant, Reacts met tout de même en œuvre des mesures supplémentaires destinées à réduire le risque sur les appareils des utilisateurs.

Sur les appareils Windows
  • Reacts crée un dossier qui hébergera un lecteur virtuel sur lequel les données Reacts de l’utilisateur sont stockées avec du chiffrement.
  • Les données locales de l’utilisateur sont cryptées avec l’algorithme de cryptage Salsa20 utilisant des clés symétriques.
  • Les clés sont stockées dans le coffre Windows de l’utilisateur. 
  • Les données sont cryptées au repos. Une fois que l’utilisateur est connecté à Reacts, les données sont accessibles sur demande.
  • Lorsque Reacts n’est pas en cours d’exécution, les données du lecteur virtuel ne sont accessibles que de façon chiffrée et donc illisibles.
Sur les appareils iOS (Apple)

Reacts compte sur le « sandbox» iOS chiffré pour protéger les données au repos de Reacts contre les autres applications.

Sur les appareils Android

Reacts vérifie que le chiffrement de l’appareil est activé avant de permettre le stockage de données dans l’appareil.

Sur les navigateurs Web

Reacts n’autorise pas la mise en cache des fichiers dans le navigateur, ce qui les empêche de rester au repos. Les cookies de session et d’authentification sont stockés avec un cryptage.

6. Redondance et reprise après sinistre

L’infrastructure de la plateforme Reacts est conçue en gardant à l’esprit la haute disponibilité (HA) et la reprise après sinistre (DR). 

Mesures de haute disponibilité

Toutes les machines virtuelles sont déployées dans des ensembles de disponibilité Azure avec deux instances ou plus. L’isolation des domaines dans des ensembles de disponibilité offrent une disponibilité et une résilience élevées contre les défaillances locales, telles que les pannes de courant et de connectivité. 

Mesures de reprise après sinistre

Les machines virtuelles et autres ressources infonuagiques sont hébergées dans deux régions Microsoft Azure différentes: 

1. Est du Canada – région principale;

2. Centre du Canada – région secondaire.

Les régions Azure principale et secondaire contiennent une copie entièrement fonctionnelle de l’infrastructure de la plateforme Reacts. 

La réplication entre les régions se fait automatiquement et sans qu’aucune intervention humaine ne
soit requise. 

En cas de défaillance régionale, les mécanismes de récupération après sinistre sont gérés par Azure Site Recovery, qui est configuré pour le basculement automatique vers la région Centre du Canada. 

Les comptes de stockage Azure sont aussi configurés avec un stockage géo-redondant dans les régions « Est du Canada » et « Centre du Canada » d’Azure. 

Objectifs de reprise après sinistre

L’objectif de point de récupération (RPO) est fixé à 60 secondes ou moins. 

L’objectif de temps de récupération (RTO) est fixé à 2 heures ou moins. 

Isolement régional

Les régions Azure principale et secondaire sont actuellement physiquement séparées par plus de 700 kilomètres.

7. Sauvegardes de données

Système de sauvegarde de données à 3 niveaux 

1. Sauvegarde en ligne active : 0 perte de données – la base de données principale de TII est activement répliquée sur un serveur secondaire via un cluster de bases de données à haute disponibilité. 

2. Sauvegarde passive en ligne : +/- 1 heure de perte de données potentielle – TII effectue des sauvegardes passives du serveur principal de base de données. Ces sauvegardes ne sont pas automatiquement écrasées, ce qui permet à TII de minimiser les pertes de données en cas de corruption. Les fichiers de sauvegarde de la base de données sont stockés sur un compte de stockage Azure sécurisé et géo-redondant. 

3. Les sauvegardes quotidiennes persistantes sont effectuées sur les disques de toutes les machines virtuelles, ce qui offre une couche de protection supplémentaire. Ils sont stockés dans un coffre-fort Azure Recovery Services conformément aux politiques de rétention de TII. 

Chiffrement de sauvegarde 

Les données cryptées restent cryptées lors de la sauvegarde et sont soumises aux politiques de sécurité et d’accès à distance de TII. 

8. Journaux d'audit

Reacts enregistre les opérations effectuées par les utilisateurs. Ces journaux contiennent les informations suivantes : 

  • Date et heure pour chaque type d’opération;
  • Type d’opération;
  • Succès de la connexion;
  • Échec de la connexion;
  • Demande de session;
  • Session acceptée;
  • Session annulée;
  • Document partagé;
  • Réinitialisation de mot de passe;
  • Changement de mot de passe;
  • Demandeur (identificateur de l’utilisateur);
  • Message (description du type d’opération);
  • ID de salle (identifiant d’une session entre utilisateurs);
  • Champs supplémentaires (d’autres champs facilitant la lecture de l’entrée du journal).

Les données de journalisation sont disponibles sur demande par le propriétaire du compte

9. Audits indépendants

Technologies innovatrices d’imagerie (TII) s’engage à respecter ses politiques de sécurité et de confidentialité ainsi que les plus hauts standards de qualité pour sa solution.

De plus, TII s’engage à faire subir un test d’intrusion annuel à sa solution Reacts par une organisation externe spécialisée (« Hitachi Systems Security »), afin de garantir le maintien de la qualité et de la sécurité de la plateforme Reacts ainsi que du réseau informatique.

10. Carte de flux de données

11. Authentification unique (SSO)

TII utilise la norme OAuth2 et le protocole OpenId Connect pour établir une relation de confiance entre le système d’un partenaire et la plateforme Reacts. 

Cette relation de confiance permet à l’utilisateur de passer du système d’un partenaire à la plateforme Reacts sans avoir à se réauthentifier (authentification unique).

12. Hébergement

Les serveurs de TII sont hébergés dans une instance localisée des services infonuagiques de Microsoft Azure. 

  • L’instance principale réside dans la région d’Azure « Est du Canada ».
  • L’instance secondaire réside dans la région d’Azure « Centre du Canada ».