CCTP. Système de Contrôle d accès. Aéroport de Lorient Bretagne Sud

(1)

CCTP

Système de Contrôle d’accès

Aéroport de Lorient Bretagne Sud

(2)

SOMMAIRE

1. GENERALITES ... 4

1.1. G

UIDE DE LECTURE DU DOCUMENT

... 4

1.2. A

CRONYMES

... 5

2. DOCUMENTS DE REFERENCE (REF) ... 7

2.1. O

BJET DU PARAGRAPHE

... 7

2.2. D

OCUMENTS METIERS

(A) ... 7

2.3. D

OCUMENT

G

ENERAUX

(B) ... 7

2.4. D

OCUMENT

STITCH (C) ... E

RREUR

! S

IGNET NON DEFINI

. 2.1. D

OCUMENT

STAC (D) ... 7

3. PRESTATIONS A COUVRIR ... 8

3.1. F

OURNITURES

... 8

3.2. I

NSTALLATION

... 8

3.3. P

ARAMETRAGE

... 9

3.3.1. Essais ... 9

3.3.2. Formation ... 9

3.4. D

OCUMENTATION

... 9

4. EXIGENCES FONCTIONNELLES ... 10

4.1. O

BJET DU PARAGRAPHE

... 10

4.2. F

ONCTIONNALITES

... 10

4.2.1. Généralités ... 10

4.2.2. Qualité générale du système : compatibilité, pérennité, sécurité,… (Base) ... 10

4.2.3. Fonctionnalités « Création, édition, annulation, recherche multicritère de titres d’accès (A) » ... 12

4.2.4. Fonctionnalité « Paramétrage des accès » (B) ... 13

4.2.5. Fonctionnalité « Gestion des classes d’accès » (C) ... 15

4.2.6. Fonctionnalité « Gestion et visualisation des alarmes (D) » ... 15

4.2.7. Fonctionnalité « Visualisation sur des synoptiques graphiques de l’état des accès et des équipements (G) » 17 4.2.8. Fonctionnalité « Gestion des opérateurs et des postes de supervisions (H) » ... 18

5. EXIGENCES DE CONCEPTION (CONC) ... 18

5.1. O

BJET DU PARAGRAPHE

... 18

5.2. D

IMENSIONNEMENT

(A) ... 18

5.3. UTL (B) ... 18

5.4. T

ETES DE LECTURE

(C) ... 20

5.5. B

ADGES

(D) ... 21

5.6. P

ERFORMANCES

/ R

ESILIENCE

(E) ... 21

5.7. H

ORODATAGE

(H) ... 22

6. EXIGENCES DE COMPATIBILITE AVEC STITCH (COMP) ... 23

6.1. O

BJET DU PARAGRAPHE

... 23

6.2. A

PPLICATION

STITCH (A) ... 23

6.2.1. Généralités ... 23

6.2.2. Exigences ... 23

7. EXIGENCES D’INSTALLATION, DE CONFIGURATION ET DE MISE EN ŒUVRE ... 23

7.1. G

ENERALITES

... 23

7.2. P

OSITIONNEMENT DES EQUIPEMENTS

(A) ... 23

7.2.1. Généralités ... Erreur ! Signet non défini. 7.2.2. Exigences ... 23

7.3. C

ABLAGE

(B) ... 24

(3)

7.3.1. Généralités ... 24

7.3.2. Exigences ... 24

7.4. B

ASCULE ANCIEN

/

NOUVEAU SYSTEME

(C) ... 25

7.4.1. Généralités ... 25

7.4.2. Exigences ... 25

7.5. R

EPRISE DE DONNEES

(D)... 25

7.5.1. Généralités ... 25

7.5.2. Exigences ... 26

8. EXIGENCES LOGISTIQUES (LOGI) ... 27

8.1. M

AINTENANCE

(A) ... 27

8.1.1. Généralités ... 27

8.1.2. Exigences ... 27

(4)

1. Généralités

1.1. Guide de lecture du document

Ce document liste les exigences caractérisées par trois niveaux d’importance :

• Primordiale (P) : Si l’exigence n'est pas réalisée, le système ne pourra pas remplir sa mission

opérationnelle prioritaire et ne pourra être conformes aux critères de certification des systèmes de contrôle d’accès aéroportuaires.

• Importante (I) : Cette exigence est normalement nécessaire pour que le système puisse

remplir ses missions dans de bonnes conditions, toutefois si ses conséquences (en particulier financières) sont trop lourdes, on peut envisager une certaine dégradation sans que celle-ci soit, à elle seule, rédhibitoire.

• Facultative (F) : Cette exigence n’a pas de caractère obligatoire. Elle identifie généralement

une fonctionnalité qui revêt un caractère optionnel qui peut être liés à des aspects de facilitions,

confort ou esthétique.

(5)

1.2. Acronymes

Acronyme Signification

AES Advanced Encryption Standard

ANSSI Agence Nationale de la Sécurité des Systèmes d’Information BBC Bâtiment Basse Consommation

BBG Boîtier Bris de Glace

BP Bouton Poussoir

CCTP Cahier des Clauses Techniques Particulières CSPN Certification de Sécurité de Premier Niveau CEM Compatibilité ElectroMagnétique

