> Tech > Deux, deux et deux

Deux, deux et deux

Tech - Par iTPro - Publié le 24 juin 2010
email

En prenant deux par deux les composantes validées pour les virus, considérons d’abord les nouveaux attributs de fichier et de répertoire. Pour empêcher tout scanning redondant, le nouvel attribut de fichier, *SCAN, indique si un fichier doit être scanné et quand. L’attribut *SCAN est accompagné d’une information d’état de scan.

L’attribut apparaît dans la feuille de propriétés iSeries Navigator d’un fichier. La figure 1 montre l’attribut scan et l’état pour un fichier nommé oper dans un répertoire nommé opt. L’attribut *SCAN a trois valeurs possibles : *NO, *YES et *CHANGEONLY. *NO signifie que le fichier n’est jamais scanné, *YES signifie qu’il est scanné à chaque ouverture et fermeture, et *CHANGEONLY signifie qu’il n’est scanné que s’il a été modifié depuis le dernier scan.

Chaque fichier présente aussi une information d’état qui indique quel ensemble de définitions de virus a été utilisé pour le dernier scanning du fichier, qu’il ait été en mode binaire ou texte seulement, et quel CCSID (Coded Character Set Identifier) a servi pendant le scan. Le scanner de virus utilise un code de signature scan pour enregistrer chaque ensemble de définitions de virus avec i5/OS. Le fichier que l’on voit figure 1 n’a jamais été scanné, donc l’information sur l’état du scan est affichée de manière atténuée (c’est-à-dire indisponible).

Un nouvel attribut de répertoire, *CRTOBJSCAN, spécifie la valeur initiale de l’attribut *SCAN d’un fichier stream au moment de la création du fichier. La figure 2 illustre cet attribut pour l’exemple de répertoire opt. Si vous avez un répertoire dont les fichiers n’ont jamais besoin de scanning, mettez *CRTOBJSCAN à *NO. Sinon, choisissez une valeur qui exprime la volatilité des fichiers. Généralement *CHANGEONLY convient. Cependant, si un répertoire contient des fichiers fréquemment restaurés à partir d’une sauvegarde, spécifiez *YES afin que les fichiers soient scannés lors de la restauration.

Voyons ensuite les deux nouvelles valeurs système qui s’appliquent au scanning de virus : QSCANFS et QSCANFSCTL. La première est simplement le commutateur on/off pour le scanning de virus. Elle peut avoir la valeur *OFF pour désactiver complètement tout le scanning de virus ou *ROOTOPNUD pour valider le scanning pour les répertoires racine, QOpenSys, et UDFS. IBM semble prévoir le futur en demandant la valeur *ROOTPNUD plutôt que simplement *ON. Je suppose que certains nouveaux types de systèmes de fichiers figureront dans les futures releases i5/OS. Dès lors que le scanning est activé, la seconde valeur système, QSCANFSCTL, prend du sens (figure 3). Ses paramètres possibles sont *NONE, *FSVRONLY, *ERRFAIL, *NOWRTUPG, *USEOCOATR, *NOFAILCLO et *NOPOSTRST. La valeur système peut contenir l’une ou la totalité de ces valeurs (utiliser l’espace comme délimiteur en CL, ou cocher plusieurs cases dans iSeries Navigator). Les paramètres contrôlent une combinaison d’options runtime du scanner i5/OS, qui déterminent l’action du scan. Avant de parler de ces paramètres, voyons les options qu’ils contrôlent.

La première option est appelée write access upgrade. Quand un programme utilisateur ouvre un fichier pour l’accès en lecture seule, si le scanner de virus est invoqué et trouve une infection, il a besoin de droits d’accès en écriture pour pouvoir réparer le fichier. Quand elle est validée, cette option accorde automatiquement au scanner de virus, l’accès en écriture temporaire aux fichiers en lecture seule. La deuxième option précise les accès qui ont besoin du scanning : soit uniquement les requêtes de réseau externes, soit à la fois les requêtes externes et les requêtes d’applications natives. Comme la principale menace de virus vient des machines Windows rattachées au réseau, on peut jouer la carte de l’efficacité en supposant que les programmes natifs iSeries sont dans votre camp et pas susceptibles d’infecter l’IFS. Cependant, si vous êtes de tempérament anxieux, n’hésitez pas à scanner les accès distants et natifs.

La troisième option concerne l’action à mener dans le cas où un programme de sortie échoue. Cette option s’applique strictement au comportement pathologique de la part du programme de sortie, elle ne concerne pas le cas où un programme de sortie trouve une infection. Deux possibilités vous sont offertes : causer l’échec de l’opération de niveau supérieur, ou faire simplement comme si le programme de sortie n’avait jamais été appelé. Bien entendu, le choix le plus sage est de faire échouer la requête ou l’opération qui a déclenché le programme de sortie.

