Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Aplica-se a:
SQL Server 2016 (13.x) e versões posteriores
Este artigo descreve a arquitetura de segurança utilizada para integrar o motor de base de dados SQL Server e componentes relacionados com o framework de extensibilidade nos Serviços de Aprendizagem Automática do SQL Server. Examina os elementos protegidos, serviços, identidade do processo e permissões. Os pontos-chave abordados neste artigo incluem o propósito do launchpad, do SQLRUserGroup e das contas de trabalhadores, o isolamento de processos de scripts externos e a forma como as identidades dos utilizadores são mapeadas para as contas dos trabalhadores.
Para mais informações sobre os conceitos-chave e componentes de extensibilidade no SQL Server, consulte Arquitetura de extensibilidade em SQL Server Machine Learning Services.
Elementos de Segurança para script externo
Um script externo é submetido como parâmetro de entrada a um procedimento armazenado do sistema criado para este fim, ou é encapsulado num procedimento armazenado que define. O script pode ser escrito em R, Python ou linguagens externas como Java ou .NET. Alternativamente, pode ter modelos pré-treinados e armazenados num formato binário numa tabela de base de dados, chamáveis numa função T-SQL PREDICT.
Como o script é fornecido através de objetos de esquema de base de dados existentes, procedimentos armazenados e tabelas, não existem novos securáveis para os Serviços de Aprendizagem Automática do SQL Server.
Independentemente de como está a usar o script ou do que consistem, os objetos da base de dados serão criados e provavelmente guardados, mas não é introduzido nenhum novo tipo de objeto para armazenar script. Como resultado, a capacidade de consumir, criar e guardar objetos de base de dados depende em grande parte das permissões da base de dados já definidas para os seus utilizadores.
Permissions
O modelo de segurança de dados do SQL Server para logins e funções de base de dados estende-se a scripts externos. É necessário um login SQL Server ou uma conta de utilizador Windows para executar scripts externos que utilizam dados SQL Server ou que funcionam com SQL Server como contexto de computação. Utilizadores de base de dados que têm permissões para executar uma consulta podem aceder aos mesmos dados a partir de scripts externos.
O login ou conta de utilizador identifica o principal de segurança, que pode necessitar de múltiplos níveis de acesso, dependendo dos requisitos do script externo:
- Permissão para aceder à base de dados onde scripts externos estão ativados.
- Permissões para ler dados de objetos seguros, como tabelas.
- A capacidade de escrever novos dados numa tabela, como um modelo, ou de pontuar resultados.
- A capacidade de criar novos objetos, como tabelas, stored procedures que utilizam o script externo, ou funções personalizadas que utilizam scripts externos.
- O direito de instalar novos pacotes no computador SQL Server, ou de usar pacotes fornecidos a um grupo de utilizadores.
Cada pessoa que executa um script externo usando SQL Server como contexto de execução deve ser mapeada para um utilizador na base de dados. Em vez de definir permissões individuais para utilizadores da base de dados, poderia criar papéis para gerir conjuntos de permissões e atribuir utilizadores a esses papéis, em vez de definir permissões individuais.
Para obter mais informações, consulte Conceder permissão aos usuários para os Serviços de Aprendizado de Máquina do SQL Server.
Permissões ao usar uma ferramenta cliente externa
Os utilizadores que usam scripts numa ferramenta cliente externa devem ter o seu login ou conta mapeados para um utilizador na base de dados se precisarem de executar um script externo na base de dados, ou aceder a objetos e dados da base de dados. As mesmas permissões são necessárias quer o script externo seja enviado por um cliente remoto de ciência de dados ou executado usando um procedimento armazenado T-SQL.
Por exemplo, suponha que criou um script externo que corre no seu computador local e quer executar esse script no SQL Server. Deve garantir que as seguintes condições são cumpridas:
- A base de dados permite ligações remotas.
- O login SQL ou a conta do Windows que usou para aceder à base de dados foi adicionado ao SQL Server ao nível da instância.
- O utilizador de login SQL ou do Windows deve ter permissão para executar scripts externos. Geralmente, esta permissão só pode ser adicionada por um administrador de base de dados.
- O utilizador de login SQL ou do Windows deve ser adicionado como utilizador, com permissões apropriadas, em cada base de dados onde o script externo execute alguma destas operações:
- Recuperar dados.
- Escrever ou atualizar dados.
- Criar novos objetos, como tabelas ou procedimentos armazenados.
Depois de a conta de login ou de utilizador do Windows ter sido provisionada e receber as permissões necessárias, pode executar um script externo no SQL Server usando um objeto fonte de dados em R ou a biblioteca revoscalepy em Python, ou chamando um procedimento armazenado que contenha o script externo.
Sempre que um script externo é lançado a partir do SQL Server, a segurança do motor de base de dados obtém o contexto de segurança do utilizador que iniciou o trabalho e gere os mapeamentos do utilizador ou login para objetos securáveis.
Portanto, todos os scripts externos iniciados a partir de um cliente remoto devem especificar a informação de login ou do utilizador como parte da cadeia de ligação.
Serviços utilizados no processamento externo (launchpad)
O framework de extensibilidade adiciona um novo serviço NT à lista de serviços numa instalação SQL Server: SQL Server Launchpad (MSSSQLSERVER).
O motor de base de dados utiliza o serviço de launchpad SQL Server para instanciar uma sessão de script externo como um processo separado. O processo decorre sob uma conta de baixo privilégio. Esta conta é distinta do SQL Server, do próprio launchpad e da identidade do utilizador sob a qual o procedimento armazenado ou consulta ao host foi executada. Executar um script num processo separado, sob uma conta de baixo privilégio, é a base do modelo de segurança e isolamento para scripts externos no SQL Server.
O SQL Server também mantém um mapeamento da identidade do utilizador que realiza a chamada para a conta de baixo privilégio usada para iniciar o processo satélite. Em alguns cenários, em que scripts ou códigos fazem chamadas de volta ao SQL Server para dados e operações, o SQL Server consegue gerir a transferência de identidade de forma fluida. Um script contendo instruções SELECT ou funções de chamada e outros objetos de programação normalmente terá sucesso se o utilizador que chama tiver permissões suficientes.
Observação
Por defeito, o SQL Server Launchpad está configurado para correr sob NT Service\MSSQLLaunchpad, que está provisionado com todas as permissões necessárias para executar scripts externos. Para mais informações sobre opções configuráveis, consulte a configuração do serviço de launchpad do SQL Server.
Serviços utilizados no processamento externo (launchpad)
O framework de extensibilidade adiciona um novo serviço NT à lista de serviços numa instalação SQL Server: o launchpad do SQL Server (MSSSQLSERVER).
O motor de base de dados utiliza o serviço de launchpad SQL Server para instanciar uma sessão de script externo como um processo separado. O processo corre sob a identidade do utilizador do launchpad, mas com a restrição adicional de estar contido dentro de um AppContainer. Executar um script num processo separado, no AppContainer, é a base do modelo de segurança e isolamento para scripts externos no SQL Server.
O SQL Server também mantém um mapeamento da identidade do utilizador que realiza a chamada para a conta de baixo privilégio usada para iniciar o processo satélite. Em alguns cenários, em que scripts ou códigos fazem chamadas de volta ao SQL Server para dados e operações, o SQL Server consegue gerir a transferência de identidade de forma fluida. Um script contendo instruções SELECT ou funções de chamada e outros objetos de programação normalmente terá sucesso se o utilizador que chama tiver permissões suficientes.
Observação
Por defeito, o SQL Server Launchpad está configurado para correr sob NT Service\MSSQLLaunchpad, que está provisionado com todas as permissões necessárias para executar scripts externos. Para mais informações sobre opções configuráveis, consulte a configuração do serviço de launchpad do SQL Server.
Serviços utilizados no processamento externo
O framework de extensibilidade adiciona um novo daemon numa instalação SQL Server: mssql-launchpadd. O mssql-launchpadd é executado sob a conta de baixo privilégio mssql_launchpadd que é criada quando o pacote mssql-server-extensibility é instalado.
Apenas uma instância do motor de base de dados é suportada e existe um serviço launchpadd associado à instância. Quando um script é executado, o serviço launchpadd inicia um processo separado de launchpad com a conta de utilizador de baixo privilégio mssql_satellite no seu próprio novo espaço de nomes de PID, IPC, montagem e rede. Cada processo satélite herda a conta de utilizador mssql_satellite do launchpad e utiliza essa conta durante a execução do script.
Para mais informações, veja Arquitetura de extensibilidade nos Serviços de Aprendizagem Automática do SQL Server.
Identidades usadas no processamento (SQLRUserGroup)
O SQLRUserGroup (grupo de utilizadores restrito SQL) é criado pelo SQL Server Setup e contém um conjunto de contas locais de utilizadores Windows de baixo privilégio. Quando é necessário um processo externo, o Launchpad pega numa conta de trabalhador disponível e usa-a para executar um processo. Mais especificamente, o launchpad ativa uma conta de trabalhador disponível, associa-a à identidade do utilizador que a invoca e executa o script na conta de trabalhador.
O SQLRUserGroup está ligado a uma instância específica. É necessário um conjunto separado de contas de trabalhadores para cada instância em que o machine learning foi ativado. As contas não podem ser partilhadas entre instâncias.
O tamanho do pool de contas de utilizador é estático e o valor padrão é 20, o que suporta 20 sessões simultâneas. O número de sessões de execução externas que podem ser lançadas simultaneamente é limitado pelo tamanho deste grupo de contas de utilizador.
Os nomes das contas de trabalhadores no pool têm o formato SQLInstanceNamenn. Por exemplo, numa instância padrão, o SQLRUserGroup contém contas nomeadas MSSQLSERVER01, MSSQLSERVER02, e assim sucessivamente, até MSSQLSERVER20.
As tarefas paralelizadas não consomem contas adicionais. Por exemplo, se um utilizador executar uma tarefa de pontuação que utiliza processamento paralelo, a mesma conta de trabalhador é reutilizada para todos os threads. Se pretende fazer uso intensivo de aprendizagem automática, pode aumentar o número de contas usadas para executar scripts externos. Para obter mais informações, consulte Dimensionar a execução simultânea de scripts externos no SQL Server Machine Learning Services.
Permissões concedidas ao SQLRUserGroup
Por defeito, os membros do SQLRUserGroup têm permissões de leitura e execução em ficheiros nos diretórios SQL Server Binn, R_SERVICES e PYTHON_SERVICES . Isto inclui o acesso a executáveis, bibliotecas e conjuntos de dados incorporados nas distribuições R e Python instaladas com o SQL Server.
Para proteger recursos sensíveis no SQL Server, pode, opcionalmente, definir uma lista de controlo de acesso (ACL) que negue o acesso ao SQLRUserGroup. Por outro lado, também poderia conceder permissões a recursos de dados locais que existam no computador anfitrião, para além do próprio SQL Server.
Por design, o SQLRUserGroup não tem login na base de dados nem permissões para quaisquer dados. Em certas circunstâncias, pode querer criar uma conta de login para permitir ligações de loopback, especialmente quando uma identidade confiável do Windows é o utilizador que está a realizar a chamada. Esta funcionalidade chama-se autenticação implícita. Para mais informações, consulte Adicionar SQLRUserGroup como utilizador de base de dados.
Mapeamento de identidade
Quando uma sessão é iniciada, o launchpad associa a identidade do utilizador que inicia a sessão a uma conta de trabalhador. O mapeamento de um utilizador externo do Windows ou de um login SQL válido para uma conta de trabalhador é válido apenas durante a duração do procedimento armazenado SQL que executa o script externo. Consultas paralelas do mesmo login são mapeadas para a mesma conta de trabalhador.
Durante a execução, o launchpad cria pastas temporárias para armazenar os dados da sessão, eliminando-as quando a sessão termina. Os diretórios têm acesso restrito. Para R, RLauncher executa esta tarefa. Para Python, o PythonLauncher executa esta tarefa. Cada conta individual de trabalhador está restrita à sua própria pasta e não pode aceder a ficheiros em pastas acima do seu próprio nível. No entanto, a conta do trabalhador pode ler, escrever ou eliminar filhos na pasta de trabalho da sessão que foi criada. Se for administrador no computador, pode ver os diretórios criados para cada processo. Cada diretório é identificado pelo seu GUID de sessão.
Isolamento do AppContainer
O isolamento é conseguido através de AppContainers. Em tempo de execução, quando um script externo é detetado num procedimento armazenado ou consulta, o SQL Server aciona o launchpad com um pedido para um lançador específico da extensão. O Launchpad invoca o ambiente de execução apropriado num processo sob a sua identidade e instancia um AppContainer para o conter. Esta alteração é benéfica porque a gestão local de contas e palavras-passe deixou de ser necessária. Além disso, em instalações onde contas de utilizadores locais são proibidas, a eliminação da dependência da conta de utilizador local significa que agora pode usar esta funcionalidade.
Tal como implementados pelo SQL Server, os AppContainers são um mecanismo interno. Embora não veja evidências físicas de AppContainers no Process Monitor, pode encontrá-las nas regras de firewall de saída criadas pelo Setup para impedir que os processos façam chamadas de rede. Para mais informações, consulte Configuração de firewall para Serviços de Aprendizagem Automática SQL Server.
Mapeamento de identidade
Quando uma sessão é iniciada, o launchpad mapeia a identidade do utilizador que chama para um AppContainer.
Observação
No SQL Server 2019 e posteriores, o SQLRUserGroup tem apenas um membro, que agora é a única conta do serviço de Launchpad do SQL Server, em vez de múltiplas contas de trabalhadores.
Mapeamento de identidade
O daemon launchpadd (duplo 'D' - mssql-launchpadd) associa a identidade do utilizador que inicia a chamada a um processo separado de launchpad (com um único 'D'), com uma pasta "GUID do launchpad" e um certificado de satélite. Estas pastas GUID do launchpad são criadas em /var/opt/mssql-extensibility/data/. O processo launchpad utiliza este certificado para reestabelecer a autenticação 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 aceder à pasta GUID da plataforma de lançamento, ao certificado associado a ela e à pasta GUID da sessão.
O script SQL seguinte 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 (pedidos de loopback)
A autenticação implícita descreve o comportamento dos pedidos de ligação sob o qual processos externos a correr como contas de trabalhadores de baixo privilégio são apresentados como uma identidade de utilizador confiável ao SQL Server em pedidos de loopback para dados ou operações. Como conceito, a autenticação implícita é exclusiva da autenticação Windows, nas strings de conexão do SQL Server que especificam uma conexão de confiança, em pedidos originados de processos externos, como scripts em R ou Python. Por vezes também é referido como loopback.
As ligações confiáveis são operáveis a partir de scripts externos, mas apenas com configuração adicional. Na arquitetura de extensibilidade, os processos externos executam-se sob contas de trabalho, herdando permissões do SQLRUserGroup pai. Quando uma string de ligação especifica Trusted_Connection=True, a identidade da conta do trabalhador é apresentada no pedido de ligação, que é desconhecida por padrão para o SQL Server.
Para que as ligações confiáveis sejam bem-sucedidas, deve criar um login de base de dados para o SQLRUserGroup. Depois de o fazer, qualquer ligação de confiança de qualquer membro do SQLRUserGroup tem direitos de acesso ao SQL Server. Para instruções passo a passo, consulte Adicionar SQLRUserGroup a um login de base de dados.
As ligações confiáveis não são a forma mais comum de um pedido de conexão. Quando o script externo especifica uma ligação, pode ser mais comum usar um login SQL, ou um nome de utilizador e palavra-passe totalmente especificados se a ligação for para uma fonte de dados ODBC.
Como funciona a autenticação implícita para sessões de scripts externos
O diagrama seguinte mostra a interação dos componentes do SQL Server com o runtime da linguagem e como esta realiza a autenticação implícita no Windows.
Autenticação implícita (pedidos de loopback)
A autenticação implícita descreve o comportamento dos pedidos de conexão em que processos externos executados em AppContainers são apresentados como uma identidade de utilizador fidedigna ao SQL Server em pedidos de loopback para dados ou operações. Como conceito, a autenticação implícita já não é exclusiva da autenticação Windows, em cadeias de ligação SQL Server que especificam uma ligação de confiança, em pedidos originados de processos externos como R ou scripts Python. Por vezes também é referido como loopback.
Ao gerir identidades e credenciais, o AppContainer impede o uso de credenciais de utilizador para aceder a recursos ou iniciar sessão noutros ambientes. O ambiente AppContainer cria um identificador que utiliza as identidades combinadas do utilizador e da aplicação, pelo que as credenciais são únicas para cada par utilizador/aplicação e a aplicação não pode fazer-se passar pelo utilizador. Para mais informações, consulte AppContainer Isolation.
Para mais detalhes sobre ligações de loopback, veja Ligação de loopback ao SQL Server a partir de um script em Python ou R.
Como funciona a autenticação implícita para sessões de scripts externos
O diagrama seguinte mostra a interação dos componentes do SQL Server com o runtime da linguagem e como esta realiza a autenticação implícita no Windows.
Autenticação implícita (pedidos de loopback)
A autenticação implícita descreve o comportamento dos pedidos de conexão em que processos externos são executados como utilizadores mssql_satellite de baixo privilégio nos seus próprios namespaces e são apresentados como uma identidade de utilizador confiável ao SQL Server em pedidos de loopback para dados ou operações. Por vezes também é referido como loopback.
Uma ligação de loopback é conseguida usando o certificado de satélite da pasta GUID do launchpad para autenticar de volta ao SQL Server pelo processo satélite. A identidade do utilizador que chama é mapeada para este certificado e, assim, o processo satélite que se liga de volta ao SQL Server através do certificado pode ser mapeado de volta para o utilizador chamante.
Para mais informações, consulte conexão de loopback ao SQL Server a partir de um script em Python ou R.
Como funciona a autenticação implícita para sessões de scripts externos
O diagrama seguinte mostra a interação dos componentes do SQL Server com o runtime da linguagem e como esta realiza a autenticação implícita no Linux.
Não há suporte para Encriptação Transparente de Dados em descanso
A Encriptação Transparente de Dados (TDE) não é suportada para dados enviados ou recebidos do tempo de execução do script externo. A razão é que o processo externo corre fora do processo do SQL Server. Portanto, os dados usados pelo tempo de execução externo não são protegidos pelas funcionalidades de encriptação do motor de base de dados. Este comportamento não é diferente de qualquer outro cliente a correr no computador SQL Server que lê dados da base de dados e faz uma cópia.
Como consequência, o TDE não é aplicado a quaisquer dados que utilize em scripts externos, nem a quaisquer dados guardados em disco, nem a quaisquer resultados intermédios persistentes. No entanto, outros tipos de encriptação, como a encriptação do Windows BitLocker ou a encriptação de terceiros aplicada ao nível do ficheiro ou pasta, continuam a aplicar-se.
No caso do Always Encrypted, os runtimes externos não têm acesso às chaves de encriptação. Portanto, os dados não podem ser enviados para os scripts.
Próximos passos
Neste artigo, aprendeu os componentes e o modelo de interação da arquitetura de segurança incorporada no framework de extensibilidade. Os pontos-chave abordados neste artigo incluem o propósito do launchpad, do SQLRUserGroup e das contas de trabalhadores, o isolamento de processos de scripts externos e a forma como as identidades dos utilizadores são mapeadas para as contas dos trabalhadores.
Como passo seguinte, reveja as instruções para conceder permissões. Para servidores que utilizam autenticação Windows, deve também consultar Adicionar SQLRUserGroup a um login de base de dados para saber quando é necessária uma configuração adicional.