EUROMOD est un méta-modèle de micro-simulation statistique permettant de décrire des modèles de politiques fiscales et d'avantages fiscaux basés sur le revenu des ménages dans les pays européens. Ce méta-modèle permet de simuler, d'évaluer et de comparer les différentes politiques adoptées et de donner une estimation de l'impact des incitations au travail sur la population de chaque pays ainsi qu'au niveau de l'ensemble de la zone UE. Il est utilisé à la fois pour calculer les effets des politiques existantes et pour évaluer l'impact des réformes des politiques d'avantages fiscaux sur la pauvreté, les inégalités et les budgets nationaux.

Le modèle est utilisé comme instrument pour effectuer des analyses de scénarios basées sur des simulations à l'aide d'un logiciel statistique client, appelé EUROMOD, facilitant ainsi le travail des chercheurs et des décideurs afin d'évaluer les différentes hypothèses politiques. EUROMOD est un outil universel standardisé pour l'UE : il est conçu pour produire des modèles et des résultats pertinents pour tous les pays européens.

EUROMOD est un outil en libre accès. Il se compose de 3 éléments :

• L’application logicielle
• des règles politiques intégrées qui sont mises à jour via le logiciel pour refléter les politiques existantes au 30 juin de chaque année. Elles enrichissent tous les protocoles standard d'EUROMOD
• les micro-données d'entrée qui sont traitées par le logiciel

Il a été développé par l'Institute for Social and Economic Research (ISER) de l'Université d'Essex. Depuis le 1^er janvier 2021, la gestion a été reprise par le Centre Commun de Recherche de la Commission européenne. (https://commission.europa.eu/JRC).

Au niveau belge, le Service public fédéral - Sécurité sociale souhaite pouvoir, avec l'aide de partenaires, utiliser ce modèle pour aller plus loin et travailler sur des données administratives plus précises provenant de plusieurs sources de données afin de pouvoir estimer à l'avance un certain nombre d'effets des réformes politiques dans le domaine de la protection sociale. Cela concerne à la fois l'impact budgétaire et une estimation des personnes et des familles qui verront principalement leur revenu changer.
Cette partie s'appelle BELMOD : Modèle de micro-simulation sur les avantages fiscaux pour la Belgique.

Le modèle BELMOD a été développé en tant que modernisation de MIMOSIS. Ce projet a pris fin en août/septembre 2022. L'exploitation et la mise à jour de BELMOD (le modèle, pas le projet) est désormais un objectif opérationnel du SPF Sécurité sociale.

Son objectif était double :

• sur le plan technique, le projet vise à moderniser le modèle de micro-simulation actuel du SPF Sécurité sociale (MIMOSIS) et
• sur le plan du contenu, un inventaire des mesures politiques visant à réduire le non-recours (NTU) aux droits sociaux en Belgique sera dressé

Les sources de données supplémentaires sont actuellement les suivantes :

• des données administratives provenant du Datawarehouse Marché du travail & Protection sociale
• des données provenant du Service Public Fédéral - Finances : la banque de données STIPAD/CADNET (patrimoine immobilier) et des données provenant de la banque de données IPCAL relatives aux déclarations d'impôts (fiches de calcul des impôts des citoyens)
• des données STATBEL

Le modèle BELMOD est géré par le SPF Sécurité sociale et a été développé en collaboration avec le Bureau fédéral du Plan, la KU Leuven et l'Université d'Anvers.

Dans ce contexte, il a été demandé à healthdata.be de mettre en œuvre et de fournir une plateforme « Desktops-as-a-Service » permettant aux chercheurs externes d'accéder aux données et de les analyser à distance dans un environnement sécurisé.

Le système d'accès à distance (environnement Citrix) doit permettre aux utilisateurs d'utiliser à distance le logiciel EUROMOD et de consulter les résultats du projet BELMOD sans qu'ils puissent copier les données. En outre, étant donné que les résultats du modèle de micro-simulation sont également des fichiers .txt contenant des données au niveau individuel, ils ne doivent pas pouvoir être téléchargés. Les données sont stockées sur un serveur de fichiers et non dans des bases de données.

La machine SCN-P-XAWBELMOD est un serveur isolé sans accès à Internet.

Plusieurs organisations, en fonction des projets, utiliseront l'environnement BELMOD.  

La BCSS et le SPF Sécurité sociale téléchargeront les données sur le serveur HD SFTP dans le dossier BELMOD_IN. Un processus automatisé déplacera ensuite les fichiers téléchargés vers le serveur BELMOD dans le dossier BELMOD_IN correspondant.

