Skip to content

Guide de Conformité

Cette page donne un aperçu de la manière dont la solution peut aider les organisations à se conformer à diverses certifications ou normes.

De façon générale, toute l'information contenue dans les fichiers transférés avec la solution est chiffrée selon l'architecture cryptographique de la solution.

ISO 27001

L'offre SaaS S-Filer Portal d'OKIOK est certifiée ISO 27001 et son certificat est disponible sur demande.

Dans le cadre de cette certification, tous les contrôles liés au processus de développement et de déploiement de la solution par OKIOK ont été audités.

SOC 2 Type 2

OKIOK ne dispose pas d'un rapport SOC 2 Type 2 pour son offre SaaS S-Filer Portal, mais en a pour RAC/M Identity et OKIOK MDR. Cependant, tous les processus d'entreprise ainsi que les pratiques de développement et de déploiement sont les mêmes pour toutes les solutions d'OKIOK, donc les contrôles audités dans le cadre de ces rapports sont basés sur des preuves qui s'appliquent également à S-Filer Portal.

Les rapports SOC 2 Type 2 peuvent être mis à disposition des clients à la discrétion d'OKIOK.

PCI-DSS

La solution est une solution générique de transfert de fichiers. En tant que telle, elle ne conserve pas directement les données des titulaires de carte. Cependant, il est possible d'utiliser la solution pour échanger des fichiers contenant des données de titulaires de carte. La solution peut appliquer des politiques pour chiffrer tous les fichiers en utilisant des clés AES256 et des clés RSA de longueur suffisante (2048, 4096 ou plus) pour se conformer aux exigences PCI-DSS. De plus, la solution permet aux clients de configurer l'expiration et la rotation des clés selon des politiques conformes aux exigences PCI-DSS.

Si un client a besoin d'être certifié, voici une liste non exhaustive des exigences auxquelles le client doit se conformer :

  • Algorithmes de chiffrement et longueurs de clé
  • Durées de vie des clés et paramètres de rotation
  • Seul le personnel autorisé a accès à la base de données S-Filer et ils doivent signer des formulaires de gardien de clé

Exigences en matière de protection des données (GDPR, PIPEDA, Loi 25 du Québec, etc.)

Encore une fois, toutes les informations personnellement identifiables (PII) dans le contenu des fichiers sont chiffrées selon les politiques du système. Par défaut, ces politiques dictent que toutes les données sont chiffrées et donc protégées lorsqu'elles résident dans la solution.

Cependant, la solution collecte certaines informations utilisateur à des fins de transfert de fichiers.

  1. Nom de compte : Cela peut être n'importe quel identifiant unique. Les clients peuvent choisir de créer des comptes en utilisant n'importe quelle nomenclature pour les noms de compte. Cependant, lors de l'utilisation de la fonctionnalité "partages" de la solution et de l'invitation d'utilisateurs invités dans des partages, le nom de compte correspond à l'adresse e-mail entrée (voir e-mail ci-dessous).
  2. Nom : Il s'agit généralement du nom de l'utilisateur. Selon les juridictions, règlements et circonstances, cela pourrait être considéré comme des PII. Ce champ est obligatoire mais pourrait contenir n'importe quelle valeur et n'a pas besoin d'être unique. Il est seulement utilisé dans l'interface web pour identifier le compte connecté et personnaliser les notifications par e-mail. Si ce champ pose problème, des initiales pourraient être saisies dans ce champ ou des chaînes statiques telles que "Indisponible pour des raisons de confidentialité".
  3. Adresse e-mail : L'adresse e-mail est utilisée dans la solution pour les notifications par e-mail ou comme mécanisme pour récupérer un mot de passe oublié. L'adresse e-mail est également utilisée comme identifiant de compte pour les comptes invités créés dans les "partages".
  4. Adresse IP : Dans certaines juridictions/règlements, les adresses IP sont considérées comme des PII. S-Filer collecte les adresses IP dans ses audits et journaux à des fins de surveillance de la sécurité pour prévenir les attaques par des acteurs malveillants (ex : force brute, DoS).
  5. Numéro de téléphone : Ce champ est facultatif pour les utilisateurs et est basé sur l'opt-in, donc seuls les utilisateurs qui souhaitent utiliser le SMS comme mécanisme MFA et consentent entrent leur numéro de téléphone dans la solution. Il y a une exception lorsqu'un utilisateur effectue un "envoi rapide" à un utilisateur invité en dehors de la plateforme et souhaite authentifier le transfert en utilisant le SMS et le numéro de téléphone du destinataire. Dans ce cas, la solution exige que l'expéditeur obtienne le consentement du destinataire et enregistre la confirmation de l'expéditeur avant d'autoriser le transfert.

La solution peut afficher un écran de consentement lors de la connexion où les utilisateurs doivent consentir à ce que la solution utilise leurs informations, au minimum leur e-mail et leur adresse IP. Si l'utilisateur ne consent pas, il ne peut pas utiliser la solution et la session est terminée.

Témoins (Cookies)

La solution utilise quelques cookies pour fonctionner correctement. Ils ne contiennent pas de données personnelles identifiables et sont utilisés exclusivement par la solution pour fournir des fonctionnalités.

Voici une liste des différents cookies, de leur contenu et de leur objectif :

  • JSESSIONID : Il s'agit d'une chaîne aléatoire utilisée pour identifier la session utilisateur sur le serveur. C'est ainsi que le serveur web "sait" qui est l'utilisateur une fois qu'il est authentifié.
  • SFILER_COOKIE, SFILER_THEME : Ce sont des cookies de commodité utilisés sur la page de connexion. Ils contiennent la dernière langue utilisée, le domaine d'authentification et le thème que l'utilisateur avait lors de sa dernière utilisation de l'application. Ils sont principalement là pour éviter à l'utilisateur de devoir changer la langue ou le domaine d'authentification à chaque fois qu'il arrive sur la page de connexion.
  • toggleStates : Il s'agit d'un autre cookie de commodité utilisé dans les écrans d'administration. Ces écrans comportent plusieurs sections rétractables et ce cookie se souvient de l'état de chacune afin que la réouverture de la même page ait déjà les sections dépliées ou repliées selon les préférences de l'utilisateur.
  • SFILER_MFA_LONG_LIVED_TOKEN_COOKIE : Lorsqu'un utilisateur sélectionne "Se souvenir de moi sur cet appareil" après avoir effectué une authentification MFA, ce cookie est stocké sur l'appareil pour "se souvenir" du fait que la MFA a déjà été effectuée. Par défaut, ce cookie est stocké pendant 168 heures (1 semaine).
  • OpenIdConnect : Ce cookie est uniquement utilisé lors d'une authentification OpenID Connect. Lors de l'envoi de l'utilisateur vers le fournisseur d'authentification OpenID Connect (par exemple, Google, Microsoft, Salesforce, etc.), ce cookie contient un état et quelques informations nécessaires pour valider la réponse et la traiter correctement.