> For the complete documentation index, see [llms.txt](https://docs.kiloiot.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kiloiot.io/kilo-docs-fr/kilo-center/kilo-mioty-service-center/security/security-basics.md).

# Notions de base de sécurité

Notions de base de sécurité de KiloCenter — identifiants par défaut à modifier, chemins des certificats TLS et durcissement minimal pour les déploiements partagés.

### Objectif

Établir une base de référence sécurisée pour les déploiements de KiloCenter.

### Identifiants par défaut

Le développement local inclut des identifiants de commodité qui doivent être modifiés pour tout environnement partagé ou de production :

| Service     | Valeur par défaut                                    | Notes                                                          |
| ----------- | ---------------------------------------------------- | -------------------------------------------------------------- |
| PostgreSQL  | utilisateur `kilocenter`, mot de passe `changez-moi` | À modifier dans `config.yaml` et Docker Compose                |
| broker MQTT | utilisateur `admin`, mot de passe `KiloCenter`       | À modifier dans la configuration de Mosquitto et `config.yaml` |

### TLS pour la communication entre la station de base et le centre d'application

BSSCI nécessite TLS 1.2 ou supérieur. SCACI nécessite TLS 1.3 ou supérieur. Chaque connexion à KC-Core utilise le chiffrement TLS.

#### Modèle de confiance de l'AC

KiloCenter utilise une autorité de certification (AC) auto-signée pour émettre tous les certificats :

| Certificat            | Objectif                                             | Validité par défaut | Emplacement               |
| --------------------- | ---------------------------------------------------- | ------------------- | ------------------------- |
| Certificat de l'AC    | Racine de confiance ; distribué aux stations de base | 20 ans              | `certificates/ca.crt`     |
| Clé privée de l'AC    | Signe les certificats serveur et client              | --                  | `certificates/ca.key`     |
| Certificat serveur    | Liaisons TLS KC-Core BSSCI/SCACI                     | 1 an                | `certificates/server.crt` |
| Clé privée du serveur | négociation TLS                                      | --                  | `certificates/server.key` |
| Certificat client     | TLS mutuel par station de base (facultatif)          | 1 an                | Généré à la demande       |

Les stations de base font confiance à l' **Certificat de l'AC** , et non aux certificats serveur individuels. Cela signifie que les certificats serveur peuvent être renouvelés sans toucher aux stations de base, tant que la même AC les signe.

Si vous régénérez l'AC, tous les certificats serveur et client existants deviennent invalides et doivent être réémis. Sauvegardez `ca.key` en lieu sûr.

#### Génération des certificats

**Générer les certificats AC + serveur (première configuration)**

Aucune chaîne d'outils Go sur l'hôte requise — utilisez le `certgen` service compose :

```bash
docker compose run --rm certgen
```

> **Propriété des fichiers (Linux) :** Si les fichiers générés appartiennent à root, relancez avec `UID=$(id -u) GID=$(id -g)` préfixé.

Pour un FQDN de production :

```bash
docker compose run --rm certgen -dir /app/certificates -days 365 -server bssci.example.com
```

Cela crée quatre fichiers dans `KC-Core/certificates/`:

* `ca.crt` et `ca.key` -- certificat et clé privée de l’AC
* `server.crt` et `server.key` -- certificat et clé privée du serveur

Le certificat du serveur inclut automatiquement `localhost`, `127.0.0.1`, `0.0.0.0`, ainsi que toutes les adresses IP du réseau local comme noms alternatifs du sujet (SAN).

**Générer un certificat client**

```bash
docker compose run --rm certgen \\
    -dir /app/certificates -client-only -client 70-B3-D5-9C-D0-00-09-E6
```

**Référence de certgen**

| Option         | Valeur par défaut | Description                                                               |
| -------------- | ----------------- | ------------------------------------------------------------------------- |
| `-dir`         | `certs`           | Répertoire de sortie pour les fichiers de certificat                      |
| `-server`      | `localhost`       | Nom d'hôte du serveur (utilisé comme CN et SAN)                           |
| `-days`        | `365`             | Validité du certificat serveur/client en jours                            |
| `-ca-years`    | `20`              | Validité du certificat de l'AC en années                                  |
| `-ca-only`     | `faux`            | Générer uniquement le certificat de l'AC                                  |
| `-server-only` | `faux`            | Générer uniquement le certificat serveur (l'AC doit déjà exister)         |
| `-client-only` | `faux`            | Générer uniquement un certificat client (l'AC doit déjà exister)          |
| `-client`      | (vide)            | Nom du client pour le certificat client (par ex., EUI de station de base) |

**Scénarios courants**

**Renouveler uniquement le certificat serveur (l'AC existe déjà) :**

```bash
docker compose run --rm certgen \\
    -dir /app/certificates -server bssci.example.com -server-only
```

#### Rotation des certificats

**Via compose** (recommandé pour l'automatisation) :

```bash
docker compose run --rm certgen \\
    -dir /app/certificates -server bssci.example.com -server-only
docker compose restart kilocenter
```

**Via l'interface graphique** (renouvellement après installation) :

1. Ouvrez KC-Web et accédez à **Certificats**.
2. Cliquez sur **Renouveler les certificats serveur** et confirmez.
3. Redémarrez KC-Core pour charger les nouveaux certificats.

**Après la rotation :**

1. Redémarrez KC-Core pour charger les nouveaux certificats.
2. Vérifiez que les reconnexions des stations de base réussissent.
3. Si l'AC a été modifiée, redistribuez `ca.crt` à toutes les stations de base.

#### Configuration des certificats

KC-Core charge les certificats depuis les chemins configurés dans `config.yaml` (source dev) ou `config/config.docker.yaml` (conteneur) :

```yaml
protocol :
  bsci_tls :
    enabled: true
    cert_file: "certificates/server.crt"
    key_file: "certificates/server.key"
    ca_file: "certificates/ca.crt"
    min_version: "1.2"
  scaci_tls :
    enabled: true
    cert_file: "certificates/server.crt"
    key_file: "certificates/server.key"
    ca_file: "certificates/ca.crt"
    min_version: "1.3"
```

Dans le mode source dev, les chemins sont relatifs au répertoire de travail de KC-Core. KC-Core ne démarrera pas si ces fichiers sont manquants.

### Exposition réseau

Limitez les ports accessibles depuis l'extérieur de votre réseau local :

| Port  | Service                 | Recommandation d'exposition                          |
| ----- | ----------------------- | ---------------------------------------------------- |
| 5000  | BSSCI                   | Réseaux de stations de base uniquement               |
| 5001  | SCACI                   | Hôtes du centre d'application uniquement             |
| 9090  | KC-Gateway (gRPC-web)   | Réseaux des opérateurs et des consommateurs d'API    |
| 80    | KC-Web (conteneur)      | Réseaux des opérateurs uniquement                    |
| 50051 | gRPC interne de KC-Core | Bouclage uniquement, ne jamais exposer à l'extérieur |
| 5433  | PostgreSQL              | Bouclage uniquement                                  |
| 6379  | Redis                   | Bouclage uniquement                                  |
| 1883  | MQTT                    | Réseaux des consommateurs MQTT uniquement            |

### Liste de contrôle de durcissement

* [ ] Faites tourner tous les identifiants par défaut listés ci-dessus
* [ ] Restreindre l'accès réseau aux ports de gestion (50051, 5433, 6379)
* [ ] Stocker les clés privées des certificats avec des permissions de fichier restreintes
* [ ] Activer la journalisation au niveau audit dans les environnements de production
* [ ] Vérifier `config.yaml` pour tout autre paramètre de développement restant par défaut

### Édition Entreprise

L'Édition Entreprise ajoute des fonctionnalités de sécurité multi-tenant :

* Authentification des utilisateurs avec validation JWT
* Isolation des données par organisation
* Contrôle d'accès basé sur les rôles

Ces fonctionnalités ne sont pas disponibles dans l'Édition Communautaire.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.kiloiot.io/kilo-docs-fr/kilo-center/kilo-mioty-service-center/security/security-basics.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.