Architecture d’intégration pour le partage sécurisé de fichiers en entreprise : flux de données, DLP et chiffrement sur M365, iManage, Salesforce et MFT

Le partage de fichiers en entreprise ne se fait jamais en vase clos. Dès qu’une organisation connecte une plateforme de partage sécurisé de fichiers à Microsoft 365, à un système de gestion documentaire, à un CRM ou à un canal de transfert sécurisé de fichiers, la question de la sécurité change de dimension. Il ne s’agit plus seulement des contrôles appliqués par la plateforme principale, mais de savoir si ces contrôles suivent les données lorsqu’elles franchissent les frontières d’intégration.

C’est là tout l’enjeu de l’architecture d’intégration. Et c’est un aspect que les processus d’achat sous-estiment souvent. Les listes de fonctions des fournisseurs énumèrent les intégrations prises en charge. Mais elles répondent rarement — clairement, publiquement, de façon vérifiable — à la question de savoir si les mêmes règles DLP, les mêmes contrôles d’accès, les mêmes événements d’audit et la même posture de chiffrement s’appliquent systématiquement aux données qui transitent par un connecteur tiers, ou uniquement à celles qui circulent via les fonctions natives de la plateforme.

Cet article s’adresse aux architectes d’intégration et aux architectes sécurité qui évaluent des plateformes de partage sécurisé de fichiers en entreprise. Il cartographie les flux de données selon chaque modèle d’intégration — Microsoft 365, iManage, Salesforce et SFTP/MFT — et identifie les contrôles de sécurité qui doivent s’appliquer à tous ces flux. Il met également en lumière la question qui nécessite aujourd’hui un échange direct avec Kiteworks plutôt qu’une simple consultation documentaire : la propriété des clés de chiffrement côté client pour les données qui transitent par des connecteurs tiers.

Résumé Exécutif

Idée principale : La sécurité des intégrations ne se limite pas à la prise en charge d’un connecteur donné — elle repose sur la capacité du moteur de règles de la plateforme à gouverner les données, quel que soit le connecteur à l’origine de l’opération. La classification DLP, l’application des contrôles d’accès, la journalisation des audits et la posture de chiffrement doivent s’appliquer avec la même rigueur à un fichier déplacé via un connecteur SharePoint, une synchronisation iManage, une pièce jointe Salesforce ou un transfert SFTP. Les failles aux frontières d’intégration sont précisément là où la souveraineté des données s’effondre dans la pratique.

Pourquoi c’est important : NIS 2, DORA et ISO 27001 exigent tous que les contrôles de sécurité couvrent l’ensemble de la chaîne de traitement des données, y compris les intégrations tierces. Si votre fournisseur ne peut pas vous fournir une fiche de flux de données par modèle d’intégration — ou si cette fiche n’aborde pas la question de la propriété des clés de chiffrement via le connecteur — il s’agit d’une lacune documentaire que vos auditeurs finiront par relever.

5 Points Clés à Retenir

1. L’application des règles doit suivre les données sur tous les canaux d’intégration, pas seulement sur la plateforme principale. Les règles DLP, les labels de sensibilité et les politiques d’accès qui ne s’appliquent pas systématiquement lorsque les données transitent par un connecteur M365 ou un canal SFTP créent de véritables failles de sécurité — qui deviennent souvent des constats de non-conformité au pire moment.
2. Chaque modèle d’intégration possède une architecture de flux de données distincte — et des risques spécifiques. Un connecteur SharePoint, une synchronisation iManage, un gestionnaire de pièces jointes Salesforce et un pipeline de transfert sécurisé de fichiers manipulent chacun les données différemment. Comprendre le chemin réel des données — où elles atterrissent, ce qui les transforme, quel système les stocke — est indispensable pour évaluer la posture de sécurité de l’intégration.
3. La couverture d’audit n’a de valeur que si les événements déclenchés par les intégrations apparaissent dans le même journal que les opérations natives. Un journal d’audit de 632 événements qui enregistre les opérations natives mais omet silencieusement celles déclenchées par des connecteurs tiers ne fournit qu’une couverture partielle. Or, une couverture partielle n’est pas une couverture. Vérifiez l’exhaustivité des événements pour chaque canal d’intégration, pas seulement pour la plateforme dans son ensemble.
4. La propriété des clés de chiffrement via les connecteurs tiers exige une réponse directe, pas une simple supposition documentaire. Le chiffrement géré par le client (HYOK) est bien documenté pour les opérations natives Kiteworks. Mais la question de savoir si la même propriété des clés s’applique — techniquement et de façon vérifiable — aux données qui transitent par un connecteur M365 ou une intégration Salesforce n’est pas traitée de façon explicite dans la documentation publique. Posez la question clairement avant de valider une architecture.
5. Les canaux MFT/SFTP ne sont pas des infrastructures obsolètes — ce sont des chemins de données à haut risque qui exigent la même gouvernance que toute autre intégration. Les canaux de transfert sécurisé de fichiers et SFTP déplacent de gros volumes de données structurées, souvent par lots, souvent sans intervention humaine à chaque transfert. Le moteur de règles doit s’appliquer à ces canaux avec la même rigueur qu’aux sessions utilisateurs interactives.

