On trouve souvent dans l’entreprise des applications propriétaires où sont stockées des informations sensibles de différents types. Par exemple, dans le domaine de la médecine, les applications où sont stockées les données des patients, les dossiers médicaux, etc., qui ont la possibilité d’exporter les informations au format Excel ou PDF pour les envoyer, les imprimer, etc. Un autre exemple est celui des gestionnaires de documents, qui ont été personnalisés pour mieux gérer les flux de travail de l’entreprise, et où sont stockées les données financières essentielles, les clients, les fournisseurs, etc.

Pour se conformer à certaines réglementations telles que la GDPR, ou si nous souhaitons simplement avoir un plus grand contrôle sur ces données stockées ou exportées, nous pouvons constater qu’il est nécessaire de modifier ces applications pour ajouter un cryptage, ou plus de contrôles pour gérer les informations en toute sécurité. Ces modifications ne sont pas insignifiantes et peuvent ne pas atteindre le niveau de contrôle que nous souhaitons. D’autre part, il n’est pas non plus possible de changer les applications, les gestionnaires de documents, etc., car il a fallu du temps pour les adapter à notre flux de travail et le coût du changement peut être excessif.

SealPath, est une solution de protection et de contrôle des informations centrée sur les données qui permet de protéger les voyages intégrés à vos documents. Les données sont cryptées et vous pouvez contrôler qui y accède, quand ils y accèdent, si quelqu’un tente d’y accéder sans autorisation, etc., quel que soit l’endroit où se trouvent les fichiers : dans l’entreprise, au domicile d’un employé, sur le réseau d’un fournisseur ou d’un client, etc. La protection est dynamique et nous pouvons la modifier en temps réel pour donner plus ou moins de permissions, ou même, révoquer complètement l’accès au document si vous cessez de travailler avec quelqu’un.

 

Comment SealPath peut-il nous aider si nous voulons ce type de protection sur nos systèmes?

 

Grâce au SDK SealPath, nous pouvons intégrer cette protection permanente des données dans nos applications d’entreprise, de sorte que lorsque des informations sont exportées ou stockées dans certains dossiers d’un gestionnaire de documents, elles sont protégées et se déplacent sous le contrôle de SealPath.

SealPath propose deux types de SDK à intégrer dans nos applications:

  • SDK de protection locale: ce SDK est basé sur C#/.NET et permet la protection des informations dans les applications locales fonctionnant sur un ordinateur ou un serveur Windows.
  • REST API: Dans ce cas, nous pouvons utiliser différents langages de programmation pour invoquer l’API SealPath qui peut être exécutée sur un serveur distant et différent de celui sur lequel tourne l’application que nous voulons intégrer.

 

Comment fonctionnent ces SDK?

 

Protection locale SDK

Le SDK de protection locale est une bibliothèque qui fournit des fonctions permettant de créer et de supprimer des identités, d’obtenir les politiques de protection d’un utilisateur et de protéger et de déprotéger des fichiers avec ces politiques de protection.

Le SDK de protection doit être installé sur le même ordinateur de bureau SealPath ou serveur de fichiers SealPath. La bibliothèque de fonctions SDK appelle le service SealPath Resident sur la machine, qui effectuera les actions.

Le fichier est protégé localement et n’a pas besoin d’être envoyé ou de voyager vers un troisième serveur.

 

sealpath sdk local

 

Les politiques utilisateur sont gérées avec SealPath Desktop ou avec l’interface de gestion Web sur la machine où le SDK est exécuté ou sur toute autre machine. Le SDK obtient uniquement la liste des politiques que l’utilisateur peut appliquer, il n’effectue aucune gestion supplémentaire avec celles-ci.

Les identités des utilisateurs doivent être enregistrées dans l’interface d’administration web de l’organisation. L’enregistrement se fait en important les identités à partir de l’Active Directory de l’entreprise ou en enregistrant les utilisateurs dans la base de données du système.

 

REST API

L’API du SDK REST est basée sur une architecture client-serveur qui communique par le biais de requêtes et de réponses HTTPS. Il donne accès à différentes opérations liées à la création et à la suppression d’identités d’utilisateurs, à l’obtention de politiques de protection et à la protection et la déprotection de fichiers à l’aide de ces politiques.

La grande différence avec le SDK de protection locale est que, dans ce cas, le fichier doit se rendre sur le serveur REST pour être protégé.

 

Rest api sdk sealpath

 

Le client REST API SDK peut être développé dans n’importe quel langage de programmation. Une fois que le serveur interprète une requête, il crée une réponse HTTPS avec des données JSON situées à l’intérieur du corps ou dans les en-têtes. Les commandes API peuvent être facilement mises en œuvre avec des applications qui envoient des requêtes HTTPS et capturent leurs réponses.

