Quel modèle de sécurité global utilise l’application ?

sécurité appliqué pendant l’exécution
d’une application en dit beaucoup sur le modèle de sécurité de cette dernière.
Nous avons déjà  parlé des niveaux 40 et 50, mais que ce passe-t-il si l’application
s’exécute à  un niveau inférieur ?
Une application qui fonctionne au niveau de sécurité 30 ou inférieur risque d’essayer
d’utiliser des interfaces dont l’usage est réservé au système d’exploitation.
Avec le niveau de sécurité 20, l’application s’appuie probablement sur un contrôle
d’accès par menu. Les applications de ce genre sont discutables pour tout type
de système en réseau. Le contrôle d’accès par menu n’est utile qu’avec des menus
d’écrans passifs (green-screen). Cette méthode n’est plus très répandue. Les applications
et systèmes pratiquant le contrôle d’accès par menu sur un système en réseau sont
extrêmement vulnérables à  un accès non autorisé et à  une manipulation des ressources
système et applicatives.
Il se peut qu’une application fonctionne au niveau de sécurité 50 tout en pratiquant
le contrôle d’accès par menu. Si tous les utilisateurs ont besoin des droits spéciaux
*ALLOBJ, le contrôle d’accès par menu est probablement le modèle de sécurité retenu.
Si tous les utilisateurs ont besoin d’autres droits spéciaux, c’est probablement
que l’application est mal sécurisée.

Modèle de type propriété de groupe. Certaines applications imposent
que les utilisateurs soient membres d’un groupe possédant la totalité des programmes
et données des applications. Quand les membres du groupe accèdent au système par
l’intermédiaire d’interfaces autres que l’application, ils possèdent en fait toutes
les ressources applicatives. Ils peuvent donc utiliser des interfaces non applicatives
pour accéder à  des données par des méthodes non souhaitées ou prévues par l’application.
Non seulement cela fragilise la sécurité et la confidentialité, mais crée aussi
des problèmes de refus de service, de fiabilité et de disponibilité. Ce n’est
donc pas un bon modèle de sécurité.

Modèle de type droits de groupe. Les droits de groupe sont un
modèle de sécurité acceptable, surtout si on l’associe à  d’autres mécanismes.
Ce modèle est préférable au précédent parce qu’on peut limiter l’autorisation
à  certaines actions, tandis que le modèle de propriété permet aux utilisateurs
de manipuler à  leur guise un objet et son contenu.
Toutefois, le modèle de type droits de groupe, quand on l’applique aux données
applicatives, n’empêche pas les membres du groupe d’accéder aux données par des
mécanismes étrangers à  l’application. Supposons, par exemple, que l’on donne au
groupe ACCT *CHANGE les droits sur la base de données de paie. Les membres du
groupe ACCT peuvent mettre à  jour la base de données de paie via des programmes
applicatifs et des API et des commandes d’accès à  la base de données fournies
par le système. C’est pourquoi il faut étudier comment une application utilise
un modèle de droits de groupe, avant de l’acheter.

Modèle de type droits adoptés. Les droits adoptés permettent
à  un programme de s’exécuter avec les droits de son propriétaire et de son utilisateur.
Les droits adoptés sont souvent un modèle de sécurité utile ; cependant, avant
d’accepter un nouveau programme qui adopte des droits sur votre système, il faut
savoir quel profil utilisateur il adopte.
Il faut rechercher une application qui adopte un profil utilisateur défini par
l’application. Emettez des réserves si une application adopte un profil fourni
par le système d’exploitation comme QSECOFR. Un bon modèle de sécurité fournit
deux profils : un profil utilisateur pour accéder aux données et à  l’application
et un profil groupe nécessaire pour accéder à  l’application. Dans ce modèle, les
membres du groupe peuvent accéder à  une application mais pas aux données, sauf
via l’application qui adopte son propriétaire. Ce modèle est intéressant parce
qu’il assure une bonne sécurité avec un minimum de travail administratif.

Certaines applications mettent tous les objets d’application à  PUBLIC
*ALL, renonçant ainsi à  tout modèle de sécurité

Les valeurs *ALL, *ALWPGMADP et *ALWPTF pour les valeurs système QALWOBJRST permettent
la restauration de programmes qui adoptent les droits de leur propriétaire. Si
l’application n’utilise pas le modèle de sécurité des droits adoptés, il faut
absolument mettre la valeur à  *NONE avant d’installer ou de restaurer l’application.

Modèle des droits privés. Un modèle de sécurité fondé sur les
droits privés s’appuie sur des droits explicites octroyés aux utilisateurs sur
l’application et les données. C’est le moyen le plus souple de gérer la sécurité,
mais le travail administratif qu’il suppose peut le rendre coûteux et sujet à 
erreurs.

Modèle des droits publics. Certaines applications mettent tous
les objets d’application à  PUBLIC *ALL, renonçant ainsi à  tout modèle de sécurité.
Un peu comme une banque dont le coffre-fort serait grand ouvert dans le hall.
Si la sécurité vous importe, évitez toute application de ce genre.