Bonsoir,
suite à quelques déconvenues relatives au fonctionnement du système de badges pour ouvrir les portes à mon travail, je me demandais s'il existe pour Linux des solutions logicielles (de préférence libres) et le matériel associé pour gérer les ouvertures de portes.
J'ai bien trouvé liblogicalaccess, qui semble être une bonne base, mais je ne trouve pas de logiciel "prêt à l'emploi".
Mes besoins sont assez simples :
- pouvoir définir des groupes de portes, qui vont être les niveaux d'accès.
- pouvoir assigner une carte/un badge à une personne.
- pouvoir associer cette carte/cette personne à un niveau d'accès.
- pouvoir modifier/révoquer l'accès à une carte/une personne.
- transfert rapide et simple des listes d'accès aux centrales de contrôle des lecteurs et des portes.
- avoir accès aux journaux.
- pas d'accès à Internet.
Un truc un peu minimaliste (cli, fichiers csv) me va parfaitement.
Je précise que je n'y connais pas grand chose dans ce type de matériel. J'ai toutefois travaillé avec Winpak (Honeywell) et Centaur, et ça fait tout ce que je veux, sauf que c'est sur Windows.
Merci pour tout conseil/pointeur/suggestion.
Edit: précision suite aux discussions : je cherche un logiciel qui sache s'interfacer à une centrale propriétaire existante (et la référence d'une telle centrale). À défaut, une centrale pour laquelle le protocole/l'API est publié(e). Je veux gérer la configuration et le transfert des autorisations dans la centrale, pas les accès aux lecteurs et aux portes.
# Je crois que le coeur du problème c'est
Posté par totof2000 . Évalué à 2.
Comment se fait ce transfert ( protocole d'échange, données attendues …).
Pour le reste, rien qui ne puisse se faire via script et base de données (sql, yaml, json, etc). Le tout dans un repo GIT pour avoir la trace des modification …
Tu pourrais définir ça un peu comme les inventaires Ansible.
Pareil un truc basique clé/valeur en yaml
Perso je définirais des groupes de personnes à qui je donnerais des accès à des groupes de portes. C'est plus simple à gérer. Ensuite tu fais les associatios par groupe (pareil, dans un yaml, de la même façon qu'ansible fait la relation entre les roles et les inventaires par les playbooks).
Si c'est les journaux des modifications, tu lègues ça à GIT?
Ca c ton firewall en amont qui doit gérer ça (avec un DHCP qui attribuerait automatiquement une IP à ta machne dédiée à ça). A moins que par "pas d'internet" tu veux dire "pas de réseau", mais c'est un peu compliqué si tu veux sauvegarder …
[^] # Re: Je crois que le coeur du problème c'est
Posté par totof2000 . Évalué à 1.
J'ai pensé à ça la vite fait (parce que ta description me faisaitpenser à Ansible), mais d'unb autre côté je me dis que GIT pour ce genre d'outil pourrait vraiment être une solution.
Branche Main (ou master) => l'état actue des droits. Une personne, ou un groupe de personnes chargé de merger les requetes sur cette branche.
Les demandes d'accès se font via pull request ou merge request par les personnes qui peuvent commiter.
Tu sais qui fait quoi, quand.
Voir s'il y a possibilité de mettre en place un frontend pour les demandes d'accès qui s'interfacerait à GIT.
[^] # Re: Je crois que le coeur du problème c'est
Posté par totof2000 . Évalué à 1.
Ca pourrait être fun de développer ce genre de truc …
[^] # Re: Je crois que le coeur du problème c'est
Posté par cg . Évalué à 2.
Oui, je vois bien comment développer un système, et en effet git est tout vu pour garder les historiques, chouette idée.
Mais c'est la moitié du problème ;) : toute la difficulté est la communication avec le matériel.
Pour résumer, les centrales que je connais stockent les listes d'accès et ne sont pas dépendantes d'un ordinateur pour fonctionner. Elles gèrent elles-même les aspects matériels sous-jacents (lecteurs de badges, relais pour les portes).
J'ai croisé deux modes de transfert :
Pour cette partie, il "suffit" d'avoir le protocole (ou une lib qui l'implémente) qui permet de faire les mises à jour des listes d'autorisations dans les centrales et c'est plié (tout à l'air facile dit comme ça :D).
Je me rend compte qu'une lib comme liblogicalaccess travaille à un niveau trop bas pour moi, puisqu'elle traite directement les événements des lecteurs de badge.
OpenConcerto est un logiciel beaucoup plus large, mais pourrait faire l'affaire. La doc du module badge semble inexistante par contre :(.
[^] # Re: Je crois que le coeur du problème c'est
Posté par totof2000 . Évalué à 1.
Oui, tu délègues la gestion d'historique et de droits demodification à Git …
Je regarde, ça peut être une piste intéressante. Par contre faut voir le matériel sous-jacent.
[^] # Re: Je crois que le coeur du problème c'est
Posté par totof2000 . Évalué à 3.
Ok, la on parle des logs d'ouverture de porte … je n'avais pas compris ça comme ça … Si on a le protocole d'échange (RS485 ,c'est comme RS232 : ça définit les caractéristiques électriques de ligne, pas les messages échangés). Il faudrait que le protocole soit documenté par le constructeur de la centrale pour implémenter un échange. Si c'est pas chiffré on doit pouvoir relativement simplement sniffer le bus pour essayer de comprendre comment ça marche, mais comme tout reverse engineering, ça prend beaucoup de temps …
Là c'est pareil, il faut savoir comment sont organisées les données stockées sur le flash. Si c'est un support non standard, il faudra déjà comprendre comment on s'interface avec le flash, puis une fois que c'est fait, savoir comment les données sont organisées dessus. Si c'est du standard (Compact Flash, I2C, SPI, carte SD ou autre), seul le reverse engineering du contenu sera à faire si on a pas d'infos sur la façon dont il doit être organisé pour interagir avec.
Oui elle ne fait ni plus ni moins … C'est un élément intéressant pour intégrer dans une solution plus globale (elle ne s'interface pas avec les portes). Mais elle pourrait servir à la phase d'association utilisateur-> badge (scan du badge pour l'associer à l'utilisateur lors de l'arrivée de celui-ci).
J'ai peut etre un truc chez moi qui me permetttrait de jouer avec cette lib (le truc qui permet de recharger son pass navigo depuis chez soi …). Je peux peut-être faire quelque sexpérimentations dessus.
Sinon en regardant j'ai l'impression que toutes ces solutions sont proprios, à des niveaux plus ou moins élevés :( J'ai cru voir (j'ai fait quelques recherches suite à ton post) quelque strucs plus ou moins modulaire, mais la documentation n'est as forcément en libre accès.
Perso c'est un truc sur lequel j'aimerais bien bosser. Sinon Ca peut faire l'objet d'un projet de fin d'année intéressant pour des élèves de bac STI Electronique (si ça se fait encore - moi j'étais en F2 et j'ai eu un projet de fin d'année à réaliser - une carte d'interface moteur pas à pas sur un ensemble qui servait à doser du café) ou pour des élèves de BTS …
[^] # Re: Je crois que le coeur du problème c'est
Posté par totof2000 . Évalué à 3.
Sinon est-ce que tu peux préciser ton besoin ? Est-ce que tu cherches juste le logiciel qui serait chargé de gerer la base d'association utilisateurs=> badges pour transmettre les infos à un matériel déja existant (centrale) ou tu envisagerais quelque chose de plus complet qui gèrerait du matériel plus ou moins libre (firmware du matos) ?
L'accès à mon immeuble est géré par digik … donc je comprends un peu ce que tu veux mais pas a 100%. Est-ce que tu veux juste gérer les portes d'entrée, du batiment, ou gérer aussi des zones plus fines du batiment, avec éventuellement des portiques (style portiques à 3 branches ou portiques utilisé dans les systèmes de métro) ? A quel niveau es-tu prêt à descendre ?
[^] # Re: Je crois que le coeur du problème c'est
Posté par cg . Évalué à 3.
Oui c'est exactement ça. Je chercher à pouvoir m'interfacer avec une centrale de gestion d'accès (lecteurs et portes), mais pas plus.
Avoir d'un côté ma conf qui dit:
Harry Cover -> badge 9d12de33
Harry Cover -> autorisé à ouvrir les portes 1 et 2
Luna Park -> badge 9d33956
Luna Park -> autorisée à ouvrir les portes 1, 2, 3 et 4
Et pouvoir envoyer ces infos à la centrale qui fait sa tambouille avec ses lecteurs et ses relais.
Je ne veux absolument pas gérer un firmware sur du matos maison. Je sais - en très gros - le faire, mais pour des questions de responsabilité et l'énorme risque en cas de bug, ce n'est pas ce que je cherche.
Mais comme tu le dis si bien, tout à l'air largement propriétaire et bien fermé.
Pour détailler plus, le système que j'ai est de la famille Vigik (la config par défaut laisse entrer La Poste et autres livreurs privés !), la flash a un format physique à la con et je n'ai trouvé aucune documentation. Ce système ne me plaît pas, mais pour justifier de le changer, il faut qu'il y ait un intérêt. Pouvoir piloter et interroger la centrale est un point intéressant, notamment si ça permet à terme d'intégrer la gestion des badges dans mon SI LDAP. Mais pour ça il faut trouver une centrale dont le protocole est publié.
Bref, donc je demande si ça existe déjà ;). En tout cas ton enthousiasme sur le sujet est très rafraîchissant, c'est vrai que ça donne envie !
[^] # Re: Je crois que le coeur du problème c'est
Posté par totof2000 . Évalué à 2.
Sinon j'ai pensé à un autre truc …. Il y a peut être des contraintes (certifications pour que l'on puisse être assuré par exemple) qui font qu'une partie (hardware/module de comande) ne pourra pas être faite en mode DIY … C'est un aspect à contrôler (les systèmes d'ascenceur doivent répondre à certaines normes, au moins pour les cages, et toute l'infra physique, je ne sias pas si c'est le cas pour les systèmes/cartes de contrôle de montée/descente).
# J'ai vu ça
Posté par totof2000 . Évalué à 6.
https://www.openconcerto.org/fr/badge.html
[^] # Find it ....
Posté par totof2000 . Évalué à 5.
Mais je sais pas si le module est libre ….
https://doc.jeedom.com/fr_FR/plugins/security/gestAccess/
[^] # Re: Find it ....
Posté par cg . Évalué à 2.
Alors là c'est pas mal du tout, merci ! Le module semble faire tout ce que je veux (pour 1000€, pas si cher pour ce domaine).
Par contre, niveau protocoles ben, y'a pas trop de trucs qui ressemblent à des centrales indépendantes. Faut que je vérifie en détail quand même (je regarderai lundi).
# ouverture de porte
Posté par BAud (site web personnel) . Évalué à 5.
tu peux regarder https://github.com/ThomasGsp/sunlab ça permet de gérer l'ouverture de porte sur raspberry pi / en wifi (login / mot de passe) pour notre fablab.
et il y a une implémentation NFC (carte de transport en commun…) mais c'est pour gérer la présence des gens.
c'est du PHP/MySQL et un peu de C, assez facilement déployable et adaptable (et améliorable :p).
[^] # Re: ouverture de porte
Posté par totof2000 . Évalué à 1.
Pour un truc comme ça j'aurais plutôt utilisé Go/Rust … Langages plus modernes, avec fichiers sour GIT comme je l'ai écrit plus haut.
[^] # Re: ouverture de porte
Posté par BAud (site web personnel) . Évalué à 2.
bah l'intérêt c'était d'avoir un outil / langage simple qui permette de gérer des formulaires (même si parfois c'est plus simple d'aller directement en base MySQL, pour ajouter les admins qui peuvent valider les gens/capacités d'ouvertures, notamment… vu que ça change rarement).
Tu as les plans électrique pour gérer les électro-aimants de la porte sur
https://wikifab.hatlab.fr/SUNLAB_-_Enregistrement,_Authentification_%26_Acc%C3%A8s_%C3%A9lectronique
Puis bon, l'admin qui a réalisé cela avait PHP en tête. On a aussi une version en Python pour gérer le cahier de présence (mais là c'est pour gérer les présences, pas les ouvertures de porte), fait par un autre membre, en python principalement et sur un orangepi…
https://gitlab.com/HATLab78/badgeuse.sqylab
Bref, quand quelqu'un est motivé pour lancer son projet, tu t'adaptes à ses choix, même si tu n'aurais pas fait les mêmes :-)
[^] # Re: ouverture de porte
Posté par _kaos_ . Évalué à 3.
C'est peut-être une mauvaise idée, git.
Parce que si c'est identifiant tes données, ça va passer moyennement le RGPD. ;)
Matricule 23415
[^] # Re: ouverture de porte
Posté par cg . Évalué à 2.
Bonne remarque.
La conservation sans limite de l'historique dans git peut en effet poser un problème : un employé qui quitte l'entreprise ne doit plus avoir ses données personnelles dans nos fichiers, en dehors d'un cadre strictement légal (genre compta, salaires…).
S'agissant de contrôle d'accès, conserver ces informations longtemps (un an par exemple) n'est peut-être pas abusif. Mais même dans ce cas de figure, git n'est pas le meilleur outil pour effacer l'historique.
[^] # Re: ouverture de porte
Posté par totof2000 . Évalué à 1.
Tu ne conserves pas les logs d'accès dans GIT, mais juste qui a eu accès à quoi à un instant T dans ton entreprise (les permissions). Pour moi ça fait partier des données administratives..
Après tu peux peut être gérer ça en utilisant un hash plutôt que le nom de ton employé de telle façon que l'identification d'un employé qui n'est plus dans la boite ne puisse se faire que si la RH te communique son hash … Et pour savoir qui c'est tu interroges une API de ta RH qui t'indique qui est cette personne. Au bout d'un moment celle-ci te dit que la personne en question n'est plus dans la société et qu'il y a un procédure particulière si on a besoin d'avoir des infos …
Mais bon ….. Je serais surpris que RGPD ne permette pas à un employeur de conserver ce à quoi celui-ci a eu accès lorsqu'il était employé chez lui.
[^] # Re: ouverture de porte
Posté par _kaos_ . Évalué à 3.
Qui ne peuvent être conservées à vie, comme indiqué plus haut.
Les collisions, ça fout en l'air ton système. Ou alors, c'est de l'"anonymisation inversible" (autant dire : rien).
Bonne idée, mais en pratique pas jouable (note que c'est idem pour les assos, c'est pas que les boites qui sont concernées).
Matricule 23415
[^] # Re: ouverture de porte
Posté par NeoX . Évalué à 2. Dernière modification le 13 juin 2021 à 10:27.
donc c'est des logs
dans le GIT tu ne devrais avoir que les regles d'accès du style :
[^] # Re: durée de conservation des infos
Posté par cg . Évalué à 2.
Oui, tout à fait.
J'ai trouvé ça sur un site :
Je suis pas sorti de l'auberge :D
Petite remarque au passage pour le plaisir du troll : un admin, une RH, pas de déterminant pour les personnes qui font le ménage, c'est même plus des humains quoi ?
[^] # Re: durée de conservation des infos
Posté par totof2000 . Évalué à 1. Dernière modification le 13 juin 2021 à 14:39.
Qu'appelle-t-on données personnelles ? C'est ça la question. Parce que si le but c'est de protéger la vie privée des salariés, le fait de savoir qu'un memere de l'entreprise a eu accès à celle-ci durant le temps qu'il était employén c'est oas de la vie privée, c'est de la vie d'entreprise.
Si c'est vrai, le RGPD va beaucoup troploin sur ce point (ou alors il a été mal défini …)
[^] # Re: durée de conservation des infos
Posté par _kaos_ . Évalué à 4. Dernière modification le 13 juin 2021 à 14:50.
C'est très bien défini, au sens du RGPD :
Donc un identifiant, ça l'est.
Et non, la vie de l'entreprise, ce n'est pas une "excuse" pour passer outre, que tu le veuille ou non.
Savoir qui a eu accès à quoi il y a cinq ou dix ans est bien ce qu'interdit le RGPD, il n'y a pas d'erreur.
Matricule 23415
[^] # Re: durée de conservation des infos
Posté par totof2000 . Évalué à 1.
La question n'est pas d'avoir une excuse mais d'avoir un équilibre. Le but du RGPD est bien de protéger la vie privée des gens. Qu'on ne suive pas à la trace ce qu'une personne a fait dans l'entreprise pendant tout le temps qu'il y était est une bonne chose. Par contre (mais ce n'est que mon avis) qu'une entreprise ne puisse pas conserver un historique des personnes ayant travaillé pour elles, ainsi que leur fonctionnalité (sur laquelle se baserait leurs accès) me parait un peu exagéré. Après, y mettre des gardes-fou (du style déclaration à la CNIL des informations nécessaires à cet usage,pour que celle-ci anayse s'il y a abus me paraitrait un peu plus équilibré). Après il y a peut-être des abus potentiel que je ne vois pas, ais j'aimerais justement connaître ce type d'abus pour pouvoir comprendre le pourquoi de ce qui me paraît strict.
[^] # Re: durée de conservation des infos
Posté par totof2000 . Évalué à 1.
Si je cite la phrase :
est réputée être une «personne physique identifiable» une personne physique qui peut être identifiée, directement ou indirectement, notamment par référence à un identifiant, tel qu'un nom, un numéro d'identification, des données de localisation, un identifiant en ligne, ou à un ou plusieurs éléments spécifiques propres à son identité physique, physiologique, génétique, psychique, économique, culturelle ou sociale;
Avant otut j'ai conscience que ce que je veut dire est difficilement applicable à ce que je proposais dans ma solution basée sur GIT, mais :
LA seule contrainte serait de savoir à un instant T quels snt les id qui ont été utilisés de ce qui ne l'ont pas été.
[^] # Re: durée de conservation des infos
Posté par totof2000 . Évalué à 1.
D'après la référence citée plus haut :
=> ces informations doivent être archivées, supprimées ou anonymisées.
Si supprimer le lien entre un ID et une personne est suffisant pour anonymiser celle-ci, ce que je disais plus haut a du sens …
[^] # Re: durée de conservation des infos
Posté par _kaos_ . Évalué à 2.
Ça, ça me semble relever de la pseudonymisation.
Et franchement, sans être en mesure de justifier de l'intérêt, je ne prendrai pas de risque.
Justifier que "techniquement, c'est plus facile" sera rejeté à mon avis. Si un autre dispositif législatif par exemple te contraint à disposer de cette information sans quoi tu n'es plus en mesure de t'y conformer, l'avis a probablement des chances d'être autre. Mais il faut le justifier et prendre des mesures adaptées.
La loi n'est pas complètement idiote (même si parfois… oups :) ) et ne te demandera pas une chose et son contraire. Si c'est sujet à débat, c'est au législateur de trancher, mais pas à toi.
Matricule 23415
[^] # Re: durée de conservation des infos
Posté par totof2000 . Évalué à 1.
. Après est-ce que le RGPD est aussi strict que ça ? Est-ce qu'une déclaration à la CNIL pourrait permettre de conser ver ce genre d'infos ? Je ne sais pas …
[^] # Re: durée de conservation des infos
Posté par _kaos_ . Évalué à 2.
Tu as envie qu'on sache 10 ans plus tard que tartampion a ouvert la porte des toilettes ?
La distinction peut être très mince entre vie privée et vie d'entreprise.
Je ne suis pas juriste, donc c'est énormément sujet à correction, je pense que ça peut être levé, à condition de justifier le caractère impératif de la conservation. La sécurité n'en fait pas partie.
Matricule 23415
[^] # Re: durée de conservation des infos
Posté par totof2000 . Évalué à 1. Dernière modification le 13 juin 2021 à 15:13.
Non, c'est pas ce genre d'infos que je voulais mettre dans GIT. (j'avais mal compris ce que le PI entendait par "log).
En terme de log, GIT ne donne accès qu'à l'historique des accès accordés (via les commits), et qui a accordé ces droits, ce qui est un peu différent.
Je veux juste savoir que pendant qu'il était employé, tartempion avait les droits d'accès aux toilettes ce qui est différent.
En fait même ça ne ne veux as le savoir. C'est GIT qui garderait cette info.
[^] # Re: durée de conservation des infos
Posté par totof2000 . Évalué à 1. Dernière modification le 13 juin 2021 à 15:18.
Pour être plus précis, dans la solution que j'envisageais, GIT ne donne accès qu'à deux types de données :
- l'historique des accès accordés ( une photo des droits d'accès aux locaux par tous les employés à un instant T via les commits)
- qui a accordé ces droits
Si la deuxième partie est empêchée ar le RGPD, du coup on ne peux plus utiliser GIT en entreprise. Pour la première partie, de mon point de vie si ce n'est pas possibe, je trouve de mon point de vue que c'est un peu excessif, mais là encore il y a potentiellement des cas d'abus que je n'ai pas identifié.
[^] # Re: durée de conservation des infos
Posté par _kaos_ . Évalué à 2.
Et la loi se prémunit de cela : si tu ne justifie par du caractère obligatoire, c'est non, tu n'as pas le droit. Ce n'est pas à la loi de réfléchir à tous les usages (bons ou mauvais), mais de poser un cadre général (le G du RGPD).
Matricule 23415
[^] # Re: durée de conservation des infos
Posté par cg . Évalué à 1.
C'est une notion à creuser, cette "deuxième partie".
Par exemple on a un repo git qui doit avoir 15-20 ans d'historique (migré depuis Subversion lui-même migré depuis CVS), avec sur chaque commit le triplet prénom/nom/mail interne de l'auteur. Avec bien sûr des gens qui sont partis depuis longtemps.
Nous devrions reconstruire le repo en anonymisant ces commits pour être conforme au RGPD ?
Autre cas de figure : j'ai des archives sur LTO, DLT, disque dur, DAT, pellicule 35mm… plusieurs milliers de supports (30 ans d'archives). Sur les archives numériques (LTO), l'UID du propriétaire du fichier est stocké, et il y a parfois les auteurs des versions de tests de séquences SUR les images elles-mêmes (je travaille dans la post-prod de cinéma).
C'est largement "inaccessible" (offline et accès restreint), mais la donnée personnelle est stockée !
Je me vois pas aller gratter les pellicules pour enlever les noms :D.
[^] # Re: durée de conservation des infos
Posté par totof2000 . Évalué à 1.
Tu as tout compris mon raisonnement …
En fait là on passe aux conflits potentiels entre droit moral et contraintes RGPD. Mais à mon avis c'est quelque chose à éclaircir. En y réfléchissant un peu, il semble que ce soit ici le droit moral qui s'exerce, au moins pour du code et/ou des séquences vidéos.
Celà dit si le repo GIT permet, via les commits d'associer un UID à une personne (qui aurait été anonymisé en supprimant ce lien par une procédure ad hoc par ailleurs), je pense que ça pose problème.
U juriste dans la salle ?
[^] # Re: durée de conservation des infos
Posté par _kaos_ . Évalué à 3. Dernière modification le 13 juin 2021 à 18:04.
Vous vous posez de ces questions…
Utiliser git n'est pas un problème, identifier un utilisateur en soi non plus si cela correspond à une contrainte pour la réalisation d'un objectif (sous-entendu probablement, raisonnable) !
Tant que c'est utile, c'est bon. Si non, ça ne l'est plus. D'où l'intérêt d'être bien clair dans la finalité du (des fichiers) et traitements informatiques associés.
Donc aucun problème pour les métadonnées dans des photos ou les noms dans les commits git.
Ce qui pose problème, c'est de conserver des données identifiantes au delà d'un certain temps dès lors qu'elles ne répondent plus au besoin de la réalisation de cet objectif, qui doit être précis.
Matricule 23415
[^] # Re: durée de conservation des infos
Posté par _kaos_ . Évalué à 4. Dernière modification le 13 juin 2021 à 18:25.
J'ai probablement été un peu fort sur le :
Oui, si vous avez un doute, il faut poser la question.
Matricule 23415
[^] # Re: durée de conservation des infos
Posté par cg . Évalué à 1. Dernière modification le 13 juin 2021 à 19:29.
Merci pour la conversation passionnante et éclairante !
En cherchant des articles sur RGPD et l'historique des gestionnaires de code, je suis tombé sur un petit site francophone qui a l'air pas mal avec une conversation qui reprend tous ces éléments.
[^] # Re: durée de conservation des infos
Posté par _kaos_ . Évalué à 2.
C'est au contraire pire, puisque c'est clairement identifiant, tu le dis toi-même :)
Et si un identifiant n'est pas identifiant, ton système n'est à priori plus sécurisé.
C'est un compromis à faire.
Matricule 23415
[^] # Re: durée de conservation des infos
Posté par totof2000 . Évalué à 1.
Et pourquoi trouves-tu ça pire ?
[^] # Re: durée de conservation des infos
Posté par _kaos_ . Évalué à 2.
Parce que c'est marqué en rouge surligné en jaune clignotant et que tu vas vite avoir des problèmes si tu fais ça :)
Matricule 23415
[^] # Re: durée de conservation des infos
Posté par totof2000 . Évalué à 1.
Bof, je suis du genre à me poser des questions quand je vois un gros bouton rouge sur un socle jaune et de demander à quoi il sert …
[^] # Re: durée de conservation des infos
Posté par totof2000 . Évalué à 1.
Tout à fait. En fait le RGPD étant un peu "jeune", je suis certain qu'on aura des cas ou la limite fixée empêche certaines choses qui sont plutôt légitime. Comme je te disais, si le but du traîtement des données personnelles c'est de protéger la vie privée des gens, il ne faudrait pas non plus tomber d'ans l'extrême ou pour protéger la vie privée des gens, tu en viens à ne pas conserver (attention, je ne parle pas de divulgation ais de conservation) des donnée qui relève non pas de vie privée, mais de vie "semi privée (vie en société). Après pour une fois que la directive est en faveur des individus plutôt qu'en faveur des (grands) groupes, je ne me plains pas …
[^] # Re: durée de conservation des infos
Posté par _kaos_ . Évalué à 3. Dernière modification le 13 juin 2021 à 16:23.
Le RGPD n'est pas si jeune, si l'on considère son histoire complète (son "historique ;) ).
Avant, c'était la LCEN (2004) et encore avant, la loi informatique et libertés (1978). Il y a eu du temps pour réfléchir au problème, de le rendre simple et clair. C'est son but.
Matricule 23415
[^] # Re: durée de conservation des infos
Posté par totof2000 . Évalué à 1.
Quel que soit son historique, l'application du rgpd en l'état actuel est relativement récente.
Ce que tu dis c'est comme considérer que le fait que Mozilla publie un navigateur web depuis longtemps fait que la prochaine version du soft se fera sans bug.
De mon point de vue, même si on peut faire des similitudes entre législation et logiciel, il y a aussi des différences. L'une d'entre elles, c'est que le législatif a des cycles plus long (on pourrait comparer ça à du cycle en V) alors que les cycles de vie du logiciel sont plus court (et les résolutions de bug peuvent prenddre moins de temps).
Maintenant si on fait un peu le focus sur le RGPD :
Le RGPD est un règlement européen, contrairement à la loi informatique et libertés (qui est Française et plus ou moins issu de la mise en place du No INSEE), qui est sur certains points plus strict (ou clarifie certains sujets pouvant être interprétés) que la LCEN ou même que la loi informatique et libertés.
Perso je trouve que c'est une bonne chose, mais comme toute chose nouvelle ou modifié récemment, je pense qu'on y trouvera des bugs sur certains use cases qui ne sont pas ou mal couverts.
[^] # Re: durée de conservation des infos
Posté par _kaos_ . Évalué à 2. Dernière modification le 13 juin 2021 à 18:11.
Tu me fais dire ce que je ne dis pas.
Je dis que le RGPD est simple, pas qu'il n'a pas de défaut !
Il est simple, car général. Sa transposition en loi "locale" est bien plus complexe que les précédents.
Pour reprendre ton exemple, je ne dis pas qu'il ne peut pas y avoir de régression, donc de bug, mais le passé permet de mieux les gérer, voir les anticiper.
Le RGPD, c'est plus contraignant que les spécificités locales, oui. Mais ça s'applique pareil pour un plus grand nombre, donc c'est plus équitable quelque part.
Matricule 23415
[^] # Re: durée de conservation des infos
Posté par totof2000 . Évalué à 1.
Je pense qu'on es en phase mais que je regarde un peu trop le verre à moitié vide …
[^] # Re: durée de conservation des infos
Posté par totof2000 . Évalué à 1.
Disons que je n'ai pas compris réellement ce que tu voulais dire, et que je te reformule ce que j'en ai compris (pas dans le but de t'agresser, mais pour essayer de clarifier les choses).
Désolé si je n'ai pas compris.
[^] # Re: durée de conservation des infos
Posté par _kaos_ . Évalué à 2.
Je n'ai pas eu le sentiment que tu m'agresse, si ça peut te rassurer :)
J'ai peut-être aussi pris les choses en présupposant que tu avais eu plus d'information et d'accompagnement à ce propos. Mais ne t'en fais pas, j'étais une quiche complète avant qu'on m'aide à comprendre certains aspects. Et je ne prétend absolument pas être calé sur le sujet maintenant, encore moins juriste.
Matricule 23415
[^] # Re: durée de conservation des infos
Posté par NeoX . Évalué à 4. Dernière modification le 13 juin 2021 à 19:35.
non c'est un role est c'est exactement ce que doit faire ton système de contrôle d'accès.
ensuite tu attribues un badge à une personne, elle a une "reference"
et cette reference appartient à ce role.
toi admin, tu sais que le badge 232973612481632 qui appartient à un ou une CADRE a accédé à la salle de reunion à 20h45 un dimanche, mais pas plus.
en cas de controle, exemple il y a eu un vol de materiel (le videoprojecteur)
la police demande l'accès au log d'un coté et demandera à qui est censé appartenir le badge pour savoir qui interroger.
c'est bêtes, mais tu proteges la vie privée en ne mettant pas un nom/prenom derriere une regle d'ouverture de porte et ton depot GIT est générique, anonyme (enfin c'est mon avis)
# Please open-it
Posté par Nonolapéro . Évalué à 2.
Une gestion des accès physique avec une raspberrypi et du OAuth2 qui a démarré sur du hack.
https://www.please-open.it/
Une vidéo de description du concept : https://www.youtube.com/watch?v=ZaKoAUs-SQk
[^] # Re: Please open-it
Posté par cg . Évalué à 1.
J'ai regardé en très accéléré et cherché dans les docs/le web, j'ai rien trouvé qui parle de l'aspect matériel. Tu aurais des liens vers ce genre de sujet ?
# Bredouille pour le moment
Posté par cg . Évalué à 1.
Bon j'ai eu moins de temps que prévu pour chercher sur le sujet, mais mes maigres résultats m'ont dit que les centrales un minimum ouvertes, c'est le désert. Y'a un marché à prendre (ou pas) !
Merci à tout le monde pour les pistes, réflexions et bifurcations autour du sujet.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.