[AMA] Sécurité chez Finary, posez-moi vos questions!

Discussions sur Finary 🔥
41

Pas de souci, je ne considère pas la réponse tardive: ces sont des sujet complexes, c’est normal.

Dans notre schéma donc, Google Cloud Platform (GCP) héberge nos données dans l’UE, ici nous n’avons alors pas de besoin de Claudes Contractuelles Types « CCT »

C’est une opinion; mais il me semble que les jugements disent le contraire: héberger les données en Europe n’est pas condition suffisante: faut avoir la garantie et s’assurer qu’elles y restent. Sous le FISA 702, les US peuvent sans aucun souci accéder aux données de Google LLC peu importe ou elles sont stockées. Et même les CCT (SCC en anglais) ne suffisent pas:

C’est pas moi qui le dit, mais la court de Justice Européenne :slight_smile:

Le lien indiqué de la CNIL mentionne:

Concernant les États-Unis, la Cour a estimé que le droit américain en matière d’accès aux données par les services de renseignement (en particulier la section 702 du FISA et l’Executive Order 12333) ne permet pas d’assurer un niveau de protection essentiellement équivalent (voir en particulier le considérant 145 de l’arrêt de la Cour, la clause 4(g) de la décision 2010/87/UE de la Commission, la clause 5(a) de la décision 2001/497/CE de la Commission et l’annexe II (c) de la décision 2004/915/CE de la Commission).

Google LLC étant assujettie au FISA 702, le lien est vite fait (plein de jugements sont déjà tombés). Pour le moment les autorités se sont concentrées sur google analytics car l’impact est beaucoup plus large, mais le principe « me semble » être le même:

par rapport au 28.1:

Lorsqu’un traitement doit être effectué pour le compte d’un responsable du traitement, celui-ci fait uniquement appel à des sous-traitants qui présentent des garanties suffisantes quant à la mise en œuvre de mesures techniques et organisationnelles appropriées de manière à ce que le traitement réponde aux exigences du présent règlement et garantisse la protection des droits de la personne concernée.

Donc votre responsable estime que google LLC présente des garanties suffisantes? Je peux lister les infractions pour lesquelles eux (et ceux qui les ont utilisés comme sous-traitants) ont été jugés coupables par différents Pays si ce qu’y a écrit la CNIL ne suffit pas :slight_smile:

Tout cela dit, personnellement/individuellement on peut tou(te)s interpréter les choses comme on préfère et vous pouvez bien vous dire « si tous les autres font ainsi, ça ne doit pas être grave » sauf après 4-5 se retrouver avec des amendes à 6-7-8 chiffres. Après si la stratégie est « peu-importe, on aura tout vendu et ça ne sera pas à nous de payer » cela me semble une stratégie bien plus solide que dire « on est bon comme ça parce que on y croit » :smiley:

42

Si on veut se dédouaner du Cloud Act pour éviter que les datas puissent être accessibles par les US … A ce jour il faudrait du OnPrem et se passer de toute forme de cloud publique.

Que ce soit GCP / AWS / MS c’est le même bateau.

Et trouver un CDN seulement français … bonne chance (sans parler du frein à la scalibité internationale)

PS : beaucoup de question DPO au final et assez peu sur la sécurité technique au final :slight_smile:

43

OVH fait ça très bien.

2 « J'aime »
44

Hello

Discussions intéressantes.

Pour rendre les choses très concrètes : comment Finary assure-t’il la protection des données financières d’un américain accidentel?

  • Un américain accidentel est une personne qui répond aux critères de nationalité aux US (application du droit du sol en ce qui concerne la nationalité par exemple). Depuis plusieurs années l’administration américaine considère qu’ils doivent déclarer leurs revenus aux US et y payer le cas échéant des impôts (même si ils n’ont quasi-rien à voir avec les US en fait)
  • L’administration américaine utilise les accords de coopération relatifs à la lutte contre la criminalité financière pour récupérer les informations financières de ces personnes (qui ont parfois juste eu le malheur de naitre aux US et y résider quelques jours au début de leur vie) et leur réclamer le paiement des impôts en vertu de la réglementation américaine.
  • Quelques jugements ont rendu le partage d’information illégal dans ce cas (le plus récent en Belgique il me semble). Il s’agit ici d’un conflit de législations comme dans le cadre de l’application du RGPD : il est légal pour l’administration US de demander les données, faire droit à cette demande a été jugé illégal.
  • En l’absence de coopération des établissements financiers, l’administration US pourrait utiliser le FISA pour obtenir les données en marchant sur le droit européen, via les applications d’agrégation de comptes dont notre application favorite :wink:

C’est effectivement une question à la croisée des chemins entre DPO et technique : des moyens techniques pourraient limiter plus ou moins fortement l’exploitation des données dans le cadre d’un FISA. Parce que hélas force est de constater que la loi n’est pas ampliative :slight_smile:

