Inserção de dados protegidos do LBAC

Ao tentar inserir dados em uma coluna protegida, ou para inserir uma nova linha em uma tabela com linhas protegidas, suas credenciais do LBAC determinam como essa instrução INSERT é manipulada.

Inserindo para Colunas protegidas

Quando você tenta inserir dados em uma coluna protegida suas credenciais LBAC para escrita são comparadas com o rótulo de segurança protegendo essa coluna. Com base neste acesso de comparação, será bloqueado ou permitido.

Os detalhes de como duas etiquetas de segurança são comparadas são dadas no tópico sobre como os rótulos de segurança LBAC são comparados.

Se o acesso for permitido, a instrução procede como de costume. Se o acesso for bloqueado, então a inserção falha e um erro é retornado.

Se você estiver inserindo uma linha mas não forneça um valor para uma coluna protegida então um valor padrão é inserido se um estiver disponível. Isso acontece mesmo que suas credenciais do LBAC não permitam o acesso de gravação a essa coluna. Um padrão está disponível nos seguintes casos:

A coluna foi declarada com a opção COM DEFAULT
A coluna é uma coluna gerada
A coluna tem um valor padrão que é dado por meio de um disparo ANTES
A coluna tem um tipo de dado de DB2SECURITYLABEL, no qual etiqueta de segurança de caso que você segura para acesso de gravação é o valor padrão

Inserindo para linhas protegidas

Ao inserir uma nova linha em uma tabela com linhas protegidas, você não tem que fornecer um valor para a coluna que é do tipo DB2SECURITYLABEL. Se você não fornecer um valor para essa coluna, a coluna é preenchida automaticamente com o rótulo de segurança que você foi concedido para acesso de gravação. Caso não tenha sido concedido um rótulo de segurança para acesso de gravação, um erro é retornado e a inserção falha.

Ao usar funções integradas como SECLABEL, você pode fornecer explicitamente um rótulo de segurança para ser inserido em uma coluna do tipo DB2SECURITYLABEL. O rótulo de segurança fornecido só é usado, no entanto, se suas credenciais do LBAC permitiriam gravar em dados protegidos com a etiqueta de segurança que você está tentando inserir.

Se você fornecer um rótulo de segurança que você não seria capaz de escrever, então o que acontece depende da política de segurança que está protegendo a tabela. Se a política de segurança tiver a opção RESTRINGIR NOT AUTHORIZED WRITE SECURITY LABEL, então a inserção falha e um erro será retornado. Se a política de segurança não tiver a opção RESTRINGIR NOT AUTHORIZED WRITE SECURITY LABEL ou se ele em vez disso tiver a opção SUBSTITUIÇÃO NÃO AUTORIZADO GRAVAÇÃO SECURITY LABEL, então a etiqueta de segurança que você fornece é ignorada e se você segura um rótulo de segurança para acesso a gravação, ele é usado em vez disso. Se você não segurar uma etiqueta de segurança para acesso a gravação, um erro será retornado.

Exemplos

A tabela T1 é protegida por uma política de segurança denominada P1 que foi criada sem a opção RESTRINGIR NÃO AUTORIZADO GRAVAÇÃO SECURITY LABEL. Tabela T1 tem duas colunas mas sem linhas. As colunas são LASTNAME e LABEL. A coluna LABEL tem um tipo de dado de DB2SECURITYLABEL.

O usuário Joe guarda um rótulo de segurança L2 para acesso a gravação. Suponha que o rótulo de segurança L2 permita que ele escreva a dados protegidos por rótulo de segurança L2 mas não a dados protegidos por etiquetas de segurança L1 ou L3.

Joe emite a seguinte instrução SQL:

INSERT INTO T1 (LASTNAME, DEPTNO) VALUES ('Rjaibi', 11)

Como nenhum rótulo de segurança foi incluído na instrução INSERT, o rótulo de segurança de Joe para acesso a gravação é inserido na linha LABEL.

A tabela T1 agora fica assim:

Tabela 1. Valores na tabela de exemplo T1 após a primeira instrução INSERT
SOBRENOME	RÓTULO
Rjaibi	L2

Joe emite a seguinte instrução SQL, na qual ele fornece explicitamente o rótulo de segurança a ser inserido na coluna LABEL:

INSERT INTO T1 VALUES ('Miller', SECLABEL_BY_NAME('P1', 'L1') )

A função SECLABEL_BY_NAME no enunciado retorna um rótulo de segurança que faz parte da política de segurança P1 e é denominado L1. Joe não é permitido gravar em dados que estejam protegidos com L1 para que ele não seja permitido inserir L1 na coluna LABEL.

Como a política de segurança que protege o T1 foi criada sem a opção RESTRINGIR NOT AUTHORIZED WRITE SECURITY LABEL a etiqueta de segurança que Joe detém por escrito é inserida em vez disso. Nenhum erro ou mensagem é retornado.

A mesa agora se parece com isso:

Tabela 2. Valores na tabela de exemplo T1 após a segunda instrução INSERT
SOBRENOME	RÓTULO
Rjaibi	L2
Miller	L2

Se a política de segurança protegendo a tabela tivesse sido criada com a opção RESTRINGIR NÃO AUTORIZADO GRAVAÇÃO SECURITY LABEL então a inserção teria falhado e um erro teria sido retornado.

Próximo Joe é concedida uma isenção a uma das regras do LBAC. Suponha que suas novas credenciais LBAC permitem que ele escreva para dados protegidos com etiquetas de segurança L1 e L2. O rótulo de segurança concedido a Joe para acesso de gravação não muda, ele ainda é L2.

Joe emite a seguinte instrução SQL:

INSERT INTO T1 VALUES ('Bird', SECLABEL_BY_NAME('P1', 'L1') )

Por causa de suas novas credenciais LBAC Joe é capaz de escrever para dados que são protegidos pelo rótulo de segurança L1. A inserção de L1 é, portanto, permitida. A mesa agora se parece com isso:

Tabela 3. Valores na tabela de exemplo T1 após a terceira instrução INSERT
SOBRENOME	RÓTULO
Rjaibi	L2
Miller	L2
Ave	L1