iAccess¶

Ce site regroupe l’ensemble des comptes rendus de réunion ayant eu lieu jusqu’à présent dans le cadre du projet iAccess. Ce projet concerne la sécurité de sites comme des usines, des lieux de cultes, des hopitaux, des sites sportifs, des complexes commerciaux, etc. L’objectif du projet consiste à développer le logiciel iAccess dans le cadre d’un consortium mettant en oeuvre différentes parties prenantes au sein de différentes organisations (à ce jour, IMAG, Batemis, Bissis et Competis).

Comptes rendus de réunions¶

CR001 Réunion de lancement de iAccess¶

PartiesPrenantes:
Date:	02-01 08h-10h d
Type:	Réunion
Lieu:	Grenoble-AccessIT
	ABI, JDR, KWG, MPA, PSO, TNA, ZSH
Organisateur:	ABI
Rapporteur:	KWG
Presents:	ABI, JDR, KWG, MPA, PSO, TNA, ZSH
Objectifs:	Présentation des parties prenantes, grands objectifs

Attention

Ce compte rendu est un document de travail et n’est pas contractuel.

En ce début de projet, les parties prenantes sont les suivantes :
- Ahmed BLASI (ABI) – IM2AG, Grenoble
- Jean-Claude DUFOUR (JDR) - AccessIT, Grenoble
- Ken WONG (KWG) – IM2AG, Grenoble
- Mireille PALMA (MPA) – AccessIT, Lisbonne
- Paolo SANTIAGO SANCHEZ (PSO) – AccessIT, Caracas
- Hong SHI (HSI) – AccessIT, Zurich
- Tararya NARAMANATA (TNA) – AccessIT, Nantes
- Zork SWISH (ZSH) – AccessIT, Autriche
- Cassandra COHEN (CCN) - IM2AG, Grenoble
Le présent projet a été baptisé iAccess.
Les demandes de sécurisation de sites et de bâtiments se développent suite aux attentats des dernières années. Il s’agit d’une opportunité commerciale pour les sociétés de sécurité comme AccessIT.
La société AccessIT est spécialisée dans les systèmes de contrôle d’accès.
AccessIT ne produit pas les équipements de sécurité, mais les assemble et les installe.
Les logiciels contrôlant ces équipements sont développés par AccessIT à la demande pour chaque site.
L’équipe informatique de AccessIT est assez limitée actuellement.
Avec l’augmentation de la demande, AccessIT doit faire appel à des prestataires extérieurs pour répondre à ses clients.
La conception de certaines versions de iAccess sera donc confiée à l’UFR IM2AG.
Un certain nombre de contraintes techniques ont été déjà mentionnées :
- les développements devront se faire en Python 3.7 avec le framework Tornado.
Le choix de Python/Tornado est lié au fait que AccessIT utilise déjà ces technologies en interne.
Pour le matériel de sécurité, AccessIT a passé un accord avec Bissis.
Bissis est un constructeur proposant du matériel à la pointe de l’innovation.
En particulier AccessIT a décidé de se baser des bissas (sas à deux portes) pour toutes ses offres.
AccessIT et Bissis ont passé un accord pour mettre sur le marché des bissas le plus rapidement possible.
Bissis sera donc partie prenante pour le projet et fournira les bissas, avec leurs drivers.
Une prochaine réunion aura lieu dans les locaux de Bissis à Berlin pour étudier les bissas.
Différentes organisations ont déjà contacté AccessIT pour la mise en place de iAccess.
L’entreprise chimique Chimiotis désire sécuriser son site de Morrocoy pour octobre 2019.
Les sites des jeux olympiques de Tokyo doivent également être sécurisées pour 2020.
Plusieurs universités indiennes voudraient également migrer vers iAccess en 2019.
Les commerciaux de AccessIT prévoient une augmentation exponentielle des demandes au prochain trimestre.
Chaque version de iAccess sera conçue et développée de façon incrémentale, en commençant par les fonctionnalités les plus demandées par les clients.
AccessIT a décidé d’imposer l’utilisation d’UML pour la conception de ce projet (et d’autres projets).
Plus particulièrement un accord a été passé avec ModelioSoft-Paris pour des licences Modelio.
AccessIT utilisera une démarche agile pour s’assurer de l’adéquation du système avec les besoins des sites.
La conception de la version de iAccess pour Morrocoy a été confiée à l’IM2AG
La prochaine réunion aura lieu à Londres en présence de Competis.
En conclusion, il a été observé que ce consortium international ne pourrait fonctionner qui si toutes les parties prenantes parviennent à participer et à mettre en œuvre leur savoir-faire.
Les différentes parties prenantes sont toutes conscientes des opportunités commerciales apportées par ce nouveau contexte sécuritaire.