1 « J'aime »
45

mmmmh… peut-être faudrait créer un nouveau sujet car là on parle plus de fiscalité que de sécurité?

je ne vois pas de notion de résidence fiscale: on peut avor 1, 2 ou plusieurs nationalités mais que je sache ce qui importe au niveau des impôts c’est la résidence fiscale/génération de revenue et non pas la nationalité.
Et en fonction de ça il y a les accord bilatéraux ; ex. :

Par rapport à ce qu’on sait grâce a Snowden & co, le gouvernement (US) utilise ces systèmes pas pour aller piocher des données de particuliers (sauf si t’es quelqu’un qui a assez de poids opur influencer les marchés ou la géopolotique étasuniennes :slight_smile: ) mais pour faire de l’intelligence à grande échelle; je me doute qu’ils cherchent les messieurs eemxsa ou AlexIT et surtout qu’ils le fassent en laissant des preuves (comme te demander de payer un impôt) : ça pourrait créer des accidents diplomatiques (quoi que je pense rêver vu le manque de réactions des gouvernements au moments des « relationnions Snowden ») :wink:

Ceci-dit : ce qui est dans finary viens soit de la synchro soit des ajouts manuels; je peux ajouter des millions d’€ manuellement, synchroniser que certain comptes, etc. donc même si un tiers peut voir ces montants, ça ne signifie pas que ça reflète la réalité/je les ai vraiment donc difficile d’exploiter ces info tant que preuves pour réclamer des impôts.

46

Renseignez-vous.

Le gouvernement américain, comme tous les gouvernements du monde, utilisent tous les moyens disponibles dans leur arsenal législatif pour faire appliquer leurs législations (et c’est bien normal). Ne pas payer ses impôts c’est de l’évasion fiscale. Ne pas déclarer ses impôts donne lieu à l’application de pénalités sur l’impôt dû. C’est la norme (et ce n’est pas ça le problème). Le soucis c’est que les US appliquent un impôt sur la nationalité qui est l’exception plutôt que la règle ( Impôt sur la nationalité — Wikipédia ), que les US pratiquent le droit du sol et/ou du sang (généralement c’est le doit du sang un peu partout… ici le simple fait de naitre aux US donne automatiquement la nationalité américaine, de même si l’un de vos parents est américain, quand bien même il ne réside plus aux US ou vous n’avez jamais résidé aux US), et que les US traquent depuis de nombreuses années ces resquilleurs fiscaux qui s’ignorent : les américains accidentels.

Bref le cas est concret. Les données de Finary sont hébergées par des acteurs US. Quelles mesures de protection sont mises en oeuvre pour éviter la concrétisation du scénario ou le sous-traitant de Finary reçois une requête de l’administration US? Finary sera-t’il prévenu? Est-il possible (ou pas) pour l’opérateur de cloud sous-traitant de Finary de délivrer des informations des utilisateurs en toute autonomie? Si ce n’est pas le cas comment Finary répondrait à une requête qui la ciblerait directement?

1 « J'aime »
47

Renseignez-vous.

Ehm… on est plutôt dans un domaine de partage ici: le plus de données vous partagez, le plus de détails vous aurez dans les réponses. Sinon on paye et on demande à un expert de faire le boulot :wink: Perso je ne suis pas citoyen US et donc pas tenu à en connaître les lois mais partant pour apprendre pas mal de choses si on m’en donne l’occasion/moyens.

Pour quelle raison la société A devrait mettre en place des mesures pour éviter que la société B reçoive une requête (de l’admin US)? J’en vois vraiment pas. Ce qu’A est tenue à garantir, si elle gère des données perso de citoyens européens qu’elle transfert à B, sont certaines mesures de sécurité et que le même niveau soit garanti par tous ses prestataires (B).

Finary sera-t’il prévenu?

Pourquoi A devrait-il être informé par B que C lui a envoyé une requête?

Est-il possible (ou pas) pour l’opérateur de cloud sous-traitant de Finary de délivrer des informations des utilisateurs en toute autonomie?

à quel niveau? technique? légale? Pourquoi le demander à Finary et pas à l’opérateur? L’histoire du RGPD prouve que les entreprises se fient entre-elles et ne font pas de vérification; si un papier dit que « oui, on fournit les mêmes garanties que vous en Europe » alors que c’est non, on le saura que quand c’est trop tard: jusqu’à quand quelqu’un les amène en justice et on se rend compte que… « ah, tiens, c’était pas le cas mais eux ils nous avaient dit que oui: on pouvait pas savoir! »

De toute manière l’histoire nous a déjà démontré que techniquement oui et légalement … à voir : on en parle pendant des années de procès (et avocats qui coutent cher) :slight_smile:

