Politique de sécurité de l'information

1. Objet

La présente politique établit les règles que Chwezi Core Systems Limited (« Chwezi », « nous ») applique pour protéger la confidentialité, l’intégrité et la disponibilité des informations que nous détenons, des systèmes que nous concevons et hébergeons, et des environnements clients dans lesquels nous intervenons. Elle indique au personnel, aux prestataires et aux clients quels contrôles existent, qui en est responsable et à quelle fréquence ils s’exercent.

2. Champ d’application

La présente politique s’applique :

• à tout dirigeant, employé, stagiaire, prestataire et consultant travaillant pour Chwezi (« le personnel ») ;
• à toutes les informations que Chwezi crée, reçoit ou détient, sous quelque forme que ce soit, y compris les données clients conservées dans les systèmes que nous hébergeons ;
• à tous les systèmes que nous possédons, louons ou exploitons : ordinateurs portables et téléphones utilisés à des fins professionnelles, dépôts de code source, serveurs cloud et dédiés, outils de messagerie et de collaboration, ainsi que les produits logiciels que nous développons et hébergeons (notamment Kraal Code, Maduuka et Aqar) ;
• aux travaux réalisés dans les locaux des clients ou dans les systèmes des clients, y compris les évaluations de cybersécurité et les installations de vidéosurveillance (CCTV) et de contrôle d’accès.

Lorsqu’un contrat client impose une exigence de sécurité plus stricte que la présente politique, l’exigence contractuelle s’applique aux travaux réalisés pour ce client.

3. Définitions

4. Déclaration de politique et principes

Chwezi protège l’information en proportion du préjudice que causerait sa perte ou son utilisation abusive. Quatre principes régissent l’application des règles de la présente politique :

1. Moindre privilège. Une personne ou un système ne reçoit que l’accès nécessaire à la tâche en cours, et le perd lorsque la tâche prend fin.
2. Défense en profondeur. Aucun contrôle n’est utilisé isolément ; les systèmes de production sont protégés conjointement par des contrôles portant sur le réseau, l’identité, les applications et la surveillance.
3. Sécurité dès la conception. Les exigences de sécurité sont définies dès le début de chaque projet logiciel, et non ajoutées après la mise en production.
4. La preuve plutôt que l’affirmation. Chaque contrôle produit un enregistrement (journal, validation de revue, résultat de test) qui démontre qu’il a fonctionné.

Notre ensemble de contrôles est structuré autour des quatre thèmes de contrôle de la norme ISO/IEC 27001:2022 (organisationnel, humain, physique et technologique). Chwezi ne détient pas actuellement de certification ISO/IEC 27001.

5. Gouvernance, rôles et responsabilités

6. Gestion des risques et inventaire des actifs

6.1 Le Responsable de la sécurité de l’information doit tenir un registre des risques liés à la sécurité de l’information, en consignant pour chaque risque son responsable, sa probabilité, son impact, son traitement et sa date de revue.

6.2 Le Responsable de la sécurité de l’information doit revoir le registre des risques au moins tous les six mois, ainsi qu’à chaque introduction d’un nouveau produit, d’un nouvel hébergeur ou d’un système client majeur.

6.3 Le Responsable de la sécurité de l’information doit tenir un inventaire des serveurs de production, des domaines, des comptes cloud, des dépôts de code et des appareils professionnels, avec un responsable nommément désigné pour chaque entrée.

6.4 Un chef de projet ne doit pas commencer les travaux sur un nouveau système client destiné à détenir des données personnelles ou financières tant que ses risques de sécurité n’ont pas été évalués et consignés.

7. Classification et traitement de l’information

7.1 Chwezi classe l’information en quatre niveaux :

7.2 Toute information non étiquetée doit être traitée comme Confidentielle.

7.3 Le personnel ne doit pas coller d’informations Confidentielles ou Restreintes, y compris des données clients et du code source, dans des outils publics d’intelligence artificielle, des sites de partage de fichiers ou des groupes de messagerie que Chwezi n’a pas approuvés à cette fin.

7.4 Le personnel doit éliminer de manière sécurisée les informations Confidentielles et Restreintes : les documents papier par déchiquetage, et les supports de stockage par effacement sécurisé ou destruction physique, l’élimination étant consignée.