CR002 Réunion iAcces pour le stade Kasumigaoka de Tokyo¶

PartiesPrenantes:
Date:	01-05 08h-22h
Type:	Reunion
Lieu:	Tokyo
	ABI, JDR, PSO, AGO
Organisateur:	ABI
Rapporteur:	KWG
Presents:	ABI, JDR, PSO, AGO
Objectifs:	Attentes pour le stade Kasumigaoka de Tokyo

Attention

Ce compte rendu est un document de travail et n’est pas contractuel.

Nouvel intervenant :
_ Apito GUARACARUMBO (AGO) - Competis, Tokyo
La réunion a eu lieu sur le site du stade Kasumigaoka de Tokyo (新国立霞ヶ丘競技場) guidé par AGO.
Le stade a été détruit et est actuellement reconstruit à neuf pour les jeux olympiques d’été de 2020.
Son accès doit être sécurisé pour fin 2019.
Grâce aux bissas, cette installation a été considérée comme viable par AccessIT.
AccessIT et Bissis seront les seuls à pouvoir équiper des sites avec des bissas.
Un plan des installations a été fourni par Competis.
A partir de la visite du site et de ce plan, un premier plan sécurité a été établi.
Les différents points d’accès et le nombre des bissas a été déterminé par AccessIT.
De même pour le positionnement des caméras et de la salle de contrôle.

Fig. 1 : Le nouveau stade Kasumigaoka
Les différentes zones du site ont été représentées sur le plan sécurité.
Par contre les bâtiments, installations et autres espaces non sécurisés n’y sont pas.
De même pour les entrées de véhicules et autres entrées gérées par des vigiles.
Les différents types de bissas ont été choisis en fonction du niveau de sécurité à atteindre.
Il est rappelé qu’une présentation des bissas aura lieu à Berlin - Bissis.
Différents groupes de personnes autorisées devront être définis.
Par exemple les spectateurs auront des billets papier.
Ils ne pourront accéder qu’à la tribune correspondant à leur billet.
Cette autorisation n’est valide que pour la période correspondant à l’épreuve du billet.
Un exemple de billet a été fourni par Competis et reproduit ci-dessous.

Fig. 2 : Exemple de billet faisant office de badge grâce au QR code
Pendant les jeux olympiques, les athlètes accéderont au village sportif, au restaurant, et à leur bâtiment.
Ils pourront aussi aller en salle de presse et à l’administration de 8h à 17h.
Par contre l’accès au sous-sol sportif et à l’arène ne leur sera pas autorisé tout le temps.
Ce sera uniquement le cas si une épreuve de leur discipline est en cours.
Différents autres groupes de badgeurs ont été évoqués dans ce cas d’étude.
Par exemple les administratifs et les journalistes ont chacun leurs zones.
Comme sur tous les sites, les gardiens peuvent aller dans toutes les zones dont la salle de contrôle.
Ils peuvent depuis leur smartphone débloquer l’accès ou la sortie d’une personne bloquée suite à un incident.
Même si différents groupes de badgeurs ont été identifiés, d’autres pourraient apparaître.
Un superviseur unique par site pourra créer des administrateurs pour ces groupes. Il leur donnera des droits sur la gestion d’une ou plusieurs zones.
Chaque groupe d’un site sera alors créé et géré par un administrateur et pas par le superviseur.
Par exemple les administrateurs des sportifs pourront éditer leurs badges et définir les zones auxquelles ils ont accès et à quels moments.
Les administrateurs de presse s’occuperont des badges des journalistes, etc.
Bien entendu les administrateurs de groupe ne pourront pas donner à un groupe l’accès à des zones dont il n’est pas chargé.
Les badges papiers pour les spectateurs seront émis par un système en ligne.
Dans une telle compétition, on attend en effet environ 100 000 spectateurs.
Plus de 400 000 billets seront sans doute émis (mais pas forcément utilisés).
Le système en ligne CyberCompetition (par Competis) sera en charge de l’émission des billets.
Pour les spectateurs les badges prendront la forme de QR codes sur leurs billets papiers (cf. CR002Fig2)
De façon générale des logiciels externes (e.g. CyberCompetition) devront pouvoir gérer les membres d’un groupe, comme ajouter des spectateurs à des compétitions pour lesquels des billets ont été émis par l’ERP CyberCompetition.
Pour la transmission par un logiciel à iAccess des informations de gestion d’un groupe, seules certaines informations seront nécessaires
Il a été convenu qu’un format XML soit utilisé dans ce cadre.
Le fichier d’exemple ci-dessous a été fourni par Competis.

