Compartilhar via

CREATE ASSEMBLY (Transact-SQL)

  • Artigo

Aplica-se a: SQL Server Instância Gerenciada de SQL do Azure

Cria um módulo de aplicativo gerenciado que contém metadados de classe e código gerenciado como um objeto em uma instância do SQL Server. Ao fazer referência a esse módulo, funções CLR (Common Language Runtime), procedimentos armazenados, gatilhos, agregações definidas pelo usuário e tipos definidos pelo usuário podem ser criados no banco de dados.

Convenções de sintaxe de Transact-SQL

Sintaxe

CREATE ASSEMBLY assembly_name
[ AUTHORIZATION owner_name ]
FROM { <client_assembly_specifier> | <assembly_bits> [ , ...n ] }
[ WITH PERMISSION_SET = { SAFE | EXTERNAL_ACCESS | UNSAFE } ]
[ ; ]
<client_assembly_specifier> ::=
    '[ \\computer_name\ ] share_name\ [ path\ ] manifest_file_name'
    | '[ local_path\ ] manifest_file_name'

<assembly_bits> ::=
{ varbinary_literal | varbinary_expression }

Argumentos

assembly_name

O nome do assembly. O nome precisa ser exclusivo no banco de dados e um identificador válido.

AUTHORIZATION owner_name

Especifica o nome de um usuário ou função como proprietário do assembly. owner_name deve ser o nome de uma função da qual o usuário atual é membro ou o usuário atual deve ter IMPERSONATE permissão para owner_name. Se não estiver especificada, a propriedade será dada ao usuário atual.

<client_assembly_specifier>

Especifica o caminho local ou o local da rede onde o assembly que está sendo carregado está localizado e também o nome do arquivo de manifesto que corresponde ao assembly. <client_assembly_specifier> pode ser expresso como uma cadeia de caracteres fixa ou uma expressão que avalia uma cadeia de caracteres fixa com variáveis. CREATE ASSEMBLY não dá suporte ao carregamento de assemblies multimódulos. O SQL Server também procura assemblies dependentes desse assembly no mesmo lugar e os carrega com o mesmo proprietário do assembly do nível raiz. Se esses assemblies dependentes não forem encontrados e ainda não estiverem carregados no banco de dados atual, CREATE ASSEMBLY o falhará. Se os assemblies dependentes já estiverem carregados no banco de dados atual, o proprietário deles deve ser o mesmo proprietário do assembly recém-criado.

Importante

O Banco de Dados SQL do Azure e a Instância Gerenciada de SQL do Azure não dão suporte à criação de um assembly de um arquivo.

<client_assembly_specifier> não pode ser especificado se o usuário conectado estiver sendo representado.

<assembly_bits>

A lista de valores binários que compõem o assembly e seus assemblies dependentes. O primeiro valor na lista é considerado o assembly do nível raiz. Os valores correspondentes aos assemblies dependentes podem ser fornecidos em qualquer ordem. Todos os valores que não correspondem às dependências do assembly raiz são ignorados.

Observação

Essa opção não está disponível em um banco de dados independente.

varbinary_literal

Um literal varbinary .

varbinary_expression

Uma expressão do tipo varbinary.

PERMISSION_SET { SAFE | EXTERNAL_ACCESS | UNSAFE }

Especifica um conjunto de permissões de acesso ao código que são concedidas ao assembly quando acessado pelo SQL Server. Se não for especificado, SAFE é aplicado como padrão.

A PERMISSION_SET opção é afetada pela opção Configuração do servidor: clr strict security . Quando clr strict security está habilitada, todos os assemblies são tratados como UNSAFE.

Recomendamos usar SAFE. SAFE é o conjunto de permissões mais restritivo. O código executado por um assembly com SAFE permissões não pode acessar recursos externos do sistema, como arquivos, rede, variáveis de ambiente ou o Registro.

EXTERNAL_ACCESS Permite que os assemblies acessem determinados recursos externos do sistema, como arquivos, redes, variáveis de ambiente e o Registro.

UNSAFE permite que os assemblies tenham acesso irrestrito a recursos, dentro e fora de uma instância do SQL Server. O código em execução de dentro de um UNSAFE assembly pode chamar código não gerenciado.

SAFE é a configuração de permissão recomendada para assemblies que executam tarefas de computação e gerenciamento de dados sem acessar recursos fora de uma instância do SQL Server.

Observação

As EXTERNAL_ACCESS opções e UNSAFE não estão disponíveis em um banco de dados independente.