CSPN Certification de Sécurité de Premier Niveau CVE Common Vulnerabilities and Exposures DOE Dossier d’Ouvrage Exécuté

EAL Evaluation assurance Level GCA Gestionnaire de Contrôle d’Accès GTB Gestion Technique du Bâtiment HQE Haute Qualité Environnementale HSM Hardware Security Module

HTTPS Hyper Texte Transfer Protocol Secure IMS Interruption Maximale de Service LDAP Lightweight Directory Access Protocol MCS Maintien en Condition de Sécurité

MDP Module de Porte

OIV Organisme d’Importance Vitale

(6)

OS Operating System (système d’exploitation)

PCZSAR Partie Critique des Zones de Sûreté à Accès Réglementé PIF Poste d’Inspection Filtrage

PIV Point d’Importance Vitale POTL Porte Ouverte Trop Longtemps RFID Radio Frequency Identification

RGS Référentiel Général de Sécurité (de l’ANSSI) RoHS Restriction of Hazardous Substances

SCA Système de Contrôle d’Accès ou Serveur de Contrôle d’Accès SGITA Système de Gestion Informatisé des Titres d’Accès

SAM Secure Access Modul

SI Système d’Information

SSH Secure SHell

STAC Service technique de l’Aviation civile

STITCH Système de Traitement Informatisé des Titres de Circulation et des Habilitations TCA Titre de Circulation Aéroportuaire

TOR Tout Ou Rien

UTL Unité de Traitement Local VLAN Virtual LAN (Réseau virtuel)

VPN Virtual Private Network : Système permettant d’établir un lien sécurisé direct entre deux entités informatiques distantes

ZSAR Zones de Sûreté à Accès Réglementé

(7)

2. Documents de référence (REF)

2.1. Objet du paragraphe

L’objet du paragraphe est d’identifier un certain nombre de documents qui peuvent être utilisés pour être mis en référence et où figurent les descriptions techniques plus détaillées.

Les documents sont listés par domaine et une rapide description du rôle et contenu du document est donné en ‘Observations’.

Il appartient au rédacteur de faire référence aux seuls documents qui lui sont nécessaires sans insérer l’ensemble des documents présentés ici.

2.2. Documents métiers (A)

Numéro Référence du document Observations

REF-A-1 NF C 15.100

La norme française NF C15-100 réglemente les installations électriques en basse tension en France.

REF-A-2 NF C 15.103

Relative aux indices de protection (IP) et résistance aux chocs mécaniques des matériels à utiliser.

2.3. Document Généraux (B)

REF-B-1 Guide sur la sécurité des technologies sans contact pour le contrôle des accès physiques, ANSSI, 2012

REF-B-2 Référentiel Général de Sécurité v2.0, ANSSI, 2014 Cryptage minimum : AES128 bits sur bus RS485, TLSv1.2 sur IP

REF-B-3 Note DAT-NT-004/ANSSI/SDE/NP relative à la télé assistance

REF-C-4 STITCH_SPE_Specification_technique_badges_v1.8 - Diffusable Internet, KLEE – DGAC, 2016

Document réalisé dans le cadre du projet STITCH et décrivant de manière précise la structuration du mapping de mémoire de la puce DESFire. Il décrit également l’emploi des différentes clés destinées

2.1. Document STAC (D)

REF-D-1 Guide d’aide à la migration vers la technologie MIFARE DESFire

(8)

3. Prestations à couvrir

Le présent marché comprend les prestations suivantes :

•

Remplacement du système de contrôle d’accès MSPASS par un système de type MIFARE®

DESFire EV1 ou EV2, avec serveur virtualisale VMware et MSphere avec licence SMI serveur

• Interconnection du système DESFire avec le système STICH existant en reletion avec

• Remplacement des 6 lecteurs de badges de type MSPASS existants, par un système de

contrôle répondant aux normes décrites ci-dessous (badge de type

MIFARE^® DESFire EV1 ou EV2)

, compatible avec le logiciel STITCH permettant la gestion des titres de circulation aéroportuaire, ainsi que leur tête de lecture.

• Installation de 2 lecteurs de badges supplémentaires (local informatique et local STITCH) avec

système de fermeture de portes par ventouse (variante pour système de fermeture par serrure électromagnétique).

• Fourniture et pose d’un tambour de hauteur totale type ROTASEC 120 simple version ou

équivalent avec un lecteur de badges

MIFARE^® DESFire EV1 ou EV2

uniquement en entrée (sortie libre) ainsi que les travaux de génie civile s’y afférant et ainsi que les câblages nécessaires.

•

Dépose et enlèvement de l’ancien système 3.1. Fournitures

Ce paragraphe décrira les matériels et logiciels qui seront fournis par le titulaire au titre de ce contrat. Il inclura par exemple :

• Le poste de supervision, le serveur applicatif virtualisable sur environnement VMware

Vsphere, les logiciels associés (système d’exploitation, produit de contrôle d’accès, …) permettant la supervision et la gestion ainsi que la base de données des personnes ;

•

L’ensemble des matériels nécessaires à l’équipement et au raccordement des accès ;

• Les dispositifs de fermeture électrique par serrure électromagnétique adaptés aux

caractéristiques de l’accès (nombre 2)

•

L’ensemble des équipements électriques (coffrets de puissance, protection, borniers de raccordement, départs, auxiliaires de commandes et de signalisation, …) nécessaire à l’alimentation, au contrôle et au raccordement du tambour;