Fig. 3 : Exemple de fichier généré par Competis - Exemple Competis 01_05
La transmission des données entre CyberCompetition et iAccess devra se faire via un web service sécurisé.
En conclusion, la visite sur le site du stade olympique de Tokyo a été très instructive.
Il correspond bien aux fonctionnalités de base que devra permettre iAccess à terme.

CR003 Réunion iAcces pour Chimiotis¶

PartiesPrenantes:
Date:	02-17 15h-23h
Type:	Réunion
Lieu:	Morrocoy-Chimiotis
	ABI, JDR, PSO, AGO
Organisateur:	ABI
Rapporteur:	KWG
Presents:	ABI, JDR, PSO, AGO,
Objectifs:	Cas d’étude Usine de Morrocoy

Attention

Ce compte rendu est un document de travail et n’est pas contractuel.

Nouvel intervenant, directeur de l’usine à Morrocoy :
_ Eliezer LAEMMEL (ELL) - Morrocoy, Chimiotis
Grâce aux contacts d’AGO, une visite du site chimique de Morrocoy a été organisée opportunément.
Chimiotis, la société gérante désire s’équiper de bissass pour son système d’accès sécurisé.
Il s’agit donc d’un prospect chaud pour iAccess.
Un premier plan sécurité a été créé à partir des informations fournies par Chimiotis.

Fig. 1 : Potentiel plan sécurité pour le site de Morrocoy
Contrairement au stade de Tokyo, le site Morrocoy n’accueille pas de spectateurs.
Un élément important concerne les règles à appliquer en cas d’incendie dans une zone.
Tous les points d’accès doivent être ouverts automatiquement vers l’extérieur dans les zones dites “Incendie Libre” (IL).
Dans les autres zones, un incident est envoyé à tous les gardiens.
Chaque gardien signale qu’il a bien reçu l’incident et peut ensuite consulter si des personnes sont présentes dans la zone et débloquer tel ou tel point d’accès.
Il faudra donc prendre en compte les systèmes à incendie et les interfacer avec iAccess.
Par ailleurs à première vue le nombre de groupes est a priori plus faible à Morrocoy qu’à Tokyo.
Le nombre de badgeurs par groupe va de 1 à 300 environ.
Les ouvriers font les 3 x 8 mais de manière relativement régulière.
Les membres de chaque groupe sont finalement assez stables.
En effet le personnel de l’usine ne change que rarement et les groupes sont basés sur des règles relativement stables dans chaque zone.
Ci-dessous le dernier plan d’autorisation fourni par l’administration de Chemiotis.

