Sécurité et conformité

Pas seulement une affirmation — une pile. Cette page documente notre architecture de sécurité, notre alignement réglementaire et notre gouvernance. Construite pour la diligence raisonnable en approvisionnement.

🇨🇦

Souveraineté canadienne

Les données restent au Canada. Infrastructure hébergée au Canada ou contrôlée par le client.

🛡️

Conception sécuritaire

Zéro télémétrie par défaut. Accès au besoin de savoir. Déconnectable.

📋

Prête pour l'approvisionnement

SPAC, CCCS et documentation SR&ED. Ouverte à l'audit.

1. Souveraineté et résidence des données

Pour les clients gouvernementaux et réglementés, la souveraineté des données est non négociable. Nous la traitons comme une architecture, pas une politique.

Infrastructure canadienne par défaut

  • Laboratoire principal physiquement situé au Nouveau-Brunswick, Canada.
  • Toutes les données client traitées et stockées au Canada, sauf demande explicite contraire.
  • Les déploiements cloud utilisent uniquement des régions canadiennes (nœuds CDN Cloudflare, pas de calcul).

Aucune dépendance de données étrangère

  • Aucun service cloud géré américain pour les charges de travail Protégées.
  • Aucun service d'analyse, de suivi ou de télémétrie tiers avec traitement de données à l'étranger.
  • Pour les charges de travail protégées/client, l'inférence IA est locale ou contrôlée par le client par défaut ; les données client ne sont pas envoyées à des API IA étrangères sauf demande explicite et approbation écrite.

Environnements contrôlés par le client

  • Travail livré à une infrastructure contrôlée par le client dans la mesure du possible.
  • Accès au référentiel accordé au client — nous ne détenons jamais les seules clés.
  • Déploiement sur site pris en charge pour les environnements isolés ou sensibles.

2. Architecture de sécurité

La sécurité est en couches — pas un seul outil. Chaque couche est inspectable et vérifiable.

Couche 1 : Sécurité physique

  • Matériel dédié dans un espace privé à accès contrôlé.
  • Aucune colocation ni centre de données partagé.
  • Matériel propriétaire, pas loué ou emprunté au cloud.

