1.2.3 Principes généraux

1.2.3.1 - Hébergement des applicatifs

Les applicatifs WEB se présentent sous forme de sites statiques. Leur hébergement peut donc se faire via un service cloud dédié ou un serveur WEB classique (HTTPd ou Nginx).

Les applicatifs Java sont autonomes (Tomcat est embarqué via SpringBoot). Ces applicatifs peuvent être déployés sur tout type de VM et automatisés/gérés automatiquement.

1.2.3.2 - Haute disponibilité

Tous les noeuds (applicatif Java et éventuellement serveur WEB classique) sont redondés et disposent de répartition de charge en amont. Le composant Transfert est également redondé (deux instances peuvent travailler en parallele) mais aucune API n’est exposée. Le composant Notification est, lui aussi, redondé mais il n’expose pas d’API publique (accessible via Internet)

1.2.3.3 - Scalabilité

La scalabilité sera à mettre en place en fonction des possibilités offertes par le fournisseur de cloud.

1.2.3.4 - Zone réseau

Les données sont, dans le schéma du chapitre précédent, séparées dans une zone spécifique (nommée DATA). Cette segmentation en zone est très palpable dans les hébergements tradionnels (répondant au pattern défense en profondeur). Dans le CLOUD, cet isolement se matérialise par l’usage d’un service managé (SAAS). La protection réseau n’est donc pas certaine et dépend (encore) du fournisseur de cloud.

L’applicatif Transfert est séparé des autres dans une zone dédiée (nommée BATCH) car les fonctionnalités portées par cet applicatif sont sensibles et qu’il n’a pas besoin d’être exposés à Internet.

Sur le même principe, Les applicatifs Securite et Admin sont séparés dans une zone dédiée (nommée ADMIN) car leur usage est réservé aux personnes ayant des accès bien particuliers, à travers le PROXY ENTRANT ADMIN.

Les applicatifs de la zone APP sont

  • destinés à exposer des services (et donc des données) aux usagers via Internet
  • nécessaires au bon fonctionnement des services exposés (comme Notification)

1.2.3.5 - Sécurisation des appels à PSL

Les APIs publiques exposées par les applicatifs de la zone APP sont sécurisées.

  • Si l’utilisateur est connecté avec un fournisseur d’identité public, cette identification est suffisante pour sécuriser et identifier l’utilisateur lors de tous ces appels.
  • A défaut d’authentification externe, l’utilisateur est néanmoins associé à une identité anonyme via la création d’un token JWT par les APIs afin de fournir un identifiant unique à l’utilisateur à travers toutes les APIs (pour retrouver dans les logs les appels successifs réalisés par un même utilisateur : chargement d’une configuration, téléversement d’un document, sauvegarde/chargement d’un brouillon, soumission d’un télé-dossier, …).

Les APIs internes sont aussi exposées par les applicatifs de la zone APP mais ne sont pas accessibles directement depuis Internet. Mais le token de sécurité à utiliser est le même que celui utilisé pour appeler l’applicatif exposé à Internet.

Les APIs d’administration nécessite un token d’administration basé sur une identité fournie par l’applicatif Securite (LDAP).