8. Sécurité liée au personnel

8.1 Avant d’accorder l’accès à des informations Restreintes, Chwezi doit vérifier l’identité et les références du nouveau membre du personnel ou du prestataire, dans la mesure permise par la loi.

8.2 Chaque membre du personnel et chaque prestataire doit signer un accord de confidentialité avant de recevoir l’accès à des informations Confidentielles ou Restreintes. Cette obligation se poursuit après la fin de la collaboration.

8.3 Chaque membre du personnel et chaque prestataire doit suivre une formation de sensibilisation à la sécurité et à la protection des données au cours de son premier mois, puis au moins une fois par an. Le Responsable de la sécurité de l’information doit tenir un registre des formations.

8.4 Lorsqu’une personne quitte Chwezi ou change de fonction, son responsable hiérarchique doit en informer le Responsable de la sécurité de l’information au plus tard le dernier jour de travail de cette personne. Le Responsable de la sécurité de l’information doit supprimer, dans un délai d’un jour ouvrable, tous les accès dont la personne n’a plus besoin, et la personne doit restituer les appareils et les informations de l’entreprise.

9. Utilisation acceptable

9.1 Le personnel peut utiliser les systèmes de Chwezi à des fins professionnelles et pour un usage personnel limité qui n’enfreint ni la présente politique ni la loi.

9.2 Le personnel ne doit pas :

• partager des mots de passe, des dispositifs d’authentification ou des comptes ;
• tenter d’accéder à des systèmes, des données ou des comptes qu’il n’a pas été autorisé à utiliser ;
• installer des logiciels sans licence ou désactiver les logiciels de sécurité sur les appareils professionnels ;
• connecter des appareils professionnels détenant des informations Restreintes à des réseaux non fiables sans le VPN approuvé ou une connexion chiffrée ;
• utiliser les systèmes de Chwezi pour harceler, diffamer ou porter atteinte aux droits d’autrui, ou pour tout acte constituant une infraction au titre du Computer Misuse Act, 2011 (loi ougandaise de 2011 sur l’usage abusif de l’informatique) ou de toute autre loi applicable.

9.3 Chwezi peut surveiller ses propres systèmes et comptes à des fins de sécurité. Cette surveillance est limitée à ce qui est nécessaire pour protéger les systèmes et les données et est effectuée conformément à la Politique de protection des données et de la vie privée.

10. Contrôle d’accès et authentification

10.1 Les propriétaires de systèmes doivent accorder les accès selon le principe du besoin d’en connaître, au moyen de comptes individuels nominatifs. Le personnel ne doit pas utiliser de comptes partagés, sauf lorsqu’un système en exige techniquement un ; dans ce cas, le propriétaire du système doit conserver ses identifiants dans le gestionnaire de mots de passe et journaliser son utilisation.

10.2 Le propriétaire du système doit approuver et consigner chaque attribution d’accès à un système de production, à un système client ou à un dépôt de code.

10.3 Les Administrateurs systèmes doivent activer l’authentification multifacteur (MFA) sur la messagerie, les dépôts de code, les panneaux de contrôle cloud et d’hébergement, les gestionnaires de mots de passe, l’accès à distance et tout compte disposant d’un accès privilégié.

10.4 Le personnel doit utiliser des mots de passe d’au moins 12 caractères, uniques pour chaque système, conservés uniquement dans le gestionnaire de mots de passe approuvé par Chwezi, et doit changer immédiatement un mot de passe s’il soupçonne qu’il a été compromis.

10.5 Les administrateurs doivent utiliser un compte privilégié distinct, ou une élévation de privilèges limitée dans le temps, pour les tâches d’administration ; ils ne doivent pas utiliser de comptes privilégiés pour la messagerie ou la navigation sur le web.

10.6 Les Administrateurs systèmes doivent utiliser des clés SSH ou une méthode équivalente fondée sur des certificats pour l’accès aux serveurs, et doivent désactiver la connexion par mot de passe pour l’administration des serveurs de production.

10.7 Le Responsable de la sécurité de l’information doit revoir les droits d’accès aux systèmes de production, aux comptes cloud et aux dépôts de code au moins tous les trois mois, et supprimer les accès qui ne sont plus nécessaires.