Pourquoi l’Architecture d’Intégration Est une Question de Souveraineté

Une posture de souveraineté défendable suppose que vous puissiez retracer précisément où vont les données lorsqu’elles transitent par une intégration, quel système les détient à chaque étape et quels contrôles de sécurité s’appliquent à chaque point. Cette exigence se retrouve dans l’article 21 de NIS 2, les exigences DORA sur les risques liés aux tiers TIC et les contrôles de sécurité de la supply chain d’ISO 27001.

La plupart des fournisseurs de partage sécurisé de fichiers publient des listes d’intégrations prises en charge. Peu publient une documentation détaillée des flux de données par modèle, indiquant par exemple si les règles DLP sont évaluées avant ou après le passage par le connecteur, si la propriété des clés HYOK s’applique en continu tout au long du pipeline du connecteur, ou si la clé de chiffrement qui protège le fichier au repos reste la même (sous la même propriété client) tout au long du parcours. Ces détails architecturaux sont au cœur d’une revendication de souveraineté. Leur absence n’est pas une simple omission.

Kiteworks documente largement ses capacités d’intégration. Mais il faut reconnaître qu’une documentation consolidée des flux de données par modèle d’intégration, rassemblant ces détails architecturaux dans une fiche unique et publiable, n’existe pas à ce jour dans le domaine public. Les fonctions décrites dans cet article sont issues de la documentation produit accessible publiquement. Les questions critiques qui restent sans réponse publique sont explicitement signalées.

Flux de Données par Modèle : Quatre Architectures d’Intégration

Comprendre la posture de sécurité d’une intégration commence par la compréhension du flux réel des données. Les quatre modèles ci-dessous — Microsoft 365, iManage, Salesforce et SFTP/MFT — présentent chacun une architecture, un profil de risque et des questions spécifiques que les architectes sécurité doivent résoudre avant de les déployer dans des environnements sensibles.

Microsoft 365 : SharePoint, Teams, OneDrive et Outlook

Microsoft 365 constitue le modèle d’intégration dominant pour la plupart des clients entreprises. La surface d’intégration couvre quatre produits distincts — bibliothèques SharePoint, partage de fichiers Teams, synchronisation OneDrive et messagerie Outlook — qui déplacent chacun les données différemment et posent des questions de sécurité spécifiques.

Ce que fait l’intégration

L’intégration M365 de Kiteworks permet aux utilisateurs d’accéder aux données SharePoint, Teams et OneDrive depuis l’interface Kiteworks via la Repositories Gateway — le framework natif de connecteurs tiers de Kiteworks — et d’envoyer et recevoir des fichiers via Outlook sans quitter le client de messagerie natif. Les règles DLP, les labels de classification et les contrôles d’accès de Kiteworks s’appliquent à ces opérations via le moteur de règles de la plateforme, quel que soit le produit M365 à l’origine de l’action.