Fig. 2 : Plan d’autorisation (simplifié) pour le site de Morrocoy
Les autorisations aux zones sont présentées pour chaque groupe à droite.
A gauche sont représentées les périodes liées à ces autorisations.
Après discussion avec l’administration il apparait qu’il s’agit d’une version très simplifiée.
En effet l’usine devant tourner 24h/24h, 365j/365, des groupes d’ouvriers sont ajoutés pour les jours fériés et les week-ends.
Ces groupes ne sont pas représentés sur le planning annuel montré en CR003Fig2.
Ce planning est représentatif de ce qui se passe chaque année.
Les groupes du planning annuel sont homogènes par rapport aux zones autorisées.
Autrement dit, pour une période un groupe peut accéder toujours aux mêmes zones (cf. CR003Fig2).
En réalité, et selon un exemple donné par ELL, certains groupes (e.g. GX et GY) peuvent accéder à la zone PT et PO en semaine de 8h à 12h pendant l’été.
Mais de plus GX peut en plus accéder à la zone X et DM le week-end de 16h à 23h de mars à avril.
Actuellement tous ces différents cas sont gérés de manière ad-hoc par les gardiens en poste aux points d’accès de chaque zone.
En pratique cette gestion est un peu aléatoire et se base sur le bon-vouloir des gardiens et des employés.
Il faudra absolument définir des autorisations plus fines dans iAccess pour représenter ce genre de périodes.
Une autorisation doit être un triplet (groupe(s), période, zone(s)).
Par exemple, en reprenant l’exemple donné par ELL, on doit pouvoir définir deux autorisations comme suit.

Tab. 1 : Exemple ELL 01-06¶

Groupes Période Zones

GX, GY xxxxxxJASxxx LMMJVxx 08:00-12:00 PT, PO

GX xxMAxxxxxxxx xxxxxSD 16:00-23:00 X, DM
Les autorisations sous forme de triplets pourraient aussi convenir a priori pour le stade de Tokyo en 2020.
Il s’agit en effet d’une représentation générale et sans doute satisfaisante.
Il a été décidé de partir a priori sur ce modèle d’autorisation pour iAccess.
Dans le cas de Morrocoy, il semble qu’un seul administrateur pourrait gérer tous les groupes.
Cela contraste avec le site de Tokyo où plusieurs administrateurs devront gérer des groupes différents et inversement ou un même groupe pourra être géré par des administrateurs différents.
Actuellement l’usine est gardée par 60 gardiens, 24/24.
Avec iAccess on estime que 4 gardiens serait suffisant, d’où 12 en 3x8.
Comme pour les autres sites, le serveur de contrôle serait installé dans la salle de contrôle.
Chemiotis émet également le besoin de pouvoir recevoir des visiteurs via des badges courts.
Dans ce cas les badges courts pourraient être distribués en direct à la réception et utilisés immédiatement.
Actuellement il n’y a aucun système pour les badges courts à Morrocoy.
Il s’agit simplement d’un coup de téléphone donné aux gardiens, ce qui n’est évidemment pas sécurisé.
Chemiotis souhaiterait par contre disposer de l’historique d’accès.
Chemiotis voudrait contrôler les heures de présences dans l’usine des employés.
La conservation de l’historique des événements étant imposée par la réglementation du Venezuela, cette fonctionnalité devra être intégrée dans iAccess.
Un web service permettra à des systèmes externes (e.g. systèmes de paye / de contrôle de présence) d’importer les événements d’accès de iAccess (horaire d’entrée pour chaque point d’accès).
Ce web service devra être sécurisé pour des aspects de confidentialité mais aussi de sécurité (e.g. heures d’accès des gardiens, etc).
A Tokyo, le service web d’export sera utilisé entre autres par les services commerciaux pour déterminer les billets vendus n’ayant pas été utilisés.
Après discussion avec Competis, l’historique d’accès est également nécessaire pour Tokyo vu le grand niveau de sécurité attendu au Japon.
En conclusion, les besoins du site de Morrocoy sont tout à fait pertinents pour iAccess.
AccessIT confirme son intérêt de développer une version de iAccess pour ce site.
Cette version sera la première développée par l’IM2AG.
La prochaine réunion aura lieu comme prévu à Berlin - Bissis.

CR004 Matériels de contrôle d’accès¶

