totof2000 a écrit 1895 commentaires

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 …)

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.

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.

Mais je sais pas si le module est libre ….

https://doc.jeedom.com/fr_FR/plugins/security/gestAccess/

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).

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 ?

le logiciel est connecté à la centrale via un bus rs485, et envoie les mises à jour des listes d'accès au fur et à mesure. Il reçoit aussi les logs via ce bus rs485.

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 …

depuis le logiciel, il faut transférer la configuration sur un petit stockage flash, puis mettre cette mémoire flash dans chaque centrale pour importer les configs. Pour récupérer les logs, il faut aussi les exporter depuis la centrale pour les mettre sur un PC ensuite.

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.

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.

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 …

Oui, je vois bien comment développer un système, et en effet git est tout vu pour garder les historiques, chouette idée.

Oui, tu délègues la gestion d'historique et de droits demodification à Git …

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.

Je regarde, ça peut être une piste intéressante. Par contre faut voir le matériel sous-jacent.

Ca pourrait être fun de développer ce genre de truc …

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.

https://www.openconcerto.org/fr/badge.html

transfert rapide et simple des listes d'accès aux centrales de contrôle des lecteurs et des portes.

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 …

pouvoir définir des groupes de portes, qui vont être les niveaux d'accès

Tu pourrais définir ça un peu comme les inventaires Ansible.

pouvoir assigner une carte/un badge à une personne.

Pareil un truc basique clé/valeur en yaml

pouvoir associer cette carte/cette personne à un niveau d'accès.

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).

avoir accès aux journaux.

Si c'est les journaux des modifications, tu lègues ça à GIT?

pas d'accès à Internet.

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 …

Ah, moi c'était les télétubbies ..

Euh … Finalement non ,mon jeu de mots risque de ne pas plair.

Ca c'est voir le verre a moitié vide. Le verre a moitié plein c'est que ça pourrait fair e des émules, que d'autres boites pourraient suivre le pas RiscV parce que ça signifierait que le marché sera demandeur (peu de boites ont la capacité de prendre des risques sur de nouvelles architectures CPU).

Les développement de RiscV peut être boosté. Ca ferait un sérieux concurrent à ARM - pour un cout de R&D moindre que de partir de zero (ça c ma vision du verre a moitié plein).

Et du coup AMD pourrait suivre le pas en achetant une boite qui développe du RiscV ou en produisant sa propre version.

Celà dit j'aurais préféré que ce soit une autre boite qu'Intel qui fasse ce rachat, parce que là, le risque pourraît être de vouloir tuer la concurrence dans l'oeuf, mais sauf erreur de ma part, sur ce créneau de CPU, Intel n'a pas vraiment d'offre, et si on y réfléchit d'un point de vue stratégique, ce rachat a du sens - ils ont une carte a jouer.

Perso j'aurais été plus méfiant si ça avait été MicroChip par exemple

J'espère par contre que les concepteurs du CPU ont bien verrouillé le fait que ce coeur restera libre.

Ca c'est voir le verre a moitié vide. Le verre a moitié plein c'est que ça pourrait fair e des émules, que d'autres boites pourraient suivre le pas RiscV parce que ça signifierait que le marché sera demandeur (peu de boites ont la capacité de prendre des risques sur de nouvelles architectures CPU).

Le verre a moitié plein c'est que le développement de RiscV peut être boosté. Ca ferait un sérieux concurrent à ARM - pour un cout de R&D moindre que de partir de zero (ça c ma vision du verre a moitié plein).

Et du coup AMD pourrait suivre le pas en achetant une boite qui développe du RiscV ou en produisant sa propre version.

J'espère par contre que les concepteurs du CPU ont bien verrouillé le fait que ce coeur restera libre.

Je disais l'un de mes préférés parce que dans le genre un qui est pas mal c'est asterix chez les normands

Tu aurais pu en faire un acec le commentaire que j'ai fait juste au dessus …

ET SI CET ÉGYPTIEN AJOUTE QUELQUE CHOSE, JE LE PASSE PAR DESSUS BORD

Par contre faut éviter de es télécharger sur les réseaux P2P. Yen a qui ont essayé, ils ont eu des problèmes.

Il y a des puristes qui pourraient trouver mon approche imprécise, mais elle a le mérite de prendre les bases et de les représeznter d'une manière concrète.

je continuerai ensuite.

J'ai volontairement splitté un peu mes réponses pour que tu puisses poser des questions.

Je ne sais pas si la prochaine fois je vais parler de l'operateur NOT (c'est la fameuse barre qu'on trouve sur l'expression ā ou continuer par quelques petits exercices.

Je poste les représentations ici (je me suis planté dans la représentation précédemment)

Représentation de S=a.b+c

|   a      b                |
|--| |----| |---+----(S)----|
|       c       |           |
|------| |------+           |

Représentation de S=a.(b+c)

|   a       b                |
|--| |--+--| |---+----(S)----|
|       |        |           |
|       |   c    |           |
|       +--| |---+           |

Priorité des opérateurs.

Comme enb algèbre classiques, les operateurs ont des priorités.

L'opérateur ET est prioritaire sur l'opérateur OU.

Par exemple :

s=a.b+c signifie que l'état de la sortie est dépendant de l'état de a et de b, ou de l'état de C.

Représentation :

Si on veut que b+c soit prioritaire, on peut mettre des parenthèses. Ca donne :

S=a.(b+c)

Représentation :

Essaie de générer la table de vérité de ces deux expressions.

Table de vérité.

On appelle table de vérité la table qui représente tous les états possible de l'expression.

Par exemple pour ET

S=a.b

On crée un tableau qui relève tous les éléments de ton ou de tes expressions

+---+---+---+
| a | b | S |
+---+---+---+

Ensuite dans ce tableau, pour chaque éléments d'entrée, on positionne les états possibles Comme on a 2 éléments et que chaque élément peut prendre deux valeurs, ça donne ça :

+---+---+---+
| a | b | S |
+---+---+---+
| 0 | 0 |   |
+---+---+---+
| 0 | 1 |   |
+---+---+---+
| 1 | 0 |   |
+---+---+---+
| 1 | 1 |   |
+---+---+---+

Ensuite on écrit l'état de S en fonction de l'état des élé"ments dont il dépend. Pour l'operateur S=a.b ça donne :

+---+---+---+
| a | b | S |
+---+---+---+
| 0 | 0 | 0 |
+---+---+---+
| 0 | 1 | 0 |
+---+---+---+
| 1 | 0 | 0 |
+---+---+---+
| 1 | 1 | 1 |
+---+---+---+

pour OU, je laisse à titre d'exercice

s=a+b

+---+---+---+
| a | b | S |
+---+---+---+
| 0 | 0 |   |
+---+---+---+
| 0 | 1 |   |
+---+---+---+
| 1 | 0 |   |
+---+---+---+
| 1 | 1 |   |
+---+---+---+

operateur OU

S=a+b signifie que l'état de S dépend de l'état de B Autrement dit, S est actif si A est actif OU b est actif.

Ca peut se représenter par des interrupteurs en parallèle

|     a
|----| |----+                        |
|           |                        |
|           +-----------------(S)----|
|     b     |                        |
|----| |----+                        |

Si a=O et B=0, la sortie n'est pas active (circuit ouvert)

si a=0 et b=1, la sortie est active (fermeture de circuit en b)
si a=1 et b=0, la sortie est active (fermeture de circuit en a)
si a=1 et b=1, la sortie est active (fermeture de circuit en a et en b)

On a bien donc une activation de l'état de sortie de S en fonction de a ou de B.