PII - GDPR, HIPAA, PDPA et autres réglementations

La sécurité est d'une importance capitale pour Zato Source et c'est un produit qui intègre la sécurité. Dans toutes les phases de développement ou de maintenance, à chaque étape, beaucoup d'efforts sont déployés pour s'assurer que Zato soit sécurisé par défaut.

Ce document présente une vue d'ensemble des mécanismes de sécurité qui peuvent être utilisés par les architectes techniques pour concevoir des environnements censés protéger les informations personnellement identifiables (PII) conformément aux réglementations telles que GDPR, HIPAA ou PDPA.

Le contenu est fourni à titre informatif et ne constitue pas un avis juridique. Il est conseillé aux lecteurs de contacter un personnel qualifié pour discuter des exigences en matière de PII dans le cadre de leurs projets.

Sécurité dès la conception

  • La sécurité fait partie intégrante du produit, ce n'est pas une réflexion après coup ; au contraire, chaque partie de l'architecture tient compte d'une sécurité forte dès sa conception, en passant par son développement et jusqu'à sa maintenance permanente.

Autorisations d'accès

  • Les services définis par l'utilisateur peuvent être sécurisés à l'aide d'une série de mécanismes, notamment les API keys, AWS, Basic Auth, JWT, NTLM, OAuth, SSL/TLS, Vault, WS-Security, et XPath
  • Les autorisations d'accès aux services peuvent être regroupées en hiérarchies de contrôle d'accès basées sur les rôles (RBAC).
  • Il n'y a pas d'informations d'identification par défaut - tous les secrets sont toujours générés dynamiquement et définis comme très forts (uuid4 ou plus fort).

Données en transit

  • Les données en transit peuvent être cryptées à l'aide du protocole TLS, y compris la possibilité d'exiger des certificats de clients et le blocage des certificats.

Données au repos

  • Tous les secrets (par exemple, les mots de passe de connexion) sont conservés sous une forme cryptée.
  • Les clés nécessaires au décryptage des secrets peuvent être lues à partir d'un stockage sûr tel que Amazon CloudHSM.
  • Les IIP arbitraires peuvent être stockées de manière transparente sous forme cryptée dans des bases de données et décryptées à la volée sans nécessiter de programmation de la part de l'utilisateur.

SSO et gestion des utilisateurs

  • Livré avec une API intégrée pour créer des environnements d'authentification unique.
  • Comprend des appels et des flux de travail pour la gestion des utilisateurs.
  • Les utilisateurs peuvent être décrits par des attributs arbitraires, chacun pouvant être crypté et décrypté de manière transparente si nécessaire.
  • Tout accès aux IIP est toujours reflété dans un log d'audit, y compris les informations sur l'auteur d'une opération donnée.

Cryptographie forte

Traitement des journaux

  • Les journaux peuvent être stockés dans des fichiers ou des installations de traitement à distance (par exemple NewRelic ou Sentry)
  • Masquage des données - pour minimiser le risque que des attaquants accèdent à des informations nominatives, les parties secrètes des paramètres de connexion ne sont pas stockées dans les fichiers logs (par exemple, à la place des mots de passe, un caractère générique **** est stocké).

Clustering

  • Pour assurer la continuité des activités, les serveurs Zato font toujours partie d'un cluster et il n'y a pas de limite au nombre de serveurs qu'un cluster peut contenir.

Test d'API

  • Livré avec des outils intégrés pour exporter les définitions d'API vers OpenAPI, ce qui permet des évaluations périodiques des mesures de sécurité de l'API