PartiesPrenantes:
Date:	03-15-07h-20h
Type:	Réunion
	KWG, CMS, YBI, MPA, ZSH
Lieu:	Berlin-Bissis
Organisateur:	KWG
Rapporteur:	KWG
Presents:	KWG, CMS, YBI, MPA, ZSH
Objectifs:	Architecture et discussions sur les fonctionnalités gardien

Attention

Ce compte rendu est un document de travail et n’est pas contractuel.

Nouvelles parties prenantes :
_ Clarissa Maris (CMS) - Bissis, Berlin
_ Yohav El Benali (YBI) - Bissis, Berlin
La réunion a eu lieu dans les locaux de Bissis.
Bissis est sur le point de commercialiser des sas de sécurité révolutionnaires.
Ces systèmes physiques seront prochainement commercialisés sous le nom de Bissas.
Bissis souhaite accélérer la mise sur le marché des bissas et souhaite donc intégrer le consortium pour participer à l’élaboration de iAccess.
Il est entendu que Bissis fournira ces Bissas et pour chaque modèle un driver logiciel pour l’intégrer à iAccess
Par contre un problème est vite apparu pendant la réunion.
Il sera impossible de voir les bissas avant au moins deux mois, et cela pour des problèmes de confidentialité.
Vu les très nombreuses innovations, de multiples brevets sont en court d’acquisition et ce procédé est long.
La direction ne souhaite prendre aucun risque de fuites et même en interne seuls certains employés (e.g. YBI) ont une vision globale des bissas tel qu’ils seront présentés dans quelques mois.
Après quelques échanges et discussions animées, il est apparu que ce ne devrait cependant pas être un problème pour iAccess.
Bissis fournira des simulateurs pour que puissent commencer les tests lorsque nécessaires.
Toutes les parties logicielles sur le serveur applicatif pourront être réalisées en amont grâce à la simulation des bissas et des caméras pilotées par les drivers à installer sur le serveur de contrôle.
AccessIT, qui travaille depuis longtemps avec Bissis, est confiant dans cette démarche.
L’utilisation d’une spécification UML a été soulignée comme un point essentiel dans ce contexte tendu.
Il a été convenu que l’IM2AG fournirait rapidement des scénarios qui serviront à écrire les tests de la version pour Morrocoy.
Il s’agit non seulement de tester les scénarios de passage sans incident, mais aussi les scénarios générant des alarmes envoyées aux gardiens.
En ce qui concerne les fonctionnalités des bissas, Bissis a proposé une illustration via l’étude d’un système proposé par un de ses concurrents.
Les bissas ressembleront par certains côtés au système “Cilindro Bibussola” de AllUserIndustrie:

Fig. 1 : “CILINDRO BIBUSSOLA” par AllUserIndustrie (cf VideoBibussola)
Le Bibussola n’est là qu’à titre d’illustration ; les bissas ont de nombreuses différences.
Des groupes de 2 à 16 bissas peuvent être alignés par point d’accès.
Le matériel est extrêmement performant (à condition que les contrôles logiciels suivent).
Ceci permet des flux importants à un même point d’accès (jusqu’à 100 passages/mn).
Les bissas sont symétriques
Ils possèdent systématiquement des lecteurs sur les deux faces (contrairement aux Bibussolas).
Ils peuvent ainsi contrôler à la fois l’entrée et la sortie.
Ce qui permet à tout moment être capable de savoir qui est dans une zone.
Cette fonction est nécessaire entre autres pour ne pas dépasser le nombre maximum de personnes autorisées par zone.
Si une zone est pleine, une alerte devra être générée pour qu’un affichage le signale et que les gardiens soient prévenus de venir expliquer la situation.
Les lecteurs des bissas sont polyvalents et permettent plusieurs types d’identification.
Ils lisent différents types de badges papier, par exemple des QR codes.
Ils peuvent lire également des cartes classiques ou sans contact (jusqu’à 1m).
Quel que soit le type de badge, les informations envoyées par le driver du bissas au serveur de contrôle sont toujours identiques.
La première information est le numéro du point d’accès dans le site.
La seconde information est le numéro du bissas dans ce point d’accès
La troisième information est la face sur laquelle le badge a été lu (A ou B).
La dernière information est le “bCode” (code badge) lu par le lecteur de badge.
Les lecteurs sont équipés de deux leds (une rouge et verte).
Deux détecteurs de chaque côté permettent au bissas de signaler lorsqu’une porte arrive en position ouverte ou en position fermée.
Tout comme le Cilindro Bibussola, les bissas possèdent un détecteur de présence à l’intérieur du sas.
A chaque fois qu’une porte est refermée, il détecte l’absence ou la présence d’une personne et si du métal est présent en retournant Void, OK ou M.