10.8 Les Responsables techniques doivent veiller à ce que les produits logiciels que nous hébergeons offrent un contrôle d’accès fondé sur les rôles, des délais d’expiration de session et des pistes d’audit, afin que chaque client puisse appliquer le principe du moindre privilège au sein de sa propre organisation.

11. Cryptographie

11.1 Les Administrateurs systèmes doivent configurer chaque système de Chwezi de manière à chiffrer les données transmises sur des réseaux publics au moyen de TLS 1.2 ou d’une version supérieure, et chaque site web et application que nous hébergeons de manière à rediriger le HTTP en clair vers le HTTPS.

11.2 Les Administrateurs systèmes doivent chiffrer au repos les informations Restreintes, y compris les bases de données de production et les sauvegardes des clients, au moyen d’AES-256 ou d’un algorithme actuel équivalent, par chiffrement du disque, du volume ou de la base de données.

11.3 Chaque ordinateur portable professionnel doit avoir le chiffrement intégral du disque activé avant d’être utilisé pour les travaux de Chwezi.

11.4 Les clés de chiffrement, les secrets d’API et les certificats doivent être conservés dans le gestionnaire de mots de passe ou dans un coffre-fort de secrets dédié, jamais dans le code source ni dans des documents partagés. Leur accès doit être limité aux personnes qui exploitent le système.

11.5 Les Administrateurs systèmes doivent renouveler les certificats avant leur expiration et doivent utiliser le renouvellement automatique lorsque la plateforme le permet.

12. Hébergement, infrastructure et sécurité des réseaux

12.1 Chwezi héberge ses systèmes et sites web auprès de fournisseurs de centres de données et de services cloud reconnus. Certains de nos systèmes et sites web sont hébergés sur des serveurs situés aux États-Unis d’Amérique, en Finlande et en Allemagne. Le Responsable de la sécurité de l’information doit tenir un registre indiquant dans quel pays et par quel fournisseur chaque système est hébergé, et doit le communiquer à un client qui en fait la demande pour les systèmes de ce client.

12.2 Chwezi doit sélectionner des hébergeurs qui exploitent des centres de données physiquement sécurisés, dotés d’un accès contrôlé et d’une alimentation électrique et d’un refroidissement résilients, et qui publient des attestations de sécurité indépendantes (telles qu’une certification ISO/IEC 27001 ou des rapports SOC 2).

12.3 Lorsqu’un contrat client exige que ses données soient hébergées dans un pays ou une région déterminés, Chwezi doit y héberger les données de ce client et ne doit pas les déplacer sans l’accord écrit du client.

12.4 Les Administrateurs systèmes doivent renforcer chaque serveur de production avant sa mise en service : services inutilisés désactivés, identifiants par défaut supprimés, pare-feu hôte activé avec uniquement les ports nécessaires ouverts, et interfaces d’administration restreintes aux adresses approuvées ou au VPN.

12.5 Les Responsables techniques doivent maintenir séparés les environnements de production, de préproduction et de développement. Le personnel ne doit pas copier de données personnelles réelles de clients vers des environnements de développement ou de test, sauf si elles ont été anonymisées ou si le client a donné son accord par écrit.

12.6 Les Administrateurs systèmes ne doivent pas exposer directement les serveurs de bases de données à l’internet public.

12.7 Les Administrateurs systèmes doivent mettre en œuvre une protection contre les logiciels malveillants ou une surveillance de l’intégrité des fichiers sur les serveurs de production, et doivent activer la limitation du débit ou le blocage des tentatives de connexion échouées répétées sur les services exposés à internet.

12.8 Les Administrateurs systèmes doivent protéger les domaines de messagerie de Chwezi au moyen d’enregistrements SPF, DKIM et DMARC, et doivent maintenir activé le filtrage du spam et de l’hameçonnage sur les boîtes aux lettres de l’entreprise. Le personnel doit signaler les messages d’hameçonnage présumés au Responsable de la sécurité de l’information et ne doit pas en ouvrir les liens ni les pièces jointes.

13. Développement logiciel sécurisé

13.1 Chaque projet logiciel doit consigner ses exigences de sécurité, y compris ses besoins en matière d’authentification, d’autorisation, de protection des données et de journalisation, avant le début du développement.

