Una stored procedure con EXECUTE AS OWNER è una sostituzione valida per una vista che seleziona dalle tabelle dello schema terzo?

Question

Un utente del database A deve avere accesso solo a dati specifici. Questi dati sono attualmente forniti da una vista B.VIEW1 selezionando dalle tabelle di proprietà dello schema B e C.

CREATE VIEW [B].[VIEW1] AS SELECT * FROM [B].[VIEW2], [C].[VIEW1] 

Dal C.VIEW1 non è di proprietà B, Ownership Chains applicano.

Ciò significa che anche se Un è concesso SELEZIONA autorizzazione per B.VIEW1, non può scegliere.

SELECT permission denied on object 'C.VIEW1', database '...', schema '...'. 

è una stored procedure B.PROC1 con EXECUTE AS OWNER Clause un sostituto valido per B.VIEW1 in termini di sicurezza?

CREATE PROC [B.PROC1] WITH EXECUTE AS OWNER AS BEGIN SELECT * FROM [B.VIEW2], [C].[VIEW1] END 

Oppure ci sono effetti collaterali negativi che potrebbero portare a problemi di sicurezza?

Answer 1

In termini di sicurezza, questo sembra essere un good way per impedire l'accesso alle tabelle sottostanti.

Un effetto collaterale negativo è che non è possibile filtrare il set di risultati generato dalla stored procedure da una clausola WHERE, GROUP BY o simile.

Ma questo non è così tragico se si definiscono vincoli statici in una vista sottostante o si definiscono vincoli "dinamici" tramite stored proc's input parameters.

1) vincoli statici in vista sottostante

CREATE VIEW [B].[VIEW3] AS SELECT * FROM [B].[VIEW2], [C].[VIEW1] WHERE [X]='Something' AND [Y] = GETDATE() 
CREATE PROC [B].[PROC1] WITH EXECUTE AS OWNER AS BEGIN SELECT * FROM [B].[VIEW3] END 

2) vincoli dinamici tramite parametri di ingresso

CREATE PROC [B].[PROC1] (@X varchar(30), @Y DATETIME) WITH EXECUTE AS OWNER AS BEGIN SELECT * FROM [B].[VIEW2], [C].[VIEW1] WHERE [X]=@X AND [Y]=@Y AND