Sécurité du compte et de l'organisation

English Markdownv0.3.0

Cette page rassemble ce qui protège l'accès à vos projets : les sessions de console, le mot de passe, le second facteur et son obligation dans une organisation, l'accès du personnel de Glowsoft à vos données, et la façon de nous signaler une vulnérabilité. La sécurité des données de votre application (politiques, clés du backend) est traitée dans Sécurité des données.

Sessions de console

Une personne qui se connecte reçoit une session. Une machine n'en ouvre pas : elle présente un jeton (voir API et Comptes de service).

Une session se ferme 8 heures après son ouverture, et après 60 minutes sans appel.
Elle ne porte pas de portées : c'est la personne qui est là, avec tout ce que son rang permet.
Changer de mot de passe ou de second facteur ferme les autres sessions du compte ; un changement de rôle les ferme toutes.

Sur l'écran Compte, la carte « Sessions » liste vos sessions ouvertes, d'où et jusqu'à quand, et par quel facteur chacune a été ouverte. Fermer une session la refuse au premier appel qui suit ; elle ne se rouvre pas. Par la ligne de commande : bastide account session list, puis bastide account session revoke --session-id <valeur> (account.session.revoke).

Mot de passe et tentatives

Au moins 12 caractères, 256 au plus. Il ne reprend pas votre adresse et ne figure pas parmi les mots de passe compromis ou trop courants ; la vérification se fait sur place, sans service tiers. Seule une empreinte est gardée.
5 échecs en 15 minutes pour un compte depuis une adresse IP déclenchent une attente : 60 secondes, puis le double à chaque échec, jusqu'à 15 minutes. La réponse est trop_de_tentatives, avec l'en-tête Retry-After.
Une adresse inconnue, un compte suspendu et un mot de passe faux reçoivent la même réponse, identifiants_invalides.

Le mot de passe se change sur Compte, carte « Mot de passe », sous une session (pas sous un jeton).

Le second facteur

Trois moyens, à ajouter sur Compte, carte « Second facteur » :

Une application d'authentification (TOTP : 6 chiffres, 30 secondes). Un code accepté ne repasse pas.
Une clé d'accès (WebAuthn) : elle ne signe que pour la console, et exige votre présence et votre vérification (code ou empreinte).
Dix codes de récupération, à usage unique, montrés une seule fois à la confirmation du premier facteur. Vous pouvez en émettre dix nouveaux, qui remplacent les anciens.

À la connexion, le mot de passe juste rend un défi ; le second temps doit venir dans les 5 minutes, en 5 essais au plus.

Les droits gardés par le second facteur

Écrire en SQL, migrer la base et gérer les clés du backend exigent un second facteur, quelle que soit l'organisation. Concrètement :

les rôles qui ouvrent ces gestes, Mainteneur, Administrateur et Propriétaire, ne s'attribuent (par changement de rôle ou par acceptation d'une invitation) qu'à un compte qui tient un facteur confirmé ; sinon second_factor_required, et rien n'est écrit ;
le dernier facteur d'un compte qui tient un tel rôle ne peut pas être retiré.

Un compte de service ne peut pas tenir de facteur : il n'est pas concerné, et son garde-fou est l'exemption nominative décrite plus bas.

Exiger le second facteur dans l'organisation

Une organisation peut exiger un second facteur de ses Propriétaires, Administrateurs et membres Sécurité.

