Proteger a camada de aplicativos
Para proteger a camada de aplicativos, considere a autenticação do usuário e do banco de dados, os certificados digitais e a criptografia.
Autenticação interna do usuário
Com a autenticação interna do Server, os usuários são autenticados por meio do JavaScript do lado do cliente, que chama uma função local SHA256 para hash e faz salt da senha antes de enviar o hash ao Server para comparação com a senha hash no banco de dados do usuário (armazenado no MongoDB). O Server armazena apenas o valor em hash; ele nunca vê o texto não codificado da senha de um usuário.
Nota
Atualizamos o algoritmo usado para o hash de senhas na autenticação interna. Nas versões anteriores à 22.1, o cliente chamava uma biblioteca bcrypt local para fazer o hash e salt da senha antes de enviar o hash para o Server.
Consulte a seção Autenticação deste guia para obter mais informações sobre outros métodos de autenticação disponíveis com o Server.
Autenticação do banco de dados
O Alteryx Server persiste a maioria das informações do aplicativo em um MongoDB integrado. Durante a instalação, um ID de usuário e uma senha de aplicativo são gerados para acessar informações no banco de dados. Vá para a página de ajuda do Controlador para obter outras opções de banco de dados, incluindo o Mongo gerenciado pelo usuário e o MongoDB Atlas.
Criptografia de transporte
A criptografia impede a exposição e a modificação de dados confidenciais durante o transporte, como senhas, informações de sessão do usuário e transações. Recomendamos criptografar conexões com o Server usando HTTPS com TLS 1.2 ou superior para impedir a interceptação por pessoas não autorizadas. A operação HTTPS pode ser configurada em "Configurações do sistema"; para garantir que o TLS seja negociado na versão 1.2 ou superior, talvez seja necessário modificar as configurações do Schannel conforme mencionado na seção deste guia intitulada Proteger a camada do sistema operacional .
Acesse Configurar SSL/TLS no Server para obter mais informações.
Segurança dos dados em repouso
Durante a execução do processo, o Server cria evidências duráveis na forma de arquivos temporários, metadados e arquivos de log. Esses dados em repouso são armazenados fisicamente no Mongo DB e no armazenamento local do Server. Abaixo, você encontrará algumas questões comuns sobre dados em repouso, incluindo técnicas que podem ser implementadas para resolvê-las.
Nota
As instâncias MongoDB Enterprise ou MongoDB Atlas gerenciadas pelo usuário oferecem suporte à criptografia em repouso. Para obter mais informações, acesse a documentação do MongoDB .
Os arquivos temporários no formato YXDB são usados para armazenar dados durante a execução do processo Alteryx. Esses arquivos podem conter dados reais que são transmitidos pelo fluxo de trabalho no tempo de execução.
Os arquivos temporários são colocados em escopo nas invocações do Engine e excluídos assim que não forem mais necessários pelos processos em etapas posteriores ou após a execução do fluxo de trabalho do Alteryx. Esses arquivos, às vezes, podem ficar para trás se o processo do Alteryx falhar. Mesmo nesse caso, os arquivos temporários ainda serão excluídos automaticamente quando o serviço for reiniciado.
O diretório de nível superior onde os arquivos temporários são armazenados é definido no Alteryx Server em Configurações do sistema > Engine > Temporary Directory . Cada invocação do Engine armazena os arquivos temporários individuais em um subdiretório separado neste local.
Como proteger o armazenamento de arquivos temporários
Siga estas recomendações para proteger ainda mais os arquivos temporários.
Tenha RAM (memória) adequada para que o Alteryx use menos armazenamento em disco (troca).
Desmarque a opção Allow users to override these settings em Configurações do sistema > Engine para negar aos usuários a opção de gravar em outros locais. Acesse a página de ajuda Motor para obter mais informações.
Desmarque a opção Browse Everywhere Settings em Configurações do sistema > Engine , para impedir a criação do arquivo YXBE (recurso "Navegar de qualquer lugar").
Localize o diretório de arquivos temporários em uma unidade criptografada (por exemplo, usando o BitLocker).
Exclua o diretório de arquivos temporários dos backups automatizados.
Quando a autenticação é configurada para SSO ou IWA, o Server não possui nem armazena as credenciais usadas para fazer login. Ao usar a autenticação interna do Server, somente hashes de senha com salt são armazenados.
As senhas que o Server usa para autenticar o MongoDB de apoio são criptografadas em repouso usando funções criptográficas fornecidas pelo sistema operacional.
Os logs do Server permitem rastrear erros, avisos, informações e mensagens de depuração. Os arquivos de log contêm informações sobre eventos do Server, fluxos de trabalho, arquivos de dados acessados e o número de registros que estão sendo processados em uma determinada tarefa. Eles não contêm dados reais que estão sendo consumidos, processados ou produzidos. Os logs são coletados para o motor, o nó da IU do Server e o Alteryx Service.
Se os fluxos de trabalho não forem carregados, entre em contato com o suporte ao cliente para obter assistência.
Os logs são salvos nos seguintes locais:
Os logs do nó da IU do Server são armazenados em
C:\ProgramData\Alteryx\Gallery\Logse têm um nome como: alteryx-2017-09-13.csvOs logs do Server/de serviço são armazenados em
C:\ProgramData\Alteryx\Servicee têm um nome como "AlteryxServiceLog_2017-06-04_00-46-07.log", com o log mais recente sendo nomeado "AlteryxServiceLog.log"Os logs do motor vêm desabilitados por padrão, mas podem ser habilitados em "Configurações do sistema".
Nota
Os logs do motor podem conter rastreamentos de pilha ou mensagens de erro retornadas por outros processos que o motor chama ou invoca durante a execução do fluxo de trabalho, e essas mensagens podem potencialmente expor dados ou metadados que foram passados para o processo externo. Por esse motivo, recomendamos habilitar os logs do motor somente durante o processo de solução de problemas realizado por pessoal autorizado.
Os logs no nível do sistema estão disponíveis no visualizador de eventos do Windows.
Segurança dos dados em trânsito
Os componentes do Alteryx Server transferem dados e fluxos de trabalho. Em diferentes pontos do processo de transferência, os dados em trânsito são criptografados ou expostos, dependendo da configuração.
A IU de front-end do Server usa HTTP como padrão (texto não codificado na porta TCP 80). Recomendamos configurar o Server para HTTPS (SSL/TLS na porta 443).
A comunicação entre nós dentro de um cluster do Server distribuído (consulte os tipos de implantação neste guia) também utiliza a porta 80, mas é criptografada com a criptografia AES-256 e usa as informações hora, salt e token do controlador. Isso garante um payload seguro e sensível ao tempo.
O MongoDB integrado em execução no controlador escuta em um soquete TCP/IP não criptografado (porta TCP 27018). Em uma instância do Server não distribuída, o ouvinte de soquete é somente localhost e não deve ser exposto à rede. Se você executar um Server distribuído (consulte Tipos de implantação neste guia) com o MongoDB integrado, conexões de outros nós de cluster para o MongoDB do controlador serão descriptografadas. Para criptografar as comunicações do banco de dados com TLS/SSL, você precisa alternar para um MongoDB gerenciado pelo usuário (ou MongoDB Atlas).
Métodos de criptografia para fontes de dados (Oracle e SQL Server) e plataformas de relatório (Tableau e PowerBI) são definidos por driver ou conector ODBC de terceiros.
Os dados em trânsito são protegidos por meio de hash e salt de senha, bem como pela geração de tokens de API de cliente em tempo de execução, documentados na seção Proteção do Server deste guia. Para obter a proteção completa dos dados em trânsito, recomendamos criptografar conexões do Server com HTTPS usando TLS 1.2 ou superior.
Armazenamento de credenciais
Dependendo do uso ou da configuração do seu Server, ele pode armazenar várias credenciais. Revise como essas informações confidenciais são tratadas.
Um fluxo de trabalho em execução pode se conectar a várias fontes de dados externas durante a execução, usando credenciais que podem ser
incorporadas no fluxo de trabalho e protegidas usando a opção para ocultar criptografia ou criptografia de usuário/máquina (DPAPI) (método herdado, não recomendado)
obtidas do armazenamento criptografado DCM.E no momento da execução
armazenadas em uma conexão de dados gerenciada ou em um alias do Server.
Para conexões de dados gerenciadas, você verá " __ENCPWD__ " no XML do fluxo de trabalho, e a credencial correspondente será armazenada em formato criptografado em um dos seguintes arquivos XML, dependendo de como a conexão de dados foi configurada:
%UserProfile%\AppData\Roaming\Alteryx\Engine\GalleryAlias.xml%ProgramData%\Alteryx\Engine\SystemAlias.xml%ProgramData%\Alteryx\Engine\SystemConnections.xml
Com a autenticação integrada do Windows ou SAML, as credenciais de usuário do Server não são de propriedade ou armazenadas pelo Server.
Para autenticação interna, as credenciais de usuário do Server passam por hash, salt e hash novamente.
Segredos internos, como o token do controlador e a senha do Mongo DB, são criptografados por máquina usando a API Windows Crypto com chaves neste local:
%ProgramData%\Microsoft\Crypto\RSA\MachineKeys
. Acesse a página de ajuda
Controlador
para obter mais informações.
Certificados digitais
Um certificado digital é uma prova da identidade do seu Server assinado por uma autoridade de certificação confiável. Para oferecer suporte adequado a conexões criptografadas do navegador do cliente para o Server, você precisa criar um certificado digital para o Server. Esse certificado precisa ser assinado por uma autoridade de certificação em que sua organização confia antes que ele seja instalado nos hosts do Server. Acesse Configurar SSL/TLS no Server para obter mais informações.