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
SIEM & PME : Comment construire la boîte noire de votre SI ?
Passez à la cybersécurité proactive, transformez la collecte et l’analyse des logs en un bouclier dynamique contre les cybermenaces. Découvrez comment mettre en place une approche SIEM modulaire, évolutive et accessible, pour anticiper, détecter et réagir efficacement aux attaques.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Veeam passe à la vitesse supérieure avec iResOps pour Microsoft 365
- Visibilité, réputation, clients : ce que les petites entreprises ne pourront plus déléguer en 2027
- IA souveraine : l’Europe avance, mais son interconnexion prend du retard
- Cloud public : la sécurité des données s’impose comme premier critère pour les agents publics
Articles les + lus
Continuer avec Exchange Server : quelles conséquences ?
Raccourcis Réseau et Navigateur : le kit de Diagnostic des Professionnels IT
Raccourcis PowerShell et Windows Terminal pour les Professionnels IT
Commandes Windows 11 : le Guide des Outils accessibles avec Win + R
Sécurité : une approche dans la durée avant tout
À la une de la chaîne Tech
- Continuer avec Exchange Server : quelles conséquences ?
- Raccourcis Réseau et Navigateur : le kit de Diagnostic des Professionnels IT
- Raccourcis PowerShell et Windows Terminal pour les Professionnels IT
- Commandes Windows 11 : le Guide des Outils accessibles avec Win + R
- Sécurité : une approche dans la durée avant tout
