> Tech > Contrôle au niveau schéma

Contrôle au niveau schéma

Tech - Par Renaud ROSSET - Publié le 21 février 2011
email


Vous pensez peut-être pouvoir simplifier la gestion des contrôles d’accès au niveau objet en définissant simplement des autorités au niveau schéma (bibliothèque). Un schéma est un conteneur de tous les objets DB2, et donc le fait de contrôler l’accès à l’objet contenant semble un moyen logique de

Contrôle au niveau schéma

contrôler l’accès aux objets qu’il contient. Hélas, il n’en est pas ainsi parce que les contrôles au niveau schéma manquent de granularité. Un profil utilisateur a besoin d’un minimum d’autorité *USE pour accéder à n’importe lequel des objets DB2 dans un schéma. Les autorités de données définies au niveau table ou objet sont ensuite utilisées pour déterminer si un utilisateur peut accéder aux données de gestion stockées dans un objet DB2. Il n’y a donc pas de raccourci de gestion de sécurité au niveau schéma : les profils utilisateur doivent bénéficier d’autorités aux deux niveaux : schéma et objet.

Un schéma SQL et une bibliothèque IBM i sont des objets équivalents. Cependant, l’autorité publique par défaut donnée aux objets respectifs est différente. Avec la commande Create Library (CRTLIB), le paramètre CRTAUT contrôle l’autorité publique par défaut. Ce paramètre par défaut est *SYSVAL, qui signifie que la valeur système QCRTAUT détermine la stratégie pour l’accès public. La valeur système par défaut est *CHANGE, ce qui explique notre affirmation précédente à propos des sites IBM i donnant à tous les utilisateurs sur leur système, l’accès *CHANGE à leurs bases de données. Pour remédier à ce problème, IBM recommande de changer QCRTAUT en *EXCLUDE ou en *USE dans la plupart des cas, pour limiter l’accès public à vos objets bases de données. Pour tenir compte du changement apporté à la valeur système QCRTAUT, il vous faudra probablement procéder à quelques changements de l’environnement et des programmes.

L’instruction SQL Create Schema crée une bibliothèque avec une autorité publique différente quand le nommage SQL (*SQL) est utilisé. Le paramètre du format de nommage est disponible sur toutes les interfaces SQL qui valident le nommage SQL ou System (*SYS). Si vous utilisez le nommage System, le comportement de l’autorité publique obéit à la sémantique CRTLIB. Quand le nommage SQL est en vigueur, une bibliothèque (et tous les objets SQL) est créée avec une autorité publique *EXCLUDE. Par conséquent, le nommage SQL vous oblige à accorder explicitement l’accès public à l’objet ou à définir des autorités privées. Là encore, ce comportement suit les orientations générales d’IBM visant à exclure tout accès public au schéma par défaut.

Téléchargez cette ressource

État des lieux de la sécurité cloud-native

État des lieux de la sécurité cloud-native

L’État des lieux de la sécurité cloud-native vous offre une analyse complète des problématiques, des tendances et des priorités qui sous-tendent les pratiques de sécurité cloud-native dans le monde entier. Une lecture indispensable pour renforcer votre stratégie de sécurité dans le cloud. Une mine d’infos exclusives pour élaborer votre stratégie de sécurité cloud-native.

Tech - Par Renaud ROSSET - Publié le 21 février 2011