Etablir des règles : le secret d’une parfaite intégrité

Les besoins de chaque entreprise sont différents, et s’il est vrai qu’il n’existe
pas de politique de sécurité unique convenant à  toutes les entreprises, il faut
cependant dire que toutes les politiques efficaces ont des points communs. Voici
quelques-uns des points forts à  prendre en compte. Tout d’abord, cette politique
doit fixer des principes généraux pour l’utilisation de certaines fonctions ou
ressources. On peut, par exemple, permettre aux employés de se connecter à  Internet
à  des fins personnelles, tant que leur productivité n’en souffre pas, mais on
peut leur interdire de télécharger du code depuis l’Internet. On peut également
inscrire des comportements que l’on souhaiterait voir adoptés par les employés
dans certaines situations, comme par exemple demander de passer un antivirus sur
tous les courriers électroniques avant d’ouvrir et de lancer les fichiers attachés.

Ensuite, il faut couvrir les besoins de sécurité de l’intranet ou du réseau interne,
y compris les exigences de sécurité concernant les personnes et les limites d’utilisation
d’informations sensibles. Ainsi, chez IBM, tous les collaborateurs, sous-traitants
et fournisseurs doivent porter et utiliser un badge d’identification avant d’entrer
dans les locaux. La politique de sécurité d’IBM exige également que chaque collaborateur
attache physiquement son ordinateur portable à  un meuble de bureau fixe, pour
en empêcher le vol.

Il faut aussi convenir de règles concernant les mots de passe (ils doivent par
exemple comporter 8 caractères, dont au moins un chiffre, et les changer tous
les 180 jours) et la politique concernant les autorisations. Le système d’autorisation
peut, par exemple, décréter que, par défaut, toutes les bibliothèques applicatives
excluent tout le monde, puis octroyer aux utilisateurs ou aux groupes appelés
à  exécuter une application des droits spécifiques sur la bibliothèque applicative.

Il faut également clarifier le rôle de chacun dans l’entreprise, et préciser leurs
différents privilèges. Ainsi, la plupart des collaborateurs n’ont pas de privilèges
(appelés droits spéciaux sur l’AS/400), mais les opérateurs du système AS/400
ont des droits spéciaux *JOBCTL et *SAVSYS. On peut également rajouter des considérations
spéciales pour les officiers de sécurité et les fournisseurs tiers qui doivent
se connecter au système. On peut contrôler ces utilisateurs ou demander aux officiers
de sécurité de changer leur mot de passe plus fréquemment que les autres.

Une fois les exigences bien définies, il faut examiner l’éventuel besoin de connexion
en dehors du réseau local. S’il est prévu d’utiliser un serveur Web, il faut déterminer
si celui-ci se trouve à  l’intérieur ou à  l’extérieur du pare-feu et les exigences
concernant ce dernier. Suivent d’autres considérations : quels éventuels services
seront autorisés sur le serveur Web lui-même, quels services seront autorisés
à  revenir dans le réseau interne en franchissant le pare-feu, et quels services
pourront aller sur Internet. S’il est vrai que des pirates peuvent essayer de
pénétrer dans les réseaux internes en franchissant illégalement les serveurs Web
et les pare-feu, il est également vrai que des collaborateurs peuvent aussi provoquer
des dégâts en envoyant des données vitales aux concurrents, à  la presse ou autres
en mode FTP.

Il faut aussi se demander quelles sont les données fournies par le serveur Web,
d’où elles viennent et où les stocker. Si l’on stocke les données apportées sur
un système sur le réseau interne, comment le serveur Web retrouve-t-il les informations
? Une application peut se connecter au réseau interne et y recueillir des informations
en temps réel, mais cette pratique revient à  laisser une connexion ouverte  » toujours
active  » dans le réseau interne. On peut aussi programmer l’extraction périodique
de données ou le  » push  » de données depuis le système interne vers le serveur
Web. Ces deux dernières solutions sont peut-être plus sûres, mais les données
risquent d’être trop anciennes. IBM préconise de ne stocker et ne fournir sur
le serveur Web que les informations dont l’application Web a réellement besoin.
Le seul fait de posséder des informations n’oblige pas à  les stocker dans un système
accessible au public. Cela nous conduit à  la confidentialité.

On s’inquiète de plus en plus de la manière dont certaines sociétés utilisent
les données personnelles, sans souci de respect ni d’éthique. La politique de
sécurité doit exprimer clairement la position de l’entreprise en regard de la
confidentialité, c’est-à -dire le type de données recueillies sur les clients et
les employés, comment protéger et utiliser ces informations. Par exemple, va-t-on
vendre les listes de clients ou les envoyer à  un groupe d’étude de marché pour
déterminer leurs habitudes d’achat ? (Pour plus d’informations sur le sujet de
la confidentialité, voir  » Privacy Movement Gains Momentum « , NEWS/400, Novembre
1999).

Un aspect important mais souvent oublié d’une politique de sécurité concerne les
produits de fournisseurs de logiciels. Avant d’acheter un logiciel, il faut le
passer au crible pour s’assurer qu’il respecte l’ensemble des exigences de sécurité,
pour ne pas découvrir après coup qu’il ne répond pas au cahier des charges. Si
on constate des lacunes avant l’achat, on peut demander au fournisseur d’apporter
les modifications nécessaires. (Pour plus d’informations sur les critères de sécurité
que les fournisseurs de logiciels doivent remplir, voir l’article  » Contrôler
les sécurités des éditeurs de logiciels « , dans ce même dossier).

Pour finir, il faut indiquer quelles sont les conséquences du non-respect de la
politique de sécurité. Il est indispensable que les collaborateurs comprennent
et acceptent les règles qui sont définies et soient prêts à  subir les conséquences
de leur transgression. Comme un enfant qui, tant qu’il n’est pas puni, désobéit
continuellement à  ses parents, un collaborateur ne prendra pas au sérieux une
politique de sécurité si sa transgression n’est pas sanctionnée.

Une fois la politique de sécurité établie, il faut s’assurer que tous les collaborateurs
en ont pris connaissance et l’acceptent. IBM fait signer à  ses employés un document
par lequel ils reconnaissent avoir lu la politique de sécurité de l’entreprise
et acceptent de s’y plier. Il est essentiel que le personnel comprenne que la
sécurité est un aspect de la gestion et que la politique de sécurité leur permet
de connaître les règles des éléments de sécurité et leur mise en application.
Pour les nouveaux collaborateurs, on peut expliquer la politique de sécurité pendant
la période de prise en main du travail.

Après avoir rédigé et communiqué la politique de sécurité à  tout le personnel,
le travail n’est pas fini. C’est un document vivant qu’il faut revoir régulièrement
(ou au moins quand une nouvelle technologie ou une nouvelle version d’OS/400 arrive
dans l’entreprise). Une enquête récente du magazine Information Week montre que
37% seulement des personnes interrogées revoient leur politique de sécurité une
ou plusieurs fois par an !