•

L’ensemble des câblages et chemins de câble nécessaire au raccordement des matériels;

3.2. Installation

Ce paragraphe décrit les exigences concernant l’installation du système, à charge du prestataire.

•

Le repérage, l’étiquetage et l’identification des équipements et câblage fournis ;

(9)

• L'amenée, l'établissement et l'enlèvement de tous les appareils, engins et échafaudages

nécessaires ;

• Les outillages et appareils spécifiques nécessaires au montage, démontage et réglage de

l’installation ;

• La réalisation des lignes provisoires pour l'alimentation de ses outils ;

•

Le transport sur site, la manutention, le stockage de l’ensemble du matériel ;

• La protection des installations pendant toute la durée du chantier ;

3.3. Paramétrage

Le système devra permettre les paramétrages suivants :

• Les classes d’accès à créer ;

•

Les profils d’accès (zones accessibles sur tranche horaire spécifique) ;

• Les groupes de lecteurs.

3.3.1. Essais

La mise en service prévoira une phase de test et essais en présence de personnel de l’aéroport 3.3.2. Formation

Le prestataire prévoira une formation pour au minimum 2 personnes de l’exploitation aeroport :

• Administration du système (SI, intégration, installation, passerelles, droit opérateur du

système)

• Utilisation du système ;

• Maintenance su système.

3.4. Documentation

Au titre de la prestation d’installation ou de rénovation du contrôle d’accès, le prestataire prévoira :

• La fourniture du Dossier des Ouvrages Exécutés (DOE) et sa mise à jour durant la période de

garantie ;

• La fourniture du manuel d’utilisation, des fiches produits du système mis en place.

•

Le guide d’administration et mise_en_sécurité du système et ses pré-requis informatiques

(ports, OS, BDD,…)

(10)

4. Exigences fonctionnelles

4.1. Objet du paragraphe

Ce paragraphe a pour objectif de décrire les exigences fonctionnelles attendues du produit. Il devra inclure des prestations pour la mise en œuvre du système STITCH.

4.2. Organisation retenue pour l’élaboration des badges

Les badges seront réalisés à partir du système STITCH existants qui sera reparamétrés par la DGAC/STAC.

4.3. Fonctionnalités

4.3.1. Généralités

L’objet de ce paragraphe est de spécifier les fonctionnalités qui peuvent être attendues d’un système de contrôle d’accès.

Ces exigences fonctionnelles portent sur :

• Qualité générale du système : compatibilité, pérennité, sécurité,… (BAS) ;

•

Création, édition, annulation, recherche multicritère de titres d’accès (A) ;

• Paramétrage des accès (B) ;

•

Gestion des classes d’accès (C) ;

• Gestion et visualisation des alarmes (D) ;

• Contrôle à distance des accès (E) ;

•

Visualisation en temps réel des sollicitations du système de contrôle d’accès (F) ;

•

Visualisation sur des synoptiques graphiques de l’état des accès et des équipements (G) ;

• Gestion des opérateurs et des postes de supervisions (H) ;

• Création, édition et établissement de tableaux de bord statistiques (I) ;

• Gestion des identifiés, personnes porteuses des badges (J).

4.3.2. Qualité générale du système : compatibilité, pérennité, sécurité,… (Base)

Dans tous les cas, le système de sûreté et son constructeur offriront les caractéristiques et

possibilités suivantes à des fins de pérennité, d’efficacité et de sécurité.

(11)

Numéro Importance Exigence type Observations

FONC-

BAS-1 P

Compatibilité ascendante : Le constructeur du système devra respecter une politique de compatibilité ascendante de ses produits sur au moins 10 ans pour garantir la pérennité de l’investissement. Il devra le démontrer en indiquant quels sont les automates compatibles, avec les dates de début et fin de commercialisation, avec la version du système proposé pour ce projet. Cette version doit être la plus récente mise en vente. Il sera exclu toute version antérieure.

FONC-

BAS-2 P

Ouverture : Le système sera compatible avec des technologies d’identification diverses (badges DGAC, biométrie, lecture de plaques minéralogiques, etc...). Il permettra également de gérer les alarmes techniques, intrusion et de les superviser.

FONC-

BAS-6 P

Maintenabilité : Le système permettra une gestion intelligente de la maintenance (envoi d’emails, télé-maintenance, etc...). Le constructeur de la solution proposée doit être capable de proposer un support téléphonique.

FONC-

BAS-7 P

Développement durable – Environnement : Pour être en conformité avec la volonté et les engagements RSE (Responsabilité Sociétale et Environnementale) de l’ALBS, les produits proposés devront avoir un impact environnemental réduit, notamment avec :

• une puissance et consommation électrique faible pour minimiser la taille des batteries, le diamètre des câbles,… (Maximum de : 100 mA pour les UTL / automates centraux soit moins de 1 W, 60 mA pour les modules déportées, 100 mA pour les lecteurs)

• une conformité aux Directives européennes RoHS, CEM obligatoires en Europe

• des références réalisées dans des bâtiments BBC HQE

FONC-

BAS-8

^P