13.2 Les développeurs doivent suivre des pratiques de codage sécurisé couvrant les risques de l’OWASP Top 10, notamment les requêtes de base de données paramétrées, l’encodage des sorties, la validation des entrées côté serveur et la gestion sécurisée des sessions.

13.3 Les développeurs doivent conserver l’ensemble du code source dans des dépôts contrôlés par Chwezi, avec l’authentification multifacteur (MFA) imposée. Un second développeur ou le responsable technique doit revoir chaque modification avant sa fusion dans une branche de production ; un correctif d’urgence peut être mis en production en premier, mais doit être revu dans un délai de deux jours ouvrables après sa mise en production.

13.4 Les développeurs ne doivent pas enregistrer de secrets dans les dépôts. Si un secret est enregistré, le développeur doit le signaler, et le propriétaire du système doit le révoquer et le remplacer sur-le-champ ; sa seule suppression de l’historique ne suffit pas.

13.5 Les développeurs doivent vérifier les bibliothèques et dépendances tierces au regard des vulnérabilités connues avant chaque mise en production, et au moins une fois par mois pour les systèmes en production.

13.6 Le responsable technique doit approuver chaque mise en production, et celle-ci doit être déployée selon un processus reproductible permettant un retour en arrière. Un développeur ne doit pas approuver sa propre modification pour la mise en production ; lorsque l’équipe est trop réduite pour séparer les rôles, le fondateur et directeur technique doit revoir le registre de mise en production.

13.7 Le responsable technique doit faire soumettre à des tests de sécurité, avant leur mise en service, chaque nouvelle version majeure d’un produit hébergé et tout système traitant des informations de paiement ou de santé, au minimum par revue de code et analyse des vulnérabilités.

14. Gestion des vulnérabilités et des correctifs

14.1 Les Administrateurs systèmes doivent appliquer les mises à jour de sécurité aux systèmes d’exploitation, serveurs web, bases de données et cadres applicatifs selon le calendrier suivant, à compter de la date à laquelle un correctif est disponible :

14.2 Si un correctif ne peut être appliqué dans les délais, le propriétaire du système doit en consigner la raison et appliquer un contrôle compensatoire, et le Responsable de la sécurité de l’information doit approuver le report.

14.3 Le Responsable de la sécurité de l’information doit faire procéder à une analyse des vulnérabilités des systèmes exposés à internet au moins tous les trois mois et après toute modification majeure.

14.4 Le Responsable de la sécurité de l’information doit organiser un test d’intrusion de chaque produit hébergé détenant des données personnelles de clients au moins une fois par an et après toute modification architecturale majeure. Le testeur ne doit pas être un développeur du produit testé. Les vulnérabilités de gravité élevée et critique doivent être corrigées dans les délais prévus à la section 14.1.

14.5 Toute personne peut signaler de bonne foi une vulnérabilité découverte dans un système de Chwezi à l’adresse info@chwezicore.com. Le Responsable de la sécurité de l’information doit accuser réception du signalement dans un délai de 5 jours ouvrables et consigner son évaluation.

15. Journalisation et surveillance

15.1 Les Administrateurs systèmes doivent configurer les systèmes de production de manière à journaliser les événements d’authentification, les actions privilégiées, les modifications des paramètres de sécurité et les erreurs applicatives. Les Responsables techniques doivent veiller à ce que les produits hébergés conservent une piste d’audit des actions significatives des utilisateurs sur les enregistrements métier.

15.2 Les Administrateurs systèmes doivent protéger les journaux contre toute altération et les conserver pendant au moins 12 mois, sauf si un contrat client ou la loi exige une durée différente.

15.3 Les Administrateurs systèmes doivent surveiller les systèmes de production en ce qui concerne la disponibilité, les schémas de connexions échouées et les activités inhabituelles, avec des alertes envoyées à l’administrateur responsable.

15.4 Les Administrateurs systèmes doivent synchroniser les horloges des systèmes sur une source de temps fiable afin que les journaux puissent être corrélés.

16. Sauvegarde, continuité d’activité et reprise après sinistre

16.1 Les Administrateurs systèmes doivent sauvegarder les bases de données de production et les données clients au moins une fois par jour, chiffrer les sauvegardes et les stocker dans un centre de données différent de celui du serveur principal.