Le serveur de l’API REST doit être installé sur une machine où le moteur ou le service SealPath pour serveur de fichiers est installé. Le serveur de l’API REST communique avec le service SealPath pour les serveurs de fichiers qui effectue les requêtes nécessaires au serveur de protection SealPath.

Les identités des utilisateurs doivent être préenregistrées dans le système SealPath et gérées via la console d’administration Web SealPath. Le service API REST n’effectue aucun enregistrement d’utilisateur dans l’organisation.

L’API REST peut fonctionner au niveau de l’authentification avec le protocole OAuth 2.0, pour sécuriser la communication. Une application cliente doit d’abord obtenir le jeton d’accès qui lui permet d’accéder aux fonctions de l’API REST. Pour obtenir ce jeton d’accès, l’utilisateur doit obtenir et utiliser deux paramètres : le « clientId » et le « clientSecret », afin d’invoquer ultérieurement les fonctions de protection, de non-protection, etc. du service API REST.

 

Cas d’utilisation de la protection par le biais des SDK

 

Supposons que nous disposions d’un dépôt de documentation où sont stockés différents types de fichiers : informations sur les offres, spécifications des produits, soldes, documentation, données personnelles, etc. Cet outil peut être un CMS (Content-Management-System), un ERP, un CRM, etc. Les utilisateurs y accèdent via une interface web, une application de synchronisation de fichiers, etc.

Ce dépôt a ses mécanismes de sécurité, où seuls certains utilisateurs ou groupes d’utilisateurs sont autorisés à accéder aux informations mais une fois que les documents sont téléchargés ou quittent le contexte de sécurité du dépôt, le contrôle sur la documentation est perdu.

Les types d’intégration suivants peuvent être réalisés par le biais des SDK de protection SealPath.

 

1. Protéger la documentation lorsqu’elle est téléchargée vers le dépôt

 

Ce cas est recommandé pour les cas où nous souhaitons stocker les informations cryptées. Il peut s’agir d’exigences de conformité, par exemple. Il en va de même lorsque le mécanisme de téléchargement des informations est contrôlé à un moment donné et qu’il n’y a pas beaucoup de moyens de télécharger les documents dans le système.

Le flux de communication dans ce cas serait le suivant:

  1. L’utilisateur, via son navigateur, télécharge un fichier dans l’application.
  2. Le système intercepte le téléchargement du fichier et passe un appel au SDK local ou au REST de protection SealPath.
  3. Le fichier est protégé à ce moment et est stocké de manière protégée.
  4. Si un utilisateur télécharge ultérieurement, ce fichier restera protégé et sous le contrôle de SealPath.

 

flujo de comunicación sdk sealpath

 

2. Protéger la documentation lorsqu’elle est téléchargée à partir du dépôt d’archives

 

Recommandé lorsque nous souhaitons que les informations ne soient pas protégées dans le dépôt d’archives auquel d’autres outils tels que les visionneuses, les applications qui chargent des données, etc. peuvent accéder. C’est également le cas lorsque l’application génère automatiquement des documents à partir d’une base de données pour les télécharger sur l’ordinateur de l’utilisateur.

Dans ce cas, le flux de protection d’un dossier serait:

  1. L’utilisateur accède à l’application web et décide de télécharger un fichier.
  2. Le système intercepte l’opération de téléchargement et passe un appel au SDK pour protéger le fichier téléchargé. Le fichier stocké dans le serveur reste non protégé.
  3. Le fichier est protégé et poursuit son chemin jusqu’à ce qu’il atteigne l’appareil de l’utilisateur, en restant sous le contrôle de SealPath.

 

flujo de proteccion descarga del repositorio sealpath

 

3. Protéger la documentation stockée dans le dépôt

 

si nous disposons de différentes manières de télécharger l’application, par exemple via une interface web, des synchroniseurs locaux ou d’autres applications, il peut être compliqué de protéger le téléchargement ou le chargement car il existe différentes options. Dans ce cas, la chose la plus recommandable peut être de sécuriser la documentation directement dans le dépôt lorsque nous détectons de nouveaux fichiers stockés.

L’intégration fonctionnerait comme suit:

  1. L’utilisateur enregistre les documents dans l’application en les téléchargeant via une interface web, en les chargeant avec une application de synchronisation, etc.
  2. Ces fichiers sont stockés et un service détecte quand il y a de nouveaux fichiers stockés dans le système, par des événements, un balayage périodique ou d’autres moyens.
  3. Les fichiers nouvellement stockés sont protégés par des appels au SDK. Egalement tous les documents qui se trouvaient dans le dépôt et qui ne sont pas protégés.

 

Pasos de integracion sdk almacenado repositorio

 

