Sécurité et conformité

Fonctionnalités de sécurité et de conformité dans Automation Suite sur OpenShift.

Contraintes de contexte de sécurité (SCC) pour les services UiPath

UiPath® Automation Suite requiert la valeur par défaut restricted-v2 SCC pour tous les pods de charge de travail. Ce SCC est intégré à OpenShift et est automatiquement disponible pour tous les utilisateurs authentifiés via la valeur par défaut ClusterRoleBinding system:openshift:scc:restricted-v2.

Important :

L'attribution SCC pour les comptes de service dans les espaces de noms Automation Suite ne doit pas être modifiée. Par exemple, n'accordez pas anyuid ou d'autres SCC autorisés au compte de service par défaut.

Contexte de sécurité pour les services UiPath®

Cette section fournit des détails sur le contexte de sécurité des services UiPath®.

Tous les services UiPath® sont configurés avec un contexte de sécurité défini dans leur section spec .

L’exemple suivant présente une configuration standard pour les services UiPath® :

spec:
  securityContext:
    runAsNonRoot: true
  containers:
    - securityContext:
        allowPrivilegeEscalation: false
        privileged: false
        readOnlyRootFilesystem: true
        capabilities:
          drop: ["ALL"]
  hostPID: false
  hostNetwork: false

Pour certains services UiPath®, il existe des exceptions par rapport à la configuration standard du contexte de sécurité :

• Insights dispose de plusieurs fonctionnalités qui utilisent la sandbox Chromium Linux SUID. Bien que l'accès élevé ne soit pas requis pour l'installation d'Insights, il est essentiel pour la fonctionnalité de fonctionnalité spécifique. Pour des détails, reportez-vous à Configuration du contexte de sécurité personnalisé Insights.
• Process Mining utilise les services Airflow suivants dont le contexte de sécurité diffère de la configuration standard des services UiPath® :
  • Le service statsd , comme illustré dans l’exemple suivant :

    securityContext:
        runAsUser: 65534
        seLinuxOptions:
          level: s0:c27,c4
    

  • Les pods scheduler, webserver et d'autres pods Airflow, comme illustré dans l'exemple suivant :

      securityContext:
        fsGroup: 1000
        runAsGroup: 1000
        runAsNonRoot: true
        runAsUser: 50000
        seLinuxOptions:
          level: s0:c27,c4
        supplementalGroups:
          - 1000
    

  • Le pod de runtime dynamique, comme illustré dans l’exemple suivant :

      securityContext:
        fsGroup: 1000
        runAsGroup: 1000
        runAsNonRoot: true
        runAsUser: 1001
        seLinuxOptions:
          level: s0:c27,c4
        supplementalGroups:
          - 1000
    

Dans certains cas, les ID d'utilisateur et les ID de groupe peuvent être supérieurs ou égaux à 1000, en fonction de votre environnement. Assurez-vous de configurer les ID d'utilisateur et de groupe en fonction de vos principes de sécurité et des directives de sécurité de votre organisation.

Politiques de mise en réseau

Le tableau suivant fournit une directive générale pour les stratégies réseau. Il comprend une liste des routages nécessaires à la configuration de l'espace de noms <uipath> .

Source	Destination	Direction	Ports	Type de politique	Conditions
Tous les pods dans uipath	Tout externe	Refuser	Tout (All)	PolitiqueRéseau	Politique Refuser tout (Deny-All) par défaut
Tous les pods dans uipath	Tous les pods dans uipath	Autoriser	Tout (All)	PolitiqueRéseau	Communication par espace de noms interne
Tous les pods dans uipath	DNS du système Kube	Sortie	53 TCP/UDP	PolitiqueRéseau	Résolution DNS
Tous les pods dans uipath	IP externes	Sortie	Tout (All)	PolitiqueRéseau	Communication externe
Tous les pods dans uipath	Istio	Sortie	Tout (All)	PolitiqueRéseau	Contrôle de Service Mesh
Prometheus	Tous les pods dans uipath	Entrée	Ports d’extraction personnalisés	PolitiqueRéseau	Accès à la surveillance
Passerelle Istio	Tous les pods dans uipath	Entrée	Tout (All)	PolitiqueRéseau	Trafic de passerelle
Kube System	Tous les pods dans uipath	Entrée	Tout (All)	PolitiqueRéseau	Accès au système
Système Redis	Tous les pods dans uipath	Entrée	9091/TCP	PolitiqueRéseau	Surveillance Redis
Services listés	Espace de noms Redis	Sortie	Tout (All)	PolitiqueRéseau	Accès à Redis

Exigences en matière de privilèges de cluster

Automation Suite nécessite le rôle d'administrateur de cluster pendant l'installation pour automatiser l'ensemble du processus d'installation. Vous pouvez également installer Automation Suite avec des autorisations inférieures. Une installation avec des autorisations inférieures implique des étapes supplémentaires. Pour connaître les autorisations requises par l'installation, reportez-vous à Étape 2: Création des rôles requis.

FIPS 140-2

La norme FIPS 140-2 (Federal Information Processing Standards 140-2) est une norme de sécurité qui valide l'efficacité des modules cryptographiques.

Automation Suite peut s'exécuter sur des machines compatibles FIPS 140-2.

Activation de FIPS 140-2 pour les nouvelles installations

Pour activer FIPS 140-2 sur les machines sur lesquelles vous prévoyez d'effectuer une nouvelle installation d'Automation Suite, procédez comme suit :

1. Avant de commencer l'installation d'Automation Suite, activez FIPS 140-2 sur vos machines.

2. Effectuez l'installation d'Automation Suite en suivant les instructions d'installation de ce guide.

   Remarque :

   • Si vous installez AI Center sur une machine compatible FIPS 140-2 et que vous utilisez également Microsoft SQL Server, une configuration supplémentaire est requise. Pour plus de détails, consultez la section Exigences SQL pour AI Center.
   • Assurez-vous qu'Insights est désactivé, car il n'est pas pris en charge par FIPS 140-2. Si vous devez utiliser Insights, vous pouvez le déployer sur un nœud non FIPS dédié. Pour plus de détails, consultez la section Comment déployer Insights dans un cluster compatible FIPS.

3. Définissez l'indicateur fips_enabled_nodes sur true dans le fichier input.json.

4. Assurez-vous que vos certificats sont compatibles FIPS 140-2.

   Remarque :

   Par défaut, Automation Suite génère des certificats compatibles FIPS 140-2 auto-signés dont la date d'expiration dépend du type d'installation d'Automation Suite que vous choisissez.

   Nous vous recommandons fortement de remplacer ces certificats auto-signés par des certificats émis par une autorité de certification au moment de l'installation. Pour utiliser Automation Suite sur des machines compatibles FIPS 140-2, les certificats nouvellement fournis doivent être compatibles FIPS 140-2. Pour obtenir la liste des chiffrements éligibles pris en charge par RHEL, consultez la documentation RHEL.

   Pour plus de détails sur la façon d'ajouter vos propres certificats de signature de jeton et TLS compatibles FIPS 140-2, consultez la section Configuration du certificat.