Pour l’e-mail en particulier, la passerelle de protection des e-mails (EPG) et l’intégration de la passerelle SMTP étendent l’application des règles Kiteworks aux flux de messagerie Outlook — en appliquant l’inspection du contenu, les règles DLP et les contrôles de chiffrement aux pièces jointes sortantes et à la réception de fichiers entrants, et pas seulement aux fichiers déplacés directement via l’interface de partage de fichiers.

La question du flux de données

Lorsqu’un utilisateur accède à un fichier SharePoint via le connecteur Kiteworks, deux questions architecturales sont essentielles. Premièrement : le fichier reste-t-il stocké dans SharePoint (Kiteworks agissant alors comme couche de contrôle d’accès et de règles), ou transite-t-il par l’infrastructure Kiteworks ? Deuxièmement : si le fichier transite par l’infrastructure Kiteworks, la propriété des clés HYOK s’applique-t-elle en continu tout au long de ce chemin ?

La documentation publique établit que Kiteworks applique son moteur de règles — DLP, classification, contrôles d’accès — aux opérations d’intégration M365. Elle précise aussi que le chiffrement Hold Your Own Key (HYOK) est disponible pour les données gérées par Kiteworks. Ce qui n’est pas explicitement documenté publiquement, c’est si la propriété des clés HYOK s’étend aux données qui transitent spécifiquement par le connecteur M365, ou si ce chemin suit d’autres hypothèses de chiffrement.

Questions à poser directement à Kiteworks :

• Pour les données accessibles via le connecteur SharePoint : le fichier transite-t-il par l’infrastructure Kiteworks, et si oui, sous quelle posture de chiffrement ?
• La propriété des clés HYOK s’applique-t-elle aux données traitées via le pipeline du connecteur M365, ou seulement aux données stockées nativement dans Kiteworks ?
• À quel moment du flux de données l’évaluation DLP a-t-elle lieu — avant ou après tout traitement spécifique au connecteur ?

iManage : Intégration de la Gestion Documentaire

iManage est le système de gestion documentaire dominant dans les environnements juridiques et de services professionnels. L’intégration iManage relie les fonctions de partage et de transfert sécurisé de fichiers de Kiteworks aux dossiers et espaces de travail iManage — permettant d’envoyer des données à l’externe via Kiteworks tout en restant gouverné par la structure de dossier et de contrôle d’accès d’iManage.

Ce que fait l’intégration

L’intégration permet aux utilisateurs de partager des documents iManage via les canaux de livraison sécurisés de Kiteworks sans avoir à exporter les fichiers vers un autre emplacement. Les contrôles d’accès de Kiteworks — qui peut recevoir le fichier, selon quelles conditions, avec quelle date d’expiration — s’appliquent au transfert sortant. La traçabilité de l’opération sortante est enregistrée dans le journal d’audit Kiteworks de 632 événements.

Dans les environnements juridiques où la confidentialité des dossiers est impérative et où des cadres réglementaires comme BSI C5 (pertinent pour les cabinets allemands) ou ISO 27001 imposent des exigences d’audit supplémentaires, la capacité à journaliser les transferts de fichiers externes dans une infrastructure d’audit certifiée — plutôt que dans des historiques d’e-mails ad hoc — constitue la principale valeur ajoutée de cette intégration.

La question du flux de données

La question architecturale clé pour l’intégration iManage est de savoir si les données, lorsqu’elles sont extraites d’iManage pour être envoyées à l’externe via Kiteworks, sont stockées temporairement dans Kiteworks ou directement transmises au destinataire. Si elles sont stockées temporairement : sous quelle posture de chiffrement et pour quelle durée ? Si elles sont transmises en flux : quelles garanties s’appliquent aux données en transit ?

Kiteworks documente le chiffrement de bout en bout pour les données en transit à travers les intégrations en général. Le comportement précis du transfert de données d’iManage vers l’externe via Kiteworks reste un point où une documentation spécifique par modèle d’intégration serait plus rassurante que des déclarations générales sur la plateforme. Une vérification directe auprès de l’équipe technique Kiteworks est recommandée pour les organisations soumises à des exigences strictes de confidentialité des dossiers.

Salesforce : Échange de Fichiers Intégré au CRM

