Arquitetura de segurança para a estrutura de extensibilidade nos Serviços de Machine Learning do SQL Server

Serviços utilizados no processamento externo (launchpad)

A estrutura de extensibilidade adiciona um novo serviço NT à lista de serviços em uma instalação do SQL Server: SQL Server Launchpad (MSSSQLSERVER).

O mecanismo de banco de dados usa o serviço SQL Server launchpad para instanciar uma sessão de script externo como um processo separado. O processo é executado sob uma conta de baixo privilégio. Essa conta é diferente do SQL Server, do Launchpad propriamente dito e da identidade do usuário sob a qual o procedimento armazenado ou a consulta de host foi executada. Executar o script em um processo separado, em uma conta de baixo privilégio, é a base do modelo de segurança e de isolamento para scripts externos no SQL Server.

O SQL Server também mantém um mapeamento da identidade do usuário que está chamando para a conta de trabalho de baixo privilégio usada para iniciar o processo de satélite. Em alguns cenários, em que o script ou o código faz uma chamada de volta ao SQL Server para obter dados e executar operações, o SQL Server consegue gerenciar a transferência de identidade de forma transparente. O script que contiver instruções SELECT ou funções de chamada e outros objetos de programação normalmente será bem-sucedido se o usuário de chamada tiver permissões suficientes.

Serviços utilizados no processamento externo (launchpad)

A estrutura de extensibilidade adiciona um novo serviço NT à lista de serviços em uma instalação do SQL Server: Launchpad do SQL Server (MSSSQLSERVER).

O mecanismo de banco de dados usa o serviço SQL Server launchpad para instanciar uma sessão de script externo como um processo separado. O processo é executado sob a identidade do usuário do launchpad, mas com a restrição adicional de estar contido dentro de um AppContainer. Executar o script em um processo separado, no AppContainer, é a base do modelo de segurança e de isolamento para scripts externos no SQL Server.

O SQL Server também mantém um mapeamento entre a identidade do usuário chamador e a conta de trabalho com poucos privilégios usada para iniciar o processo satélite. Em alguns cenários, em que o script ou o código faz uma chamada de volta ao SQL Server para obter dados e realizar operações, o SQL Server consegue gerenciar a transferência de identidade de forma transparente. O script que contiver instruções SELECT ou funções de chamada e outros objetos de programação normalmente será bem-sucedido se o usuário de chamada tiver permissões suficientes.

Serviços usados no processamento externo

A estrutura de extensibilidade adiciona um novo daemon em uma instalação do SQL Server: mssql-launchpadd. mssql-launchpadd é executado na conta de baixos privilégios mssql_launchpadd, que é criada quando o pacote mssql-server-extensibility é instalado.

Há suporte para apenas uma instância do mecanismo de banco de dados e há um serviço de launchpadd associado à instância. Quando um script é executado, o serviço launchpadd inicia um processo launchpad separado com a conta de usuário de baixos privilégios mssql_satellite em seus próprios novos namespaces de PID, IPC, montagem e rede. Cada processo satélite herda do launchpad a conta de usuário mssql_satellite e a utiliza durante toda a execução do script.

Para obter mais informações, confira Arquitetura de extensibilidade no Serviços de Machine Learning do SQL Server.

Identidades usadas no processamento (SQLRUserGroup)

O SQLRUserGroup (grupo de usuários ocm restrições do SQL) é criado pela instalação do SQL Server e contém um pool de contas de usuário locais do Windows com privilégios baixos. Quando um processo externo é necessário, o launchpad seleciona uma conta de trabalho disponível e a utiliza para executar um processo. Mais especificamente, o launchpad ativa uma conta de serviço disponível, a associa à identidade do usuário que fez a chamada e executa o script sob essa conta de serviço.

• O SQLRUserGroup está vinculado a uma instância específica. Um pool separado de contas de trabalho é necessário para cada instância em que o aprendizado de máquina foi habilitado. Contas não podem ser compartilhadas entre instâncias.

• O tamanho do pool de conta de usuário é estático e o valor padrão é 20, o que dá suporte a 20 sessões simultâneas. O número de sessões de runtime externas que podem ser iniciadas simultaneamente é limitado pelo tamanho desse pool de conta de usuário.

• Os nomes de conta de trabalho no pool estão no formato SQLInstanceNamenn. Por exemplo, em uma instância padrão, SQLRUserGroup contém contas chamadas MSSQLSERVER01, MSSQLSERVER02 e assim por diante, até MSSQLSERVER20.