SI du système : Afin d’assurer l’ouverture, l’évolutivité et la puissance du système proposé, ce dernier devra au minimum supporter les bases de données Microsoft SQL Server 2012 64 bits ou SQL Server 2014 64 bits ou SQL Server 2016 64

(12)

bits selon taille de la base de données et avoir une véritable architecture client-serveur. Les systèmes fonctionnant avec des bases de données propriétaires seront exclus. Idem le système devra fonctionner sous l’OS Windows Server 2016 Standard Edition, ou Windows Server 2012 R2 Standard Edition.

FONC-

BAS-9 P

Sécurité du système : Le système retenu devra être certifié CSPN (Certification de Sécurité de Premier Niveau) de l’ANSSI. Cette exigence de sécurité doit permettre d’avoir un système qui respecte ses principes :

• La solution devra être sécurisée de bout en bout, du badge jusqu’au serveur ;

• Toutes les communications sur réseau IP cryptées TLS v1.2 avec certificats (intégrité et authentification) entre le serveur et les UTL d’une part et les postes clients d’autre part,

• Les communications sur le bus RS485 seront cryptées AES 128 bits et signées,

• Le client final aura obligatoirement la maîtrise de sa clé de communication du bus RS485 et de ses clés pour toutes les applications du badge DGAC (accès, restaurant,…) par la saisie, sur un poste client lourd, de ses clés (cérémonie des clés) obligatoirement sur une seule IHM conçue pour cet objectif. Cette IHM devra permettre obligatoirement de gérer toutes les clés avec une notion de site / organisme possible par clé pour pouvoir différencier les clés par site / organisme,

• Le principe de diversification des clés devra pouvoir être disponible, activable selon le guide de l’ANSSI.

4.3.3. Fonctionnalités « Création, édition, annulation, recherche multicritère de titres d’accès (A) »

FONC-A-3 P

Les opérateurs autorisés du système de contrôle d’accès doivent pouvoir rechercher un ou plusieurs titres d’accès selon l’ensemble des critères caractérisant un titre d’accès.

FONC-A-4 P

Les recherches multicritères doivent pouvoir porter sur les mouvements enregistrés sur une période minimale de un mois

(13)

4.3.4. Fonctionnalité « Paramétrage des accès » (B)

FONC-B-1 I

L’application de contrôle d’accès doit permettre la gestion des droits d’accès d’un titre dans des classes d’accès.

Ces classes d’accès pourront être constituées de lecteurs, de groupes de lecteurs.

La gestion de plages horaires autorisées doit être possible pour chaque classe d’accès parmi au moins 32 plages horaires possibles dans le système

I

L’attribution des droits d’accès aux usagers pourra se faire de deux façons différentes qui peuvent se cumuler :

Gestion individuelle

Les droits d’accès se feront usager par usager par :

• l’attribution de lecteurs, de niveaux ascenseur, ou de groupes de lecteurs et/ou de niveaux ascenseur,

• l’affectation d’une plage horaire pour chaque lecteur, niveau ascenseur ou groupe,

• une date de début et de fin de validité pour chaque attribution de droits.

Gestion multi-classes

A chaque usager, il sera possible d’associer une (ou plusieurs) classes d’accès. Il sera ainsi possible d’associer une classe d’accès générale (droit d’accès incluant plusieurs groupes, lecteurs, niveaux d’ascenseur) à plusieurs personnes ayant les mêmes droits d’accès.

Chaque lecteur, niveau ascenseur, groupe et classes d’accès, attribué à un usager, pourra également être associé à une date de début et de fin de validité qui s’ajoute à celle définie pour l’usager. Un niveau de priorité permettra de définir les accès autorisés.

Le système devra obligatoirement permettre d’associer au moins 4 classes d’accès et/ou groupes d’accès par usager pour s’adapter à la

Cela permettra de gérer notamment des missions temporaires. Un usager pourra ainsi avoir plusieurs profils actifs en même temps.

(14)

diversité des types d’usagers et réduire le nombre de classes d’accès à créer et à exploiter.

FONC-B-3 I

In fine, il sera possible visualiser facilement, par usager, la liste de tous les lecteurs et niveaux ascenseur résultants issus de l’attribution des lecteurs, niveaux, groupes et classes d’accès.

FONC-B-4 I

Les fonctions de sécurité avancée (anti-retour, contrôle renforcé, code sous contrainte, double badgeage, SAS, mode crise / Vigipirate avec au moins 7 niveaux, etc…) seront disponibles dans la solution technique retenue. Ces fonctions pourront avoir un caractère permanent ou conditionnel (par exemple : gestion de mode crise sur activation d’un opérateur habilité, etc...).

Ceci permet d’offrir une adaptabilité aux besoins d’aujourd’hui ou de demain.

FONC-B-5 P

Le logiciel ne doit pas interdire le déverrouillage des accès par commandes manuelles (clé, coup de poing, etc.).

FONC-B-6 P

Dans tous les cas, les demandes de commandes d'ouverture et fermeture doivent faire l'objet d'une information enregistrée par le système, en précisant l'origine de la commande (opérateur), à l'exception des dispositifs anti-panique du type « coup de poing », où seule l'information de début et fin doit être enregistrée.

FONC-B-7 I

Le logiciel doit permettre d'autoriser l'accès ponctuellement à une ou plusieurs zones à un détenteur de badge en traçant l’ensemble des éléments de l’opération.

