Segurança e conformidade

Funcionalidades de segurança e conformidade no Automation Suite no OpenShift.

Restrições de contexto de segurança (SCC) para serviços da UiPath

O UiPath® Automation Suite requer a Restrição de Contexto de Segurança (SCC) padrão restricted-v2 para todos os pods de carga de trabalho. Esse SCC é integrado no OpenShift e está automaticamente disponível para todos os usuários autenticados por meio do padrão ClusterRoleBinding system:openshift:scc:restricted-v2.

Importante:

A atribuição de SCC para contas de serviço nos namespaces do Automation Suite não deve ser modificada. Por exemplo, não conceda anyuid ou outros SCCs permissivos à conta de serviço padrão.

Contexto de segurança para serviços da UiPath®

Esta seção fornece detalhes sobre o contexto de segurança dos serviços da UiPath®.

Todos os serviços UiPath® são configurados com um contexto de segurança definido em sua seção. spec

O exemplo a seguir mostra uma configuração típica para os serviços da UiPath®:

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

Para alguns serviços da UiPath®, há exceções da configuração típica do contexto de segurança:

• O Insights tem várias funcionalidades que usam o Chromium Linux SUID Sandbox. Embora o acesso elevado não seja necessário para instalar o Insights, ele é essencial para a funcionalidade de recursos específicos. Para obter detalhes, consulte Configuração do contexto de segurança personalizado do Insights.
• O Process Mining usa os seguintes serviços do Airflow cujo contexto de segurança é diferente da configuração típica para serviços da UiPath®:
  • O serviço statsd , conforme mostrado no exemplo a seguir:

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

  • O scheduler, webserver e outros pods do Airflow, conforme mostrado na amostra a seguir:

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

  • O pod de runtime dinâmico, conforme mostrado na seguinte amostra:

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

Em algumas instâncias, os IDs de usuário e IDs de grupo podem ser maiores ou iguais a 1000, dependendo do seu ambiente. Certifique-se de configurar os IDs de usuário e grupo de acordo com seus princípios de segurança e as diretrizes de segurança da sua organização.

Políticas de rede

A tabela a seguir fornece uma diretriz geral para as políticas de rede. Inclui uma lista de rotas necessárias para configurar o namespace <uipath> .

Origem	Destino	Direction	Portas	Tipo de Política	Condições
Todos os pods em uipath	Tudo externo	Negar	Todos	PolíticaDeRede	Política negar tudo padrão
Todos os pods em uipath	Todos os pods em uipath	Permitir	Todos	PolíticaDeRede	Comunicação de namespace interno
Todos os pods em uipath	DNS do sistema do Kube	Saída	53 TCP/UDP	PolíticaDeRede	Resolução de DNS
Todos os pods em uipath	IPs Externos	Saída	Todos	PolíticaDeRede	Comunicação Externa
Todos os pods em uipath	Índice	Saída	Todos	PolíticaDeRede	Controle de service mesh
Prometheus	Todos os pods em uipath	Ingress	Portas de extração personalizadas	PolíticaDeRede	Monitoramento do acesso
Gateway do Istio	Todos os pods em uipath	Ingress	Todos	PolíticaDeRede	Tráfego do gateway
Sistema Kube	Todos os pods em uipath	Ingress	Todos	PolíticaDeRede	Acesso ao sistema
Sistema Redis	Todos os pods em uipath	Ingress	9091/TCP	PolíticaDeRede	Monitoramento do Redis
Serviços listados	Namespace do Redis	Saída	Todos	PolíticaDeRede	Acesso ao Redis

Requisitos de privilégio de cluster

O Automation Suite requer a função de administrador do cluster durante a instalação para automatizar todo o processo de instalação. Alternativamente, você pode instalar o Automation Suite com permissões mais baixas. Uma instalação com permissões mais baixas envolve algumas etapas adicionais. Para as permissões que a instalação requer, consulte Etapa 2: Criação das funções necessárias.

FIPS 140-2

O Federal Information Processing Standards 140-2 (FIPS 140-2) é um padrão de segurança que valida a eficácia dos módulos de criptografia.

O Automation Suite pode ser executado em máquinas habilitadas para FIPS 140-2.

Habilitando o FIPS 140-2 para novas instalações

Para habilitar o FIPS 140-2 nas máquinas em que planeja realizar uma nova instalação do Automation Suite, siga estas etapas:

1. Antes de iniciar a instalação do Automation Suite, habilite o FIPS 140-2 em suas máquinas.

2. Execute a instalação do Automation Suite seguindo as instruções de instalação neste guia.

   Observação:

   • Ao instalar o AI Center em uma máquina habilitada para FIPS 140-2 e utilizar o Microsoft SQL Server em conjunto, algumas configurações adicionais serão necessárias. Para obter detalhes, consulte Requisitos do SQL para o AI Center.
   • Certifique-se de que o Insights esteja desabilitado, pois não é suportado em FIPS 140-2. Se precisar usar o Insights, você pode implantá-lo em um nó dedicado não FIPS. Para obter detalhes, consulte Como implantar Insights em um cluster habilitado para FIPS.

3. Defina o sinalizador fips_enabled_nodes como true no arquivo input.json .

4. Certifique-se de que seus certificados sejam compatíveis com FIPS 140-2.

   Observação:

   Por padrão, o Automation Suite gera certificados autoassinados compatíveis com FIPS 140-2, cuja data de expiração depende do tipo de instalação do Automation Suite que você escolher.

   Recomendamos fortemente que você substitua esses certificados autoassinados por certificados emitidos por CA no momento da instalação. Para usar o Automation Suite em máquinas habilitadas para FIPS 140-2, os novos certificados fornecidos devem ser compatíveis com FIPS 140-2. Para obter uma lista de cifras elegíveis com suporte do RHEL, consulte a documentação do RHEL.

   Para obter detalhes sobre como adicionar sua própria assinatura de token compatível com FIPS 140-2 e certificados TLS, consulte Configuração do certificado.