From 46103dda8b4271dd07876420608b505f1be5f21f Mon Sep 17 00:00:00 2001 From: Christophe Siraut Date: Mon, 18 Dec 2017 17:01:58 +0100 Subject: [PATCH] split documentation for inclusion in Combo (wip); move mutlimachines version to multimachines branch --- architecture-1.md | 46 ++++ architecture-2.md | 138 +++++++++++ architecture-3.md | 17 ++ architecture-4.md | 65 +++++ architecture-5.md | 61 +++++ architecture-6.md | 237 ++++++++++++++++++ architecture.md | 610 ---------------------------------------------- index.rst | 28 ++- 8 files changed, 589 insertions(+), 613 deletions(-) create mode 100644 architecture-1.md create mode 100644 architecture-2.md create mode 100644 architecture-3.md create mode 100644 architecture-4.md create mode 100644 architecture-5.md create mode 100644 architecture-6.md delete mode 100644 architecture.md diff --git a/architecture-1.md b/architecture-1.md new file mode 100644 index 0000000..0df95f8 --- /dev/null +++ b/architecture-1.md @@ -0,0 +1,46 @@ +# 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. + +![Logo Publik](images/architecture.png) + +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. + +## Chemin d'une requête + +Une requête Publik chemine par les services suivants : + +service web (nginx) : + +- dispose d'un certificat SSL +- dispose des composants Publik +- interroge la base de donnée et répond aux requêtes des utilisateurs + +service de base-de-données (postgresql) : + +- enregistre et restitue les données des applications, + +Note: lors d'installations critiques nous recommandons de doubler chacun +des services, et la mise-en-place d'une interface de stockage distribuée. +Un serveur proxy est en charge de la terminaison SSL, de la répartition de +la charge et la tolérance aux pannes. diff --git a/architecture-2.md b/architecture-2.md new file mode 100644 index 0000000..4257fe0 --- /dev/null +++ b/architecture-2.md @@ -0,0 +1,138 @@ +# 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. + +Note: lors d'installations critiques, nous créons un lien symbolique depuis +/var/lib/mabrique/documents vers un montage NFS. + +## 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 + +![Logo Publik](images/schema.png) + +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). + +![Logo Publik](images/dialogue.png) + +## 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 () ; +- 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). + +![Logo Publik](images/api.png) + +### 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. + +![Logo Publik](images/combo.png) + +## + +## 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. + +![Logo Publik](images/provisioning.png) diff --git a/architecture-3.md b/architecture-3.md new file mode 100644 index 0000000..598eac6 --- /dev/null +++ b/architecture-3.md @@ -0,0 +1,17 @@ +# Ressources matérielles + +Les ressources nécessaires varient en fonction de la quantité de données à traiter. +Une installation de développement peut aisément tenir sur une machine virtuelle. +Lors d'installation critiques nous isolons les composants sur des machines séparées. + +Exemple de machine pour opérer des briques : + +- 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. diff --git a/architecture-4.md b/architecture-4.md new file mode 100644 index 0000000..346b58c --- /dev/null +++ b/architecture-4.md @@ -0,0 +1,65 @@ +# Dépendances logicielles + +## Service de base-de-donnée + +Chaque brique utilise une ou plusieurs bases de données PostgreSQL. + +## Composants logiciels sous-jacents + +Publik est un logiciel développé en Python, sur le framework Django. +Il est développé et testé pour fonctionner sur un système +d’exploitation Debian GNU/Linux en version stable (oldstable est supporté égallement). + +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. diff --git a/architecture-5.md b/architecture-5.md new file mode 100644 index 0000000..67d83fe --- /dev/null +++ b/architecture-5.md @@ -0,0 +1,61 @@ +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. + +![Logo Publik](images/saas.png) diff --git a/architecture-6.md b/architecture-6.md new file mode 100644 index 0000000..9c6d62c --- /dev/null +++ b/architecture-6.md @@ -0,0 +1,237 @@ +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 + +![Logo Publik](images/flux_si_tiers.png) + +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 + + +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 : + +- [http://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-](http://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx)[certificate.aspx](http://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx) +- + +### 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. + +![Logo Publik](images/reverse_proxy.png) + +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. + +![Logo Publik](images/passerelle_locale.png) + + + +### 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. + diff --git a/architecture.md b/architecture.md deleted file mode 100644 index a6fc0df..0000000 --- a/architecture.md +++ /dev/null @@ -1,610 +0,0 @@ -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. - -![Logo Publik](images/architecture.png) - -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 - -![Logo Publik](images/schema.png) - -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). - -![Logo Publik](images/dialogue.png) - -### 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 () ; -- 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). - -![Logo Publik](images/api.png) - -#### 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. - -![Logo Publik](images/combo.png) - -### - -### 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. - -![Logo Publik](images/provisioning.png) - -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. - -![Logo Publik](images/saas.png) - -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 - -![Logo Publik](images/flux_si_tiers.png) - -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 - - -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 : - -- [http://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-](http://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx)[certificate.aspx](http://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx) -- - -### 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. - -![Logo Publik](images/reverse_proxy.png) - -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. - -![Logo Publik](images/passerelle_locale.png) - -#### 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). diff --git a/index.rst b/index.rst index 790e0e5..3505b9b 100644 --- a/index.rst +++ b/index.rst @@ -6,11 +6,33 @@ Guide de déploiement ==================== -.. toctree:: - :maxdepth: 2 +Architecture +------------ + +.. toctree:: + :maxdepth: 1 + + architecture-1 + architecture-2 + architecture-3 + architecture-4 + architecture-5 + architecture-6 + +Installation +------------ + +.. toctree:: + :maxdepth: 1 - architecture installation + +Exploitation +------------ + +.. toctree:: + :maxdepth: 1 + exploitation