Notre plateforme de sécurité repose sur les contrôles que nous avons intégrés à notre service pour protéger les données des clients.
Régulièrement, nous estimons le risque, nous supervisons nos contrôles et nous évaluons les menaces potentielles. Ces informations nous servent à mettre à jour le cadre de nos contrôles, depuis les politiques et les procédures aux protocoles de chiffrement.
Le type de données stocké dans notre système inclut généralement :
La confidentialité et l'intégrité des données client constituent notre mission clé. Nous prenons toutes les mesures commerciales et professionnelles acceptables pour assurer le meilleur niveau possible en matière de confidentialité et d'intégrité, tout comme les clients pourraient l'attendre de nous et d'eux-mêmes.
Nous fournissons un cryptage puissant de toutes les données en transit et au repos. Le cryptage en transit est assuré par le protocole TLS (Transport Layer Security), protocole standard dans le secteur qui prend en charge uniquement les plus puissants algorithmes de cryptage, dont l'algorithme AES (Advanced Encryption Standard) ayant des longueurs de clés allant jusqu'à 256 bits. Le cryptage au repos est, quant à lui, assuré par l'exploitation du chiffrement de stockage AWS, à l'aide d'AWS KMS pour créer et stocker les clés de chiffrement AES 256 bits.
TLS version 1.2 permet l'établissement d'un canal de communication crypté entre le navigateur Web de l'utilisateur final et le service HighBond, ce qui assure la confidentialité et l'intégrité de toutes les transmissions de données de bout en bout.
L'algorithme de cryptage AES est largement reconnu et approuvé par les organisations dans le monde entier comme standard dans le secteur pour des applications gouvernementales, militaires et commerciales.
La plupart des navigateurs prennent en charge le cryptage TLS AES 256 bits. Si votre navigateur ne prend pas en charge le cryptage TLS AES 256 bits, vous ne pourrez pas accéder au service HighBond ni aux composants qui lui sont liés.
Tous les messages électroniques provenant de notre plateforme sont transmis par des canaux cryptés TLS, le cas échéant. Si le serveur de messagerie du destinataire ne prend pas en charge TLS, les messages électroniques sont envoyés par l'intermédiaire de la connexion non chiffrée par défaut.
Processus de cryptage des données entre le serveur Web et le navigateur Web
| Navigateur Web | Prise en charge |
|---|---|
| Android 4.0.4 et versions supérieures |  |
| Chrome / OS X | |
| Firefox 31.3.0 ESR/ Win 7 et versions supérieures | |
| Firefox 37 / OS X et versions supérieures | |
| Internet Explorer 11 / Win 7 | |
| Internet Explorer 11 / Win 8.1 | |
| IE Mobile 10 / Win Phone 8.0 et versions supérieures | |
| Safari OS X 10.6.8 et versions supérieures | |
| Safari iOS 8 et versions supérieures | |
Lorsque des clients choisissent de publier des données dans Résultats comme preuves dans le cadre des tests de contrôle ou pour un examen approfondi dans le cadre de l'atténuation des risques, ACL Analytics et ACL Analytics Exchange incluent tous deux une fonction de hachage pour que les utilisateurs finaux des clients puissent l'appliquer aux champs contenant des données sensibles, comme :
La fonctionnalité de hachage permet aux clients de protéger par le chiffrement des champs contenant des données sensibles ayant été envoyées sur notre service. Les valeurs hachées sont protégées par une fonction de chiffrement à sens unique qui ne peut pas être inversée, ce qui permet d'assurer la confidentialité des données sensibles, qu'elles soient au repos ou en cours de traitement.
Les mots de passe des utilisateurs ne sont jamais stockés. Un algorithme de chiffrement puissant est utilisé pour générer des chaînes irréversibles connues sous le nom de hachages du mot de passe. Même s'ils sont obtenus, les hachages stockés ne présentent aucun intérêt pour un adversaire. L'algorithme utilise une longue valeur aléatoire unique connue sous le nom de valeur salt, qui est différente pour chaque utilisateur et qui assure la protection contre les attaques à partir du pré-calcul des hachages de mot de passe.
L'expiration du mot de passe est une fonctionnalité de sécurité qui limite l'accès non autorisé à notre service.
Si vous utilisez l'expiration du mot de passe, pensez aux points suivants :
Remarque
La durée minimale prise en charge pour l'expiration du mot de passe est de 7 jours. Il n'y a pas de durée maximale.
Notre service inclut un paramètre de sécurité qui détermine si les mots de passe répondent aux critères de complexité demandés. Les exigences en matière de sécurité sont renforcées lorsque vous modifiez ou réinitialisez votre mot de passe dans la Barre de lancement.
Les mots de passe doivent répondre aux exigences en matière de sécurité :
Remarque
Les mots de passe peuvent contenir des caractères spéciaux.
Lors de la connexion à notre plateforme ou lors de la génération d'un jeton à utiliser dans une autre application, vous disposez de cinq essais au maximum pour saisir votre mot de passe.
Après cinq essais, reCAPTCHA s'affiche. reCAPTCHA est un service de protection des sites web contre les tentatives d'hameçonnage et les spams, et ce dernier vous demande d'entrer une série de caractères ou de nombres pour montrer que vous n'êtes pas une machine.
Une session est une période d'activité comprise entre la connexion et la déconnexion d'un utilisateur à une application. Les sessions sont globales pour tous les modules SaaS HighBond, ce qui signifie que vous pouvez utiliser la même session de connexion, que vous soyez dans Stratégie, Projets, Résultats ou Rapports. Votre session expire si vous restez inactif pendant la durée définie par un Admin du compte.
Remarque
L'expiration de la session ne s'applique pas à l'application mobile, ni à ACL Analytics ni à Analytics Exchange.
Lors de la création d'une nouvelle organisation, le délai d'expiration de la session est défini par défaut à 60 minutes. Si des utilisateurs ont accès à plusieurs organisations, leur session expirera conformément à la plus courte période d'expiration de session définie dans toutes les organisations.
Si vous utilisez l'expiration de session, pensez aux points suivants :
La mise sur liste verte d'IP permet à des organisations de configurer une ou plusieurs adresses IP (Internet Protocol) ou une plage d'adresses IP à partir desquelles un utilisateur peut accéder à l'organisation. La mise sur liste verte d'IP peut être utilisée comme facteur supplémentaire en plus des mots de passe dans une authentification multifacteur pour s'assurer que seuls les utilisateurs autorisés accèdent à l'organisation.
La liste verte d'IP impacte uniquement nos applications lorsque celles-ci interagissent avec les données du Cloud, notamment lorsque vous effectuez les actions suivantes :
Si vous utilisez la mise sur liste verte d'IP, prenez en compte les éléments suivants :
Remarque
Pour que les Admins de comptes ne puissent pas se bloquer eux-mêmes l'accès à ACL GRC, ils ne peuvent pas configurer d'adresse IP ne correspondant pas à leur adresse IP actuelle.
Astuce
Pour vous conformer à la liste verte d'IP de votre organisation, vous pouvez vous connecter au VPN (Virtual Private Network) de votre organisation pour accéder à notre service depuis votre ordinateur portable ou votre périphérique mobile.
Les rôles d'utilisateur définissent les types d'autorisations d'un utilisateur pour l'accès aux données Cloud. Les autorisations peuvent inclure des tâches comme la gestion des paramètres, ainsi que l'ajout, l'affichage, la modification ou la suppression de données. Un utilisateur peut avoir plusieurs rôles dans différents modules.
Vous êtes responsable de fournir un accès à tous vos utilisateurs sous licence via un rôle Admin du compte désigné. Ce faisant, vous êtes chargé de déterminer les utilisateurs disposant d'un accès ainsi que de définir les niveaux d'accès requis par l'entreprise et les réglementations de conformité applicables.
Selon la façon dont votre organisation gère l'accès logique, vous pouvez utiliser une méthode centralisée et affecter votre département informatique comme Admin du compte, ce qui lui permet d'administrer les accès généraux des utilisateurs.
Sinon, vous pouvez utiliser une ligne de conduite plus décentralisée où les responsables des centres des achats en assurance respectifs peuvent administrer le contrôle des accès via des rôles d'application utilisateur prescrits conformes aux exigences de sécurité informatique ou aux exigences réglementaires.
Pour obtenir des informations détaillées sur les rôles et les privilèges dans chaque module, consultez les rubriques suivantes :