As tarefas paralelizadas não consomem contas adicionais. Por exemplo, se um usuário executar uma tarefa de pontuação que usa processamento paralelo, a mesma conta de trabalho será reutilizada para todos os threads. Se pretende fazer uso intensivo do aprendizado de máquina, você pode aumentar o número de contas usadas para executar scripts externos. Para obter mais informações, consulte Escalar a execução simultânea de scripts externos nos Serviços de Machine Learning do SQL Server.

Permissões concedidas a SQLRUserGroup

Por padrão, os membros do SQLRUserGroup têm permissões de leitura e de execução em executáveis nos seguintes diretórios SQL Server: Binn, R_SERVICES e PYTHON_SERVICES. Isso inclui o acesso a executáveis, bibliotecas e conjuntos de arquivos internos nas distribuições do R e do Python instaladas com o SQL Server.

Para proteger recursos confidenciais no SQL Server, você pode, opcionalmente, definir uma ACL (lista de controle de acesso) que nega acesso ao SQLRUserGroup. Por outro lado, você também pode conceder permissões a recursos de dados locais que existem no computador host, além do SQL Server propriamente dito.

Por definição, SQLRUserGroup não possui login no banco de dados nem permissões para acessar quaisquer dados. Em determinadas circunstâncias, talvez você queira criar um login para permitir conexões de loopback, especialmente quando uma identidade confiável do Windows é o usuário que faz a chamada. Essa funcionalidade é chamada de autenticação implícita. Para obter mais informações, confira Adicionar SQLRUserGroup como um usuário de banco de dados.

Mapeamento de identidade

Quando uma sessão é iniciada, o launchpad mapeia a identidade do usuário de chamada para uma conta de trabalho. O mapeamento de um usuário externo do Windows ou de um login SQL válido para uma conta de trabalho é válido apenas durante a vigência do procedimento armazenado SQL que executa o script externo. Consultas paralelas do mesmo logon são mapeadas para a mesma conta de trabalho do usuário.

Durante a execução, o launchpad cria pastas temporárias para armazenar dados de sessão, excluindo-os quando a sessão termina. O acesso aos diretórios é restrito. No R, o RLauncher executa essa tarefa. No Python, o PythonLauncher executa essa tarefa. Cada conta de trabalho individual é restrita à sua própria pasta e não pode acessar arquivos em pastas acima do seu próprio nível. No entanto, a conta de trabalho pode ler, gravar ou excluir filhos contidos na pasta de trabalho de sessão que foi criada. Se você for um administrador no computador, você poderá exibir os diretórios criados para cada processo. Cada diretório é identificado por seu GUID de sessão.

Isolamento do AppContainer

O isolamento é obtido por meio de AppContainers. Em tempo de execução, quando um script externo é detectado em um procedimento armazenado ou em uma consulta, o SQL Server chama o launchpad com uma solicitação de um inicializador específico da extensão. O Launchpad invoca o ambiente de runtime apropriado em um processo sob sua identidade e instancia um AppContainer para contê-lo. Essa alteração é benéfica porque o gerenciamento de conta local e de senha não é mais necessário. Além disso, em instalações em que as contas de usuário local são proibidas, a eliminação da dependência de conta de usuário local significa que agora você pode usar esse recurso.

Conforme implementado pelo SQL Server, os AppContainers são um mecanismo interno. Embora você não veja evidências físicas de AppContainers no monitor de processos, pode encontrá-las em regras de firewall de saída criadas pela instalação para impedir que processos façam chamadas de rede. Para obter mais informações, confira Configuração de firewall para os Serviços de Machine Learning do SQL Server.

Mapeamento de identidade

Quando uma sessão é iniciada, o launchpad mapeia a identidade do usuário de chamada para um AppContainer.

Mapeamento de identidade

O daemon do Launchpadd (com dois "d" - mssql-launchpadd) associa a identidade do usuário chamador a um processo launchpad separado (com um único "d"), com uma pasta de "GUID do launchpad" e um certificado satélite. Essas pastas GUID do launchpad são criadas em /var/opt/mssql-extensibility/data/. O processo do launchpad usa esse certificado para autenticar-se novamente no SQL e, em seguida, cria pastas temporárias para cada GUID de sessão na pasta GUID do launchpad. O processo satélite (R, Python ou ExtHost) pode acessar a pasta GUID do launchpad, o certificado nele contido e a pasta GUID da sua sessão.

O script SQL a seguir imprime o conteúdo das pastas do launchpad.

EXECUTE sp_execute_external_script @language = N'R'
    ,@script = N'
