Sybase ASE, gestion de la sécurité avec les vues inter-bases (cross database)

Introduction

Sybase ASE possède un mécanisme de gestion des autorisations d’accès aux objets en cascade à la fois strict et souple.

• Strict car le propriétaire de chaque objet définit explicitement les permissions qu’il souhaite accorder.
• Souple car la cascade permet de gérer la sécurité d’accès via des vues ou procédures de manière simple, y compris sur des objets situés sur des bases différentes.

Autrement dit, un utilisateur peut se voir attribuer des permissions d’accès à une vue ou une procédure sans pour autant détenir les autorisations sur les objets sous-jacents.

Néanmoins, dans le cadre particulier de liens inter-bases (ou cross database en anglais) , cet 'ownership chain' doit être défini de manière précise.

Cross database : les règles

Le chaînage de droits fonctionne selon les 3 règles suivantes :

1. Les droits sont contrôlés sur l’objet parent.
2. Le user appelant la vue doit être un utilisateur de ou des bases référencées dans la vue.
3. Les droits sont contrôlés à chaque fois qu’un objet sous-jacent a un propriétaire différent de l’objet courant.

Cas pratique

Soit la situation suivante dans laquelle deux bases sont impliquées, chaque base ayant un propriétaire (dbowner) différent. Dans l’une on crée une table, dans l’autre on crée une vue référençant les données de cette table.

Les bases de données base1 et base2 ont pour proriétaire respectif base1_dbo et base2_dbo

Dans la base base2 est créée une table, table qu’un utilisateur de la base base1 (user: base1_usr) va interroger.

create table t2 (a int) 
go
insert t2 values (1) 
insert t2 values (2) 
insert t2 values (3) 
go

create view v1 
as 
select a 
from base2.dbo.t2
where a >= 2
go

select a 
from v1
go
SELECT permission denied
on object v1, 
database base1, 
owner dbo.

grant select on v1 
to base1_usr

select a 
from v1
go
Server user id 14 
is not a valid user 
in database 'base2'

exec sp_adduser base1_usr

select a 
from v1
go
SELECT permission denied 
on object t2, 
database base2, 
owner dbo

grant select 
on t2
to base1_usr

select a 
from v1
go

a
--
2
3

La situation est certes réglée d’un point de vue fonctionnel, mais une faille de sécurité est désormais ouverte : l’utilisateur base1_usr dispose d’un accès direct sur la table t2 de la base2. Cette situation n’est pas souhaitable pour le contrôle d’accès à la donnée.

Les données doivent certes être accessibles, mais sous contrôle des définitions et règles de gestion mises en place à travers la vue ou la procédure.

select a from t2
go

a
--
1
2
3

À noter que si les deux bases ont le même propriétaire (dbowner), naturellement la règle 3 ne s’applique pas et la gestion du cross database n’est en rien différente d’une gestion de droits en cascade classique.

La règle 3 indique que le contrôle de sécurité est réalisé à chaque changement de propriétaire d’objet. Il faut donc faire en sorte d’éviter ce contrôle en autorisant l’un des dbo à créer un objet dans la base partenaire.

revoke select 
on t2 to base1_usr

exec sp_adduser base2_dbo
go

grant create view 
to base2_dbo
go

create view v2
as
select a 
from base2.dbo.t2
where a >=2
go

grant select 
on v2 
to base1_usr
go

select a
from base2_dbo.v2
go

a
--
2
3

select a 
from t2
go
SELECT permission denied on
object t2, 
database base2, 
owner dbo

create view v3
as
select a
from base2_dbo.v2
go

select a
from v3
go

a
--
2
3

Remarques

Elément notable, si c’est le compte 'sa' qui compile le vue v3, alors les droits chaînés sont accordés de manière implicite :

create view v3 as select * from base2_dbo.t2
go

grant select on v4 to base1_usr
go

Dans ce contexte, base1_usr devra certes être créé en tant que user dans la base2, mais il n’est pas nécessaire d’autoriser le dbo partenaire à créer des objets locaux.

La table système sysobjects indique dans quel contexte a été compilée une vue :

select isnull(loginame,'dbo') + '.' + name from sysobjects where type ='V';
-------------
dbo.v1
base2_dbo.v2
dbo.v3
sa.v4