L’intégration Salesforce répond à un problème opérationnel courant : les équipes commerciales et les responsables de comptes doivent envoyer et recevoir des documents sensibles — contrats, propositions, documents de due diligence — dans le contexte des dossiers CRM, mais la gestion native des fichiers de Salesforce ne répond pas aux exigences de sécurité imposées aux données sensibles dans les secteurs réglementés.

Ce que fait l’intégration

L’intégration Salesforce de Kiteworks permet aux utilisateurs d’envoyer des fichiers directement depuis les dossiers Salesforce en utilisant l’infrastructure de livraison sécurisée de Kiteworks. Les destinataires reçoivent un lien sécurisé plutôt qu’une pièce jointe. Le fichier est livré via l’environnement contrôlé par les règles de Kiteworks — contrôles DLP, expiration du lien, limites de téléchargement et journalisation des accès s’appliquent. Le dossier Salesforce peut être mis à jour avec le statut de livraison.

Pour les secteurs soumis à des exigences strictes de classification des données — services financiers sous DORA, santé sous les réglementations nationales, juridique sous les règles de déontologie — ce modèle d’intégration est essentiel car il évite que des fichiers sensibles soient envoyés par e-mail en pièce jointe non contrôlée simplement parce que le commercial travaille dans Salesforce au lieu d’une interface dédiée au partage sécurisé de fichiers.

La question du flux de données

La question critique pour l’intégration Salesforce est de savoir si l’évaluation DLP a lieu au moment où le fichier quitte Salesforce pour entrer dans le pipeline de livraison Kiteworks — et si cette évaluation est appliquée de façon cohérente avec les contrôles DLP sur les fichiers téléchargés directement dans Kiteworks. Si le chemin d’exécution diffère pour les transferts issus de Salesforce, il peut exister une faille d’application des règles que des acteurs malveillants (ou des utilisateurs négligents) pourraient exploiter.

La documentation publique indique que le moteur de règles de Kiteworks s’applique à tous les canaux d’intégration. Il est toutefois important de vérifier que les transferts issus de Salesforce passent bien par le même pipeline DLP que les téléchargements natifs — y compris l’inspection du contenu, et pas seulement la classification par métadonnées. Cette vérification doit faire partie de l’évaluation technique.

SFTP, AS2 et Transfert Sécurisé de Fichiers

Les canaux SFTP, AS2 et FTPS sont souvent considérés comme des infrastructures obsolètes. Ce n’est pas le cas. Dans les services financiers, la supply chain, la santé et le secteur public, les canaux de transfert sécurisé de fichiers (MFT) déplacent de gros volumes de données structurées — souvent par lots, souvent automatiquement, souvent sans qu’un humain ne vérifie chaque transfert. Les contrôles de règles appliqués à ces canaux sont aussi importants, voire plus, que ceux appliqués aux sessions utilisateurs interactives.

Ce que fait l’intégration

La fonction MFT de Kiteworks prend en charge les protocoles SFTP, AS2 et FTPS, en plus de son API REST et de son interface web. Les transferts automatisés, le traitement par lots et les scénarios de connectivité partenaires — courants dans l’EDI santé, le règlement financier et l’échange de données gouvernementales — sont gérés via ces canaux. La plateforme prend en charge les transferts planifiés, le routage conditionnel et la traduction de protocoles entre formats standard MFT.

L’architecture diffère ici des intégrations basées sur des connecteurs. Les transferts SFTP et AS2 sont souvent entièrement automatisés, sans session utilisateur interactive. Cela signifie que l’exhaustivité du journal d’audit est particulièrement cruciale pour ces canaux : si un transfert par lots déplace plusieurs milliers de fichiers et qu’un incident survient, la traçabilité doit être aussi complète que pour un transfert initié par un humain.

La question du flux de données

Plusieurs questions concernent spécifiquement les canaux MFT automatisés. Le serveur MFT de Kiteworks intègre la DLP, la protection avancée contre les menaces (ATP), l’antivirus et l’analyse Content Disarm and Reconstruct (CDR) directement dans les workflows de transfert — ce qui signifie que l’inspection DLP s’applique aux transferts MFT automatisés pendant l’exécution du workflow, et non en contrôle post-transfert optionnel. C’est une fonction documentée : la DLP est un nœud intégré au workflow, pas une vérification additionnelle. Pour les environnements à fort volume, il convient de vérifier que la capacité de scan DLP répond aux exigences de volume de transfert de votre déploiement. Les événements d’audit des opérations MFT sont enregistrés dans le même journal unifié de 632 événements que les autres activités de la plateforme.

