E4 - Cahier des charges national

1.1 Un contexte est un environnement d'apprentissage dans lequel une organisation cliente adresse une demande à un prestataire informatique interne ou externe à l'organisation cliente. Ces organisations sont réelles ou directement inspirées du réel. L'organisation cliente et le prestataire informatique sont décrits à travers leurs principaux processus métier et support, leur système d'information et l'ensemble de leurs relations formalisées (contrats ou catalogue de services, politique de sécurité, charte, etc.). La demande peut porter sur l'évolution ou la maintenance d'un ou plusieurs éléments de l'environnement technologique d'apprentissage et les réponses apportées peuvent mobiliser d'autres solutions techniques (par exemples, en Slam, recours à un outil de développement exploité pour faire évoluer une solution logicielle et, en SISR, utilisation d'un outil de gestion de configuration pour enregistrer une évolution de l'infrastructure de communication).

1.2 Les besoins de l'organisation cliente sont clairement identifiés dans un ou plusieurs cahiers des charges qui définissent les contraintes techniques, financières et temporelles à respecter.

1.3 L'environnement technologique d'apprentissage supportant le système d'information de l'organisation cliente comporte au moins :

• un service d'authentification pour les utilisateurs internes et externes à l'organisation ;
• un SGBD (mysql ou postgresql sur -);
• un accès sécurisé à Internet (squid3 sur s-proxy) ;
• un environnement de travail collaboratif (yunohost sur s-mess);
• un logiciel de gestion d'incidents (GLPI sur s-itil);
• un logiciel de gestion des configurations (GLPI/FusionInventory sur s-itil);
• deux serveurs, éventuellement virtualisés, basés sur des systèmes d'exploitation différents, dont l'un est un logiciel open source (Windows Server, Linux) ;
• une solution de sauvegarde ; (script sur s-backup)
• des ressources dont l'accès est sécurisé et soumis à habilitation ;
• deux types de solution technique d'accès dont une mobile (par exemples un smartphone, une tablette).

1.4 Les logiciels de simulation ou d'émulation sont utilisés en réponse à des besoins de l'organisation. Ils ne peuvent se substituer à des équipements réels dans l'environnement technologique d'apprentissage. Une solution d'infrastructure réduite à une simulation par un logiciel ne peut être acceptée.

1.5 Tous les documents et ressources qui décrivent un contexte doivent être accessibles en ligne via Internet aux commissions de correction à partir d'une date fixée par les autorités académiques :

• documents de présentation des organisations (organisation cliente et prestataire informatique) ;
• description de l'environnement technologique d'apprentissage ;
• tout ou partie des documents de référence utilisés par l'organisation cliente et par le prestataire informatique qui sont utiles pour définir le contexte (référentiels de bonnes pratiques, normes ou standards, description des processus, données métiers, etc.) et nécessaires pour le déroulement de l'épreuve ;
• les schémas d'infrastructure réseau ;
• la documentation technique des services disponibles ;
• les fichiers de configuration, la documentation technique des équipements matériels et logiciels disponibles ;
• les éléments financiers et juridiques liés aux services et aux équipements disponibles.

1.6 Lorsque les deux situations professionnelles présentées par un candidat s'appuient sur deux contextes différents, chaque contexte et son environnement technologique d'apprentissage doivent respecter les règles communes aux deux parcours. Le respect des règles relatives au parcours du candidat (SISR ou Slam) est mesuré à partir du cumul des caractéristiques des deux environnements technologiques d'apprentissage.

Règles spécifiques au parcours SISR

2.1 L'environnement technologique supportant le système d‘information de l'organisation cliente comporte au moins :

• un réseau comportant plusieurs périmètres de sécurité (DMZ, n-infra, n-+user, …);
• une solution permettant l'administration à distance sécurisée de serveurs et de solutions techniques d'accès (ssh);
• un logiciel d'analyse de trames (wireshark, tcpdump) ;
• un logiciel de supervision système et réseau (nagios, shinken, …);
• trois types de solution technique d'accès dont une mobile (par exemples un smartphone, une tablette) ;
• un service rendu à l'utilisateur final respectant un contrat de service comportant des contraintes en termes de sécurité et de haute disponibilité.

2.2 La structure et les activités de l'organisation s'appuient sur au moins trois solutions d'infrastructures opérationnelles parmi les suivantes :

1. une solution garantissant des accès sécurisés à un service, internes au périmètre de sécurité de l'organisation (type intranet) ou externes (type Internet ou extranet) ;
2. une solution garantissant la continuité d'un service ;
3. une solution garantissant la tolérance de panne de systèmes serveurs ou d'éléments d'interconnexion ;
4. une solution permettant la connexion sécurisée entre deux sites distants '(VPN Ipsec) ;
5. une solution permettant le déploiement des solutions techniques d'accès ; (application FOG)
6. une solution gérée à l'aide de procédures automatisées écrites avec un langage de « scripting » ;
7. une solution permettant la supervision de la qualité, de la sécurité et de la disponibilité des services avec remontées d'alertes (nagios + déclenchement d'alertes) ;
8. une solution permettant la détection d'intrusions ou de comportements anormaux sur le réseau (fail2ban, portsentry ou snort);
9. une solution permettant la répartition de charges entre services, serveurs ou éléments d'interconnexion (équilibrage de charge avec Haproxy/LVS sur s-lb).

2.3 Les solutions d'infrastructure présentes dans le contexte sont opérationnelles et documentées. Elles s'appuient sur des composants matériels accessibles au moment de l'épreuve.