Ces données seront accessibles via la machine Citrix SCN-P-XAWBELMOD pour être analysées par les chercheurs. Les rapports générés sont placés dans un répertoire de validation par les chercheurs. Seul un éditeur de données peut valider les données et déplacer le(s) fichier(s) vers le répertoire d'exportation du projet correspondant. 

Ensuite, les fichiers seront automatiquement téléchargés dans le répertoire BELMOD_OUT du serveur SFTP.

Les utilisateurs accèderont à l'environnement Citrix via le VPN remote.healthstat.be en utilisant leurs comptes provisionnés sur Active Directory (AD).

 

La connexion est vérifiée par le contrôleur Citrix (WIV-P-DDC01), puis les utilisateurs ont accès au serveur BELMOD où les applications sont installées. Ces applications sont utilisées pour effectuer l'analyse.

Le serveur BELMOD est placé dans sa propre OU, séparée de tous les autres serveurs XAW.

Les utilisateurs sont regroupés dans AD. Ces groupes font tous partie de la même OU. Le serveur SCN-P-XAWBELMOD est accessible par deux types de comptes différents. Ces types sont les suivants :

• Utilisateurs normaux : « BELMOD users SCN-P-XAWBELMOD » 
• Utilisateurs limités : « BELMOD users SCN-P-XAWBELMOD limited users »

Dans l'état actuel des choses, les utilisateurs normaux sont autorisés à se connecter à la version bureau du serveur. Les utilisateurs limités ne peuvent se connecter qu'à l'application publiée par EUROMOD. Les utilisateurs limités sont également limités dans leur utilisation du serveur, puisqu'ils ne peuvent pas utiliser des éléments tels que la corbeille, le panneau de contrôle, etc. En outre, tous les utilisateurs ne peuvent pas accéder aux différents lecteurs du serveur.

Les utilisateurs sont regroupés dans ce que l'on appelle des « groupes globaux » dans AD. Ces groupes globaux relèvent tous de la même OU.

L'objet informatique et les différents groupes d'utilisateurs sont tous situés dans le domaine DHD.local.

General description of the application UM-EM

User manual of the application UM-EM

Technical manual of the application UM-EM

Support services UM-EM

Local manager of UM-EM

Service and Support portal of healthdata.be (Sciensano)

General description of the eHealth TTP service

User manual of the eHealth TTP service

Technical manual of the eHealth TTP service

Support services eHealth TTP service

Support portal of eHealth

General description of the application eHBox

User manual of the application eHBox

Technical manual of the application eHBox

Support services eHBox

Local manager of eHBox

Support portal of eHealth

General description of the application eHBox client

User manual of the application eHBox client

Technical manual of the application eHBox client

Support services eHBox client

Local manager of eHBox client

Support portal of healthdata.be (Sciensano)

Dans l'application Bureau du projet BELMOD (machine SCN-P-XAWBELMOD), les restrictions suivantes s'appliquent à tous les utilisateurs :

• pas d'accès à Internet 
• pas d'accès au drive C:\
• impossibilité de vérifier et de modifier les propriétés d'un fichier ou d'un répertoire
• impossibilité d'installer le logiciel
• impossibilité d'éteindre ou de redémarrer le serveur
• pas de copier-coller entre le serveur BELMOD et la machine locale

Il existe deux types distincts d'utilisateurs d'applications :

• Utilisateurs de l'application Euromod : ont accès à l'application Citrix Euromod
• Utilisateurs de l'application complète : ont accès à l'application Bureau Citrix du projet BELMOD contenant toutes les applications demandées (y compris EUROMOD) - voir la liste complète à la section 6.

Il existe également des administrateurs locaux. Ils disposent de privilèges supplémentaires et ont accès à tous les fichiers et répertoires du drive E:\.

Note: Si les administrateurs locaux ont besoin qu'un nouveau projet soit créé, une demande d'information doit être signalée via Service Now (voir la section Comment créer et soumettre une demande d'information) avec le nom du projet, les répertoires correspondants et les utilisateurs ayant besoin d'accéder à ce projet et dans quel(s) groupe(s) ils doivent avoir accès.

Les utilisateurs ont accès au serveur Citrix via le lien suivant →  https://remote.healthstat.be/vpn/index.html

Note: Si de nouvelles informations d'identification sont nécessaires, un administrateur local doit créer et soumettre un ticket Service Now (voir la section Comment créer et soumettre une demande d'information) avec les informations suivantes :