Comment la gestion des politiques est-elle effectuée et avec quelles politiques la documentation doit-elle être protégée?

 

Le SDK SealPath offre un haut niveau de granularité lorsqu’il s’agit d’appliquer des politiques de protection:

La protection peut être associée à un dossier particulier ou à une bibliothèque de documents dans le dépôt, de sorte que tout ce qui est sauvegardé, téléchargé ou téléchargé à partir du dossier est protégé par cette politique.

  • La protection peut être associée à des documents individuels, de sorte que, selon l’utilisateur, le groupe auquel il appartient, le contexte de l’utilisateur (par exemple, à partir duquel le téléchargement ou le chargement de la documentation est effectué), une certaine politique de protection peut être appliquée.
  • Comme pour les applications de protection du bureau ou du serveur de SealPath, le SDK de protection peut attribuer aux fichiers les privilèges de Affichage seul, modification, copier-coller, impression, ajout d’utilisateurs ou contrôle total. Vous pouvez fixer des dates d’expiration sur la documentation, la possibilité d’inclure des filigranes, l’accès hors ligne pendant X jours, etc.
  • Les politiques sont généralement définies dans la console de gestion SealPath et appliquées à partir du SDK. Toutefois, il est également possible d’appliquer des politiques « personnalisées » générées à la volée à partir du SDK en fonction des besoins ou du contexte de l’utilisateur, ou de créer et de mettre à jour de nouvelles politiques de protection.

 

Quels types de fonctionnalités le SDK m’offre-t-il?

 

Le SDK de protection locale et l’API REST offrent tous deux des fonctions pour protéger, déprotéger, vérifier si un fichier est protégé, etc. Ce sont les plus importantes:
 

1. Gestion de l’identité

  • Établir l’identité de la protection : Nous indiquons au SDK qui sera l’utilisateur qui effectuera les opérations de protection et de déprotection des fichiers.
  • Changer d’identité : nous pouvons travailler avec plusieurs identités et les changer en fonction des besoins de protection.
  • Supprimer l’identité : débloquer une identité du SDK que nous n’utiliserons plus.

 

2. Les opérations de protection et de non-protection

  • Protéger avec une politique : Sécuriser un fichier avec une politique de protection préétablie.
  • Protéger avec une politique « sur mesure » : Générer une politique sur mesure « à la volée » et protéger le fichier avec elle.
  • Vérifier si un fichier est protégé.
  • Obtenir la politique de protection d’un fichier.
  • Obtenir les autorisations d’un utilisateur pour un fichier protégé.
  • Déprotéger un fichier.

 

3. Gestion de la politique de protection

  • Créer une nouvelle politique de protection.
  • Mettre à jour une politique de protection déjà créée, par exemple pour révoquer l’accès d’un utilisateur à un document protégé.
  • Obtenir une politique de protection basée sur le Guid, le nom, etc.
  • Filtrer les politiques de protection d’un certain utilisateur en fonction de certaines caractéristiques. Selon le filtre, vous pouvez obtenir une ou plusieurs politiques qui répondent aux critères de filtrage.
  • Supprimer la politique de protection.

 

De plus, l’API REST offre des fonctions d’acquisition du jeton OAuth v2.0 pour initialiser l’environnement de manière sécurisée et effectuer le reste des opérations de protection.

Pour les différentes fonctions, il existe également des codes d’erreur qui fournissent des informations sur les raisons pour lesquelles l’opération n’a pas été effectuée ou a échoué.

Enfin, toutes les informations relatives au suivi et à l’audit des accès aux dossiers, sont disponibles dans l’interface d’administration web de SealPath ou peuvent être envoyées via Syslog ou WebApis à un SIEM ou à un autre système qui permet de traiter et de post-traiter les journaux d’audit.

sealpath tracking auditoria accesos a ficheros

 

Conclusions

 
Le SDK de protection locale SealPath et l’API SealPath REST offrent tous deux aux entreprises un moyen facile d’intégrer la sécurité centrée sur les données ou la protection et le contrôle de la documentation dans leurs applications d’entreprise.

Ils peuvent ainsi, sans grand effort, assurer le respect de certaines réglementations où le cryptage des informations est essentiel. Ils peuvent également appliquer une protection permanente à leurs informations sensibles afin que, lorsqu’elles ont quitté le contexte de sécurité des applications ou le référentiel, ils aient toujours leurs données confidentielles sous contrôle.

Que l’application soit locale sur Windows avec .NET, une application web fonctionnant sur un serveur Linux ou tout autre type d’architecture, SealPath propose différentes solutions pour rendre l’intégration simple et adaptée à l’environnement technologique de l’organisation.

 

N’hésitez pas à nous contacter pour toute question ou pour plus d’informations, une équipe d’experts vous aidera avec tout ce dont vous avez besoin.