import documentation from odt files
This commit is contained in:
parent
7a980ea27e
commit
44b81d4c08
|
@ -0,0 +1,547 @@
|
|||
Architecture technique
|
||||
======================
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
### 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 :
|
||||
|
||||
- [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)
|
||||
- <http://www.javaxt.com/Tutorials/Windows/How_to_Enable_LDAPS_in_Active_Directory>
|
||||
|
||||
### 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).
|
File diff suppressed because it is too large
Load Diff
|
@ -0,0 +1,256 @@
|
|||
Notice d’exploitation
|
||||
=====================
|
||||
|
||||
Ce document constitue la notice l’exploitation d’un système Publik
|
||||
standard. Des adaptations sont naturellement à envisager en fonction des
|
||||
besoins particuliers.
|
||||
|
||||
Rappels
|
||||
-------
|
||||
|
||||
Vous trouverez une documentation complète et spécifique à l’architecture
|
||||
et à l’installation de Publik dans les documents intitulés : *Publik –
|
||||
Architecture technique* et *Publik – Installation*. Les notes qui
|
||||
suivent en donnent un aperçu.
|
||||
|
||||
### Architecture
|
||||
|
||||
Une infrastructure type de Publik est composée des machines suivantes :
|
||||
|
||||
- un service frontal de répartition de charge (*proxy),*
|
||||
- deux serveurs d'application (*web1* et *web2),*
|
||||
- un serveur de base de données *sql* (Postgres),
|
||||
- un serveur de fichier (partage NFS).
|
||||
|
||||
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.
|
||||
|
||||
Liste des modules applicatifs potentiels de Publik :
|
||||
|
||||
- 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 provisionning,
|
||||
- Bijoe : élaboration et production de rapports statistiques,
|
||||
- Chrono : gestion d'inscriptions et rendez-vous
|
||||
|
||||
### 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.
|
||||
|
||||
Notice d'exploitation
|
||||
---------------------
|
||||
|
||||
### Pilotage du frontal HTTP
|
||||
|
||||
C'est le service Nginx qui gère les requêtes HTTP, son pilotage se fait
|
||||
de façon classique :
|
||||
|
||||
\# service nginx stop
|
||||
|
||||
\# service nginx start
|
||||
|
||||
\# service nginx restart
|
||||
|
||||
À noter que lorsqu'un service Publik est coupé, Nginx renvoie des
|
||||
erreurs *502 Bad Gateway*. HAProxy réagit alors en tentant la requête
|
||||
sur l'autre machine. Si l'autre répond aussi 502, HAProxy peut afficher
|
||||
un message de maintenance.
|
||||
|
||||
### Pilotage des services de Publik
|
||||
|
||||
Tous les services sont pilotables avec le système *service* fourni par
|
||||
Debian.
|
||||
|
||||
Liste des services Publik en place :
|
||||
|
||||
- *hobo* : système de déploiement et de provisionning
|
||||
- *authentic2-multitenant* : gestion d'identité et websso
|
||||
- *combo* : CMS des portails usager et agent
|
||||
- *wcs* : moteur de démarches (formulaires et workflows)
|
||||
- *passerelle* : hub de webservices
|
||||
- *fargo* : porte-document
|
||||
- *supervisor* (cas particulier pour le pilotage de hobo-agent,
|
||||
sous-service hobo qui sera bientôt piloté directement par systemd)
|
||||
|
||||
Pour exemple, pilotage du service combo (portails) :
|
||||
|
||||
\# service combo stop
|
||||
|
||||
\# service combo start
|
||||
|
||||
\# service combo restart
|
||||
|
||||
S'agissant d'une installation dual, ces actions doivent être effectuées
|
||||
sur les deux machines.
|
||||
|
||||
Attention : si un service de Publik est démarré ou redémarré alors que
|
||||
PostgreSQL n'est pas disponible, ce démarrage ne fonctionnera pas. Il
|
||||
faudra redemander le démarrage explicitement.
|
||||
|
||||
Note: la migration de tous les composants de Publik vers systemd est en
|
||||
cours et sera terminé avant fin 2017.
|
||||
|
||||
### Journaux des événements (logs)
|
||||
|
||||
L’historique des événements applicatifs est accessible via l'outil
|
||||
*journalctl*. Par exemple pour suivre les événements de combo :
|
||||
|
||||
\# journalctl -fu combo
|
||||
|
||||
Pour suivre l'ensemble des composants :
|
||||
|
||||
\# journalctl -f -u combo -u authentic2-multitenant -u wcs -u fargo -u
|
||||
hobo -u supervisor
|
||||
|
||||
Les logs HTTP sont ceux de nginx, fichiers textes rangés par service
|
||||
dans */var/log/nginx :*
|
||||
|
||||
/var/log/nginx/authentic2-multitenant-access.log
|
||||
|
||||
/var/log/nginx/authentic2-multitenant-error.log
|
||||
|
||||
/var/log/nginx/bijoe-access.log
|
||||
|
||||
/var/log/nginx/bijoe-error.log
|
||||
|
||||
/var/log/nginx/combo-access.log
|
||||
|
||||
/var/log/nginx/combo-error.log
|
||||
|
||||
/var/log/nginx/fargo-access.log
|
||||
|
||||
/var/log/nginx/fargo-error.log
|
||||
|
||||
/var/log/nginx/hobo-access.log
|
||||
|
||||
/var/log/nginx/hobo-error.log
|
||||
|
||||
/var/log/nginx/passerelle-access.log
|
||||
|
||||
/var/log/nginx/passerelle-error.log
|
||||
|
||||
/var/log/nginx/wcs-access.log
|
||||
|
||||
/var/log/nginx/wcs-error.log
|
||||
|
||||
Exemple pour suivre ce qui concerne combo :
|
||||
|
||||
\# tail -f /var/log/nginx/combo-\*.log
|
||||
|
||||
### Mise à jour des composants
|
||||
|
||||
#### Fréquence de mise à jour
|
||||
|
||||
Entr'ouvert livre une nouvelle version de Publik les soirs des 2ème et
|
||||
4ème jeudi de chaque mois. L'installation peut être faite aussitôt, mais
|
||||
nous conseillons à des hébergeurs tiers non infogérés par Entr'ouvert de
|
||||
faire la mise à jour le mardi suivant.
|
||||
|
||||
La mise à jour provoque une courte indisponibilité du système : elle
|
||||
doit être faite sur des heures de faible affluence. Pour information,
|
||||
Entr'ouvert effectue ces mises à jour autour de 22 ou 23h le jeudi soir,
|
||||
en attendant une baisse de la fréquentation visible dans les logs nginx.
|
||||
|
||||
#### Déroulé en installation double (load-balancing)
|
||||
|
||||
S'agissant d'une installation double (load-balancing entre web1 et
|
||||
web2), la procédure générale à suivre est :
|
||||
|
||||
1. arrêt du frontal nginx sur web2 ⇒ HAProxy envoie tout sur web1,
|
||||
2. vérifier que PostgreSQL est bien fonctionnel,
|
||||
3. mise à jour de web1 (procédure ci-dessous),
|
||||
4. vérification du fonctionnement du site (parcours de 3 ou 4 URLs),
|
||||
5. mise à jour de web2,
|
||||
6. relance du frontal nginx sur web2,
|
||||
7. vérification du fonctionnement du site (parcours de 3 ou 4 URLs).
|
||||
|
||||
Attention : si un service de Publik est redémarré alors que PostgreSQL
|
||||
n'est pas disponible, ce démarrage ne fonctionnera pas. Il faudra
|
||||
redemander le démarrage explicitement. Ceci signifie qu'il est très
|
||||
fortement conseillé de faire la mise à jour de Publik indépendamment de
|
||||
celle de PostgreSQL. Entr'ouvert conseille de faire la mise à jour de
|
||||
PostgreSQL **avant** les composants de Publik.
|
||||
|
||||
Les composants de Publik sont livrés sous forme de paquet Debian, leur
|
||||
mise à jour suit la procédure classique :
|
||||
|
||||
\# apt update
|
||||
|
||||
\# apt upgrade
|
||||
|
||||
Il est cependant possible qu'une nouvelle version demande l'installation
|
||||
d'une nouvelle dépendance, dans ce cas « *apt upgrade* » refusera la
|
||||
mise à jour et il faudra la forcer par :
|
||||
|
||||
\# apt full-upgrade
|
||||
|
||||
En cas de doute, contacter <support@entrouvert.com>
|
||||
|
||||
### Mise à jour PostgreSQL
|
||||
|
||||
La mise à jour de PostgreSQL peut être faite à chaud selon les
|
||||
procédures Debian normales. Durant la mise à jour, les services ne
|
||||
fonctionneront pas (réponses 5xx) et HAProxy délivrera une erreur «
|
||||
maintenance ». Dès le redémarrage de PostgreSQL, les services Publik
|
||||
rétabliront les connexions vers le serveur SQL et le système sera à
|
||||
nouveau utilisable.
|
||||
|
||||
Attention : si un service de Publik est démarré ou redémarré alors que
|
||||
PostgreSQL n'est pas disponible, ce démarrage ne fonctionnera pas. Il
|
||||
faudra redemander le démarrage explicitement.
|
||||
|
||||
Support
|
||||
-------
|
||||
|
||||
Les moyens de contact pour le support sont :
|
||||
|
||||
- l'extranet projet avec le gestionnaire de demandes (accès réservé) :
|
||||
[https://dev.entrouvert.org/projects/ma](https://dev.entrouvert.org/projects/nanterre-rsu/issues)[c](https://dev.entrouvert.org/projects/nanterre-rsu/issues)[ollectivite](https://dev.entrouvert.org/projects/nanterre-rsu/issues)[/issues](https://dev.entrouvert.org/projects/nanterre-rsu/issues),
|
||||
- la liste de discussion projet (abonnements sur demande) :
|
||||
[ma](mailto:nanterre-rsu@listes.entrouvert.com)[collectivite](mailto:nanterre-rsu@listes.entrouvert.com)[@listes.entrouvert.com](mailto:nanterre-rsu@listes.entrouvert.com),
|
||||
- le courriel spécifique support pour macollectivite (génère
|
||||
automatiquement une demande) :
|
||||
[support-ma](mailto:support-nanterre-rsu@entrouvert.com)[collectivite](mailto:support-nanterre-rsu@entrouvert.com)[@entrouvert.com](mailto:support-nanterre-rsu@entrouvert.com),
|
||||
- le courriel support générique d'Entr'ouvert :
|
||||
<support@entrouvert.com>.
|
||||
|
||||
|
|
@ -3,14 +3,17 @@
|
|||
You can adapt this file completely to your liking, but it should at least
|
||||
contain the root `toctree` directive.
|
||||
|
||||
Welcome to Infrastructure de Publik's documentation!
|
||||
====================================================
|
||||
Infrastructure de Publik
|
||||
========================
|
||||
|
||||
Contents:
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
1_architecture
|
||||
2_installation
|
||||
3_exploitation
|
||||
|
||||
|
||||
Indices and tables
|
||||
|
|
Loading…
Reference in New Issue