Fig. 2 : Incident de « piggybacking (cf VideoBibussola seconde 52)
En fait les bissas sont entièrement contrôlés par le driver fourni par Bissis.
Ces drivers seront installés sur le serveur de contrôle.
Chaque bissas sera connecté au panneau de brassage du serveur de contrôle par une connexion RFC 821
Bissis propose deux types de bissas, les bissas Astra et les bissas Xtra.
Les bissas Astra sont destinés à recevoir un public important.
C’est pour cela que AccessIT préconise leur utilisation au stade de Tokyo.
Les bisas Xtra sont écartés car leur débit est insuffisant.
Les bissas Astra permettent entre autres d’organiser des files d’attentes uniques par point d’accès.
Ils sont munis d’un feu visible depuis la file indiquant l’état du bissas (disponible = vert, rouge = utilisé, orange = bientôt libre).
Ce feu tricolore permet de montrer le prochain bissas Astra disponible (voyant orange).
Pour cela, un détecteur de présence à l’intérieur fait passer le feu à l’orange lorsqu’un badgeur est entré dans le bissas et que la seconde porte s’ouvre.
En fait, une fois de plus, ce genre de fonctionnalités est prédéfini et intégré au bissas et ne sont pas commandés par le driver de Bissas depuis le serveur de contrôle.
AccessIT insiste de nouveau sur le fait que différents scénarios devront donner lieu à des incidents envoyés aux gardiens.
C’est le cas par exemple si un badgeur ne sort pas du sas au bout de 8 secondes.
C’est également le cas si quelqu’un bloque une porte (avec un pied ou autre).
Bissis propose aussi des bissas haute sécurité, les bissas Xtra.
Ces bissas sont préconisés par AccessIT pour l’usine de Morrocoy.
Ils permettent d’être sûr (à 98%) que le badgeur est bien la personne associée au badge.
La personne ne peut en effet sortir du sas qu’après avoir effectué une identification physique.
Cette identification physique se fait à l’intérieur du sas, après l’identification badge à l’entrée.
L’identification physique est une empreinte digitale
Si la personne n’est pas autorisée un incident système sera généré par le bissas Xtra.
Il en sera de même si le détecteur de métaux intégré dans les Xtra se déclenche.
Le badgeur sera alors bloqué dans le sas et devra attendre qu’un gardien vienne le débloquer.
Une fois de plus Bissis propose le matériel pour permettre cela, mais les fonctions devront être réalisées sur le serveur de contrôle en fonction des informations émises par les bissas.
Evidemment les digitCodes transmis par le lecteur d’empreinte digitale devront être comparés aux données disponibles sur le serveur applicatif.
Dans iAccess ce sont les administrateurs de groupes qui seront chargés, en plus de la délivrance des badges selon la procédure normale, de collecter les empreintes digitales des badgeurs.
L’identification physique des badgeurs dans un Xtra devra se faire en moins de 5 secondes.
L’identification des badges et surtout le calcul des autorisations lors d’un passage de badge devra toujours pouvoir être faite en moins de 2 secondes.
Sachant que l’on envisage plus de 200 entrées ou sorties simultanément un soin tout particulier devra être apporté à cet aspect.
Bissis propose également d’autres éléments matériels pour la sécurité.
Des caméras directionnelles C800 pourront être installées comme option d’iAccess.
Les gardiens devront pouvoir à tout moment les réorienter à distance.
Les plans de sécurité proposés par AccessIT pour Morrocoy et Tokyo sont déjà basés sur l’utilisation de ce matériel.
Cependant pour des raisons de délai, les caméras ne seront pas connectées à iAccess pour la première version du logiciel
Les bissas doivent être reliés au serveur de contrôle du site via des liaisons “RFC 321”; les caméras via des liaisons “RFC 821”.
Le matériel et les protocoles associés sont en cours d’être brevetés par Bissis.
Il doit y avoir une salle de contrôle par site ; elle contient le serveur de contrôle.
Il s’agit d’un matériel spécialisé quasi temps réel auquel de multiples câbles sont connectés sur un panneau de brassage (jusqu’à des centaines sur certains sites).
Ce serveur de contrôle devra être connecté au serveur applicatif via une liaison TCP/IP sécurisée.
Seuls les gardiens doivent avoir accès à la salle de contrôle.
En conclusion de cette réunion (longue), il apparaît clairement que les technologies innovantes proposées par Bissis en font un partenaire idéal.
De plus, le matériel n’étant pas disponible à ce jour, il est essentiel de préparer les scénarios à prendre en compte et de les spécifier de manière rigoureuse.
Bissis fournira des simulateurs matériels pilotables par le driver fourni.
Dans un premier temps des tests seront ainsi effectués à partir des scénarios fournis par IM2AG.
Une réunion est prévue (03-18) pour discuter des points non abordés jusque-là et notamment de l’architecture de déploiement.