FONC-B-8 I Le système doit permettre d'effectuer des recherches sur la configuration opérationnelle.

FONC-B-

11 I

la fonction « anti pass-back » (permettant que le badge ne donne à nouveau l'entrée que lorsqu'il a été enregistré en sortie.) lorsqu’elle est intégrée doit pouvoir être désactivée.

FONC-B-

12 I

Le logiciel doit permettre à un détenteur de droits particuliers de s'affranchir de la fonction « anti pass-back ». L'autorisation d'accès doit être accompagnée d'un message particulier traçant l'utilisation de ce privilège.

Ex : pour les pompiers, secours

FONC-B-

13 F

Le logiciel doit permettre d’empêcher l’accès à une zone incluse dans une autre si la personne n’a pas préalablement badgé à l’entrée de la première zone. Exemple : l’accès à la zone

(15)

blanche n’est possible qu’après avoir badgé pour entrer dans la zone orange.

FONC-B-

14 F

Le logiciel doit posséder une fonction qui interdit l'accès à une zone, à une personne qui n'a pas été vue sortir de la zone où elle était préalablement localisée (cette fonction ne s'applique qu'aux zones ayant un lecteur en entrée ou en sortie).

FONC-B-

15 F

Le logiciel doit traiter le passage effectif : « la personne ayant badgé n'est considérée dans la zone que lorsqu'elle a vraiment pénétré dans cette zone, et non pas lors de la présentation de la carte d'accès ».

4.3.5. Fonctionnalité « Gestion des classes d’accès » (C)

FONC-C-1 I

L’application de contrôle d’accès doit permettre de paramétrer les différents lecteurs ainsi que la configuration du système en termes d'équipements des accès :

• adjonction de nouveaux lecteurs,

• gestion de plages horaires,

• gestion de groupes de lecteurs,

• paramètres de temporisation,

• durée d'impulsion gâche,

• sensibilité d'un capteur,

• paramétrage des modes dégradés,

• création de plans de synoptique

• gestion de groupes de lecteurs

• gestion de classes d’accès composées de un ou plusieurs lecteurs et/ou de un ou plusieurs groupes de lecteurs

4.3.6. Fonctionnalité « Gestion et visualisation des alarmes (D) »

FONC-D-1 P La datation sera effectuée au plus près de l’évènement ou de l’alarme c’est à dire sur les

(16)

UTL obligatoirement dont l’heure sera régulièrement mise à jour par le serveur

FONC-D-2 P Le logiciel doit rendre obligatoire la procédure d'acquittement des alarmes.

FONC-D-3 P

Le système doit permettre de suivre l’évolution de l’état des alarmes : date et heure de l'apparition, description, localisation, date et heure de prise en compte par l'opérateur, date et heure de résolution.

FONC-D-4 I

Le logiciel doit présenter les alarmes aux opérateurs dans l'ordre de priorité du niveau le plus élevé au plus faible.

Sur des alarmes prioritaires définies, il devra être possible d’obliger à les acquitter par plusieurs opérateurs de niveau différent (ex : opérateur courant + chef opérateur).

FONC-D-5 I

Une consigne spécifique pourra être attachée à chaque alarme. Cette consigne pourra être affichée à l’agent de protection à chaque apparition de l’alarme.

FONC-D-6 F

Dans un site avec des zones incluses dans d’autres zones, on ne peut ouvrir une zone intermédiaire que si l’on a badgé dans les zones externes.

Principe de la gestion de l’anti- retour géographique et dans des zones imbriquées

FONC-D-7 P

Le logiciel doit traiter et afficher les alarmes en temps réel. Les alarmes doivent être différenciées des événements normaux du système (ex. : accès autorisé…).

FONC-D-8 I

Le logiciel doit permettre d’imprimer les alarmes, événements issus d’une recherche multicritères sur une période minimale de un mois.

FONC-D-

10 I

Dans le cadre d’un fonctionnement normal, différentes alarmes peuvent intervenir :

• Alarme d’exploitation : L’alarme d’exploitation est déclenchée lorsqu’un accès est ouvert trop longtemps (POTL), ou lorsqu’une demande d’accès est refusée, ou lors de la présentation d’un titre d’accès inconnu, déclaré perdu ou volé. Ce type d’alarme doit être aiguillé selon le type et l’accès concerné à un ou plusieurs opérateurs de supervision avec le motif du refus.

(17)

• Alarme technique : L’alarme technique est déclenchée lorsqu’un défaut d’un équipement est signalé ou lorsqu’une armoire technique est ouverte (autoprotection). Ce type d’alarme doit être aiguillé selon son origine à un ou plusieurs opérateurs de supervision.

FONC-D-

11 P Dans tous les cas, l’alarme doit être visualisable sur le poste d’administration.

FONC-D-

12 I

Les opérateurs en charge de la supervision des alarmes peuvent interagir, en prenant en compte l’alarme, en acquittant l’alarme (intervention).

FONC-D-

13 I

L’état d’une alarme est successivement : Alarme nouvelle, Alarme prise en compte, Alarme acquittée, Disparition alarme.

FONC-D-

14 P Une alarme ne peut être acquittée tant que persiste l’état à l’origine de l’alarme.

FONC-D-

15 P

