Comment CertiPOS protège les données, l’argent et les preuves

CertiPOS est construit selon l’OWASP Application Security Verification Standard au niveau 2. La liste de contrôle avec ses lacunes nommées fait partie de la documentation ; un ensemble de tests de sécurité générés tourne à chaque build et sonde chaque point d’entrée : accès entre locataires, secrets divulgués, entrées malformées et redirections ouvertes.

Cloisonnement

Chaque table du serveur porte le locataire et une politique de sécurité au niveau des lignes créée dans la même migration. L’application se connecte sous un rôle pour lequel les politiques sont forcées : aucune requête ne peut traverser une société par accident ou par injection.

Transport

• HTTPS avec votre propre certificat ou un certificat émis par l’installateur ; chaque caisse épingle l’empreinte depuis le QR d’enrôlement ; TLS peut être exigé pour chaque appel.
• HSTS, en-têtes de sécurité, une politique de sécurité du contenu qui n’autorise aucune origine externe et utilise un nonce par requête pour les scripts.
• Limites de débit sur la connexion et les appels d’API par adresse ; limites de taille du corps des requêtes ; un récepteur de webhooks signé avec une garde SSRF.

Identité

• Les appareils s’enrôlent une fois avec un code et reçoivent un certificat X.509 d’une AC par locataire ; les jetons sont de courte durée et liés à l’appareil ; les appareils retirés ne peuvent pas revenir.
• Les utilisateurs de caisse se connectent par PIN, carte ou badge sous des politiques de longueur, d’historique, d’expiration et de verrouillage ; le hachage du PIN est vérifié hors du fil d’interface.
• Les utilisateurs du portail se connectent par mot de passe, une seconde étape temporelle et des codes de secours ; un autre administrateur peut réinitialiser la seconde étape.
• Politiques de session : verrouillage et déconnexion à l’inactivité, session unique avec reprise, mode formation, pointeuse.

Autorisation et approbations

• Plus de 170 droits nommés avec autoriser, refuser ou approbation requise, et des seuils quand une valeur compte ; des rôles hiérarchisés ; la caisse n’affiche une tuile que si son propre droit est accordé.
• Approbations par PIN, carte ou à distance depuis le téléphone d’un responsable ; par action, par ticket ou par session ; exécutant et approbateur sont toujours deux personnes différentes.
• Chaque dérogation est journalisée avec l’exécutant, l’approbateur, la méthode, le motif, la valeur tentée et la valeur autorisée ; le serveur vérifie le journal.

Preuves

• Les événements de ticket sont en ajout seul ; les annulations sont marquées ; chaque ticket porte la séquence de la caisse et une chaîne de hachage.
• Les changements de configuration sont stockés en différences ; les lectures de données sensibles sont auditées ; les exports d’audit sont en CSV.

Secrets, journaux, paquets

• Les mots de passe SAP et les autres secrets sont protégés par DPAPI ou AES dans un fichier de secrets protégé ; les réponses de configuration, les lignes d’audit et les paquets de support ne contiennent jamais de secret.
• Les journaux sont structurés et ne contiennent jamais de PIN, de jeton, de numéro de carte ni de secret.
• Les sauvegardes sont des dumps planifiés avec une restauration testée ; l’effacement à distance d’un appareil requiert un second administrateur par une porte signée par l’appareil.