# Sécurité du compte et de l'organisation

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](data-security.md).

## 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](api.md) et [Comptes de service](service-accounts.md)).

- 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](../reference/operations/account.session.revoke.md)).

## 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é**.

1. 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.
2. Activez l'obligation (rôle Propriétaire ou Sécurité).
3. 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**.
4. 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 :

```sh
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](../reference/operations/organization.second_factor_exemption.create.md)).

## 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](audit.md).

## 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](acceptable-use.md).

## 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](organizations.md), [Authentification unique](sso.md), [Journal d'audit](audit.md), [Sécurité des agents](agent-safety.md), [Souveraineté](sovereignty.md).