CR005 Architecture et contraintes techniques¶

PartiesPrenantes:
Date:	03-18 12h-17h
Type:	Réunion
	ABI, HSI, KWG, MPA, PSO
Lieu:	Paris-AccessIT
Organisateur:	ABI
Rapporteur:	KWG
Presents:	ABI, HSI, KWG, MPA
Objectifs:	Définir l’architecture et revenir sur les fonctions associées à chaque noeud.

Attention

Ce compte rendu est un document de travail et n’est pas contractuel.

AccessIT rappelle l’architecture classique des applications déjà mises en place par leur soin.
Il n’y a aucune raison a priori de changer d’architecture sachant qu’elle fonctionne bien dans différents contextes.
Les matériels sécurité (bissas, caméras, etc.) sont toujours connectés directement au serveur de contrôle.
Ce serveur permet de gérer en temps réel les matériels en les commandant par leur driver
Le serveur d’applications doit être plus ou moins puissant selon le volume de données à gérer et le nombre de transactions à mettre en œuvre.
Pour les sites de Tokyo ou de Morrocoy, il n’y aura a priori pas de soucis, mais AccessIT a déjà eu affaire à des sites avec plus de 800 points d’accès, 80 000 badgeurs, avec des historiques à conserver sur 5 ans (base militaire en Sibérie).
De tels clients devront pouvoir être gérés avec iAccess.
Contrairement aux architectures traditionnelles, il n’y aura pas de poste fixe pour les gardiens.
Les gardiens seront équipés de smartphones pour gérer les incidents.
C’est un grand changement car jusque-là des appareils spécialisés ou des postes fixes étaient utilisés.
Les applis des smartphones des gardiens seront connectées au serveur applicatif via une connexion sécurisée https et un réseau wifi interne sécurisé.
AccessIT mentionne qu’il est possible d’installer des systèmes de brouillage et bien d’autres choses, qui rendent ce réseau à la fois sûr et fiable.

