Sûr et signé

de l’absence de vérification de toute signature jusqu’à  la vérification de toutes les signatures, et empêchent la restauration de tout exécutable non signé. Un paramétrage plus strict de QVFYOBJRST est particulièrement utile pour vérifier que les applications reçues de tierces parties ne contiennent pas d’exécutables escrocs. Le paramétrage le plus strict aide à  empêcher la restauration des exécutables escrocs sur votre système.

  Les valeurs possibles de QVFYOBJRST vont de 1 à  5 – il est livré avec la valeur par défaut de 3, qui ordonne à  l’OS/400 de « Verify signatures on restore. Restore unsigned user-state-objects. Restore signed user-state objects only if the signatures are valid » (Vérifier les signatures à  la restauration. Restaurer les objets d’état utilisateur non signés. Restaurer les objets d’état utilisateur signés uniquement si les signatures sont valides). Tandis qu’une valeur de 1 ordonne à  l’OS/400 de « Do not verify signatures on restore. Restore all objects regardless of their signatures » (Ne pas vérifier les signatures à  la restauration. Restaurer tous les objets indépendamment de leur signature). Quant à  la valeur 5, elle ordonne à  l’OS/400 de « Verify signatures on restore. Do not restore unsigned user-state objects. Restore signed user-state objects only if the signatures are valid » (Vérifier les signatures à  la restauration. Ne pas restaurer les objets d’état utilisateur non signés. Ne restaurer les objets d’état utilisateur signés que si les signatures sont valides).

  QVFYOBJRST se comporte comme un filtre de premier niveau. Si un objet franchit ce filtre, il doit encore passer par le filtre de la valeur système QALWOBJRST puis par celui de la valeur système QFRCCVNRST. Je reviendrai sur QFRCCVNRST dans un moment.

  Je recommande de régler QVFYOBJRST de la façon la plus stricte possible et de ne le modifier que quand un fournisseur de confiance vous dit qu’il faut le régler différemment – et qu’il explique pourquoi. Quand l’application en question est restaurée, rétablir le paramétrage le plus strict de QVFYOBJRST. Vous entendrez probablement des raisons de fournisseurs comme « Nous compilons notre code sous une release antérieure et, par conséquent, notre code ne se prête pas à  la signature » ou « Nous avons dû changer le système d’exploitation parce que la performance n’était pas bonne ». Creusez suffisamment la question pour vous sentir convaincu par l’explication donnée. Sinon, chaque fois que QVFYOBJRST doit être en-dessous du paramétrage le plus strict, il faut être très attentif. Utilisez également la commande CHKOBJITG (Check Object Integrity) et son paramètre « Check Signature » introduit dans la V5R1 périodiquement pour déterminer si un employé ou un fournisseur indélicat a de quelque façon altéré, remplacé, créé ou (volontairement ou non) restauré un exécutable escroc sur votre système. La V5R1 comporte également une API de vérification de signature numérique et une nouvelle interface de vérification de signature numérique dans DCM.