Le système de contrôle d’accès conservera un historique horodaté sur une période minimale de un mois avec une identification des opérateurs des alarmes et des actions entreprises par les opérateurs.

FONC-D-

16 F

Sur tous les postes de supervision, les alarmes doivent êtres visualisables sur un synoptique graphique permettant à l’opérateur de visualiser rapidement l’emplacement et la nature de l’alarme.

Ce synoptique doit être interactif et permettre l’accès à l’état de l’équipement ou de l’accès à l’origine de l’alarme.

4.3.7. Fonctionnalité « Visualisation sur des synoptiques graphiques de l’état des accès et des équipements (G) »

FONC-G-1 F

Le système de contrôle d’accès, à travers son module opérateur, devra permettre l’accès à des synoptiques graphiques affichant en temps réel de l’état des équipements ou des accès visualisés. Ces représentations graphiques doivent être interactives et permettre l’accès à l’état de l’équipement ou de l’accès visualisé.

(18)

4.3.8. Fonctionnalité « Gestion des opérateurs et des postes de supervisions (H) »

FONC-H-1 I

Les fonctions d’administration du système doivent permettre :

• la gestion des opérateurs (création, modification, annulation, fonctions, lecteurs

& classes d’accès autorisés, personnes autorisées à gérer),

• la gestion des droits d’accès : aux postes de supervision, aux fonctionnalités du système, suivant des tranches horaires,

• la gestion des imprimantes,

• la gestion des droits d’accès aux fichiers et à leur consultation.

5. Exigences de conception (CONC)

5.1. Objet du paragraphe

Les exigences de conception définissent ce qui est attendu du produit et des éléments qui le compose en termes de performance et de capacité. Elles spécifient également des attendus de réalisation visant un niveau de sécurisation particulier.

5.2. Dimensionnement (A)

CONC-A-1 I Le système de contrôle d’accès doit permettre de gérer :

Chiffre tient compte des besoins futurs

CONC-A-2 F • 2 postes de travail

CONC-A-2 F • Au minimum 20 portes ou accès d’accès (lecteurs)

CONC-A-3 F • 200 titres d’accès

CONC-A-5 F • 20 alarmes

CONC-A-8 F • 10 classes d’accès

5.3. UTL (B)

(19)

CONC-B-1 P Les UTL sont équipées d’un système de détection d’intrusion et d’arrachage.

CONC-B-2 P