Ce qu’on peut demander à Finary est plutôt quelles données sont chez l’opérateur (ou les opérateurs) et comment leur sécurité est garantie. Si tu tiens à le savoir en détail, vaut mieux envoyer une lettre à leur DPO et lui demander sous forme d’exercice des droits RGPD : ils seront tenus à répondre d’une certaine manière tant que dans un forum ils ne le sont pas.

Si ce n’est pas le cas comment Finary répondrait à une requête qui la ciblerait directement?

Le demander en avance peut seulement servir à vérifier leur cohérence si jamais l’occasion se présente car aucune garantie qu’ils fassent ce qu’ils vont dire (s’ils vont le dire); ce que toute société ferait c’est d’évaluer avec des experts (avocats) les risques qu’ils encourent en chaque cas et se comporter en conséquence.

Google est sous FISA 702 : si les données sont stockées chez eux, pas besoin pour le gouvernement US de perdre du temps avec des demandes vu qu’ils ont directement accès aux données. Et si elles sont lisibles par la plateforme Finary hébergée chez GCP, elles le sont, plus ou moins difficilement, aussi pour le gouvernement US.

CloudFlare l’est aussi (ou au moins l’était en 2021 selon la CNIL Portugaise) :

Pas besoin pour les US de déranger Finary s’ils veulent se renseigner sur nos comptes.

48

@AlexIT je pose des questions sur cette partie du forum parce que je m’attend à ce que l’équipe de Finary y réponde. Ce qui m’importe n’est pas votre opinion (quel que soit votre niveau de compétence sur le sujet), mais la position des professionnels qui opèrent cette plateforme. Elle peut être la même ou différente de la votre, j’espère surtout qu’ils auront des réponses plus précise que votre « circulez, il n’y a rien à voir ».

Faites-vous partie de l’équipe Finary? Si oui exprimez-le clairement. Si non j’attend la réponse des personnes en charge, vous avez eu l’occasion de vous exprimer.

Je demande si « des mesures techniques et organisationnelles » sont mises en oeuvre par finary pour bloquer le scénario concret décrit dans mes deux derniers posts. Mesure techniques = en gros cybersécurité. Mesures organisationnelles = en gros compliance. ça tombe bien les deux personnes en charge ont posté sur ce fil.

Vu que le scénario est concret je m’attends à des mesures concrètes (normal).

@Mence ? @Florimon ?

1 « J'aime »
49

Bonjour @eemxsa,

Bienvenue sur la communauté, restons courtois entre chaque utilisateurs et utilisatrices du forum, nous n’en restons pas moins humains.

Je vais écourter la discussion concernant l’extraterritorialité des lois US (notamment ici la bien connu FATCA, et sa « force de frappe » internationale) la France a en effet signé une convention billatérale avec nos amis US dans le cadre d’un partage d’info touchant les « citoyens/résidents US » je vais nous épargner la lecture de cette convention par un extrait assez évocateur de l’Annexe 1 : « La France impose à toute Institution financière déclarante française d’identifier les Comptes déclarables américains et les comptes détenus par des institutions financières non participantes selon les procédures énoncées dans la présente » => Les institutions financières françaises (termes globales j’en conviens, comme les banques, les entreprises d’investissements…) doivent identifier tous « citoyen ou un résident américain » pendant leur entrée en relation, et communiquer les détails de tous personnes tombant dans ce périmètre aux autorités US (l’IRS de mémoire, via les formulaire W8). Autant dire que le % de chance de ne pas être déclaré comme prévu est infime, considérant la collecte d’une pièce d’identité, et les éléments déclaratifs à communiquer à l’entrée en relation.

A la question (si je l’ai bien comprise) « Finary peut elle être amené à communiquer à l’IRS (ou tout autre entités US en ayant le droit) les détails de ses utilisateurs tombant sous le coup de FATCA ? » la réponse est aujourd’hui « non » Finary n’étant pour l’instant pas une institution financière (attention cela peut être amené à changer si Finary offre des services d’investissements, néanmoins ces services ne seraient pas forcément offerts aux citoyens/résidents US, ce qui élimine le besoin déclaratif).
De plus, dans son offre de service actuel, Finary ne collecte pas la nationalité ou le lieu de naissance de ses utilisateurs, ainsi nous ne savons pas si x est français, ou états-uniens (attention voir parenthèse plus haut).

A la question « GCP peut il être amené à communiquer à l’IRS (ou tout autre entités US en ayant le droit) les détails de ses utilisateurs tombant sous le coup de FATCA ? » Je ne suis pas expert en droit US, j’apporte donc une reflexion de fond : il s’agit d’un cadre légal qui vise à prévenir le crime organisé ou encore le terrorisme. La portée est donc plutôt ciblée, et nécessite un mandat (émanant d’un juge US) la supposée « évasion fiscale » fait-elle partie du lot ? Peut-être, je ne peux qu’encourager à se rapprocher d’un ou d’une expert(e) en droit fiscal US pour poser ce genre de question et obtenir une réponse.

