Întrebări și Răspunsuri RLS

- RLS_ALL utilizator
- Adăugarea utilizatorilor
- Ștergerea utilizatorilor
- Sfaturi și Trucuri
|
1. Utilizator RLS_ALL
RLS_ALL este un utilizator special al bazei de date fără nicio mapare de autentificare pe server. Asta înseamnă că nu te poți conecta la SQL Server cu el.
Singura modalitate de a-l folosi este cu EXECUTE AS USER = 'RLS_ALL'
Are acces la toate datele care sunt separate prin funcționalitatea RLS.
Acest utilizator este folosit, de exemplu, pentru a crea agregate pe date deținute de mai mulți utilizatori.
De exemplu, un raport pentru vânzările totale pentru toți angajații pentru un an, dar fiecare angajat poate vedea doar vânzările proprii.
Pentru ca un utilizator Pantheon să poată folosi EXECUTE AS USER = 'RLS_ALL', trebuie să aibă permisiuni GRANT IMPERSONATE pe utilizatorul RLS_ALL.
NUMAI utilizatorii din Pantheon ar trebui să aibă permisiuni GRANT IMPERSONATE.
Acordarea acestor permisiuni conturilor încorporate SQL Server (cum ar fi SA, etc) nu este de obicei necesară.
- NUMAI utilizatorii Pantheon pot citi date din tabelele protejate RLS
Utilizatorul SA (dacă nu este mapat la utilizatorul PA) nu are acces la datele protejate.
Orice date protejate RLS pot fi citite doar de utilizatorul PA cu autorizațiile corespunzătoare.
Pentru a folosi conexiuni externe la baza de date, conexiunea la baza de date trebuie să fie realizată cu utilizatorul PANTHEON legat de utilizatorul bazei de date.
2. Adăugarea utilizatorilor
Adăugarea utilizatorilor pentru a accesa alte aplicații la baza de date PANTHEON.
Putem adăuga un utilizator cu PANTHEON:
Vezi instrucțiunile următoare: Adăugarea unui utilizator și Stabilirea autorizațiilor pentru un utilizator.
Pentru setări mai complexe, unde dorim să adăugăm un utilizator la mai multe baze de date.
Adăugarea utilizatorului și încărcarea autorizațiilor fără drepturi. Stabilim permisiunile utilizatorului cu PANTHEON:
declare
@v_cUserId sysname =
#UserName#
, @p_lang_id varchar(2)
--
, @p_subject varchar(30) = NULL
--
, @p_user_id int = NULL
, @p_contact_id int = NULL
BEGIN
select * from [dbo].[tHE_SetSubjContact] WHERE acUserId = @v_cUserId;
SET @p_user_id = (SELECT anUserId FROM [dbo].[tHE_SetSubjContact] WHERE acUserId = @v_cUserId);
set @p_contact_id = NULL;
IF (@p_user_id IS NULL)
BEGIN
Exec ppa_user_create @v_cUserId, @v_cUserId, 1;
select @p_subject = P.acOurCompany, @p_lang_id = PS.acLocalization from tPA_SysParam P, tPA_SysParamSys PS;
SELECT @p_user_id = anUserId FROM [dbo].[tHE_SetSubjContact] WHERE acUserId = @v_cUserId;
EXEC [dbo].[ppa_user_save]
@p_user_id = @p_user_id OUTPUT -- @p_user_id int OUTPUT
, @p_contact_id = @p_contact_id OUTPUT -- @p_contact_id int OUTPUT
, @p_user_name = @v_cUserId -- sysname
, @p_lang_id = @p_lang_id -- varchar(2)
, @p_active = 'T' -- char(1)
, @p_license_server = Null -- sysname = NULL
, @p_license_database = Null -- sysname = NULL
, @p_profile = Null -- varchar(10) = NULL
, @p_additpersonmark = Null -- varchar(100) = NULL
, @p_code = Null -- varchar(20)= NULL
, @p_pin = Null -- varchar(11) = NULL
, @p_foreigner = 'F'
--
, @p_subject = @p_subject -- varchar(30) = NULL
, @p_name = @v_cUserId -- varchar(30) = NULL
, @p_surName = @v_cUserId -- varchar(30) = NULL
;
exec [dbo].[ppa_security_insert] @p_user_id, False, False;--fără autorizații
exec ppa_security_save @p_user_id, False, False;
print @p_user_id
exec [dbo].[ppa_authorization_security_save]
NULL -- @p_authorization varchar(50)
, @p_user_id -- @p_principal_id int
, 0 -- @p_principal_type bit
, NULL -- @p_parent_id varchar(50)
, 0 -- @p_acquired bit
, 0 -- @p_inherited bit
, 0 -- @p_permission_select bit
, 0 -- @p_permission_update bit
, 0 -- @p_permission_delete bit
, 32767 -- @p_permission_update_period int
, 1 -- @p_propagate_entities bit = 0
, Null -- @p_licence char(2) = 'MF'
exec pPA_SysSQLLoginPswdChange @v_cUserId, Null, @v_cUserId;
EXEC sp_addrolemember N'db_owner', @v_cUserId;
EXEC sp_addrolemember N'db_datawriter', @v_cUserId;
EXEC sp_addrolemember N'db_datareader', @v_cUserId;
end;
select * from [dbo].[tHE_SetSubjContact] WHERE acUserId = @v_cUserId;
select * from tPA_SetDoctypeUserSecurity where anUserId = @p_user_id;
end;
3. Ștergerea utilizatorilor
declare
@v_cUserId sysname = #USER#,
@command nvarchar(max);
begin
select * from [dbo].[tHE_SetSubjContact] WHERE acUserId = @v_cUserId;
delete from [dbo].[tHE_SetSubjContact] WHERE acUserId = @v_cUserId;
IF (DATABASE_PRINCIPAL_ID(@v_cUserId) IS NOT NULL)
BEGIN
SET @command = N'DROP USER ' + QUOTENAME(@v_cUserId) + N';'
EXEC(@command);
END;
IF (SUSER_ID(@v_cUserId) IS NOT NULL)
BEGIN
SET @command = N'DROP LOGIN ' + QUOTENAME(@v_cUserId) + N';'
EXEC(@command);
END;
select * from [dbo].[tHE_SetSubjContact] WHERE acUserId = @v_cUserId;
end;
4. Sfaturi și Trucuri
Cu securitatea la nivel de rând (RLS) a SQL Server, aceasta adaugă o separare ușoară a datelor utilizatorului, dar adaugă un pic de complexitate a planului de execuție a interogărilor pentru fiecare interogare care folosește tabelele pe care RLS este activat.
Scopul este de a minimiza acea complexitate a planului de execuție a interogărilor.
- Utilizare în proceduri stocate
Evită multe join-uri cu tabele RLS. Dacă trebuie să alături multe tabele, este mai bine să alături câteva (2-4 tabele), să pui rezultatul într-o tabelă temporară (care poate fi chiar indexată corespunzător) și să alături acea tabelă temporară la alte tabele.
Asta va face munca optimizatorului de interogări mai ușoară, deoarece interogarea este împărțită în mai multe piese.
- Utilizare în trigger-e
În trigger-ele de tip after nu este nevoie să te alături la tabela de bază pentru a obține datele.
Pentru instrucțiunea de actualizare sau inserare, tabela pseudo-inserată conține deja valori noi care sunt de asemenea în tabela de bază.
Așadar, tot ce trebuie să faci este să te alături la ea.
Dacă ai un scenariu în care trebuie să verifici existența unor date într-un trigger și să actualizezi datele pe baza acelei verificări, este mai bine să pui rezultatele verificării într-o tabelă temporară, să verifici dacă acele date satisfac condiția dorită și să le folosești pentru a actualiza tabela de bază.
- Suportul funcțiilor încorporate ale SQL Server pentru paralelism
Dacă trebuie vreodată să verifici un nume de utilizator sau un login SQL sub care contextul curent se execută, folosește următoarele funcții în instrucțiunile select.
Acestea sunt singurele care suportă paralelism în planurile de execuție SQL Server:
USER_NAME, CURRENT_USER, SUSER_NAME, SUSER_SNAME, SUSER_ID, SUSER_SID.
Orice altă funcție încorporată împiedică luarea în considerare a planurilor de execuție a interogărilor paralele.