Toutes les UTL devront fonctionner de manière autonome sans perturbation en mode normale comme en mode dégradé en cas de perte de la liaison avec les équipements en amont (serveur, réseau grâce à une base locale d’usager autorisés en accès et intrusion, d’automatismes téléchargés depuis le serveur dans chaque UTL.

CONC-B-3 P

En cas de coupure de liaison avec le serveur de gestion du système, les UTL doivent pouvoir archiver temporairement un nombre d’alarmes ou d’événements compatible avec les exigences (10 000 événements), puis assurer automatiquement une mise à jour différée de l’archivage centralisé quand la communication est rétablie.

CONC-B-4 I

En cas de coupure de liaison avec le serveur de gestion du système, les UTL doivent pouvoir gérer au minimum 200 badges.

CONC-B-5 I

Les UTL possèderont une mémoire (contenant les instructions du traitement) type EPROM (Erasable Programmable Read Only Memory) ou RAM (Random Access Memory) sauvegardée par batterie (24 heures minimum).

CONC-B-6 I

Les UTL doivent être capables de gérer « l'anti pass-back » des lecteurs qui lui sont associés de manière autonome. Les UTL devront obligatoirement dialoguer directement entre elles, sur le ou la partie du réseau Ethernet restant fonctionnelle, pour assurer cette gestion«

l'anti pass-back » si les lecteurs sont réparties sur plusieurs UTL. Il est important d’avoir la meilleure continuité opérationnelle possible en l’absence de serveur et/ou d’une partie du réseau Ethernet

CONC-B-7 I

Les UTL devront avoir une prise IP RJ45 10/100 Mb auto-adaptatif native pour communiquer via le réseau Ethernet (sans convertisseur) avec le serveur.

Cette adresse IP sera IPv4, IPv6 ready, IP fixe.

Paramétrage de la configuration IP à travers un Web serveur embarqué sécurisé HTTPS, ou SSH.

(20)

CONC-B-8 I Les UTL devront gérer des identifiants de 10 octets et un minimum obligatoire de 7 octets.

La longueur de l’UID DESFire est de 7 octets.

CONC-B-9 I

Les UTL et leurs modules déportés seront des automates industriels :

• Fonctionnant à des températures comprises entre -10°C et + 55°C,

• Alimentation de 10 à 28 Vdc,

• Bornier débrochable,

• Entrée universelle paramétrable : TOR, comptage, équilibrée 4 états ou 5 états,

• Relais avec choix entre NO/NF et supportant une charge jusqu’à 2A, 48 Vdc et 48 W,

• Signalisation d’état par LED sur chaque bus, réseau, alim, entrée

CONC-B-

10 I

Les UTL seront compatibles avec un serveur radius, la norme 802.1X via des certificats associés pour authentifier les équipements sur le réseau Ethernet.

CONC-B-

12 P

Toutes les entrées seront équilibrées pour l’intrusion ET le contrôle d’accès pour détecter les éventuels sabotages

5.4. Têtes de lecture (C)

CONC-C-1 P Les têtes de lecture sont équipées d’un système de détection d’intrusion et d’arrachage.

CONC-C-2 P

Les têtes de lecture doivent comporter une signalisation visuelle d’accès autorisé et d’accès refusé, ainsi qu’une signalisation sonore en cas de porte maintenue ouverte.

CONC-C-3 P

Les vis de fixation des lecteurs ne doivent être directement accessibles qu'à l'intérieur du secteur contrôlé avec le niveau de sûreté le plus important, si celui-ci est supérieur ou égal à II.

CONC-C-4 P Aucun droit d’accès ne doit être déporté dans la tête de lecture.

CONC-C-5 P

Les têtes de lecture doivent avoir démontré un excellent niveau de protection contre les fraudes. Elles devront avoir fait l’objet d’une

(21)

certification de sécurité de premier niveau (CSPN) selon ANSSI architecture 1, «lecteur transparent» (aucune clé de badge stockée dans le lecteur).

CONC-C-6 P

Les têtes de lecture ne doivent pouvoir être programmées que via les UTL, et en aucun cas au moyen d’une carte de maintenance simplement présentée à la tête de lecture pour la reprogrammer.

CONC-C-7 I Les lecteurs seront IP65, anti vandale IK10.

5.5. Badges (D)

CONC-D-1 P Les badges utilisés seront de technologie MIFARE^® DESFire EV1 ou EV2

5.6. Performances / Résilience (E)

Numéro Importance Exigence Observations

CONC-E-1 I

Le temps de réponse entre la présentation d’un badge et la commande d’ouverture de l’accès doit être inférieur à 1 s.

CONC-E-2 P

Le temps d’apparition d’une alarme sur une console d’exploitation (en service) doit être inférieur à 2 s.

CONC-E-3 P

Au niveau du système et des équipements, une alimentation de secours d'une autonomie de 48 heures minimum par UTL devra pallier une perte de l'énergie principale (batterie /onduleur).

Les 2 alarmes « défaut secteur EDF » et

« batterie niveau bas » par alimentation chargeur surveillée de l’UTL devront être envoyées aux exploitants

CONC-E-4 I Le constructeur s’engage à fournir du matériel de remplacement identique pendant 10 ans.

CONC-E-5 I

Tous les équipements seront dimensionnées en fonction des besoins en dégageant un potentiel de croissance de l’ordre de 20 % sur les entrées / sorties et les lecteurs

(22)

CONC-E-6 I

En cas de panne du serveur principal de contrôle d’accès, lors du rétablissement, le ou les serveurs doivent être remis en service avec le paramétrage présent juste avant la panne ou si cela n’est pas possible avec la dernière sauvegarde effectuée.

Les serveurs applicatifs sont virtualisés sur des serveurs physiques fournis par la CCI.

CONC-E-7 I

La perte d’un serveur devra être palliée par l’activation de serveur de secours. Cette activation se fera de façon automatique / à chaud. En particulier, elle ne nécessite pas de sauvegarde et restauration de la base de données. Le lien avec le système (par exemple STITCH) sera également activé sur le serveur redondant sans intervention manuelle.

serveur physique de secours fourni par la CCI.

CONC-E-8 P

La perte de la connexion de toute communication (entre un automate et un lecteur, entre le serveur et les UTL,…) sera détectée et généra une alarme technique.

CONC-E-9 P

Le système réalisera de façon automatique (ou manuelle), des sauvegardes de la configuration et des données au minimum une fois toutes les nuits.

5.7. Horodatage (H)

CONC-H-1 P Toutes les données seront datées dans chaque UTL

CONC-H-2 P

La datation sera précise à la seconde près et le système garantira la synchronisation de tous les équipements UTL périodiquement via le serveur de temps du système.

CONC-H-3 P

La mise à l’heure locale au niveau serveur de gestion système sera faite manuellement avec une possibilité de synchronisation externe par NTP (Network Time Protocol).

CONC-H-4 P

Le passage en heure d’été/heure d’hiver sera automatique mais cette fonction pourra être désactivée.

(23)

6. Exigences de compatibilité avec STITCH (COMP)

6.1. Objet du paragraphe

Les exigences de compatibilité décrites ci-dessous sont destinées à s’assurer du bon fonctionnement du système installé avec d’autres systèmes déjà mis en place ou qui seront mis en œuvre ultérieurement.

6.2. Application STITCH (A)

6.2.1. Généralités

L’objet de ce paragraphe est de spécifier les aspects de compatibilités avec le système STITCH.

Ces exigences sont à insérer dans le CCTP dès lors que le système de contrôle d’accès est prévu d’être interconnecté avec ce système (pour obtenir les badges nouvellement créés et désactivés dans ce système).

6.2.2. Exigences

COMP-A- 1

La passerelle d’interconnexion du système avec STITCH devra disposer d’une attestation de compatibilité STITCH délivrée par le STAC.

Cette attestation sera valable pour la version de passerelle mis en œuvre au titre du marché.

Ces attestations de compatibilité sont consultables sur le site

Internet du STAC

(www.stac.aviation- civile.gouv.fr/fr).

Il est à vérifier que la version de la passerelle installée soit bien celle ayant fait l’objet d’une attestation de compatibilité STAC.

7. Exigences d’installation, de configuration et de mise en œuvre

7.1. Généralités

L’objet du présent paragraphe est de spécifier les exigences concernant l’installation du système (mise en place, positionnement des équipements, câblage, …)

7.2. Positionnement des équipements (A)

7.2.1. Exigences

INST-A-1 Les UTL,

modules de porte

sont installées à l’intérieur des zones qu’elles contrôlent.

(24)

INST-A-2

Les automates (UTL, module de porte,...) devront être implantés dans des coffrets, ou armoires avec des rails DIN pour fixer les automates et un contact d’auto-protection à l’ouverture pour être géré par le système en alarme si ouverture.

7.3. Câblage (B)

7.3.1. Généralités

L’objet de ce paragraphe est de spécifier les travaux concernant le câblage. Ceci couvre à la fois le câblage réseau (Ethernet) mais également le câblage entre les UTL et les Modules de Porte et dispositif de verrouillage et lecteurs.

7.3.2. Exigences

INST-B-1 P Les cheminements de câbles seront mis en place à l’intérieur des zones contrôlées.

INST-B-2 P

Les liaisons de communication entre les moyens physiques d’ouverture et l’unité de traitement local seront des liaisons dédiées au système de sécurité.

INST-B-3 P

Les liaisons filaires seront surveillées de manière à garantir qu’aucune tentative de fraude ne puisse être réalisée.

INST-B-4 P La perte d’informations au niveau des liaisons devra être signalée et traitée comme une alarme.

INST-B-6 P

Les protocoles de communication utilisés (algorithmes de chiffrement inclus) devront être décrits, et particulièrement les principes de sécurisation et de vérification des échanges.

INST-B-7 P

La communication entre le badge, la tête de lecture et l’UTL sera chiffrée de bout en bout par des mécanismes conformes aux référentiels cryptographiques recommandés par l’ANSSI (Annexe B1 du RGS).

INST-B-8 P

La communication entre l’UTL et le serveur de gestion du système sera chiffrée de bout en bout par des mécanismes conformes aux référentiels

(25)

cryptographiques recommandés par l’ANSSI (Annexe B1 du RGS).

INST-B-9 P

Les câbles servant pour la transmission des informations du système de contrôle d’accès sont des câbles dédiés à ce système.

INST-B-10 P

Les réseaux définis pour le système de contrôle d’accès seront totalement indépendants des réseaux du site autant pour les câbles que pour les équipements électroniques ou informatiques associés.

7.4. Bascule ancien / nouveau système (C)

7.4.1. Généralités

L’objet de ce paragraphe est de spécifier les travaux nécessaires pour passer de l’ancien système au nouveau système. Ces exigences s’attacheront à garantir une continuité de service lors de et à minimiser les opérations complexes et lourdes (remplacement des badges de tous les agents lors d’une ‘opération badges’, bascule de tous les UTL dans un espace de temps court,…).

7.4.2. Exigences

INST-C-1

Dans le cadre de la migration de l’ancien système vers le nouveau, le titulaire proposera plusieurs scénarios de migration. Pour élaborer ces scénarios, le titulaire pourra s’appuyer sur le document cité en REF-D-1. Ces scénarios pourront être optimisés sur :

• Le coût global de mise en œuvre de la nouvelle solution,

• Le temps de migration,

• Sur la simplicité de migration

7.5. Reprise de données (D)

7.5.1. Généralités

L’objet de ce paragraphe est de spécifier les prestations concernant la reprise de données de

l’ancien système vers le nouveau. Celle-ci peut être nécessaire dans le cas d’une migration entre

deux systèmes différents.

(26)

7.5.2. Exigences

INST-D-1 F

La reprise des données intègrera :

• Les informations porteurs,

• Les badges

• Les classes d’accès

INST-D-3 F

Le titulaire proposera au client, une matrice de reprise de données décrivant les données reprises et les liens vers la nouvelle base de données.

Ces reprises pourront également faire l’objet de règles définies avec le client.

(27)

8. Exigences logistiques (LOGI)

8.1. Maintenance (A)

8.1.1. Généralités

L’objet de ce paragraphe est de spécifier les prestations liées à la maintenance du système mis en œuvre ou rénové au titre de ce marché. Ces exigences viseront à maintenir le système dans des conditions opérationnelles cohérentes avec le niveau de sécurisation global du système.

8.1.2. Exigences

LOGI-A-1 F

à l’issue de la période de garantie, le prestataire proposera un contrat de maintenance.

LOGI-A-2 I

Lors du signalement d’une anomalie par le client, le titulaire dispose d’un délai de 4 heures pour prendre connaissance du problème et proposer un délai pour sa résolution.

LOGI-A-3 P

Le titulaire assurera le MCS (Maintien en Condition de Sécurité) du système par la mise à jour régulière (1 x/an) des patchs et versions curatives et de sécurité selon les CVE.

Le titulaire devra prendre un contrat de maintenance logiciel auprès du constructeur de la solution pour que ce dernier mette à sa disposition ses patchs et versions. Le titulaire se chargera de les implanter et diffuser régulièrement sur le système en place sur site soutien du système de contrôle d’accès.

LOGI-A-4 P

Les éventuelles actions de télémaintenance devront être réalisées en respectant les principes et recommandations du document REF-B-3.