En soit, l’IRS se contente (pour l’instant) de vérifier avec les institutions financières la cohérence des reportings, et les contactes elles en cas de doute, au final c’est bien l’institution financière qui fait le KYC, et non pas l’agrégateur bancaire, c’est donc elle qui a accès aux documents d’entrée en relation, et peut vérifier les données indiquées.

A dispo,
Florimon

5 « J'aime »
50

Tout d’abord merci à tous pour votre participation à ce sujet, et à @Florimon pour tes réponses :pray:

Cela fait plusieurs messages que la discussion s’écarte du sujet initial : bien que la compliance et la sécurité soient étroitement liées je vous invite à recentrer vos questions sur cette dernière, cela sera plus facile pour la personne qui cherche des informations sur ce domaine spécifique.

Si certains d’entre vous souhaitent discuter plus en détail de la compliance je vous encourage à créer un nouveau fil de discussion dédié :+1:

2 « J'aime »
51

Merci @Florimon pour ces précisions sur la compliance. Promis je crée un fil dédié si ça me regratte de ce côté là :slight_smile:

Il me reste maintenant quelques questions orienté « sécurité » :

  • Dans le message 5, @Mence parle de tables séparées entre l’identification client et les données financières conservées. Ces tables sont-elles hébergées dans le même SGBD? Par le même prestataire?
  • Y a-t’il une séparation des droits d’accès entre la partie « identités » et la partie « finances » de vos bases de données - quelqu’un qui accède à la partie identité ne peut accéder à la finance et vice-versa ?
  • Dans le post 13, vous parlez de logging sur vos bases de données. Ce logging vous permet-il de récupérer aussi les accès des équipes d’administration de votre prestataire à vos bases de données ? Avez-vous déjà identifié de tels accès?
  • Faites vous de la corrélation de logs (SIEM) ? Le puit de logs (et le SIEM) sont-ils hébergés chez le même prestataire que le reste ?
1 « J'aime »
53

Je répondais avec le mauvais compte, je re-poste avec le bon pour ne pas confondre les lecteurs

Je ne rentrerai volontairement pas dans les détails, mais je n’ai pas parlé de table séparées, j’ai juste parlé d’un id commun

Oui

Si par prestataire vous entendez GCP, access transparency nous permet de consulter les potentiels logs d’accès de leurs employés à notre plateforme

C’est un chantier en cours, et pas le moindre :slight_smile:

1 « J'aime »
54

Top merci Mence

55

Bonjour à tous :slight_smile:

La connexion de nos comptes bancaires se fait via Powens, et donc Finary n’a qu’un accès en readonly.
Mais qu’en est-il des assurances vies en Synchro automatique ? Ou tout autre investissement récupérable via API. L’accès est-il encore uniquement en readonly ? Comment ces connexions sont-elles sécurisées ? Où sont stockées les identifiants de connexion ?

Merci !

56

Bonjour, pour les Api souvent, elles sont en lecture seule et pour celle que tu dois configurer pour les plateformes de crypto, tu dois les mettre en lecture seule aussi. La Seule fois où elles sont en « écriture » c’est quand tu autorises un bot ou un logiciel tierce de faire des transactions pour toi.

57

Linxo peut effectuer des virements depuis tes comptes Fortuneo donc pas si lecture seule que ça leur api :sweat_smile: m’étonnerait pas que d’autres proposent ça aussi mais que ce soit pas implémenté :man_shrugging:t2:

58

Bonjour @Eluk,
Powens gère aussi ces connexions, et pour certaines vous avez le choix des permissions que vous donnez aux clés d’API (quand vous les générez sur l’interface de l’établissement en question), mais dans tous les cas Powens n’utilise que des méthodes en lecture seule sur les APIs en question. Niveau sécurité et stockage, c’est au même niveau que les identifiants bancaires.

59

Bonjour Mence,

Je ne suis pas un spécialiste de la sécurité informatique et le niveau de complexité de ce qui précède ne me rassure pas tellement. Je suis pourtant très interessé par votre plateforme.

Avez-vous connaissance d’un moyen de spécifier clairement aux organismes bancaires ou autres qu’un Login et un mot de passe ne sont donnés que pour un accès en consultation et sans autre droit ?

Cordialement

60

ce n’est pas possible, ça doit se faire du coté de qui détient les informations (ex. banque) qui pourrait fournir un code client/mot de passe en lecture seule à la place de celui habituel à accès complet.
Ce qui n’est pas fait car normalement toute opérations « risquée » nécessite une validation additionnelle qui requiert intervention humaine (code mono-usage envoyé par texto, mail, app ou autre moyen)

61

Concrètement ils peuvent donc avoir un accès admin et non en lecture seule alors ?