Pour les organisations exploitant des pipelines MFT automatisés à haut volume, la vérification pratique consiste à s’assurer que le débit de scan DLP répond aux besoins de transfert du déploiement — et à tester un lot pour vérifier que chaque événement fichier est bien journalisé, et pas seulement un résumé au niveau du job.

Contrôles Transverses : Ce Qui Doit S’Appliquer Partout

Chaque modèle d’intégration possède ses propres flux de données. Mais quatre contrôles doivent s’appliquer systématiquement à tous, sous peine de rendre le modèle de sécurité incomplet. Ce sont ces contrôles que les architectes d’intégration doivent vérifier canal par canal — et pas seulement au niveau de la plateforme.

DLP et Classification : Application des Règles sur Tous les Canaux

La prévention des pertes de données n’a aucun sens si elle ne s’applique que lors des interactions avec la plateforme principale. L’objectif de la DLP dans un environnement intégré est que la règle suive la donnée, quelle que soit l’application à l’origine de l’opération. Un fichier téléchargé directement dans Kiteworks et un fichier accédé via un connecteur SharePoint doivent être soumis à la même inspection de contenu, à la même évaluation des labels de classification, et au même blocage/alerte/audit si une règle est déclenchée.

Kiteworks met en œuvre des règles DLP tenant compte des intégrations, conçues pour s’appliquer à tous les canaux. Les labels de sensibilité Microsoft Information Protection (MIP) sont reconnus et appliqués lors de l’évaluation des règles — un fichier déjà classifié par l’infrastructure MIP de M365 ne contourne donc pas les règles DLP de Kiteworks simplement parce qu’il arrive via le connecteur M365. Des labels de classification personnalisés peuvent être appliqués indépendamment des labels MIP si l’organisation dispose de sa propre taxonomie.

Le point à vérifier : l’inspection DLP — pas seulement la vérification des métadonnées ou des labels, mais l’inspection réelle du contenu — s’applique-t-elle aux fichiers arrivant via chaque canal d’intégration ? Pour chacun des quatre modèles ci-dessus, demandez au fournisseur de détailler la séquence d’évaluation DLP dans sa documentation technique ou ses architectures de référence.

Contrôle d’Accès : Application Cohérente Quel que Soit le Point d’Entrée

Un modèle de contrôle d’accès qui gouverne l’accès natif à Kiteworks mais qui peut être contourné via un connecteur SharePoint n’est pas un modèle de contrôle d’accès — c’est un ensemble de paramètres bien intentionnés mais exploitables. Chaque canal d’intégration est un point d’entrée potentiel, et les mêmes règles basées sur les rôles et les attributs doivent s’appliquer partout.

Kiteworks applique les contrôles d’accès au niveau du moteur de règles, ce qui signifie que les contrôles sont évalués quel que soit l’interface ou l’intégration à l’origine de la demande. Les rôles utilisateurs, les attributs de département, les labels de sensibilité et les facteurs contextuels — géolocalisation, conformité du terminal, plages horaires — peuvent tous être pris en compte dans les décisions d’accès pour les opérations déclenchées par une intégration, et pas seulement pour les interactions avec l’interface native.

Pour les intégrations Salesforce et iManage en particulier, où l’identité utilisateur est établie dans un système tiers avant l’appel à l’intégration Kiteworks, vérifiez comment fonctionne la fédération d’identité et si le moteur de règles Kiteworks reçoit bien le contexte d’attributs nécessaire pour prendre des décisions d’accès pleinement informées. Si le contexte d’identité est tronqué lors de la connexion, la politique de contrôle d’accès risque d’être appliquée avec moins d’informations qu’en session native.

Journalisation d’Audit : Couverture Complète des Événements par Canal

