25 KiB

Raw Blame History

Architecture

Ce document présente l’architecture technique d’un système Publik nécessaire pour garantir un fonctionnement sécurisé et permanent. Il se concentre sur les briques logiciels « actives » et ne détaille pas les modules nécessaires classiques à tout système d’information : supervision, logs, sauvegarde, technique de virtualisation, orchestration des configuration, architecture des machines, etc.

Présentation générale

Publik est un ensemble de composants : on parle des « briques » de la solution. Elles sont représentées ci-dessous sous la forme de petits carrés. Elles sont accessibles par les humains via le web (HTTPS) au travers d’interfaces « frontoffice » ou « backoffice ».

Le composant « passerelle » est particulier, il assure la connexion avec des systèmes tiers en traduisant les webservices internes de Publik en protocoles et formats des logiciels cibles.

Liste des briques disponibles :

Authentic : gestion des identités, IdP (identity provider)
Combo : CMS pour portails usager et agent (porte d’entrée de Publik)
w.c.s. : formulaires et workflows
Passerelle : connecteurs vers systèmes tiers
Fargo : porte-documents
Corbo : diffusion de messages
Chrono : prise de rendez-vous
Welco : interface de saisie (multi-canal)
Hobo : système de déploiement et de provisioning

Un système Publik installé ne comporte pas obligatoirement toutes les briques.

Structure d’une brique

Une brique Entrouvert est un paquet Debian standard issu d’un module Python standard. C’est un logiciel libres dont vous pouvez obtenir et modifier les sources selon vos besoins. Les fichiers d’installation sont posés dans /var/lib/mabrique, et les fichiers de configuration sont placés dans /etc/mabrique. Les services et les journaux des briques sont pilotés par systemd.

Pour certaines briques nous créons un lien symbolique depuis /var/lib/mabrique/documents vers un montage NFS.

Infrastructure de base requise

Machines nécessaires

Idéalement, pour une meilleure isolation et une meilleure sécurité, chaque brique dispose de son propre serveur. Cependant il est possible de varier les installations, jusqu’à tout installer sur une seule machine (par exemple lors de tests, de PoC, de développements).

Machine recommandée pour opérer une brique :

processeur architecture x86-64 double cœur
mémoire vivre 4Go
volume disque fonction de l’usage prévu, typiquement 10Go (minimum 1Go pour un test)

Les briques w.c.s. (formulaires) et fargo (porte-documents) doivent disposer d’un volume plus important pour gérer les documents des usagers. Ceux-ci sont stockés sur le système de fichier, son volume est donc à évaluer en fonction de l’usage prévu.

Il est fortement conseillé de disposer d’un pool de machines virtuelles dont la puissance et les volumes disques peuvent être modifiés à chaud. La technologie de containers apporte cette souplesse avec un minimum de perte de puissance.

Chemin d'une requête

Une requête Publik chemine par les services suivants :

proxy :