• Prénom, nom
• Numéro de téléphone
• Adresse e-mail
• Utilisateur Citrix à accès limité ou utilisateur Citrix à accès complet
• Accès utilisateur → membre de quel(s) groupe(s) 

Le drive E:\ dispose d'une sauvegarde continue.
Les utilisateurs peuvent restaurer leurs propres fichiers supprimés via l'application « corbeille ».
S'il n'est pas possible de récupérer un fichier, un ticket Service Now peut être créé afin que healthdata.be puisse transmettre la demande de restauration à Arxus.

Le service healthdata.be (Sciensano) traite chaque rapport d'incident selon une procédure opérationnelle standard (POS). Une version publique de cette POS « HD Incident Management Process » est également disponible sur ce portail : docs.healthdata.be.

Pour soumettre un incident lié aux projets et applications en production, et facilités ou gérés par le service healthdata.be de Sciensano, vous devez d'abord vous connecter au portail Services et Support de HD : https://sciensano.service-now.com/sp.

Après l'étape de connexion, vous arriverez sur la page principale du portail.

Lorsque vous vous connectez pour la première fois, vous devez compléter votre profil, par exemple avec des données de contact, afin d'assurer le suivi de votre ticket. Une fois le profil soumis, vous pouvez revenir à la page principale du portail.

Sur la page principale, vous devez sélectionner « Obtenir de l'aide ».

La page suivante « Créer un incident » apparaîtra.