Le journal d’audit de 632 événements de Kiteworks est l’un des principaux atouts de gouvernance de la plateforme. Cette valeur repose sur l’exhaustivité — les événements déclenchés par les intégrations doivent apparaître dans le même journal que ceux issus de l’activité native. Si les opérations issues des connecteurs génèrent des événements partiels, ou si les transferts MFT automatisés sont consignés dans un journal séparé et moins détaillé, la traçabilité de la plateforme s’en trouve compromise.

Le périmètre des 632 événements couvre les opérations issues des intégrations. La vérification pratique est simple : pour chaque canal d’intégration, demandez un échantillon de journal d’événements sur un environnement de test et vérifiez que les accès fichiers, déclenchements DLP et authentifications apparaissent avec le même niveau de détail que pour les opérations natives. Pour l’intégration SIEM, vérifiez que les événements issus des connecteurs arrivent dans le même flux syslog et avec la même réactivité.

Chiffrement : Propriété des Clés aux Frontières d’Intégration

C’est le contrôle pour lequel la documentation publique ne tranche pas complètement la question — et où une vérification directe s’impose.

Kiteworks prend en charge le chiffrement Hold Your Own Key (HYOK), donnant aux clients le contrôle des clés qui protègent leurs données au repos sur la plateforme. Pour le stockage natif Kiteworks, c’est une vraie garantie de souveraineté.

La question ouverte est de savoir si cette garantie HYOK s’étend en continu aux données qui transitent par les connecteurs d’intégration. Lorsqu’un fichier est accédé via le connecteur SharePoint M365, traité via le pipeline Salesforce ou livré via le connecteur iManage — la propriété des clés HYOK s’applique-t-elle tout au long du parcours ? C’est une question d’architecture technique à valider avec Kiteworks pour chaque configuration de connecteur.

Il ne s’agit pas d’une faiblesse du produit — mais d’une lacune documentaire. La réponse technique est peut-être que HYOK s’applique partout. Mais tant que cela n’est pas explicitement précisé dans la documentation d’architecture par modèle, ou confirmé directement par les équipes techniques Kiteworks, il faut le considérer comme une question ouverte. Les organisations pour lesquelles HYOK est une exigence impérative — notamment celles soumises aux exigences BSI C5 ou mettant en œuvre des contrôles de souveraineté architecturale — doivent faire de cette question un critère de validation lors de l’évaluation technique.

Checklist de Mise en Œuvre : Vérifier la Sécurité des Intégrations par Canal

Cette checklist s’adresse aux architectes d’intégration en phase d’évaluation technique. Elle détaille quoi vérifier et comment — pas seulement quels sont les contrôles.

Avant de Commencer

• Cartographiez tous les canaux d’intégration concernés. N’évaluez pas seulement ceux que vous prévoyez d’utiliser au lancement — tous les canaux activés, même inutilisés, constituent une surface d’attaque.
• Pour chaque canal, identifiez la classification des données qui y circuleront. Les questions de vérification ci-dessous sont cruciales pour les canaux traitant des données sensibles ou réglementées.
• Obtenez les attestations BSI C5 Type 2, le certificat ISO 27001 et tout rapport SOC 2 Type II pertinent de Kiteworks. Ils attestent d’une vérification tierce des contrôles de sécurité. Ils constituent un socle, mais ne remplacent pas la vérification par intégration.

Vérification DLP par Canal d’Intégration

• Demandez une confirmation écrite que l’inspection DLP (et pas seulement la classification par métadonnées) s’applique aux fichiers arrivant via chaque connecteur : M365, iManage, Salesforce, SFTP/MFT.
• En environnement de test, transférez un fichier censé déclencher une règle DLP via chaque connecteur. Vérifiez que la règle s’applique et que l’événement apparaît dans le journal d’audit avec les attributs attendus.
• Pour les labels de sensibilité MIP : transférez un fichier avec un label appliqué dans M365 via le connecteur SharePoint. Vérifiez que Kiteworks reconnaît et applique le label sans exiger une re-classification manuelle.

Vérification du Journal d’Audit par Canal