Recomendamos o uso EXTERNAL_ACCESS de assemblies que acessam recursos fora de uma instância do SQL Server. EXTERNAL_ACCESS Os assemblies incluem as proteções de confiabilidade e escalabilidade dos SAFE assemblies, mas, do ponto de vista da segurança, são semelhantes aos UNSAFE assemblies. O código em EXTERNAL_ACCESS assemblies é executado por padrão na conta de serviço do SQL Server e acessa recursos externos nessa conta, a menos que o código represente explicitamente o chamador. Portanto, a permissão para criar EXTERNAL_ACCESS assemblies deve ser concedida somente a logons confiáveis para executar código na conta de serviço do SQL Server. Para obter mais informações sobre representação, confira Segurança da integração do CLR (Common Language Runtime).

A especificação UNSAFE permite que o código no assembly tenha total liberdade para executar operações no espaço de processo do SQL Server que podem comprometer a robustez do SQL Server. UNSAFE os assemblies também podem subverter potencialmente o sistema de segurança do SQL Server ou do Common Language Runtime. UNSAFE As permissões devem ser concedidas somente a assemblies altamente confiáveis. Somente membros da função de servidor fixa sysadmin podem criar e alterar UNSAFE assemblies.

Para obter mais informações sobre conjuntos de permissões de assembly, consulte Projetando assemblies.

A segurança de acesso ao código não é mais suportada

O CLR usa o CAS (Segurança de Acesso do Código) no .NET Framework, para o qual não há mais suporte como um limite de segurança. Um assembly CLR criado com PERMISSION_SET = SAFE pode ser capaz de acessar recursos externos do sistema, chamar código não gerenciado e adquirir privilégios de administrador de sistema. No SQL Server 2017 (14.x) e versões posteriores, a sp_configure opção clr strict security aprimora a segurança dos assemblies CLR. A clr strict security está habilitada por padrão e trata assemblies SAFE e EXTERNAL_ACCESS como se eles fossem marcados como UNSAFE. A clr strict security opção pode ser desabilitada para compatibilidade com versões anteriores, mas não é recomendada.

Recomendamos que você assine todos os assemblies por um certificado ou chave assimétrica, com um logon correspondente que tenha recebido UNSAFE ASSEMBLY permissão no master banco de dados. Os administradores do SQL Server também podem adicionar assemblies a uma lista de assemblies, na qual o Mecanismo de Banco de Dados deve confiar. Para obter mais informações, consulte sys.sp_add_trusted_assembly.

Comentários

CREATE ASSEMBLY carrega um assembly que foi compilado anteriormente como um arquivo .dll do código gerenciado para uso dentro de uma instância do SQL Server.

Quando habilitada, a opção PERMISSION_SET nas instruções CREATE ASSEMBLY e ALTER ASSEMBLY é ignorada em tempo de execução, mas as opções PERMISSION_SET são preservadas nos metadados. Ignorar a opção minimiza a quebra de instruções de código existentes.

O SQL Server não permite registrar versões diferentes de um assembly com o mesmo nome, cultura e chave pública.

Ao tentar acessar o assembly especificado no <client_assembly_specifier>, o SQL Server representa o contexto de segurança do logon atual do Windows. Se <client_assembly_specifier> especificar um local de rede (caminho UNC), a representação do logon atual não será transportada para o local de rede devido a limitações de delegação. Nesse caso, o acesso é feito usando o contexto de segurança da conta de serviço do SQL Server. Para obter mais informações, consulte Credenciais (Mecanismo de Banco de Dados).

Além do assembly raiz especificado por assembly_name, o SQL Server tenta carregar todos os assemblies que são referenciados pelo assembly raiz que está sendo carregado. Se um assembly referenciado já tiver sido carregado no banco de dados devido a uma instrução anterior CREATE ASSEMBLY , esse assembly não será carregado, mas estará disponível para o assembly raiz. Se um assembly dependente não tiver sido carregado anteriormente, mas o SQL Server não conseguir localizar seu arquivo de manifesto no diretório de origem, CREATE ASSEMBLY o retornará um erro.

Se algum assembly dependente referenciado pelo assembly raiz ainda não estiver no banco de dados e for carregado implicitamente junto com o assembly raiz, ele terá o mesmo conjunto de permissões que o assembly de nível raiz. Se for necessário criar os assemblies dependentes usando um conjunto de permissões diferente daquele usado pelo assembly de nível raiz, ambos terão que ser carregados explicitamente antes do assembly do nível raiz com o conjunto de permissões apropriado.

Validação de assembly