Vous pouvez maintenant documenter votre incident ou problème en fournissant les informations suivantes (les champs marqués d'un * sont obligatoires) :

Veuillez indiquer l'urgence de la résolution de votre problème en fonction de sa criticité pour l'entreprise.

Après avoir sélectionné le Rôle que vous assumez, une liste d'Applications pertinentes pour vous devient disponible : sélectionnez l'application pour laquelle vous rencontrez un problème.

Recherchez et sélectionnez le Projet souhaité en saisissant un mot-clé, le numéro de projet HD ou l'abréviation du projet.

Veuillez décrire clairement et brièvement (1 phrase) l'objet de votre problème.

Veuillez décrire en détail le problème. Les aspects suivants sont importants pour nous permettre de comprendre et de résoudre le problème :

• une description des actions que vous voulez effectuer mais que vous n'arrivez pas à accomplir (Exemples : fournissez-nous le nom du champ, la règle de validation, le bouton, etc.)
• une description (si possible) des étapes séquentielles que vous suivez pour utiliser le service ou l'application de healthdata.be pour lequel vous avez besoin de support
• une brève description du problème technique que vous rencontrez (Exemple : messages d'erreur)

Nous vous recommandons vivement d'ajouter une capture d'écran décrivant le problème (IMPORTANT : Ne nous fournissez pas les données du patient !).

Vous pouvez ajouter la capture d'écran en cliquant sur « Add attachments ».

Sur le côté droit du formulaire, les éléments d'information requis du formulaire d'incident sont énumérés. Lorsque ces champs sont remplis, leurs noms disparaissent de la case « required information » (informations obligatoires).

Le formulaire ne peut être soumis que si tous les champs obligatoires sont remplis, en appuyant sur le bouton vert « Soumettre ».

Si tous les champs obligatoires n'ont pas été remplis, un message d'avertissement apparaîtra en haut du formulaire.

En outre, les champs obligatoires manquants seront mis en évidence en vert.

Lorsque le formulaire d'incident a été soumis avec succès, un aperçu de votre soumission apparaît dans un nouvel écran.

À droite de l'écran, vous trouverez les détails, y compris le numéro de l'incident.

À gauche de l'écran, vous trouverez une chronologie du traitement de votre incident, en commençant par votre création.

Pour introduire une demande d'information, veuillez suivre les instructions de travail de healthdata.be décrites ci-dessous.

Schéma - Aperçu de la procédure

Procédure sous forme d'instructions de travail

ÉTAPE 1. L'utilisateur demande une information

Action : Un utilisateur demande une information. Il peut s'agir :

• d'une explication sur un projet
• d'une liste
• etc.

ÉTAPE 2. Le Service Desk crée un ticket « Request for information » (Demande d'information)

Action : Si l'utilisateur n'a pas créé de ticket à partir du portail, le Service Desk crée un ticket de type Demande d'information au nom de l'utilisateur.

Les champs obligatoires sont le sujet et la description.

La demande est soumise après avoir cliqué sur « Order now ».

ÉTAPE 3. Le Service Desk enquête sur la demande et enrichit la demande

Action : Le Service Desk ouvre l'élément demandé, lié à la demande, et étudie les besoins du demandeur. Si nécessaire, le Service Desk ajoutera des informations de clarification dans le champ « customer communication » (communication avec le client), qui est visible pour l'utilisateur.

ÉTAPE 4. Satisfaire la demande

Action : Si le Service Desk sait comment traiter la demande, il exécute l'action. S'il ne sait pas comment faire, il cherchera d'abord à savoir s'il est en mesure de satisfaire la demande ou s'il doit l'attribuer à un autre groupe d'affectation (étape 6).

ÉTAPE 5. Définir le statut de l'élément demandé comme « Closed Complete »

Action : Le Service Desk ou le groupe d'affectation L2 informe l'utilisateur en saisissant un commentaire aisément compréhensible dans le champ « customer communication » et fait passer le statut de la demande à « Closed Complete ».

ÉTAPE 6. Assigner l'élément demandé au groupe L2

Action : s'il n'est pas possible de répondre à la demande, le Service Desk attribuera la demande à un groupe d'affectation L2.

ÉTAPE 7. Satisfaire la demande

Action : le groupe d'affectation L2 va satisfaire la demande et exécuter l'étape 5.

QUEL EST LE PROBLÈME ?

Nous bloquons les e-mails de votre organisation parce que la configuration de vos services de messagerie et/ou de DNS peut permettre aux spammeurs/pirates informatiques d'en abuser. Plus précisément, votre configuration actuelle permet à d'autres expéditeurs d'usurper l'identité de votre organisation en leur permettant d'imiter le « Header From» de l'e-mail de votre organisation.

En d'autres termes, ils peuvent envoyer des messages de phishing et de spam qu'il est impossible de distinguer des e-mails authentiques de votre organisation.

Si vous êtes responsable de la gestion de votre infrastructure TIC, lisez ce qui suit. Sinon, transmettez ce message à votre département TIC ou au service TIC qui gère votre infrastructure TIC.

COMMENT RÉSOUDRE LE PROBLÈME ?

Vous devez vérifier que votre configuration répond aux exigences de sécurité du « Sender Alignment ». Plus précisément, vos services de messagerie et votre DNS doivent être configurés conformément aux normes TIC.

Ces configurations sont courantes, bien documentées et prises en charge par les hébergeurs :

• https://dmarcian.com/alignment/
• https://mxtoolbox.com/dmarc/spf/spf-alignment
• https://o365info.com/how-does-sender-verification-work-how-we-identify-spoof-mail-the-fiveheros-spf-dkim-dmarc-exchange-and-exchange-online-protection-part-9-of-9/

Nous avons constaté que ce problème est fréquent dans les organisations qui ont déplacé leur infrastructure TIC vers des services en Cloud tels que Microsoft (O365), Amazon, Google et MS Azure sans configurer correctement l'infrastructure TIC (qui n'est pas gérée par ces fournisseurs).

Les configurations et les recommandations doivent être mises en œuvre sur l'infrastructure TIC du client, qu'elle soit interne ou externe. Les DNS et les services de messagerie sont les principales plateformes TIC pour ces actions.

L'UTILISATION DE DIFFÉRENTS DOMAINES LORS DE L'ENVOI D'E-MAILS

Les e-mails contiennent une « Envelope From » et un « Header From ». Les deux doivent correspondre pour éviter que l'e-mail ne soit bloqué.

Quelques exemples :

1. Un service public utilise son nouveau nom de domaine dans le « Header From » en son ancien nom de domaine dans l'« Envelope From ».

• Envelope From = noreply@publicservice.fgov.be
• Header From = noreply@publicservice.belgium.be

➔ Ces e-mails seront bloqués.

Remarque : Comme il s'agit d'une adresse « noreply », l'expéditeur ne remarquera même pas que l'e-mail est rejeté.

2. Une organisation utilise un service Cloud (Freshservice) pour son outil d'assistance et l'« Envelope From » n'a pas été modifié.

• Envelope From = bounces+us.3.52773-helpdesk=organisation.be@emailus.freshservice.com
• Header From = helpdesk@organisation.be

➔ Ces e-mails seront bloqués.

3. Une entreprise utilise un service Cloud (Amazon SES) pour envoyer la notification de l'envoi et « Envelope From » n'a pas été modifié.

• Envelope From = 01020188573f374-96de6437-9134-45f4-8aa6-3e9ac18d5848-000000@euwest-1.amazonses.com
• Header From = noreply@company.be

➔ Ces e-mails seront bloqués.