> For the complete documentation index, see [llms.txt](https://docs.medcrypt.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.medcrypt.com/fr/guardian/get-started/security-best-practices.md).

# Bonnes pratiques de sécurité

## **Présentation**

Une mise en œuvre adéquate de la sécurité est essentielle lors de l’intégration de Guardian à vos dispositifs médicaux. Suivez ces bonnes pratiques pour protéger correctement les fichiers de Guardian et préserver la sécurité de votre dispositif tout au long de son cycle de vie.

## **Sécurité des fichiers de Guardian**

Guardian utilise trois groupes distincts de fichiers, chacun ayant des exigences de sécurité différentes :

* **Fichiers système** (anciennement appelés **Fichiers préchargés (PLF) :** Il s’agit des fichiers fondamentaux de votre système. Ils doivent être chargés lors de la fabrication ou au moyen de mises à jour logicielles signées. Ils doivent toujours être protégés contre l’écriture et ne jamais être mis à jour directement.
* **Package de provisionnement** (anciennement appelé **Fichiers de provisionnement initial (IPF) :** Ce package contient les fichiers d’amorçage nécessaires à la configuration initiale du dispositif et sert au premier provisionnement de celui-ci. Il s’agit d’un ensemble de fichiers « moyennement fiables », qui ne doivent être distribués que dans des environnements contrôlés, de préférence chargés lors de la fabrication et supprimés immédiatement après le provisionnement.
* **Fichiers du dispositif** (anciennement appelés **Fichiers provisionnés (PF) :** Ils contiennent l’identité et les identifiants uniques de chaque dispositif, générés ou récupérés pendant le processus de provisionnement.

## Exigences relatives au TPM

Guardian ne nécessite pas de module de plateforme sécurisée (TPM), mais les TPM peuvent être utilisés pour renforcer la sécurité lorsqu’ils sont disponibles.

## Formats de certificat

Guardian prend en charge les certificats X.509 standard ainsi que les certificats propriétaires de Medcrypt, optimisés pour les dispositifs soumis à des contraintes de mémoire. Les certificats que vous extrayez sont des certificats X.509 ordinaires avec des dates d’expiration standard, qui peuvent être examinés normalement.

## Scénarios de récupération des fichiers

Les conséquences de la perte de fichiers Guardian dépendent des fichiers perdus et du moment où la perte survient :

* **Pendant le développement :** Vous pouvez régénérer les clés et recommencer à tout moment avant l’intervention de l’infrastructure.
* **Après le chargement initial :** Vos `.mcpi` et `.mcpr` doivent rester intacts. La perte de `.mcpr` avant la fin du provisionnement signifie que le processus doit être recommencé.
* **Après un provisionnement réussi :** Votre `.mcpi` doit rester intact. Un fichier `.mcp` peut être récupéré en soumettant à nouveau le même fichier `.mcpr` .

**Important :** La perte d’un fichier .mcpi, quel que soit le moment, rend inutilisables les clés et les composants provisionnés.

## **Chiffrement du disque**

Le chiffrement du disque vise à protéger les fichiers au repos. Les méthodes de chiffrement du disque doivent utiliser une clé de chiffrement elle-même protégée au repos (par exemple au moyen d’un TPM).

## **Protection contre l’écriture**

#### **En tant que root**

Sur les dispositifs où les processus qui accèdent aux fichiers Guardian s’exécutent en tant que root, la protection contre l’écriture peut être assurée au moyen d’attributs de fichier (si le système de fichiers et le système d’exploitation sont compatibles) ou en montant le disque en lecture seule. Dans les deux cas, les fichiers doivent appartenir à root (et avoir les permissions u-w,g-w,o-w).

#### **Sans privilèges root**

Sur les dispositifs où les processus qui accèdent aux fichiers Guardian ne s’exécutent pas en tant que root, la protection contre l’écriture peut être assurée en attribuant les fichiers système à root et en leur appliquant les permissions u-w,g-w,o-w (avec, éventuellement, des attributs de fichier ou un montage en lecture seule). Comme le package de provisionnement et les fichiers du dispositif doivent être modifiables dans certains scénarios, ils doivent appartenir à un « utilisateur de provisionnement » dédié, qui les écrira (et avoir les permissions u+w,g-w,o-w).

## **Protection contre la lecture**

#### **En tant que root**

Sur les dispositifs où les processus qui accèdent aux fichiers Guardian s’exécutent en tant que root, la protection contre la lecture peut être assurée en attribuant aux fichiers les permissions u-r,g-r,o-r.

#### **Sans privilèges root**

Sur les dispositifs où les processus qui accèdent aux fichiers Guardian ne s’exécutent pas en tant que root, la protection contre la lecture peut être assurée en créant un groupe spécial « guardian-asset » auquel appartiendront les fichiers, puis en leur attribuant les permissions u+r,g+r,o-r. Les processus qui doivent accéder à ces fichiers doivent alors être exécutés par un utilisateur appartenant à ce groupe.

#### **Écriture des fichiers nécessaires au provisionnement**

Le provisionnement initial d’un appareil est simple : les fichiers de l’appareil sont écrits dans un chemin approprié et le paquet de provisionnement est, de préférence, effacé.

Lors du reprovisionnement, deux ensembles de fichiers de l’appareil coexistent : l’ensemble actif et le nouvel ensemble en cours de génération. Il convient de veiller tout particulièrement à ne pas écraser l’ensemble actif pendant le provisionnement. Il est donc généralement nécessaire d’employer une stratégie de basculement, par exemple à l’aide de liens symboliques, de variables d’environnement ou du remontage des disques.

#### **Bonnes pratiques supplémentaires pour la sécurité des appareils**

Il est primordial de garantir la sécurité des clés. Elles doivent être stockées dans des zones mémoire protégées contre l’exfiltration de données par JTAG ou par des techniques similaires. Il est essentiel que les clés privées restent dans l’appareil et n’en soient extraites à aucune étape de son cycle de vie.

## **Considérations de sécurité relatives au provisionnement**

Lors du provisionnement initial, écrivez les **fichiers de l’appareil** dans des chemins appropriés et effacez le **paquet de provisionnement** **et ses fichiers** immédiatement. Pour le reprovisionnement, utilisez une stratégie de basculement (liens symboliques, variables d’environnement ou remontage des disques) afin d’éviter d’écraser les fichiers actifs lors de la génération de nouveaux ensembles.

## **Principes fondamentaux de la sécurité des appareils**

Stockez les clés dans des zones mémoire protégées contre l’exfiltration de données par JTAG ou par des méthodes similaires. Les clés privées ne doivent jamais quitter l’appareil, à aucune étape de son cycle de vie. Mettez en place des contrôles d’accès et une surveillance appropriés afin de détecter les tentatives d’accès non autorisé.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.medcrypt.com/fr/guardian/get-started/security-best-practices.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.