O SQL Server verifica os binários de assembly carregados pela CREATE ASSEMBLY instrução para garantir as seguintes verificações:

  • O binário de assembly está bem formado com metadados e segmentos de código válidos, e os segmentos de código têm instruções do Microsoft Intermediate Language (MSIL) válidas.

  • O conjunto de assemblies do sistema ao qual ele faz referência é um dos seguintes assemblies com suporte no SQL Server: , , , Microsoft.VisualC.dllSystem.Xml.dllSystem.Web.Services.dllSystem.Core.dllSystem.Xml.Linq.dllCustomMarshallers.dllSystem.Data.SqlXml.dllSystem.dllSystem.Security.dllSystem.Data.dllmscorlib.dllMicrosoft.VisualBasic.dll Outros assemblies de sistema podem ser referenciados, mas eles devem ser registrados explicitamente no banco de dados.

  • Para assemblies criados usando conjuntos de permissões ou SAFE EXTERNAL ACCESS permissões:

    • O código do assembly deve ser do tipo seguro. A segurança do tipo é estabelecida pela execução do verificador do CLR no assembly.

    • O assembly não deve conter nenhum membro de dados estáticos em suas classes, a menos que estejam marcados como somente leitura.

    • As classes no assembly não podem conter métodos finalizadores.

    • As classes ou os métodos do assembly devem ser anotados somente com os atributos de código permitidos. Para obter mais informações, consulte Integração CLR: atributos personalizados para rotinas CLR.

Além das verificações anteriores que são executadas quando CREATE ASSEMBLY as execuções, há verificações extras que são executadas no tempo de execução do código no assembly:

  • Chamar determinadas APIs do .NET Framework que exigem uma permissão de acesso ao código específica poderá falhar se o conjunto de permissões do assembly não incluir essa permissão.

  • Para SAFE e EXTERNAL_ACCESS assemblies, qualquer tentativa de chamar APIs do .NET Framework anotadas com determinados HostProtectionAttributes falhará.

Para obter mais informações, consulte Projetando assemblies.

Permissões

Requer a permissão CREATE ASSEMBLY.

Se PERMISSION_SET = EXTERNAL_ACCESS for especificado, requer EXTERNAL ACCESS ASSEMBLY permissão no servidor. Se PERMISSION_SET = UNSAFE for especificado, requer UNSAFE ASSEMBLY permissão no servidor.

O usuário deve ser o proprietário de todos os assemblies referenciados pelo assembly que será carregado se já houver assemblies no banco de dados. Para carregar um assembly usando um caminho de arquivo, o usuário atual precisa ter um logon autenticado pelo Windows ou ser membro da função de servidor fixa sysadmin. O logon do Windows do usuário que executa CREATE ASSEMBLY deve ter permissão de leitura no compartilhamento e nos arquivos que estão sendo carregados na instrução.

Permissões com a segurança estrita do CLR

As seguintes permissões necessárias para criar um assembly CLR quando o CLR strict security está habilitado:

  • O usuário deve ter a permissão CREATE ASSEMBLY
  • Além disso, uma das seguintes condições também deve ser verdadeira:
    • O assembly é assinado com um certificado ou uma chave assimétrica que tem um logon correspondente à permissão UNSAFE ASSEMBLY no servidor. A assinatura do assembly é recomendada.
    • O banco de dados tem a propriedade TRUSTWORTHY definida como ON e o banco de dados pertence a um logon que tem a permissão UNSAFE ASSEMBLY no servidor. Essa opção não é recomendada.

Para obter mais informações sobre conjuntos de permissões de assembly, consulte Projetando assemblies.

Exemplos

R. Criar um assembly de uma DLL

O exemplo a seguir pressupõe que os exemplos do Mecanismo de Banco de Dados do SQL Server estejam instalados no local padrão do computador local e que o HelloWorld.csproj aplicativo de exemplo seja compilado. Para obter mais informações, confira Exemplo de Olá, Mundo.

CREATE ASSEMBLY HelloWorld
FROM '<system_drive>:\Program Files\Microsoft SQL Server\100\Samples\HelloWorld\CS\HelloWorld\bin\debug\HelloWorld.dll'
WITH PERMISSION_SET = SAFE;

Importante

O Banco de Dados SQL do Azure não dá suporte à criação de um assembly de um arquivo.

B. Criar uma montagem a partir de bits de montagem

Substitua os bits de exemplo (que não estão completos ou válidos) pelos bits de montagem.

CREATE ASSEMBLY HelloWorld
    FROM 0x4D5A900000000000
WITH PERMISSION_SET = SAFE;

Conteúdo relacionado