| Authentification et Gestion des accès
Quel est le système d’authentification utilisé ?
Le système d’authentification utilisé est le Compte Sage. Le Compte Sage est le système d’authentification du groupe Sage, basé sur le standard OAuth 2.0. Consultez le Centre d’aide dédié Compte Sage pour plus d’informations.
L’authentification multi-facteurs est-elle disponible ? Oui, il est possible d’activer l’authentification multi-facteurs, en paramétrant votre compte Sage. Le lien permettant de configurer votre compte Sage est disponible depuis le portail Sage 100 Hébergée/SPC. Pour cela, allez dans le menu Mon profil > Modifier mes options de sécurité Sage ID.
Le client est-il responsable de l'administration de l'accès des utilisateurs (attribution/révocation de l'accès, etc.) ? Oui, le client est responsable de l’administration des accès des utilisateurs. L’administration des utilisateurs et de leurs droits se fait à travers le portail SPP et sur le portail Online pour les droits d’accès par société.
Accessibilité de l’application Est-il possible de restreindre l’accès aux applications Sage 100 Hébergée/SPC par la mise en place d’un filtrage d’adresses IP ou par un certificat ? Non, le portail Sage 100 Hébergée/SPC est un portail public, commun à tous les utilisateurs et disponible depuis toutes les régions du monde. Il n’y a donc pas de restriction d’adresses IP pour l’accès au Portail.
L’application est-elle accessible à partir d’appareils mobiles ? Oui, l'application Web est conçue pour être accessible à partir d'appareils mobiles, tablettes, etc. La seule condition est que votre navigateur soit compatible Html5 et supporte le protocole Secure Websocket.
Règlement Général de Protection des Données (RGPD) L'accès aux données à caractère sensible/personnel est restreint aux seules personnes habilitées ? Si les clients donnent explicitement leur accord via le portail SPP, les collaborateurs Sage auront accès à leurs données. L’accès des collaborateurs Sage est automatiquement révoqué au bout de 24 heures. - Sage 100 Hébergée :
Les collaborateurs en charge de l'infrastructure (équipe Anglaise dédiée) auront accès à la base de données et aux backups. - Sage 100 SPC :
Les collaborateurs en charge de l'infrastructure (équipe Anglaise dédiée) n’ont pas accès à la base de données. Le partenaire, propriétaire de la souscription, à un accès total aux données.
L'accès aux données personnelles/sensibles est tracé le portail SPP logue tous les accès aux applications et les actions d’administration, lequels sont consultables par l'administrateur du site client.
Ces données sont stockées dans la zone Europe de l'Ouest (Dublin).
Des revues d'accès sont-elles effectuées régulièrement ? Précisez la fréquence Sage ne contrôle pas les accès aux sites réalisés par les clients. Chaque client a cependant la possibilité de vérifier lui même l’ensemble des accès réalisés sur son site, via l’onglet audit sur le portail SPP http://www.sageerponlineservices.com . Sage contrôle uniquement les accès aux sites réalisés par ses collaborateurs. Ce contrôle permet d'assurer que ces accès soient bien effectués dans le cadre de la mission d’assistance des collaborateurs. Sage réalisera ces contrôles une fois par mois.
L'accès physique au serveur stockant les données est-il sécurisé ? Son accès est-il restreint aux seules personnes habilitées (administrateurs) ? Si les données sont stockées/sauvegardées dans le Cloud : le fournisseur garantit-il un stockage en France/UE ? La solution Sage 100 Hébergée/SPC est hébergée sur la plateforme Microsoft Azure.
Plateforme Microsoft Azure garantie toutes ces conditions. Elle est certifiée ISO 27001, ISO 27018, SOC 1, SOC 2, SOC3, FedRAMP, HITRUST, MTCS, IRAP et ENS. Aucun collaborateur de Sage n'a un accès physique à la plateforme Azure.
Les collaborateurs sont-ils sensibilisés aux bonnes pratiques liées à la consultation/traitement de données sensibles ou personnelles ? Chez Sage, tous les collaborateurs, quelle que soit leur position, sont formés à la protection des données et aux bonnes pratiques de sécurité. Il s'agit ici d'une formation continue obligatoire qui est conduite tout au long de l’année.
Existe-il une procédure de notification en cas de perte/violation de données personnelles ou sensibles ? Oui, se référer aux Conditions générales d'utilisation > Annexe 13 > Article 3 > Nos engagements
Politique de sauvegarde ou backup Quelle est la politique de backup des bases de données ? Des sauvegardes automatiques des bases de données sont effectuées selon la fréquence suivante : - 7 sauvegardes quotidiennes, effectuées chaque nuit (persistance 7 jours),
- 1 sauvegarde mensuelle (persistance 1 mois)
- 1 sauvegarde annuelle (persistance 1 an)
A partir de Sage Provisioning Portal : - visualisez les sauvegardes automatiques réalisées
- conservez manuellement dans le Portail jusqu’à 5 sauvegardes
- téléchargez les sauvegardes sélectionnées pour les conserver sur un autre support. Il est recommandé au Client de le faire régulièrement.
 REMARQUE : Avant une mise à jour des applications métiers, une sauvegarde des données est systématiquement opérée.
Prévention des menaces Les données au repos et en transit sont elles chiffrées ? Les données au repos sont chiffrées avec Transparent Data Encryption (TDE). Il est activé par défaut par Microsoft lors de la création d’une nouvelle base de données. Les données en transit sont chiffrées avec le protocole TLS 1.2. Les chaînes de connexion aux bases de données Azure, utilisées par les applications Sage, respectent les recommandations de Microsoft. L'attribut encrypt=true et trustservercertificate=false est présents systématiquement dans les chaînes de connexion.
Avons-nous accès aux rapports de journalisation (par exemple, les échecs de connexion) ? L’administrateur du site client a accès aux logs d’audit depuis le portail SPP. Les échecs de connexion sont gérées au niveau du service d’authentification Compte Sage. Ces logs ne sont pas publics.
La solution a-t-elle été soumise à des tests d'intrusion ou à d'autres évaluations ? La solution Sage 100 Hébergée/SPC est soumise à un test d’intrusion : - A minima, 1 fois par an (le dernier test d’intrusion a eu lieu fin juin 2022)
- Lors de l’ajout de nouvelles fonctionnalités impactant potentiellement la sécurité.
La solution dispose-t-elle de certification (exemple : ISO27001) Non, la solution ne dispose pas de certification.
Le client a-t-il le droit d'auditer l’application, y compris de confier cet audit à un tiers ? Oui, il est possible au client de demander à auditer l’application. La signature d'une clause de confidentialité accompagnera cette demande.
L'équipe de développement est-elle sensibilisée au développement d’applications sécurisées ? Oui, l'équipe de développement est régulièrement formée sur le développement d’applications sécurisées. Un processus de développement sécurisé des applications (SDLC) est en place pour le projet. Les Security Champions ont à charge la bonne exécution de ce process et du haut niveau de sécurité des applications.
Quels sont les composants mis en place par Sage qui permettent de protéger le site ? Un Web Application Firewall protège le portail Sage 100 Hébergée/SPC. Ce dispositif permet de limiter les attaques potentielles subies par le portail. Il permet aussi de maintenir toujours à jour la liste des algorithmes sécurisés. Ces algorithmes sont utilisés pour la communication entre le navigateur Internet et la solution Sage 100 Hébergée/SPC. Un firewall protège chaque base de données. Celui-ci n’autorisant l’accès qu'à certains composants de l’infrastructure Sage 100 Hébergée/SPC. Il autorise aussi que l'accès à la Virtual Machine (VM) du client associée à cette base de données. Les VM des clients ne sont pas exposées sur Internet. La présence d'un antivirus et des règles de firewall sur ces VM limite les flux entrant et sortant.
Le protocole WSS est il sécurisé ? L’usage du protocole WSS (WebSocket Secure) pour encapsuler le flux graphique et les interactions utilisateur (clavier, souris, presse‑papier selon autorisations) est légitime. Dès le passage de HTTP vers WSS, un proxy ne dispose plus de la capacité d'inspecter le contenu. Toutefois, dans l’architecture Sage 100 SPC : - Le flux n’est pas un tunnel réseau générique permettant de transporter autre chose que les messages SparkView.
- Le protocole est strictement borné : aucun client n'injecte de frames arbitraires ou du trafic réseau.
- Aucune communication système ou commande OS ne transite directement ; SparkView interprète les messages et les traduit vers une session RDP locale sur un serveur Windows confiné.
Ce modèle est identique à ceux utilisés par les autres solutions de VDI / Remote Access du marché tel qu’Azure Virtual Desktop, Citrix HDX, VMware Horizon Blast, Chrome Remote Desktop. Par conséquent, il s’agit donc d’un fonctionnement standard du marché, validé par les proxys professionnels (BlueCoat, Zscaler, Prisma, etc.) Risque d’exploitation ou “rebond” à travers le WSS : Sur les craintes d’un rebond d’attaque via le tunnel : - Le flux WSS ne permet aucune communication entrante vers le client ou le partenaire : la session est strictement initiée depuis le navigateur utilisateur.
- Le serveur SparkView n’a aucune visibilité ni connectivité vers le poste utilisateur : aucune communication retour ne s'établit.
- Le serveur applicatif Windows (hébergeant Sage 100) est segmenté et n’a aucun accès au Système d'Information partenaire ou client.
- Le protocole WebSocket dans notre usage ne transporte pas de flux réseau, mais uniquement les frames interprétées par SparkView (affichage, événements clavier/souris).
- Même en cas de vulnérabilité SparkView (comme pour n’importe quel composant logiciel), une exploitation ne permettrait pas d’utiliser le flux WSS comme tunnel de rebond vers le SI client.
En cas d’exploitation d’une faille Sage 100 ou SparkView”, il est rappelé les protections existantes : - Les serveurs Windows sont configurés selon les bonnes pratiques opérées par Sage pour SPC.
- Isolation réseau des serveurs applicatifs, sans communication latérale ou sortante non nécessaire.
- SparkView est configuré en mode restreint, avec les fonctionnalités strictement nécessaires.
- Contrôles anti‑malware sur les serveurs applicatifs.
- Cloisonnement complet entre tenants et entre clients.
- Aucune ouverture réseau entrante depuis le client ou le partenaire, donc aucun canal permettant un rebond.
- Supervision et journaux sur l’activité SparkView / RDP / OS.
- Ce modèle protège autant Sage que le client ou le partenaire, dans les deux sens.
Recommandation opérationnelle : Sur le proxy client, la règle d’autorisation s'applique de manière restreinte : - À une URL unique correspondant au point d’entrée SparkView.
- À un ensemble d’adresses IP publiques Sage dûment communiqué.
- En appliquant une restriction par SNI (Serveur Name Indication), ce qui maintient un niveau de contrôle.
Le proxy client autorise ainsi uniquement les connexions WSS dont le certificat présenté par le serveur correspond exactement au nom de domaine du service SparkView.
Processus de sortie en cas de résiliation du contrat Est-il possible de décrire le processus de sortie ? y compris ce qui se passe lors d'une décision de mettre fin au service ? Il faudra que le client exporte le bacpac de sa base de données, via le portail SPC.  ATTENTION : Le Client dispose d’un délai de 60 jours pour récupérer ses données
A l'issue de cette période : - le site est détruit
- le dernier backup de la base de données est conservé pendant 120 jours avant d'être supprimé définitivement
- les autres backups de la base de données sont supprimés
Spécificités SPC Un client utilise BI Reporting et autorise les adresses IP de ses collaborateurs pour qu’ils accèdent aux données. Y-a-t-il des points de vigilance particuliers ? Il est très important de toujours maintenir à jour la liste des adresses IP des personnes autorisées à accéder à vos données. Il est conseillé de vérifier régulièrement cette liste, pour s'assurer qu’elle corresponde bien aux personnes dont l'accès a été explicitement autorisé. Il est conseillé de réinitialiser régulièrement le mot de passe “BI Reporting”, en cliquant sur le bouton “Réinitialiser” du menu “Paramètres de connexion SQL”. Les experts en sécurité préconisent de changer le mot de passe (password rotation), a minima, tous les 6 mois. Il est aussi conseillé de réinitialiser le mot de passe “BI Reporting” après le départ d’un collaborateur. Réinitialisez-le aussi dès lors qu'il y a un doute sur un accès non autorisé aux données. Le mot de passe “BI Reporting” généré respecte les préconisations de l’OWASP. Cela signifie que le mot de passe est généré de manière aléatoire. Qu’il est composé de lettres majuscules et minuscules, de chiffres et de caractères spéciaux, et que sa longueur est suffisamment longue.
Pour un partenaire avec un client utilisant BI Reporting, y-a-il des points de vigilance particuliers ? Les bases SQL Azure sont exposées dans le cloud. Pour protéger vos données et celles de vos clients, appliquez les bonnes pratiques suivantes, recommandées par Microsoft. - Activez Transparent Data Encryption (TDE) sur la base de données SQL Azure :
TDE est activé par défaut, lors du provisioning de la base de données par SEOS - Activez l’audit de la base de données SQL Azure pour traquer et de loguer les événements de base de données :
L’audit n’est pas activé par défaut, lors du provisioning de la base de données par SEOS - Activez la détection des menaces pour être alerté en cas d’activité anormale sur la base de données :
Microsoft Defender for SQL n’est pas activé par défaut. Cependant, il est possible d’activer la détection des menaces au niveau de la souscription. Cette activation permet d'auditer l’ensemble des ressources et pas uniquement les bases de données - Activez SQL Vulnerability Assessment pour identifier les vulnérabilités de la base de données :
SQL Vulnerability Assessment n’est pas activé par défaut. Cependant, il est possible d’activer Vulnerability Assesment au niveau de la souscription. Cette activation permet d'auditer l’ensemble des ressources et pas uniquement les bases de données Pour tout complément d’information, se référer à la documentation officielle de Microsoft :
Liens utiles Erreur 1250 sur les produits online |