Couche 2 : Sécurité réseau

  • Développement local uniquement. Aucun accès distant aux machines de build.
  • Règles de pare-feu en refus par défaut. Seuls les ports requis sont ouverts.
  • VPN requis pour toute administration à distance (site à site, pas de point d'accès public).

Couche 3 : Sécurité applicative

  • Sortie statique (Astro + Bun) — aucune surface d'attaque côté serveur à l'exécution.
  • Les dépendances sont contrôlées par le fichier bun.lock ; les preuves de revue ou d'audit peuvent être fournies lorsque requis.
  • Aucun traqueur JavaScript tiers, ni analytique, ni script externe.
  • Zéro télémétrie à l'exécution par conception : les pages de contenu ordinaires ne chargent pas d'analytique, de traqueurs ou de scripts externes tiers.

Couche 4 : Sécurité de la chaîne d'approvisionnement

  • Les builds sont contrôlés par fichier de verrouillage et la sortie statique peut être reproduite depuis la source pour examen.
  • Hash de commit Git = identifiant de déploiement. Traçabilité un-à-un.
  • Tous les outils de build open source et vérifiables (Astro, Bun, Tailwind).
  • Pertinent pour les exigences de SBOM (Software Bill of Materials).

Couche 5 : Sécurité humaine

  • Un principal nommé avec pleine responsabilité. Aucune entité écran, aucun sous-traitant caché.
  • Base du besoin de savoir pour toutes les données client.
  • ACN et confidentialité liant tout le personnel.

3. Posture de cybersécurité

Alignée avec les directives du Centre canadien pour la cybersécurité (CCCS) et les exigences d'approvisionnement émergentes.

Alignement ITSG-33 / ITSG-37

  • Conçu pour se mapper aux bases de référence de sécurité du gouvernement canadien lorsque applicable ; une cartographie formelle des contrôles peut être produite par engagement.
  • Contrôles d'accès (AC), d'audit (AU) et d'intégrité système (SI) documentés.
  • Catégorisation de sécurité disponible pour les charges de travail Protégé B sur demande.

Préparation en réponse aux incidents

  • Plan de réponse aux incidents défini : détecter → contenir → éradiquer → récupérer → documenter.
  • Notification client dans les 24 heures de toute suspicion de brèche de données.
  • Canaux de signalement à la GRC et au CCCS documentés pour les incidents applicables.

Surveillance continue

  • Journaux système locaux conservés pour analyse médico-légale.
  • L'historique du référentiel est maintenu dans Git avec auteur, horodatage et traçabilité de déploiement ; les commits signés peuvent être utilisés pour les engagements exigeant une provenance plus forte.
  • Chaque build peut être retracé vers l'historique source et les dossiers de déploiement.

4. Contrôle d'accès et identité

Authentification

  • Authentification à deux facteurs (2FA) appliquée aux comptes administratifs et services tiers lorsque prise en charge.
  • Aucune identité partagée. Comptes individuels uniquement.
  • Gestionnaires de mots de passe utilisés pour le stockage sécurisé des identifiants.

Autorisation

  • Contrôle d'accès basé sur les rôles (RBAC) pour les environnements clients.
  • Besoin de savoir : seuls les individus travaillant directement sur un projet y ont accès.
  • Sous-traitants (éventuels) provisionnés avec des comptes aux privilèges minimaux et limités dans le temps.

Gestion du cycle de vie

  • Accès automatiquement révoqué à la fin du projet ou en cas de résiliation.
  • Rotation des identifiants en cas de suspicion de compromission.
  • Aucun accès administrateur permanent aux systèmes de production client.

5. Confidentialité et traitement des données

La confidentialité n'est pas de la conformité — c'est un principe fondamental. Nous concevons des systèmes qui ne collectent rien par défaut.

Alignement LPRPDE / LACRPCP

  • Minimisation des données : nous ne collectons que ce qui est requis pour le projet.
  • Limitation de la finalité : les données sont utilisées uniquement à la fin déclarée, pas pour l'analytique ou l'entraînement d'IA.
  • Base du consentement : consentement explicite et documenté avant tout traitement de données personnelles.
  • Accès et correction : les clients peuvent demander toutes les données que nous détenons ; les corrections sont faites rapidement.

Architecture sans télémétrie

  • Les pages publiques elect-rix ne chargent pas de scripts d'analytique ou de suivi comportemental tiers.
  • Pas de Google Analytics, ni Pixel Meta, ni Hotjar, ni Mixpanel.
  • Aucun cookie d'analytique elect-rix n'est défini ; Cloudflare est utilisé pour la livraison du site public, la mise en cache et la protection de base en périphérie.
  • C'est vérifiable : inspectez l'onglet réseau sur les pages de contenu ordinaires — aucune police, analytique ou script de suivi tiers n'est chargé par le site.

Notes de vérification du site public

  • elect-rix.tech est servi comme site statique ; aucun serveur applicatif ne traite les données de formulaires visiteurs sur les pages de contenu ordinaires.
  • Aucun script côté client n'est chargé par cette page.
  • Aucun outil d'analytique, pixel publicitaire ou suivi comportemental n'est installé.
  • Aucun cookie d'analytique n'est défini par elect-rix.
  • Cloudflare est utilisé uniquement pour la livraison du site public, la mise en cache, TLS et la protection de base en périphérie ; les journaux opérationnels en périphérie ne sont pas utilisés comme analytique marketing elect-rix.

Conservation et destruction des données

  • Données client conservées uniquement pendant la durée de l'engagement.
  • Après le projet : retour de tous les artefacts ou destruction selon instruction écrite.
  • Aucune copie conservée dans des lecteurs personnels, courriels ou stockage non sécurisé.
  • Certificats de destruction disponibles sur demande.

6. Conformité réglementaire

elect-rix.tech est structurée pour s'aligner sur les cadres réglementaires fédéraux et provinciaux canadiens.

Réglementation / Cadre Alignement
LPRPDE Confidentialité par conception. Minimisation des données. Zéro télémétrie. Basé sur le consentement.
LACRPCP (NB / NS / PEI / TN) Traitement des dossiers gouvernementaux. Contrôles d'accès. Protocoles de destruction.
ITSG-33 / ITSG-37 Base de référence des contrôles de sécurité. Évaluation des risques. Piste d'audit.
Directives cyber du CCCS Intégrité de la chaîne d'approvisionnement. Préparation SBOM. Réponse aux incidents.
WCAG 2.1 AA Accessibilité visée pour tous les livrables publics.
Programme SR&ED du Canada Documentation R&D. Dépenses éligibles suivies. Documents contemporains.

Avis de non-responsabilité : elect-rix opère comme nom commercial / marque de RixBot Technologies Inc., une société incorporée au Nouveau-Brunswick. Bien que nous alignions nos pratiques sur ces cadres, nous ne sommes pas un auditeur certifié ni un cabinet d'avocats. Pour des exigences de certification formelles, nous pouvons engager des tiers certifiés en votre nom.

7. Préparation à l'approvisionnement gouvernemental

L'approvisionnement du secteur public exige des preuves, pas des promesses. Voici comment nous atteignons ce seuil.

Préparation SPAC / Services partagés Canada

  • Résidence des données au Canada par défaut — aligné avec les attentes des charges de travail Protégées.
  • Responsabilité du personnel : un principal canadien nommé, aucun sous-traitant caché.
  • Cote de fiabilité et vérification d'antécédents disponibles sur demande pour les engagements sensibles.

Petite entreprise / fournisseur contrôlé par des Canadiens

  • Peut se qualifier pour certains volets d'approvisionnement axés sur les PME lorsque les règles du programme s'appliquent.
  • Approvisionnement simplifié : engagement direct, pas de tiers multiples complexes.
  • La documentation des retombées régionales peut être fournie lorsque pertinente.

Documentation et piste d'audit

  • Les livrables peuvent être maintenus avec une provenance versionnée dans Git ; une provenance signée peut être ajoutée lorsque requise par l'engagement.
  • Documentation complète du projet disponible pour audit : exigences, conception, résultats de tests.
  • Dossiers financiers tenus pour le SR&ED et la conformité fiscale.

8. Cadre d'inspection Fall Wall

L'inspection Fall Wall (FWI) est notre méthodologie interne de vérification de la sécurité — une vérification systématique des barrières qui maintiennent les systèmes en sécurité. Quand un mur tombe, qu'est-ce qui l'attrape ?

1. Les cinq murs

  • Périmètre : limites réseau, pare-feu, VPN.
  • Identité : authentification, autorisation, cycle de vie des accès.
  • Données : chiffrement au repos, en transit et en utilisation.
  • Application : codage sécurisé, analyse des dépendances, intégrité à l'exécution.
  • Humain : formation, politiques, réponse aux incidents, responsabilité.

2. Protocole d'inspection

  • Chaque mur est testé indépendamment : que se passe-t-il s'il échoue ?
  • Analyse de défaillance en cascade : l'échec d'un mur compromet-il le suivant ?
  • Équipe rouge : simulation de scénarios de brèche et mesure de la réponse.
  • Équipe bleue : vérification des capacités de détection, de confinement et de récupération.

3. Documentation et attestation

  • Résultats FWI documentés par engagement, disponibles pour le client.
  • Points de remédiation suivis jusqu'à leur fermeture avant la mise en production.
  • Réinspection déclenchée par : nouvelles menaces, changements d'infrastructure ou incidents.

FWI a été développé par elect-rix.tech pour combler un gap en approvisionnement : les acheteurs ont besoin de preuves de sécurité, pas seulement d'assurances. C'est notre réponse à « comment savoir que c'est sécurisé ? »

9. SR&ED et crédits d'impôt à l'innovation

elect-rix.tech suit activement ses activités de recherche et développement pour les programmes de crédits d'impôt canadiens.

Activités R&D éligibles

  • Optimisation de l'inférence IA locale (nouveaux algorithmes, quantification, réglage matériel).
  • Architecture de systèmes résilients (conception hors ligne d'abord, motifs déconnectables).
  • Calcul préservant la confidentialité (architectures zéro-télémétrie, apprentissage fédéré).
  • Pratiques de build reproductibles et outillage de chaîne d'approvisionnement.

Documentation contemporaine

  • Carnets de laboratoire dans Git : datés, versionnés et attribuables ; la signature peut être appliquée lorsque requise.
  • Suivi du temps pour toutes les heures R&D éligibles par projet.
  • Dossiers de dépenses pour matériaux, équipement et coûts de sous-traitants qualifiés.

Structure des crédits d'impôt

  • L'admissibilité SR&ED et le traitement des crédits dépendent de la structure du demandeur, des dépenses et des règles de l'ARC/provinciales.
  • elect-rix maintient des dossiers R&D contemporains pour appuyer des demandes SR&ED potentielles lorsque applicable.
  • Les positions fiscales formelles devraient être confirmées avec un comptable ou conseiller fiscal qualifié avant le dépôt.

10. Liste de vérification de diligence raisonnable

Utilisez cette liste pour évaluer n'importe quel fournisseur, incluant elect-rix.tech, pour l'approvisionnement gouvernemental ou réglementé.

  • Résidence des données : Où les données sont-elles créées, traitées et stockées ?
  • Chaîne d'approvisionnement : Le fournisseur peut-il fournir un SBOM ou un inventaire de dépendances ?
  • Vérification du personnel : Partie responsable nommée ? Vérifications d'antécédents disponibles ?
  • Réponse aux incidents : Plan défini ? SLA de notification client ?
  • Assurance : Couverture E&O / responsabilité cyber ? Adéquate pour la valeur du contrat ?
  • Accessibilité : Conformité WCAG revendiquée ? Vérifiée ?
  • Piste d'audit : Gestion de versions ? Commits signés ? Journaux de déploiement ?
  • Retombées autochtones / régionales : Admissible RIR ? Embauche locale ?
  • Résiliation : Retour / destruction des données ? Certificat de destruction ?
  • Sous-traitants : Nommés ? Liés par une confidentialité équivalente ?

Questions d'approvisionnement ?

Pour le SR&ED, la préparation aux contrats gouvernementaux, ou la documentation de diligence raisonnable :

contact@elect-rix.tech

elect-rix.tech — Intégrité. Loyauté. Honnêteté. — Testées.