Fig. 1 : Smartphones des gardiens
Les incidents doivent être localisés (e.g. bissas, point d’accès et/ou zone) et gardés dans l’historique.
Lorsqu’un gardien prend un incident, celui change d’état (“nouveau”->”affecté”).
En fonction des cas, et la plupart du temps après s’être rendu sur place, le gardien peut agir sur l’incident pour l’ignorer ou le régler.
Un incident ignoré ou réglé est considéré comme fermé mais peut encore être commenté, en lui associant du texte, des photos ou de l’audio/vidéo.
Le règlement d’un incident dépend des cas.
En cas d’incident d’accès, le gardien peut fermer ou ouvrir une des portes du bissas (ou les deux) depuis sa tablette.
En cas d’incident d’incendie, le gardien peut déverrouiller un ou plusieurs bissas dans le sens de la sortie.
Quand le bissas est déverrouillé, la simple détection d’une personne devant le bissas l’ouvre le bissas et il est refermé une fois qu’elle est passée.
En situation de crise, le temps de réaction des gardiens peut devenir essentiel.
Pour améliorer la rapidité d’intervention des gardiens, iAccess fournira dans une seconde version un paramétrage avec des types d’incidents prédéfinis.
C’est le rôle des superviseurs de les définir et cela se fait généralement lors de la définition du plan sécurité initial en fonction des caractéristiques du site.
Assez souvent on découvre par la suite de nouveaux types liés à des situations répétitives (e.g. “tuyau percé” dans une usine, “malaise dans un bissas” dans un hôpital, “cartable coincé dans un bissas” dans une école, etc.).
Les gardiens peuvent alors sélectionner les types d’incidents correspondant à la situation.
Evidemment si nécessaire les gardiens peuvent utiliser la fonction téléphone de leur smartphone pour appeler les services compétents (urgences, police, armée, etc.)
La discussion sur le rôle des gardiens s’est achevée sur la conclusion suivante.
L’IHM des gardiens doit être particulièrement ergonomique vu le contexte d’utilisation à la fois quotidien et potentiellement intensif.
_
En ce qui concerne le poste superviseur (toujours un seul, pour des raisons de sécurité) et les postes administrateurs (autant que nécessaire), ceux-ci seront également connectés au serveur applicatif par une liaison Ethernet, avec un client lourd utilisant le protocole https.
Il s’agit dans les deux cas de PCs sous LINUX.
_
Les administrateurs gèrent non seulement les inscriptions des badgeurs, mais aussi les problèmes liés à la perte d’un badge.
Lorsqu’un badge est perdu, volé (y compris via agression), le badgeur est tenu d’en informer immédiatement le centre de sécurité.
Cela ne concerne pas les tickets avec des badges papier, qui sont gérés directement par la société qui les vend.
Quel que soit le type de badge, un badge est toujours associé à une seule personne à la fois et une personne ne peut posséder qu’un badge (pour un site) à un moment donné.
Les badgeurs sont connus au minimum par leur nom et leur prénom et un numéro d’identité national (NIN).
Le NIN utilisé dépend des personnes et des pays considérés.
Ce peut être le numéro de passeport, le numéro de carte d’identité ou tout autre document selon le pays.
Un mail et deux numéros de téléphone peuvent également être renseignés lors de l’enregistrement.
A chaque fois qu’un badge est donné à quelqu’un, qu’il est annulé suite à une perte ou un vol, l’opération doit être enregistrée dans l’historique.
Toutes ces opérations sont effectuées par les administrateurs de groupes.
Lorsqu’un badgeur appartient à plusieurs groupes, et si ces groupes sont gérés par différents administrateurs, n’importe quel de ces administrateurs peut gérer la perte du badge.
Finalement, le serveur applicatif est le seul élément de iAccess a être connecté à internet via tcp-ip.
C’est lui qui gèrera les web-services mentionnés auparavant.
_
Il est fait état d’un démarrage éminent de la phase de collecte des exigences.
Les spécifications UML seront faites par le groupe M1 MIAGE au sein de l’IM2AG à partir des comptes rendus de réunions réalisés jusque-là.
Les personnels de la société AccessIT ne seront pas disponibles dans les semaines qui viennent.
Il risque d’en être de même des membres IM2AG ayant participé à ces réunions, un voyage en Russie puis en Irlande étant prévu pour le prochain mois.

Ce contenu est disponible sur le site http://CyberBatiment.readthedocs.org

Tab. 1 : Exemple ELL 01-06¶
Groupes	Période	Zones
GX, GY	xxxxxxJASxxx LMMJVxx 08:00-12:00	PT, PO
GX	xxMAxxxxxxxx xxxxxSD 16:00-23:00	X, DM