La quatrième et dernière option détermine quand il faut scanner les objets restaurés : soit immédiatement lors de la restauration, soit ultérieurement quand un utilisateur ouvrira le fichier, selon l’attribut de scanning de celui-ci. La prudence conseille de toujours scanner chaque fichier restauré, au risque de retarder considérablement la restauration à partir d’une sauvegarde. De plus, ce peut être une mesure redondante et superflue si un fichier restauré est toujours scanné à l’ouverture.

Maintenant que nous connaissons ces options, voyons la signification de chaque valeur *QSCANFSCTL. *NONE. Valeur par défaut qui indique que les aspects de scanning suivants seront choisis lors de l’invocation d’un programme de sortie : (1) employer les mises à niveau de l’accès en écriture, (2) faire échouer la requête de niveau supérieur si le scan échoue, (3) ne pas scanner automatiquement les objets restaurés.

*FSVRONLY. Seuls les accès aux systèmes de fichiers distants doivent être scannés. Les programmes i5/OS natifs ne déclencheront pas un scan, quels que soient les paramètres de l’attribut file scan.

*ERRFAIL. Faire échouer la requête de niveau supérieur si le programme de sortie échoue. Cela peut se produire si le programme de sortie n’existe pas, si une erreur d’interface survient, ou si le programme de sortie est incapable de scanner le fichier à cause d’une erreur de coding ou de tout autre obstacle. L’appelant de niveau supérieur est informé qu’un scan de virus n’a pas pu aller à son terme, mais le programme se voit interdire de poursuivre avec d’autres accès au fichier. Si *ERRFAIL n’est pas spécifié, la requête de niveau supérieur se déroule normalement, comme si aucun scan de virus n’avait été demandé.

*NOWRTUPG. Interdire les mises à niveau d’accès en écriture, ce qui empêche le scanner de virus de réparer les fichiers en lecture seule. Si cette valeur est activée, le scanner de virus empêche l’application de niveau supérieur d’accéder au fichier.

*USEOCOATR. Difficile à prononcer, cette valeur signifie « utiliser-l’attribut- uniquement-quand-les-objets-ont-changé pour contrôler le scan. Si vous ne spécifiez pas cette option, la valeur *SCAN de *CHANGEONLY d’un fichier est ignorée.

*NOFAILCLO. Empêche l’échec des requêtes de fermeture quand le programme de sortie échoue. Le programme de niveau supérieur reprend le contrôle, sans indication de la défaillance. Cependant, le fichier n’est pas fermé et aucune des modifications qui lui ont été apportées n’est retenue. En outre, l’état de scan du fichier est défini de manière à indiquer que le scan a échoué.

*NOPOSTRST. Ne pas scanner des fichiers aussitôt après la restauration. Généralement, les fichiers sont scannés automatiquement lors de la restauration et ils pourraient alors être scannés à nouveau de manière redondante quand on les ouvre. L’activation de cette valeur élimine les scans redondants mais donne la possibilité de restaurer des fichiers infectés qui resteraient dans le système de fichiers jusqu’à ce qu’un scan à la demande ultérieure y accède et le répare. N’hésitez pas à choisir cette valeur si vous êtes certains que tous les objets sont scannés avant la sauvegarde.

La troisième paire de composantes de validation de virus est constituée par les programmes de sortie eux-mêmes, nommés QIBM_QP0L_ SCAN_OPEN et QIBM_QP0L_SCAN_ CLOSE. Les programmes de sortie reçoivent en entrée un descripteur de fichier pointant sur le fichier à scanner, et ils renvoient en sortie un code d’état indiquant si le scan a détecté un virus et, dans l’affirmative, si le fichier a été bien réparé. Les programmes de sortie eux-mêmes reçoivent beaucoup d’autres informations indirectement par l’intermédiaire des attributs du fichier et des valeurs système et ils doivent tenir compte de toutes ces informations dans leurs processus de décision. IBM fournit une documentation complète pour les interfaces de programmes de sortie à publib.boulder. ibm.com/infocenter/iseries/v5r3/ic2924/index. htm?info/ifs/rzaaxscan.htm.

Téléchargez gratuitement cette ressource

HP Elite Slice G2 : optimisez la collaboration… et votre budget !

HP Elite Slice G2 : optimisez la collaboration… et votre budget !

Téléchargez cette étude Forrester et découvrez comment booster la collaboration tout en dégageant un excellent R.O.I grâce au système de vidéoconférence HP Elite Slice G2 avec Microsoft Teams !

Tech - Par iTPro - Publié le 24 juin 2010