16.2 Les Administrateurs systèmes doivent conserver les sauvegardes pendant au moins 30 jours, sauf si un contrat client prévoit une durée différente.

16.3 Les Administrateurs systèmes doivent tester la restauration à partir des sauvegardes au moins tous les trois mois, pour au moins un système de production par rotation, et en consigner le résultat.

16.4 Le Responsable de la sécurité de l’information doit tenir à jour, pour chaque produit hébergé, un plan de reprise après sinistre qui précise les étapes de reprise, les personnes responsables ainsi que le délai de reprise et le point de reprise convenus avec les clients.

16.5 Chwezi doit conserver le code source, la configuration de l’infrastructure et la documentation sous une forme permettant de reconstruire un système de production chez un autre fournisseur en cas de défaillance du fournisseur principal.

17. Terminaux, appareils mobiles et travail à distance

17.1 Le personnel doit veiller à ce que chaque ordinateur portable et téléphone professionnel qui accède à des informations Confidentielles ou Restreintes dispose d’un verrouillage de l’écran, du chiffrement intégral de l’appareil, des mises à jour de sécurité courantes et, pour les ordinateurs portables, d’une protection active contre les logiciels malveillants.

17.2 Le personnel peut utiliser un téléphone personnel pour la messagerie électronique et instantanée professionnelle uniquement si celui-ci dispose d’un verrouillage de l’écran et des mises à jour courantes, et uniquement au moyen d’applications dont Chwezi peut fermer la session à distance.

17.3 Le personnel doit signaler immédiatement la perte ou le vol d’un appareil au Responsable de la sécurité de l’information, afin que les sessions puissent être révoquées et l’appareil effacé lorsque cela est possible.

17.4 Lorsqu’il travaille à distance ou dans des lieux publics, le personnel doit verrouiller les appareils laissés sans surveillance et prendre des précautions raisonnables pour que les écrans ne puissent être vus ni les conversations entendues par des tiers.

18. Sécurité physique

18.1 La dernière personne à quitter un bureau de Chwezi doit le fermer à clé. Le personnel doit accompagner les visiteurs dans les zones où des informations Confidentielles sont traitées.

18.2 Le personnel doit conserver dans un rangement fermé à clé, lorsqu’ils ne sont pas utilisés, les documents papier et les supports amovibles contenant des informations Confidentielles ou Restreintes.

18.3 Chwezi n’exploite pas son propre centre de données. La sécurité physique des serveurs est assurée par les hébergeurs sélectionnés conformément à la section 12.2.

19. Fournisseurs et tiers

19.1 Avant qu’un fournisseur ne reçoive l’accès à des informations Confidentielles ou Restreintes ou à des systèmes de production, le Responsable de la sécurité de l’information doit évaluer ses contrôles de sécurité et le lieu de ses traitements.

19.2 Le fondateur et directeur technique ne doit pas signer de contrat avec un tel fournisseur à moins que celui-ci ne comporte des obligations de confidentialité, de sécurité et de notification des violations, ainsi que des clauses relatives au traitement des données lorsque des données personnelles sont concernées.

19.3 Le propriétaire du système doit limiter l’accès du fournisseur à ce que requiert le service, l’accorder au moyen de comptes nominatifs et le supprimer à la fin du service.

20. Gestion des incidents

20.1 Toute personne doit signaler immédiatement un incident de sécurité présumé au Responsable de la sécurité de l’information, par téléphone au +256 784 464178 ou par courriel à info@chwezicore.com avec l’objet « SECURITY INCIDENT » (incident de sécurité). Le personnel ne doit pas mener d’investigation au-delà de ce qui est nécessaire pour contenir l’incident et ne doit pas supprimer d’éléments de preuve.

20.2 Le Responsable de la sécurité de l’information doit diriger la réponse selon les étapes suivantes : identification, confinement, éradication, rétablissement et revue, en tenant un registre écrit de l’incident consignant les heures, les actions et les décisions.

20.3 Lorsqu’un incident affecte le système ou les données d’un client, Chwezi doit en informer l’interlocuteur désigné du client dans les meilleurs délais, et en tout état de cause dans un délai de 72 heures à compter de la confirmation de l’incident, sauf si le contrat client prévoit un délai plus court. Chwezi doit fournir au client les informations dont il a besoin pour satisfaire à ses propres obligations légales.