print("Contents of /var/opt/mssql-extensibility/data :");
print(system("ls -al /var/opt/mssql-extensibility/data"));
print("Contents of Launchpad GUID folder:");
print(system("ls -al /var/opt/mssql-extensibility/data/*"));
print(system("ls -al /var/opt/mssql-extensibility/data/*/*"))
'
    ,@input_data_1 = N'SELECT 1 AS hello'

Autenticação implícita (solicitações de loopback)

A autenticação implícita descreve o comportamento de solicitação de conexão sob o qual processos externos, em execução como contas de trabalho com privilégios baixos, são apresentados como uma identidade de usuário confiável para o SQL Server em solicitações de loopback para dados ou operações. Como um conceito, a autenticação implícita é exclusiva da autenticação do Windows, em cadeias de conexão do SQL Server que especificam uma conexão confiável, em solicitações originadas de processos externos, tais como o script R ou Python. Às vezes, isso também é chamado de loopback.

As conexões confiáveis podem ser usadas a partir de scripts externos, mas apenas com configuração adicional. Na arquitetura de extensibilidade, os processos externos são executados em contas de trabalho, herdando permissões do SQLRUserGroup pai. Quando uma cadeia de conexão especifica Trusted_Connection=True, a identidade da conta de trabalho é apresentada na solicitação de conexão, que é desconhecida por padrão para o SQL Server.

Para que as conexões confiáveis sejam bem-sucedidas, você deve criar um logon de banco de dados para o SQLRUserGroup. Depois de fazer isso, qualquer conexão confiável de qualquer membro de SQLRUserGroup tem direitos de logon para o SQL Server. Para obter instruções detalhadas, confira Adicionar SQLRUserGroup a um logon de banco de dados.

As conexões confiáveis não são a formulação mais amplamente usada de uma solicitação de conexão. Quando o script externo especifica uma conexão, caso essa conexão seja para uma fonte de dados ODBC, pode ser mais comum usar um logon do SQL ou um nome de usuário e senha totalmente especificados.

Como funciona a autenticação implícita para sessões de script externo

O diagrama a seguir mostra a interação dos componentes do SQL Server com o runtime da linguagem e como ele faz a autenticação implícita no Windows.

Autenticação implícita (solicitações de loopback)

A autenticação implícita descreve o comportamento de solicitação de conexão sob o qual processos externos em execução sob AppContainers são apresentados como uma identidade de usuário confiável para o SQL Server em solicitações de loopback para dados ou operações. Como um conceito, a autenticação implícita não é exclusiva da autenticação do Windows, em cadeias de conexão do SQL Server que especificam uma conexão confiável, em solicitações originadas de processos externos, tais como o script R ou Python. Às vezes, isso também é chamado de loopback.

Ao gerenciar identidade e credenciais, o AppContainer impede o uso de credenciais do usuário para obter acesso a recursos ou fazer logon em outros ambientes. O ambiente do AppContainer cria um identificador que usa as identidades combinadas do usuário e do aplicativo, portanto, as credenciais são exclusivas para cada emparelhamento de usuário/aplicativo e o aplicativo não pode representar o usuário. Para obter mais informações, confira Isolamento do AppContainer.

Para obter mais detalhes sobre conexões de loopback, confira Conexão de loopback para o SQL Server de um script Python ou R.

Como funciona a autenticação implícita para sessões de script externo

O diagrama a seguir mostra a interação dos componentes do SQL Server com o runtime da linguagem e como ele faz a autenticação implícita no Windows.

Autenticação implícita (solicitações de loopback)

A autenticação implícita descreve o comportamento de solicitação de conexão sob o qual processos externos em execução como usuários do mssql_satellite com privilégios baixos nos próprios namespaces são apresentados como uma identidade de usuário confiável para o SQL Server em solicitações de loopback para dados ou operações. Às vezes, isso também é chamado de loopback.

Uma conexão de loopback é estabelecida usando o certificado do satélite da pasta GUID do Launchpad para autenticar novamente no SQL Server pelo processo de satélite. A identidade do usuário que fez a chamada é mapeada para esse certificado e, portanto, o processo satélite que se reconecta ao SQL Server usando o certificado pode ser associado novamente ao usuário que fez a chamada.

Para obter mais informações, confira Conexão de loopback para o SQL Server de um script Python ou R.

Como funciona a autenticação implícita para sessões de script externo

O diagrama a seguir mostra a interação dos componentes do SQL Server com o runtime da linguagem e como ele faz a autenticação implícita no Linux.