reçoit la requête et la transmet vers un serveur d’application,
est en charge de la terminaison SSL (et dispose de certificat qui couvre l'ensemble des systèmes),
est en charge de la répartition de la charge et la la tolérance aux pannes.

web1 et web2 :

ont des installations identiques au niveau logiciel,
disposent des composants Publik,
interrogent la base de donnée et transfèrent les fichiers en fonction des niveaux d’accès des utilisateurs.

Postgres :

enregistre et restitue les données des applications,
il est courant d’utiliser une installation à deux machines identiques avec une réplication de type master/slave.

NFS :

fournit l’interface de stockage pour les fichiers partagés.

Machine PostgreSQL

Chaque brique utilise une ou plusieurs bases de données PostgreSQL, il faut donc disposer d’une machine pour cela. Il est courant d’utiliser une installation à deux machines identiques en master/slave, avec les mêmes recommandations que ci-dessus.

Publik peut utiliser un système PostgreSQL existant, le cas échéant.

Composants logiciels sous-jacents

Publik est un logiciel développé en Python 2.7, sur le cadriciel (framework) Django 1.8. Il est prévu pour fonctionner sur un système d’exploitation GNU/Linux et sa distribution officielle (par paquets) cible Debian GNU/Linux en version stable ou oldstable.

Le frontal web recommandé est nginx, bien que Publik puisse fonctionner avec Apache et d’autres serveurs HTTP. La liaison entre les applicatifs Python et le frontal web est assurée par gunicorn (évolution en cours vers uwgsi).

Les différents composants (briques) de Publik échangent des messages AMQP via RabbitMQ.

Publik nécessite PostgreSQL en version 9 (>9.4 recommandée) sur lequel chaque brique disposera de sa base de données propre.

Source des logiciels (dépôts APT)

Les différents composants logiciels utilisés par Publik proviennent, par ordre de préférence :

de la distribution Debian GNU/Linux stable (ou oldstable)
des backports officiels Debian, disposant du suivi de sécurité par l’équipe Debian
des paquets Debian fournis et maintenus par les projets upstream
de paquets Debian maintenus par Entr’ouvert qui en assure le suivi de sécurité

Flux réseau à ouvrir

Publik est un système web : ses composants doivent être accessibles en HTTPS (443/tcp). Le S final est important : Publik n’est pas prévu pour fonctionner en HTTP.

Les différentes briques de Publik communiquent entre elles également en HTTPS, elles doivent donc disposer d’un accès DNS (53/udp et 53/tcp) et HTTPS.

Le système de provisonning (déploiement, configuration et diffusion des utilisateurs et des rôles) utilise AMQP (5671/tcp).

La connexion avec PostgreSQL utilise 5432/tcp.

La plupart des accès à des logiciels tiers se fait via webservice, généralement en HTTPS (443/tcp). Il peut également y avoir connexion à des annuaires LDAP (389/tcp).

La solution Publik n’a pas encore été validée sur IPv6.

Pour le support et la maintenance du systèmes, des accès SSH (22/tcp) sont nécessaires, voir ci-dessous.

Certificats X509

La diffusion HTTPS étant obligatoire, il est nécessaire de disposer de certificats valides pour chaque brique déployée ; chacune des briques utilisant un nom de serveur distinct. En général un certificat étoile (wildcard *.example.net) couvre toutes les briques.

MCO par Entr'ouvert

Pour qu'ils puissent assurer le maintien en conditions opérationnelles (MCO) de la partie logicielle Publik, les travailleurs d'Entr'ouvert doivent :

avoir un accès SSH aux machines le plus direct possible (sans nécessité de passer par un VPN, qui plus est s'il est propriétaire ou exotique). Entr’ouvert peut indiquer une liste d’adresses IPv4 source ;
disposer d'un accès administrateur (root) sur les machines, via su ou sudo.

Cet accès n’est pas demandé sur les machines d’infrastructure « non logicielle » telle que le serveur de base de données PostgreSQL, le serveur de log, les backups, etc. La maintenance de ces systèmes est laissée aux opérateurs habituels du site ; sauf contrat spécifique avec Entr’ouvert.

Si l'accès web à la solution est fermé, par exemple dans le cas d'un PoC ou d'une utilisation interne, alors cet accès doit être possible pour Entr'ouvert (là encore, accès direct sans VPN si possible).

Si les permissions root sont impossibles, il est au moins nécessaire, pour des raisons de support, qu'Entr'ouvert accéde facilement aux logs des machines voire à son système de supervision, et ce en temps réel. Il doit par ailleurs exister une procédure de passage root en cas d'urgence. Enfin, si Entr'ouvert n'a pas d'accès root à la machine, cela signifie que la supervision et les mises à jour régulières (au moins quotidiennes) sont opérées par l'hébergeur ; condition sans laquelle Entr'ouvert ne peut pas garantir une sécurité maximale du système.

Enfin, Entr’ouvert ne peut assurer un MCO efficace que sur des machines Debian GNU/Linux maintenues à jour – cette maintenance peut même être assurée par Entr’ouvert. Pour tout autre système d’exploitation, un contrat spécifique doit être prévu.

Architecture d’une brique logicielle

Utilisation de cadriciels (frameworks)

Chaque brique logicielle est une application Python/Django – à l’exception de la brique w.c.s. qui utilise le cadriciel Quixote.

L’utilisation d’un framework permet de disposer d’un ensemble de composants afin de développer plus rapidement, mais aussi de manière plus homogène, et surtout en assurant à tout moment une excellente sécurité de l’application. C’est en effet le framework qui :

reçoit les données, les interprète et les valide avant de les envoyer à l’application ;
permet de contrôler l’envoi des données aux bases de données par l’application (pas de requêtes SQL directes) ;
sécurise les sorties de l’application (HTML) en imposant un contrôle fort sur les données affichable.

Dans Publik, en plus de l’utilisation de toutes les possibilités de Django d’autres protections sont mises en place :

isolation des composants (chaque composant est une brique logicielle indépendante) ;
chaque brique dispose de sa propre base de données, complètement isolée des autres (chaque base peut même être hébergée sur un serveur propre) ;
chaque brique peut gérer plusieurs sites (mode multi-tenants), dans ce cas chaque site dispose d’un « tenant » dans la base de données sous forme d’un schéma PostgreSQL : chaque site est donc indépendant et isolé ;
utilisation du front-end nginx pour diffuser tous les éléments statiques des applications ;
connexion de l’application via le protocole wsgi pour un premier filtrage des requêtes (les requêtes invalides sont rapidement éliminées).

D’une façon générale, Publik utilise au maximum des composants éprouvés : le code des applications se concentre uniquement sur la logique de celles-ci. Il s’agit de suivre les principes DRY (Don’t Repeat Yourself) et KISS (Keep It Simple Stupid) afin de mieux sécuriser l’application : la sobriété recherchée par Publik est aussi présente dans le code du logiciel.

Schéma

Le schéma ci-dessus montre que l’application n’est pas en contact « direct » avec l’extérieur. Elle utilise toujours des composants logiciels soit éprouvés (celery, requests, tenant-schemas), soit communs à toutes les briques (hobo, mellon).

Dialogues entre briques

Les briques de Publik dialoguent via deux canaux :

webservices (HTTPS JSON) pour ce qui concerne l’échange de données
messages (AMQP) pour ce qui concerne la gestion des utilisateurs et des rôles, i.e. le provisioning au travers des différents composants

Par ailleurs SAML est utilisé pour ce qui concerne le WebSSO (le dialogue se déroule via le navigateur de l’usager).

API Publik

Description générale

L’API des webservices Publik permet aux briques d’échanger des données. La plupart ont trait à l’échange de données autour d’un usager.

Fournisseurs d’API :

w.c.s. est la brique qui propose le plus de webservices autour des demandes d’un usager (http://doc.entrouvert.org/wcs/dev/#api) ;
Passerelle met en place des connecteurs donc la plupart ont pour objectif de remonter les informations d’un système tiers concernant un usager ;
Passerelle est aussi utilisé pour remonter des informations de type « référentiels » depuis des systèmes tiers ;
Authentic propose des API permettant la gestion des rôles, des usagers (attributs et rôles).

Consommateurs d’API :

Combo est un consommateur de ces API afin de présenter à l’usager l’ensemble des données que Publik connaît le concernant ;
w.c.s. utilise les API de passerelle pour présenter des référentiels dans les formulaires ;
w.c.s. utilise les API d’Authentic dans ses actions de workflow afin de pouvoir gérer les rôles d’un usager qui a fait une certaine demande ;
w.c.s. peut également faire appel à tout webservice de Passerelle afin d’intervenir sur un système tiers, toujours lors d’action de workflow (typiquement pour injecter des données dans un système tiers).

Exemple d’un dialogue Combo / w.c.s.

Objectif : lorsque l’usager se connecte sur son portail usager, une cellule de la page affiche la liste de ses demandes en cours. Pour cela, combo va faire appel à différents webservices de w.c.s. qui lui retourneront les informations nécessaires à afficher dans les cellules de la page.

Messagerie pour provisioning

Le système de provisioning des utilisateurs et des rôles opère via un diffuseur de message AMQP (RabbitMQ). Lorsqu’une modification est effectuée sur la brique authentic, celle-ci diffuse un message à l’attention de toutes les instances des autres briques concernées. Le message est reçu par tous les agents de toutes les machines de l’infrastructure, et est diffusé aux briques concernées, qui se chargent de modifier les utilisateurs des instances cibles.

Infrastructure d’hébergement SaaS

L’infrastructure d’hébergement proposée par Entr’ouvert utilise les techniques suivantes :

des machines physiques au matériel redondant (alimentation double, disques durs RAID 1) avec de très importantes capacités CPU (au moins 16 coeurs) et mémoire vive (au moins 128Go) : ces machines sont capables de supporter sans délai des montées en charges brusques ;
ces machines disposent de disques ultra-rapides (SSD) pour fournir des espaces disques locaux véloces si nécessaire (espace système, espaces temporaires) ; ainsi que de disques rapides (SAS ou SATA) pour des espaces de stockages locaux importants (backups locaux, fichiers transitoires) ;
des machines virtuelles basées sur un système de container (OpenVZ, en migration vers lxc) permettant de dimensionner la puissance CPU ou la mémoire vive de chaque machine à chaud ;
des espaces disques obtenus par NFSv3 depuis un SAN, permettant un redimensionnement à chaud des volumes disque ; par ailleurs le SAN utilise la technologie ZFS avec des snapshots horaire, quotidien et hebdomadaires ;
les machines virtuelles utilisent des IP virtuelles (« failover ») qui peuvent être déplacées en quelques minutes vers une autre machine physique, et ainsi ne pas nécessiter de modification DNS en cas de déplacement des VM.

En terme de sécurité de données :

En plus des snapshots ZFS, des backups incrémentaux (quotidiens) et complets (hebdomadaires) sont effectués sur une machine isolée hors site ;
Le système de restauration est régulièrement vérifié ;
La duplication d’une machine ou son transport vers un autre hôte physique peut être effectuée en quelques minutes (modulo propagation des IP fail-over) ;
Le serveur PostgreSQL est une machine à disque RAID-5, sauvegardée quotidiennement. Elle est secondée d’une machine « slave » capable de prendre le relais en cas de défaillance.

En terme de sécurité réseau :

Un pare-feu est présent sur chaque machine physique, en entrée comme en sortie. En dehors des accès HTTPS aux briques applicatives, tous les flux sont filtrés par défaut et ouvert uniquement au cas par cas ;
Une surveillance « fail-to-ban » coupe les IP qui tentent des connexions non autorisées ;
L’hébergeur des machines physiques assure par ailleurs une protection anti-DDOS.

Un serveur de log externe regroupe tous les événements de toutes les installations.

Une supervision générale est assurée par des agents SNMP et NRPE qui remontent les informations sur une plateforme Nagios et alertent les travailleurs d’Entr’ouvert en temps réel.

Autres infrastructures possibles

Infrastructure PoC / test

Dans le cadre d’une installation de test ou PoC (preuve de concept) il est habituel d’installer Publik sur une seule machine. Dans ce cas, toutes les briques partagent :

un seul frontal ngnix
un seul serveur de base de donnée
des espaces disques locaux (/var/lib/brique)
un système de log (en général le syslog système)

Dans ce cadre, Publik peut être installé sur une machine aujourd’hui habituelle :

processeur x86-64 double cœur
mémoire vive 2Go
espace disque 10Go, voire moins

Cependant et pour rappel, Publik nécessitant un fonctionnement HTTPS, il reste nécessaire de disposer :

d’un enregistrement DNS par brique instanciée ;
d’un certificat x509 valable pour chaque brique, généralement un wildcard sur le domaine choisi.

Infrastructure légère et « élastique »

Entre une infrastructure SaaS telle que celle gérée par Entr’ouvert capable de répondre à des dizaines d’installations, et une infrastructure minimale telle que celle décrite pour un PoC, toutes les combinaisons sont possibles.

La partie la plus délicate à gérer est souvent la partie x509, et parfois la partie DNS quand il est question de pouvoir créer de nouvelles instances automatiquement dans le cadre d’un ensemble de communes (syndicat, organisme, métropole ou agglomération désirant diffuser la solution Publik à ses « membres »).

Pour rendre l’installation « élastique », c’est-à-dire capable de s’adapter au futur, il est conseillé :

de virtualiser toutes les machines ;
d’utiliser une technique de virtualisation permettant des modifications CPU, RAM et disque faciles, idéalement à chaud ;
de disposer d’un serveur PostgreSQL central ;
d’avoir accès à un SAN pour le stockage des données ;
d’avoir toute liberté sur la partie DNS, éventuellement via des CNAME ou une délégation de zone ;
de disposer d’un certificat x509 wildcard pour chaque domaine à gérer.

Une fois l’installation effectuée, il est souvent assez simple de permettre le déplacement d’une brique vers une autre machine : copie des configurations et des données, modification DNS, l’opération correctement préparée est sans risque et ne provoque pas de coupure de plus de 10 minutes.

Infrastructure pour hébergement sur site

Un hébergement sur site est de type « élastique » (cf supra), voici les recommandations d’usage pour l’initialisation :

machine « IdP » pour authentic (utilisable par d'autres systèmes que Publik)
machine « applications » : hobo + combo + w.c.s. + fargo + passerelle
machine PostgreSQL
autres briques sur une autre machine ou sur la machine « applications »
backups et redondance (fail-over) assurés par ailleurs

Pour une collectivité avec plusieurs déploiements prévus à l’initialisation, la machine « applications » peut être scindée :

machine hobo + combo + passerelle
machine w.c.s. + fargo (porte-documents)
autres briques sur une machine tierce

Toutes les machines sont virtuelles et modifiables rapidement (CPU et RAM) avec une marge importante. Les répertoires de données proviennent d'un SAN et sont extensibles, principalement pour w.c.s. et fargo (porte-documents).

Caractéristiques d’une machine virtuelle à l’initialisation :

processeur x86-64 4 cœurs
mémoire vive 4Go
espace disque 16Go ; et plus (via SAN) sur les applications stockant des documents w.c.s. et fargo.

Le serveur PostgreSQL est sécurisé, c’est-à-dire qu’il dispose au moins d'un slave pour fail-over. Si besoin il peut être installé par Entr’ouvert.

Accès à un S.I. tiers

Lorsque Publik doit accéder à un système d’information tiers, il doit y avoir ouverture des flux nécessaires :

accès webservices : passerelle consomme ou fourni des webservices au S.I. tiers ;
accès LDAP pour les annuaires : accès par l’IdP pour authentification et synchonisation.

Pour les webservices, la connexion sera effectuée par Passerelle, via un connecteur.

Si le connecteur n’existe pas encore et doit donc être programmé, les webservices tiers doivent utiliser des protocoles ouverts et reconnus, tels que REST/JSON ou SOAP. Ils doivent être documentés et validés.

Protection des accès webservices

Les webservices, en entrée comme en sortie, doivent utiliser HTTPS. L’authentification peut être :

en login/mot de passe (HTTP Basic authentication)
par certificat X509 client et serveur
… tout autre mode d’authentification peut être étudié par Entr’ouvert.

Note : les API internes à Publik utilisent un système d’authentification spécifique similaire à JWT, décrit dans http://doc.entrouvert.org/wcs/dev/#api

Note 2 : En cas de proxy sur la chaîne, il faut vérifier l’absence de cache.

Protection de l’accès LDAP : X509

La connexion LDAP doit se faire en TLS, avec des certificats X509 clients et serveurs validés de chaque côté. Entr’ouvert peut fournir des certificats depuis son AC privée.

S’il s’agit d’un accès LDAP à un système Active Directory, voici deux documentation concernant la mise en place de TLS sur ce système :

Ajout de protections sur webservices existants

Au cas où les logiciels tiers ne mettent pas en place de protection suffisante sur leurs webservices, plusieurs solutions de sécurisation peuvent être envisagées, dont les plus classiques sont : ajout d’un reverse-proxy, ajout d’une instance « locale » de Passerelle, mise en place d’un VPN.

Ajout d’un reverse-proxy

Un reverse-proxy est placé en frontal devant les webservices, ajoutant la couche HTTPS et/ou une authentification (par HTTP Basic ou X509). C’est généralement la solution la plus efficace, simple à mettre en place et ne nécessitant qu’une maintenance classique, qui peut être intégrée à la maintenance générale du SI. C’est donc la solution conseillée.

Le reverse-proxy est une solution de type Apache ou Nginx. Il est connecté d’une part au webservice à diffuser, et d’autre part à un réseau accessible par Publik. Il ajoute :

le chiffrage du flux (HTTPS) ;
une authentification : soit basique, soit basée sur un certificat X509 client ;
un filtrage des URLs accessibles ou non depuis telle ou telle IP (typiquement pour l’IP de la passerelle Publik).

Un filtrage IP général peut également être ajouté au niveau d’un firewall placé en amont du reverse-proxy, par exemple le firewall d’arrivée générale du site client. Ce filtrage n’autorisera que l’IP de Passerelle à accéder aux webservices.

Ajout d’une instance Passerelle « locale »

Dans cette configuration, une instance de Passerelle est ajoutée, au même niveau qu’un reverse-proxy (cf supra). Les connecteurs de Passerelle assurent alors localement la traduction des webservices tiers en webservices Publik, ces derniers ajoutant la sécurisation de l’accès entre le SI et Publik.

Cette solution présente l’avantage d’assurer un contrôle de sécurité fort des webservices diffusés à destination de Publik, contrôle assuré par Publik. Cependant, la maintenance est plus complexe que l’installation d’un reverse-proxy. Aussi ne doit-elle être mise en place que si les webservices de l’application sont très difficiles à sécuriser.

Accès via VPN

Si la seule solution est un VPN, cela demande étude préalable par les équipes techniques d’Entr’ouvert (OpenVPN est le seul VPN déjà utilisé par Entr’ouvert en production).

25 KiB Raw Blame History Unescape Escape