À propos de la sécurité ROS 2

Aperçu

Les fonctionnalités de sécurité ROS 2 intégrées permettent de contrôler les communications dans tout le graphe ROS. Cela permet non seulement de chiffrer les données en transit entre les participants du domaine ROS, mais également d’authentifier les participants qui envoient des données, de garantir l’intégrité des données envoyées et d’activer les contrôles d’accès à l’échelle du domaine.

Les services de sécurité ROS 2 sont fournis par le Data Distribution Service (DDS) sous-jacent qui est utilisé pour les communications entre les nœuds. Les fournisseurs de DDS fournissent des implémentations DDS open source et commerciales qui fonctionnent avec ROS. Cependant, afin de créer une implémentation de DDS conforme aux spécifications, tous les fournisseurs doivent inclure des plugins de sécurité comme indiqué dans la Spécification de sécurité DDS. Les fonctionnalités de sécurité ROS tirent parti de ces plugins de sécurité DDS pour fournir un chiffrement, une authentification et un contrôle d’accès basés sur des politiques. La sécurité DDS et ROS est activée via des fichiers de configuration prédéfinis et des variables d’environnement.

L’enclave de sécurité

Une enclave de sécurité encapsule une politique unique pour protéger les communications ROS. L’enclave peut définir une politique pour plusieurs nœuds, pour un graphe ROS entier ou pour toute combinaison de processus et d’appareils ROS protégés. Les enclaves de sécurité peuvent être mappées de manière flexible aux processus, utilisateurs ou appareils lors du déploiement. L’ajustement de ce comportement par défaut devient important pour optimiser les communications et pour les systèmes complexes. Consultez le document de conception des enclaves de sécurité ROS 2 pour plus de détails.

Fichiers de sécurité

Une enclave de sécurité ROS 2 est établie avec six fichiers, comme indiqué par la spécification DDS. Trois de ces fichiers définissent l’identité d’une enclave, tandis que trois autres fichiers définissent les autorisations à accorder à l’enclave. Les six fichiers résident dans un seul répertoire et les nœuds lancés sans chemin d’accès d’enclave qualifié utilisent des fichiers dans l’enclave de niveau racine par défaut.

Identité de l’enclave

Le fichier Identity Certificate Authority identity_ca.cert.pem agit comme l’ancre de confiance utilisée pour identifier les participants. Chaque enclave détient également son certificat d’identification unique dans le fichier cert.pem, et la clé privée associée dans le fichier key.pem. Étant donné que le certificat cert.pem a été signé par un certificat d’identité, lorsqu’un participant présente ce certificat à d’autres membres du domaine, il est en mesure de valider l’identité du participant en utilisant sa propre copie du certificat d’identité. Cet échange de certificat valide permet à l’enclave d’établir en toute sécurité des communications de confiance avec d’autres participants. L’enclave ne partage pas la clé privée key.pem, mais l’utilise uniquement pour le déchiffrement et la signature des messages.

Autorisations d’enclave

Le fichier Permissions Certificate Authority permissions_ca.cert.pem sert d’ancre de confiance pour accorder des autorisations aux enclaves de sécurité. Ce certificat est utilisé pour créer le fichier signé governance.p7s, un document XML qui définit les politiques de protection à l’échelle du domaine. De même, le fichier XML permissions.p7s décrit les autorisations de cette enclave particulière et a été signé par l’autorité de certification des autorisations. Les membres du domaine utilisent une copie des autorisations CA pour valider ces fichiers signés et accorder l’accès demandé.

Bien que ces deux autorités de certification permettent des workflows distincts pour l’identité et les autorisations, le même certificat sert souvent à la fois d’identité et d’autorité d’autorisation.

Clés privées

Les certificats d’identité et d’autorisations sont également associés à des fichiers de clé privée. Ajoutez de nouvelles enclaves au domaine en signant leur demande de signature de certificat (CSR) avec la clé privée du certificat d’identité. De même, accordez des autorisations pour une nouvelle enclave en signant un document XML d’autorisations avec la clé privée du certificat d’autorisation.

Variables d’environnement de sécurité

La variable d’environnement ROS_SECURITY_ENABLE agit comme l’interrupteur principal « marche/arrêt » de l’enclave pour les fonctionnalités de sécurité ROS 2. La sécurité a été désactivée par défaut, de sorte que les fonctionnalités de sécurité ne seront pas activées même si les fichiers de sécurité appropriés sont présents. Afin d’activer la sécurité ROS 2, définissez cette variable d’environnement sur true (sensible à la casse).

Une fois la sécurité activée, la variable d’environnement ROS_SECURITY_STRATEGY définit comment les participants du domaine gèrent les problèmes lors du lancement des participants. Les fonctionnalités de sécurité dépendent des certificats et des fichiers de configuration correctement signés, mais par défaut, un participant mal configuré se lancera toujours avec succès, mais sans fonctionnalités de sécurité. Afin d’appliquer une stricte conformité avec les paramètres de sécurité et de ne pas lancer d’enclaves non conformes, définissez cette variable d’environnement sur Enforce (sensible à la casse).

Des variables d’environnement supplémentaires liées à la sécurité peuvent être trouvées dans le document de conception de l’intégration de sécurité ROS 2 DDS. Ces variables aident généralement ROS à gérer les enclaves et à localiser les fichiers de sécurité.

Apprendre encore plus

Pour plus d’informations et des exercices pratiques permettant la sécurité des communications ROS 2, consultez le Mise en place de la sécurité.