Ouvrez Réglages (de l'organisation), section « Second facteur ». La carte dit l'état de l'obligation et combien de comptes concernés n'ont pas de facteur ; Membres dit lesquels.
Activez l'obligation (rôle Propriétaire ou Sécurité).
Une grâce de 14 jours commence. Des relances sont écrites au journal d'audit : quatre avant la fin, une au blocage. Les avis envoyés à chaque compte se relisent dans la carte « Avis reçus » de son écran Compte.
Passé la grâce, un compte de ces rôles sans facteur confirmé est refusé dans l'organisation, par sa session comme par ses jetons, avec second_factor_required. Enrôler un facteur rouvre l'accès aussitôt.

Désactiver l'obligation rend l'accès immédiatement aux comptes refusés ; la réactiver garde la date de la première activation. Par la ligne de commande :

bastide organization second_factor configure --organization-id org_01JQ8ZK4M7NP2RSTVWXYZ34567 --required true

Exempter un compte de service

Seul un jeton de compte de service de l'organisation peut être exempté ; une personne ne s'exempte jamais. L'exemption demande un motif (une phrase de 20 à 500 caractères) et s'éteint d'elle-même après 92 jours au plus, pour une revue trimestrielle. En accorder une nouvelle au même compte retire la précédente. Les exemptions en vigueur, échues et retirées restent dans la liste, avec qui les a accordées.

Un agent lit cette liste par organization_second_factor_exemption_list ; accorder ou retirer une exemption reste un geste de personne, depuis la console, la ligne de commande ou l'API (organization.second_factor_exemption.create).

L'accès du personnel de Glowsoft à vos données

Les rôles de l'équipe de Glowsoft n'ont cours qu'au niveau de la plateforme : aucun ne vaut dans votre organisation. Pour atteindre les données d'un projet, un exploitant doit obtenir un accès, limité à ce projet et dans le temps.

À votre demande ou avec votre accord. Un exploitant demande, en disant pourquoi, pour combien de temps et en quel mode (lecture, ou lecture et écriture). Le Propriétaire ou un Administrateur du projet décide, dans les Réglages du projet, section « Accès », carte « Accès de Glowsoft ». Un accès accepté dure ce qui est demandé, huit heures au plus.
Sur incident qualifié. Un accès peut être ouvert sans votre accord pour traiter un incident ; il exige alors la validation d'un second exploitant de Glowsoft. Il apparaît dans la même carte, marqué « sur incident », avec son motif.
Toujours tracé, toujours révocable. Chaque action faite sous un accès entre au journal d'audit du projet, au nom de l'exploitant. « Révoquer maintenant » coupe l'accès à tout instant ; « Refuser » écarte une demande.

Un agent peut lister les demandes (access_request_list) et refuser ou révoquer un accès (access_request_revoke). Accepter une demande reste réservé à une personne, depuis la console ou par bastide access request accept.

Note. Aucun accès n'est jamais ouvert en silence : soit vous l'avez accepté, soit il porte la mention d'incident et la double validation, et dans les deux cas il est au journal d'audit. Voir Journal d'audit.

Signaler une vulnérabilité

Écrivez à abuse@glowsoft.fr, en français ou en anglais : ce que vous avez observé, comment le reproduire, ce que cela permettrait. N'y joignez aucune donnée réelle d'un client.

Accusé de réception sous 72 heures ; qualification sous 7 jours, avec la gravité retenue et le délai de correction visé.
Pas de poursuites contre une recherche de bonne foi : sur votre propre compte, sans accéder aux données d'autrui au-delà de la preuve, sans dégrader le service, sans publication avant correction ou délai convenu.

La politique complète est publiée sur https://bastide.app/divulgation-coordonnee (la console la sert aussi sur /divulgation-coordonnee). Le fichier /.well-known/security.txt de la console, de l'API et du site donne la même adresse. Un contenu illicite hébergé sur Bastide se signale, lui, par la page publique /signaler de la console ; voir Usage acceptable.

Erreurs fréquentes

Code	Ce qui se passe	Que faire
`second_factor_required`	L'organisation exige un facteur et vous n'en avez pas ; ou le rôle visé l'exige.	Ajoutez un facteur sur Compte, puis recommencez.
`second_facteur_requis`	Réponse normale de la connexion : le mot de passe est juste, le second temps est attendu.	Donnez le code, la clé ou un code de récupération dans les 5 minutes.
`defi_expire`	Le défi est échu, déjà servi, ou ses 5 essais sont épuisés.	Recommencez par le mot de passe.
`trop_de_tentatives`	Trop d'échecs depuis cette adresse IP.	Attendez la durée de `Retry-After`.

Voir aussi : Organisations et membres, Authentification unique, Journal d'audit, Sécurité des agents, Souveraineté.

Signaler une erreur sur cette page