Sécuriser les autres branches

– DTAAUT (*RX) et OBJAUT (*NONE) et je ne recommande pas son changement. Si votre site contrôle qui peut créer des bibliothèques, il est bon de considérer la sécurisation du répertoire /home – livré avec la même autorité publique que root. Si vous voulez contrôler qui peut créer un répertoire home pour lui-même, vous pouvez sécuriser /home en lui appliquant DTAAUT (*RX) et OBJAUT (*NONE) et créer un répertoire home pour chaque utilisateur à qui il en faut un.
Cela donne aux utilisateurs DTAAUT (*RWX) et OBJAUT (*ALL) sur leur répertoire home, ou fait de son utilisateur le propriétaire du répertoire, lui permettant ainsi de manipuler librement les objets créés dans le répertoire home.

Soyez prudents lors de la suppression d’autorités privées données aux profils fournis par IBM. Vous verrez peut-être que QTMHHTTP a une autorité privée sur des répertoires contenant vos pages Web et vos graphiques de site Web. Il (ou le profil sous lequel le serveur HTTP fonctionne) a besoin de cette autorité pour servir les pages Web. QEJBSRV a l’autorité nécessaire pour que WebSphere puisse s’exécuter correctement. QDIRSRV et QTIVOLI ont aussi des autorités privées sur des objets de votre IFS. Si vous êtes tentés de supprimer ces autorités, c’est soit que vous avez l’intention de faire fonctionner incorrectement quelques fonctions, soit que vous êtes prêts à donner à un profil différent la même autorité (par exemple, au lieu de QTMHHTTP, le profil que vous avez spécifié dans votre configuration Web sert votre site Web).

Répertoires de fournisseur tiers. Certains fournisseurs tiers sont conscients qu’ils doivent sécuriser davantage les répertoires et leurs objets. Certains, hélas, n’ont pas ce souci : ils se contentent de créer leurs répertoires et les laissent tirer leurs valeurs d’autorité publique du répertoire racine.
Autrement dit, les répertoires sont du type DTAAUT (*RWX) OBJAUT (*ALL). Pour savoir si vous pouvez réduire le niveau d’autorité publique de tels répertoires, vous devez d’abord déterminer l’objectif de chacun d’eux. Pour une application, les utilisateurs ont besoin de l’accès suivant :

OBJAUT (*NONE) et DTAAUT (*X) sur tous les répertoires dans le chemin conduisant aux objets applicatifs
OBJAUT (*NONE) et DTAAUT (*RX) sur un répertoire dont le contenu a besoin d’être lu ou listé
OBJAUT (*NONE) et DTAAUT (*RWX) sur le répertoire si les utilisateurs y créent des objets
OBJAUT (*NONE) et DTAAUT (*WX) sur le répertoire si les utilisateurs renomment ou suppriment des objets OBJAUT (*OBJMGT) au niveau objet pour les objets qui sont copiés ou renommés
OBJAUT (*OBJEXIST) au niveau objet pour les objets qui sont supprimés

A moins de bien connaître l’application, soyez très prudents quant au niveau de réduction de l’autorité *PUBLIC des sous-répertoires. En général, on peut sans risque réduire leur répertoire de premier niveau à DTAAUT (*RX) OBJAUT (*NONE). Ou, si vous savez que les objets sont créés dans leur répertoire de premier niveau, réduisez- le à DTAAUT (*RWX) OBJAUT (*NONE). Pour sécuriser les sous-répertoires ou leurs objets, vous devez bien comprendre le principe de fonctionnement de l’application afin qu’elle continue à avoir le droit d’accéder aux objets de l’application et les manipuler. Rappelons que l’autorité adoptée est ignorée lorsqu’on accède aux objets dans l’IFS et donc l’utilisateur qui accède à l’objet IFS doit posséder l’autorité suffisante pour effectuer l’opération demandée.

Répertoires d’applications créés par l’utilisateur. Vous devez examiner vos répertoires internes ou créés par l’utilisateur de la même manière que les répertoires tierce partie. Avec l’avantage que, dans ce cas, vous connaissez probablement bien les processus ou les applications qui utilisent les répertoires, ou connaissez les personnes qui les utilisent. Par conséquent, en utilisant l’information dont nous avons parlé pour déterminer les autorités appropriées sur les répertoires et leurs objets, vous pouvez sécuriser le répertoire de premier niveau, les sous-répertoires éventuels, et les objets présents dans chaque répertoire.
Comme avec les bibliothèques, si le répertoire contient des données sensibles ou dont l’accès est restreint (que le répertoire soit créé par l’utilisateur, vendu par un fournisseur, ou fourni par IBM), vous devez mettre l’autorité publique pour le répertoire sur *EXCLUDE. Après quoi, vous pourrez donner l’autorité appropriée aux individus ou aux groupes. Beaucoup d’entreprises ont l’habitude de peupler un répertoire avec un fichier temporaire contenant des informations de banque ou de carte de crédit. Ce genre de données est rarement crypté et est donc facile à lire. C’est pourquoi il est vital (et parfois obligatoire) que cette information ne soit accessible qu’aux utilisateurs concernés.

La figure 5 montre les permissions sur un répertoire utilisé pour transférer des vérifications de carte de crédit à la banque, une fois par jour. L’autorité publique est *EXCLUDE et le groupe comptabilité dispose d’une autorité qui lui permet d’exécuter le processus quotidien qui ajoute un fichier stream au répertoire Ftpbanktransfe.