Les FAI peuvent utiliser ce point de sortie (et les autres points de sortie du système) pour permettre aux utilisateurs de personnaliser, de contrôler et de gérer les stratégies d’accès aux objets base de données, locaux et distants. Ainsi, le programme de sortie pourrait utiliser une table de sécurité contenant
Granulariser la sécurité

une liste des tables de base de données sensibles, d’utilisateurs autorisés et des droits d’accès locaux et distants de ces derniers (figure 1).
Lorsqu’il est invoqué par une requête d’ouverture de base de données pour la table ORDERS, le programme de sortie pourrait déterminer le type d’accès (local ou distant) demandé, consulter la table de sécurité pour savoir si l’utilisateur demandeur possède ce type d’accès à la table, et autoriser ou rejeter la requête d’ouverture de base de données en conséquence.
En utilisant les données de la table de sécurité de la figure 1, le programme de sortie écrit par l’utilisateur effectue les opérations suivantes :
• il empêche l’utilisateur COBBG d’ouvrir la table ORDERS à partir de l’interface d’application 5250 principale, mais l’autorise à accéder à ORDERS via une interface ODBC pour peupler une feuille de calcul à l’appui d’un compterendu
• il permet à l’utilisateur KMILL d’ouvrir ORDERS à partir de l’application 5250 principale, mais l’empêche d’utiliser une interface à distance pour accéder aux données
• il permet à l’utilisateur JAREK d’ouvrir ORDERS à partir des deux interfaces locale et à distance
On peut aussi pousser le contrôle plus loin et ne permettre l’accès à distance que pendant certains jours de la semaine ou heures du jour. Comme vous écrivez le programme point de sortie, vous décidez qui peut accéder aux tables et à quelles conditions. Il est clair que le point de sortie fournit un degré de granularité de la sécurité tout à fait impossible avec la seule sécurité au niveau objet. (L’autorité adoptée par programme fournit aussi une autre fonction i5/OS pour appliquer une sécurité de fine granularité.)
Le point de sortie est également intéressant du point de vue de l’audit : il permet de capturer des informations liées à la sécurité de la base de données, du genre
• quels utilisateurs tentent d’accéder à des tables sensibles
• si l’ouverture a été le résultat d’une requête SQL
• le type d’opération d’ouverture (read, insert, update, delete)
• les programmes/interfaces utilisés lors de la tentative d’ouvrir des tables
Téléchargez cette ressource

É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.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Les risques liés à l’essor fulgurant de l’IA générative
- Pourquoi est-il temps de repenser la gestion des vulnérabilités ?
- Reporting RSE : un levier d’innovation !
- De la 5G à la 6G : la France se positionne pour dominer les réseaux du futur
- Datanexions, acteur clé de la transformation numérique data-centric