• Pour chaque connecteur, effectuez un transfert test et récupérez les entrées du journal d’audit correspondantes. Vérifiez que le type d’événement, l’identité utilisateur, l’identifiant du fichier, l’horodatage et le résultat sont tous présents — pas seulement une mention générique de transfert.
• Vérifiez que les événements issus des connecteurs apparaissent dans le même flux syslog vers votre SIEM, et non dans un canal séparé ou différé.
• Pour les transferts MFT/SFTP automatisés : effectuez un transfert par lots et vérifiez que chaque événement fichier est journalisé, et pas seulement un résumé au niveau du job.

Chiffrement et Propriété des Clés

• Si HYOK est requis : obtenez une documentation technique écrite de Kiteworks précisant si HYOK s’applique aux données traitées via chaque type de connecteur. Ne présumez pas — demandez explicitement.
• Pour chaque connecteur impliquant un transit de données via l’infrastructure Kiteworks : demandez si la propriété des clés HYOK s’applique en continu tout au long du pipeline du connecteur, et obtenez une confirmation écrite pour votre configuration.
• Vérifiez que les procédures de rotation des clés de chiffrement s’appliquent aux données traitées par les intégrations selon les mêmes modalités que pour les données stockées nativement.

Comment Kiteworks Aborde la Sécurité des Intégrations

La plupart des plateformes de partage sécurisé de fichiers considèrent les intégrations comme des extensions de fonctions — des points de connexion supplémentaires pour élargir les usages. Chez Kiteworks, les intégrations sont vues comme des extensions du périmètre d’application des règles : chaque connecteur est un point où le moteur de règles de la plateforme doit s’appliquer, et non une porte dérobée.

Cette intention de conception s’appuie sur une validation indépendante. Kiteworks détient l’attestation BSI C5 Type 2 — le catalogue de sécurité cloud de l’Office fédéral allemand pour la sécurité de l’information, l’un des cadres d’attestation cloud les plus rigoureux de l’UE. L’attestation BSI C5 Type 2 couvre le périmètre défini dans le dossier d’engagement avec l’organisme certificateur — les organisations doivent vérifier l’étendue actuelle pour savoir quels canaux d’intégration sont couverts. La certification ISO 27001 et les rapports SOC 2 Type II apportent une vérification tierce supplémentaire. Cyber Essentials Plus couvre le périmètre réglementaire britannique. La certification IRAP PROTECTED s’applique aux usages gouvernementaux australiens. Le statut FedRAMP High In Process — le niveau d’impact le plus exigeant du cadre d’autorisation fédéral américain — témoigne d’une maturité sécurité qui fait référence même hors des États-Unis.

L’étendue de ce portefeuille de certifications est importante ici car elle apporte une preuve indépendante que les contrôles de sécurité s’appliquent à l’ensemble du périmètre de la plateforme. Mais cela ne remplace pas une documentation détaillée des flux de données par modèle d’intégration. La vraie lacune — que la documentation Kiteworks est la mieux placée pour combler — est l’absence d’une fiche d’architecture consolidée retraçant les flux de données pour chaque modèle d’intégration et abordant explicitement la propriété des clés de chiffrement via chaque connecteur. Cette documentation existe en interne. Sa publication constituerait un progrès majeur pour les acheteurs soucieux de souveraineté.

Les organisations qui évaluent Kiteworks pour des architectures d’intégration sensibles doivent considérer les questions soulevées dans cet article non comme des freins, mais comme des points de vérification technique à traiter dans un processus d’évaluation structuré. Les fonctions sont solides. La documentation de ces fonctions au niveau de chaque modèle d’intégration est le prochain palier de maturité.

Conclusion

L’architecture d’intégration est le terrain où la posture de sécurité se gagne ou se perd dans la réalité — et les organisations qui bâtissent une souveraineté durable sur leurs données sont celles qui vérifient chaque modèle, chaque canal, chaque contrôle, au lieu de se contenter d’assurances globales. À mesure que les cadres réglementaires comme DORA et NIS 2 exigent une architecture de flux de données documentée, l’écart entre les promesses générales et la documentation détaillée par modèle va se réduire — et les plateformes qui anticipent ce mouvement fixeront la norme à suivre.

Foire Aux Questions