20.4 Lorsqu’un incident constitue une violation de données personnelles, le Délégué à la protection des données doit assurer la notification au Personal Data Protection Office et aux personnes concernées conformément à la Politique de protection des données et de la vie privée (CCS-POL-DPP-02).

20.5 Après chaque incident significatif, le Responsable de la sécurité de l’information doit tenir une revue dans un délai de 10 jours ouvrables, consigner la cause première et suivre les actions correctives jusqu’à leur achèvement.

21. Missions clients et travaux sur site

21.1 Le personnel doit réaliser les évaluations de cybersécurité, les analyses de vulnérabilités et les tests d’intrusion sur les systèmes des clients uniquement en vertu d’une autorisation écrite du client définissant le périmètre, le calendrier et les interlocuteurs. Les testeurs doivent rester dans ce périmètre.

21.2 Les résultats des évaluations de sécurité constituent des informations Restreintes. Le responsable de mission doit les partager uniquement avec les interlocuteurs autorisés du client et doit les supprimer ou les restituer à la fin de la mission, sauf accord contraire écrit du client.

21.3 Pour les installations de vidéosurveillance (CCTV), de contrôle d’accès et de détection d’intrusion, les installateurs doivent changer les mots de passe par défaut avant la remise, confier au client le contrôle exclusif des identifiants administrateur et ne doivent pas conserver d’accès à distance après la remise, sauf si le client l’a accepté dans un contrat de support.

21.4 Le personnel intervenant dans les locaux des clients ou dans les systèmes des clients doit respecter les propres règles de sécurité du client en plus de la présente politique.

22. Conformité, dérogations et manquements à la politique

22.1 Chwezi doit se conformer aux lois applicables à ses traitements d’informations, notamment le Data Protection and Privacy Act, 2019 (loi ougandaise de 2019 sur la protection des données et de la vie privée) et le Computer Misuse Act, 2011 de l’Ouganda, ainsi qu’aux lois des autres pays où nous servons des clients ou hébergeons des données, dans la mesure où elles s’appliquent.

22.2 Une dérogation à la présente politique ne peut être accordée que par le fondateur et directeur technique, par écrit, pour une période définie, le risque et tout contrôle compensatoire étant consignés dans le registre des risques.

22.3 Les manquements présumés à la présente politique doivent être signalés au Responsable de la sécurité de l’information. Le Responsable de la sécurité de l’information mène l’enquête ; le fondateur et directeur technique statue sur la suite à donner. Un manquement commis par un membre du personnel peut entraîner des mesures disciplinaires pouvant aller jusqu’au licenciement ; un manquement commis par un prestataire ou un fournisseur peut entraîner la résiliation du contrat. Les manquements susceptibles de constituer une infraction pénale peuvent être signalés aux autorités.

23. Suivi, revue et documents connexes

23.1 Le Responsable de la sécurité de l’information doit rendre compte au fondateur et directeur technique au moins tous les trois mois des incidents, des résultats des revues des accès, de la conformité des correctifs, des résultats des tests de sauvegarde et des risques ouverts.

23.2 Le Responsable de la sécurité de l’information doit revoir la présente politique au moins une fois par an, et plus tôt à la suite d’un incident significatif, d’une évolution de la loi ou d’une modification majeure de nos systèmes ou de notre hébergement.

23.3 Le Responsable de la sécurité de l’information doit conserver le registre des risques, l’inventaire des actifs, les enregistrements des revues des accès, les registres des formations, les registres des incidents, les résultats des tests de sauvegarde et les approbations de dérogations pendant au moins trois ans, dans le référentiel documentaire contrôlé de Chwezi.

23.4 Documents connexes :

• Politique de protection des données et de la vie privée (CCS-POL-DPP-02) ;
• Conditions d’utilisation, publiées sur chwezicore.com ;
• contrats clients et accords de traitement des données, qui peuvent ajouter des exigences propres à chaque client.

24. Historique des revues et des approbations

Approuvé pour le compte et au nom de Chwezi Core Systems Limited
Peter Bamuhigire, fondateur et directeur technique — 27 octobre 2026