[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Contrôle d'accès porte et Debian



Bonjour,

Mes réponses dans le texte

Le 28/01/2016 21:21, enae a écrit :
> Bonjour,
>
> suite à votre message, je me permets de rebondir sur votre question.
>
> Pour commencer, il serait intéressant de bien définir votre besoin, à
> savoir : qu'entendez-vous par "contrôle d'accès" ?
>
> Est-ce un simple ouvre-porte qu'il vous faut ? est-ce qu'il vous faut
> des fonctions évoluées du style "gestion de sas", "gestion
> d'ascenseur", "comptage"...?
Il s'agit que d'accès à des portes, il n'y a pas de gestion plus
évoluée, si on a néanmoins possibilité d'avoir des logs timestamp sur
les ouvertures ou les accès non autorisés.
> Combien d'accès sont concernés ? sont-ils critiques ? (= est-ce qu'ils
> ont un fort débit de passage? exemple: tourniquet) sont-ils vitaux ?
La porte principale donc le lecteur sera dans les parties communes de
l'immeuble et 3 portes internes : 2 bureaux et 1 local technique.
Le passage sera faible maxi 10 personnes dans les locaux, pas de
tourniquet. L'accès le plus critique sera bien sur la porte d'entrée.
> Quel type de badge et quelleS technologieS de badges avez-vous? (un
> badge peut regrouper plusieurs technologies sur le même support)
Pour le moment nous n'avons aucun système on marche avec des clefs.
On a bien le badge de la cantine mais c'est une piste magnétique.

> Prévoyez-vous d'utiliser le badge pour un autre usage? ou
> utilisez-vous déjà le badge pour un autre usage? (exemple: pointage
> des employés, cantine...)
Uniquement cantine mais je préfère avoir un autre badge où c'est nous
qui en faisons la gestion.

> Utilisez-vous un encodage de badge propriétaire? ou prévoyez-vous d'en
> utiliser un?
Plus c'est open mieux c'est :)

> De ces dernières questions découlent le choix du lecteur de badge,
> restera à déterminer le câblage de celui-ci (avec son alimentation)
Nous ne sommes pas contre un cablage physique pour la porte principale
et le local technique, les deux bureaux peuvent être sur batterie ou fil
au choix.

> Est-ce qu'il y a nécessité d'une interaction avec de la
> vidéosurveillance? ou de la détection d'intrusion?
Je n'y avait pas pensé mais normalement la vidéo surveillance est prévue
pour tourner H24.

> Quel types de portes sont à contrôler? et quels sont les types de
> verrouillages retenus par porte à contrôler? (porte standard avec
> verrouillage par gâche à fond de pêne, porte avec verrouillage par
> ventouse électromagnétique, porte avec verrouillage par serrure
> motorisée... tourniquet, barrière type parking...?)
Porte standard avec gâche pour le moment, pourquoi pas changer le
système pour la porte d'entrée la plus sensible.

> Est-ce pour une industrie ou pour un ERP ? (établissement recevant du
> public) Si c'est pour un ERP, les verrouillages devront impérativement
> être conformes à la NFS 61-937.
Ce ne sont que des bureaux.

> S'il y a beaucoup d'accès, ou si les accès sont critiques, selon la ou
> les solutions retenues, il faudra certainement un peu de puissance
> processeur sous le coude afin de traiter les informations.
On aura un serveur de virtualisation sous peu en interne donc on peut
augmenter les ressources avant commande.

>
> J'espère n'avoir pas oublié de point et d'avoir pu résumer de façon
> simple les principales questions à se poser lors d'un projet de
> contrôle d'accès.
>
> Une fois ces points éclaircis, se pose la question de l'interfaçage
> avec l'humain, mais malheureusement actuellement, sur le marché la
> solution windows est clairement dominante.
>
> Je ne sais pas si une solution Linux ou même une solution libre existe.
> Cela dit, ce n'est pas infaisable, mais seulement que personne n'y
> aura pensé pour le moment à le faire. (= développer tout soi-même)
On n'est pas contre développer un peu, typiquement, si un lecteur peut
s'authentifier sur un radius déjà en place en interne
on saura s'adapter.

>
> Personnellement, pour répondre à ces problématiques de contrôle
> d'accès réel, je ne suis pas sur que le raspberry pi fasse l'affaire.
> (je n'ai certes aucune expérience en raspberry pi et ne le connais que
> de nom, cependant, je doute un peu qu'il puisse réaliser toutes ces
> fonctions)
> Cela dit, s'il y a des personnes qui connaissent bien le raspberry pi,
> pourraient-elles éclairer ma lanterne?
> Je les en remercie d'avance.
>
> Voila pour les grandes lignes d'un contrôle d'accès réel et de ses
> problématiques.
> J'espère que cela pourra déjà vous aider un peu dans votre besoin,
> même si la question reste ouverte pour une solution entièrement Linux.
>
>
>
>
>
> Le 27/01/2016 10:08, Wallace a écrit :
>> Bonjour,
>>
>> Je cherche à mettre en place une solution d'authentification pour nos
>> locaux et des premières recherches les logiciels tournent tous sous
>> Windows or dans notre entreprise nous sommes full Debian en serveur et
>> Debian / Ubuntu pour les postes. Nous n'avons clairement pas envie de
>> maintenir un Windows pour cela et n'avons pas du tout confiance dans ce
>> type de solution.
>>
>> Connaissez-vous un système d'authentification (badge, clef rfid,
>> emprunte, yubikey, ou autre) dont le logiciel de gestion pourrait être
>> une solution tournant sous Linux ou mieux capable de s'authentifier sur
>> le radius que nous avons déjà sur le réseau local?
>>
>> Je précise que l'on ne cherche pas ce type de solution pour la gratuité
>> puisque d'une y a le matériel à acheter et on est pas contre une licence
>> si on a accès aux sources. L'idée c'est de ne pas changer la ligne
>> directrice du SI interne et pouvoir aussi s'interfacer avec les
>> équipements et inventer des nouveaux usages ou simplement intégrer les
>> logs d'accès dans notre système de centralisation de logs actuels.
>>
>> Merci pour vos retours.
>>
>


Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: