| Guide d'administration de Solaris Security Toolkit 4.2 |     |
| Guide d'administration de Solaris Security Toolkit 4.2 | |
| C H A P I T R E 2 |
|
Sécurisation de systèmes : application d'une méthodologie |
Ce chapitre décrit une méthodologie pour la sécurisation de systèmes. Vous pouvez appliquer le processus Solaris Security Toolkit avant de sécuriser des systèmes à l'aide du logiciel correspondant.
Ce chapitre contient les sections suivantes :
Une bonne planification est essentielle à la réussite de la sécurisation de systèmes à l'aide du logiciel Solaris Security Toolkit. La phase de planification construit un profil Solaris Security Toolkit pour le système, en fonction des stratégies et des normes de sécurité de l'entreprise, ainsi que des conditions de fonctionnement et d'application requises du système. Cette phase comprend les tâches suivantes :
Même s'ils ne sont pas décrits dans cet ouvrage, d'autres points peuvent être pris en compte, tels que la connaissance des risques, des expositions, de l'infrastructure et de ses besoins en matière de sécurité, la responsabilité, la journalisation et les audits d'utilisation.
Pour la sécurisation de systèmes, vous devez prendre certaines précautions afin d'assurer le fonctionnement du système après la mise en oeuvre du logiciel Solaris Security Toolkit. De plus, il est important d'optimiser le processus afin de limiter les temps d'arrêt au maximum.
Cette section présente certains facteurs qui doivent être pris en compte et parfaitement compris avant toute tentative de sécurisation d'un système. Évaluez soigneusement les risques et les avantages afin de déterminer les actions les plus appropriées à votre entreprise.
1. Connaissance des conditions requises pour les services et les applications du système
Vous devez identifier les services et les applications exécutés sur un système avant d'exécuter le logiciel Solaris Security Toolkit. Toutes les dépendances associées aux services et aux applications doivent être énumérées afin que la configuration du logiciel Solaris Security Toolkit puisse être ajustée. L'absence d'énumération pourrait causer la désactivation des services nécessaires ou empêcher leur démarrage. Alors que la plupart des modifications apportées par le logiciel Solaris Security Toolkit peuvent être annulées, le développement d'un profil correct avant l'installation limite les temps morts lors de la mise en oeuvre du logiciel Solaris Security Toolkit.
2. Prise en compte du fait que le système doit être déconnecté et réinitialisé
Pour que les modifications apportées par le logiciel Solaris Security Toolkit prennent effet, le système doit être réinitialisé. En fonction de l'importance du système, des services fournis et de la présence d'une fenêtre de maintenance, la mise en oeuvre du logiciel peut poser plus ou moins de problèmes à une entreprise. Pour prendre une décision, il faut d'abord évaluer attentivement le coût d'un temps d'arrêt par rapport aux risques encourus si la sécurité n'est pas améliorée.
3. Il peut être nécessaire de réinitialiser plusieurs fois un système pour vérifier son fonctionnement.
Effectuez toutes les modifications sur des systèmes hors production avant de mettre en oeuvre une configuration vitale des systèmes, à chaque fois que cela est possible. Ceci n'est pas toujours le cas, par exemple en l'absence de matériel ou de logiciel suffisant pour répliquer l'environnement cible. Des tests doivent être accomplis avant et après l'exécution du logiciel Solaris Security Toolkit lors de la sécurisation. Des dépendances non identifiées nécessitant un dépannage après la sécurisation du système pourraient être présentes. Dans la plupart des cas, ces problèmes peuvent être résolus assez rapidement en utilisant les techniques décrites dans ce chapitre. Si des problèmes de fonctionnalité sont détectés après l'exécution du logiciel Solaris Security Toolkit, il peut s'avérer nécessaire de réinitialiser plusieurs fois la plate-forme, soit pour annuler les effets du logiciel Solaris Security Toolkit, soit pour ajouter d'autres modifications à la configuration de sécurité du système afin de prendre en charge et d'activer les fonctionnalités manquantes.
4. La sécurisation d'une plate-forme ne se limite pas à la configuration de la sécurité et à l'audit du système.
Si vous envisagez de mettre à niveau la configuration d'un système pour améliorer sa sécurité, il est essentiel de comprendre que la sécurisation et l'audit d'une plate-forme ne représentent qu'une fraction des tâches nécessaires à la protection du système, des services et des données. Ce document ne traite pas des mesures et contrôles supplémentaires. Il est toutefois conseillé de prendre en considération les problèmes liés à la gestion des comptes, à la gestion des privilèges, à l'intégrité des systèmes de fichiers et des données, aux contrôles d'accès basés sur les hôtes, à la détection des intrusions, au balayage et à l'analyse de la vulnérabilité, ainsi qu'à la sécurité des applications.
5. Le système pourrait avoir déjà été exploité ou présenter des vulnérabilités exploitables.
La plate-forme en cours de sécurisation pourrait déjà avoir fait l'objet d'une attaque. Le logiciel Solaris Security Toolkit a probablement été mise en oeuvre trop tard pour assurer une protection contre les vulnérabilités exploitée. En cas de vulnérabilité exploitée :
b. Installez le logiciel Solaris Security Toolkit ;
c. Utilisez le logiciel Solaris Security Toolkit pour améliorer la sécurité.
La première étape de sécurisation d'un système consiste à connaître les stratégies et les normes de sécurité pertinentes de l'organisation, ainsi que les directives en matière de sécurité de plate-forme. Utilisez ces documents comme base du profil de Solaris Security Toolkit, car ils décrivent les conditions requises et les mesures à appliquer à tous les systèmes de l'organisation. Si l'organisation ne dispose pas de documentation, créez-en une pour augmenter votre capacité à personnaliser le logiciel Solaris Secure Toolkit.
|
Remarque - Lorsque vous recherchez de telles informations, n'oubliez pas que vous pouvez trouver du matériel dans les meilleures pratiques ou d'autres documentations. |
Pour de plus amples informations sur les stratégies de sécurité, reportez-vous à l'article Sun BluePrints en ligne « Developing a Security Policy ». Ce document peut être utilisé pour mieux comprendre le rôle des stratégies de sécurité dans le plan de sécurité d'une entreprise.
Les deux exemples qui suivent illustrent les conséquences directes des stratégies de sécurité sur la configuration du profil de Solaris Security Toolkit.
Stratégie - Tous les utilisateurs doivent obligatoirement changer leurs mots de passe tous les 30 jours.
Conséquences sur le profil - Le logiciel Solaris Security Toolkit peut être configuré pour permettre l'expiration du mot de passe. Le fichier secure.driver du logiciel Solaris Security Toolkit définit les mots de passe pour une période maximale de 8 semaines (56 jours). Pour vous conformer à la stratégie, vous devez changer le profil du logiciel Solaris Security Toolkit. Voir Solaris Security Toolkit 4.2 Reference Manual.
Même si secure.driver du logiciel Solaris Security Toolkit permet l'expiration des mots de passe lorsqu'il est exécuté sur un système, cette modification n'affecte pas les utilisateurs existants jusqu'à ce qu'ils changent leur mot de passe. Pour activer l'expiration des mots de passe des utilisateurs existants, appelez la commande passwd(1) sur chaque compte utilisateur. Pour forcer les utilisateurs existants à modifier leur mot de passe, utilisez la commande passwd -f. Pour de plus amples informations sur la commande passwd(1), reportez-vous à la collection de manuels de référence du SE Solaris 10.
Cette tâche permet de garantir que les services restent fonctionnels après la sécurisation du système. Elle comprend les étapes suivantes :
Inventaire des applications, services et fonctions opérationnelles ou de gestion. Cet inventaire est nécessaire pour déterminer le logiciel en cours d'utilisation sur un système. Les systèmes sont souvent dotés de logiciels non utilisés et de logiciels qui ne prennent pas en charge les fonctions de l'entreprise.
Les systèmes doivent, autant que possible, être réduits au maximum. Ainsi, les logiciels non utilisés pour la prise en charge d'une fonction ne doivent pas être installés. Les applications inutiles augmentent les failles du système et ses vulnérabilités exploitables. Par ailleurs, en règle générale, plus le nombre de logiciels sur un système est important, plus le nombre de patchs à appliquer augmente. Pour de plus amples informations sur la minimisation du SE Solaris, reportez-vous à l'article Sun BluePrints en ligne « Minimizing the Solaris Operating Environment for Security ». Pour de plus amples informations sur la minimisation des domaines de systèmes Sun Fire, reportez-vous aux articles Sun BluePrints en ligne « Part I: Minimizing Domains for Sun Fire V1280, 6800, 12K, and 15K Systems, » et « Part II: Minimizing Domains for Sun Fire V1280, 6800, 12K, and 15K Systems ».
Lors de l'inventaire des logiciels, veillez à inclure les composants d'infrastructure, tels que les logiciels de gestion, de contrôle et de sauvegarde, en plus des applications résidant sur le système.
Après avoir terminé l'inventaire des applications et des services, déterminez si certains composants présentent des dépendances qui pourraient avoir une incidence sur la sécurisation. De nombreuses applications tierces n'utilisent pas directement les services fournis par le SE Solaris. Vous trouverez, dans les sections qui suivent, des informations utiles sur ces applications.
|
Remarque - Tous les exemples de cette section utilisent le SE Solaris 9. |
Il est important de connaître les bibliothèques nécessaires à la prise en charge d'une application. Ceci est particulièrement utile en cas de débogage, mais également lors de la préparation d'un système avant sa sécurisation. Si vous ne connaissez pas l'état d'un système, recueillez autant d'informations que possible de manière à bien comprendre certains problèmes, tels que les dépendances logicielles.
Pour déterminer les bibliothèques utilisées par une application, vous avez le choix entre trois méthodes, selon la version du SE installée : Cette section fournit un exemple de code pour chaque méthode.
Pour la collecte d'informations sur un objet de système de fichiers, utilisez la commande /usr/bin/ldd.
Par exemple, déterminez les bibliothèques nécessaires à la prise en charge du logiciel de serveur Domain Name System (DNS).
Pour la collecte d'informations à partir d'un processus en cours, utilisez la commande /usr/proc/bin/pldd (disponible sur les SE Solaris 8, 9 et 10).
La commande pldd indique les bibliothèques partagées qui sont chargées de manière dynamique par l'application, en plus des bibliothèques par rapport auxquelles l'application est liée. Ces informations peuvent également être obtenues à l'aide de la commandetruss suivante.
Ce type de sortie contient l'identificateur de processus, l'appel système (dans ce cas open) et ses arguments, ainsi que la valeur renvoyée par l'appel système. La valeur renvoyée indique clairement si l'appel système réussit à rechercher et à ouvrir la librairie partagée.
Après avoir pris connaissance de la liste des bibliothèques partagées, utilisez la commande suivante pour déterminer les packages du SE Solaris auxquels elles appartiennent.
# grep "/usr/lib/dns/cylink.so.1" /var/sadm/install/contents /usr/lib/dns/cylink.so.1 f none 0755 root bin 63532 24346 \ 1018126408 SUNWcsl |
La sortie de la commande indique que la bibliothèque partagée en question appartient au package SUNWcsl (Core, Shared Libs). Cette procédure est particulièrement utile lors de la minimisation d'une plate-forme, car elle permet d'identifier les packages requis pour la prise en charge d'une application ou d'un service.
Les fichiers de configuration peuvent également être utilisés pour la collecte d'informations. Cette méthode a des conséquences plus directes sur la manière dont un système est sécurisé, du fait que les fichiers de configuration peuvent être renommés ou supprimés pour désactiver des services. Pour de plus amples informations, reportez-vous au manuel Solaris Security Toolkit 4.2 Reference Manual.
Pour déterminer si un fichier de configuration est en cours d'utilisation, utilisez la commande truss.
Dans cet exemple, le service DNS utilise des fichiers de configuration, tels que/etc/named.conf. Comme dans l'exemple précédent, si la valeur renvoyée pour un service indique une erreur, il est probable qu'il existe un problème. Une documentation soigneuse des résultats avant et après la sécurisation peut contribuer à accélérer l'ensemble du processus de validation.
Cette catégorie comprend des structures ou des métaservices sur lesquels sont construites des applications plus volumineuses et plus complexes. Les types de structures dans cette catégorie sont en général les suivants :
Il n'est pas toujours évident de déterminer si une application dépend de ces types de services. Lorsque des ajustements particuliers sont nécessaires pour configurer une application, par exemple lorsqu'il faut ajouter celle-ci à un domaine Kerberos, la dépendance est connue. Dans certains cas, toutefois, les dépendances des applications ne nécessitent aucune tâche supplémentaire ; la dépendance risque donc de ne pas être documentée par le fournisseur.
Le journal de correspondance des points de connexion RPC en est un exemple type. secure.driver du logiciel Solaris Security Toolkit désactive le journal de correspondance des points de connexion RPC. Cette opération peut donner lieu à des comportements inattendus dans d'autres services reposant sur ce service. L'expérience montre que les services abandonnent leurs opérations, s'interrompent ou échouent lorsque le code de l'application ne présente pas une qualité suffisante pour gérer les exceptions. Pour déterminer si une application utilise le journal de correspondance des points de connexion RPC, utilisez la commande rpcinfo. Par exemple :
Les informations figurant dans la colonne du service proviennent du fichier /etc/rpc ou d'un service d'attribution de noms configuré, tel que LDAP.
Si ce fichier ne possède pas d'entrée pour un service, comme c'est souvent le cas pour les produits tiers, le champ du service peut être vide. L'identification des applications enregistrées par d'autres applications devient donc encore plus difficile.
Prenez par exemple la commande rusers. Cette commande repose sur le service de journal de correspondance des points de connexion RPC. Si le journal de correspondance des points de connexion RPC n'est pas en cours d'exécution, la commande rusers semble s'interrompre. Après un délai d'attente, le programme renvoie le message d'erreur suivant :
Ce problème survient parce que le programme est dans l'impossibilité de communiquer avec le service. Toutefois, après le démarrage du service de journal de correspondance des points de connexion RPC à partir de /etc/init.d/rpc, le programme renvoie immédiatement son résultat.
Dans un autre exemple, le service de journal de correspondance des points de connexion RPC est en cours d'exécution alors que le service rusers n'est pas configuré pour fonctionner. Dans ce cas, la réponse générée est complètement différente et relativement facile à valider.
Étant donné que la commande rpcinfo ne possède pas de registre pour le service rusers, il est sage de supposer que le service n'est pas configuré pour être exécuté. Vous pouvez valider cette hypothèse en analysant l'entrée du service dans le fichier /etc/inet/inetd.conf.
# grep rusers /etc/inet/inetd.conf # rusersd/2-3 tli rpc/datagram_v,circuit_v wait root /usr/lib/netsvc/rusers/rpc.rusersd rpc.rusersd |
La marque de commentaire (#) au début de la ligne du service indique que le service rusers est désactivé. Pour activer le service, éliminez le commentaire de la ligne et envoyez un signal SIGHUP au processus /usr/sbin/inetd, comme suit.
|
Remarque - La commande pkill est disponible uniquement sous les SE Solaris 7 à 10. Pour les autres versions, utilisez les commandes ps et kill pour respectivement rechercher et signaler le processus. |
Pour déterminer si une application utilise RPC, il est également possible de faire appel à la commande ldd décrite ci-avant.
L'entrée pour librpcsvc.so.1 indique, outre le nom du fichier, que ce service repose sur le journal de correspondance des points de connexion RPC.
Outre le journal de correspondance des points de connexion RPC, les applications peuvent également reposer sur d'autres services de SE courants, tels que FTP, SNMP ou Network File System (NFS). Vous pouvez utiliser des techniques similaires pour déboguer ces services et déterminer s'ils sont effectivement nécessaires pour la prise en charge d'une fonction de l'entreprise. L'une des méthodes consiste à utiliser la commande netstat comme suit.
Cette commande renvoie une liste de services qui sont en cours d'utilisation ou ont récemment été utilisés, par exemple :
Dans cet exemple, de nombreux services sont utilisés, mais il n'est pas évident de déterminer les ports qui appartiennent aux services ou aux applications. Pour obtenir ces informations, analysez les processus à l'aide de la commande pfiles (1) (disponible sous les SE Solaris 8, 9 et 10). La commande pfiles renvoie des informations pour tous les fichiers ouverts de chaque processus.
# for pid in `ps -aeo pid | grep -v PID`; do > pfiles ${pid} | egrep "^${pid}:|sockname:" > done |
Ces dépendances peuvent être déterminées plus efficacement à l'aide de la commande lsof (pour obtenir la liste des fichiers ouverts).
Téléchargez le code source lsof à l'adresse suivante :
ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/
Téléchargez les binaires lsof à l'adresse suivante :
La commande lsof permet de déterminer les fichiers et les ports utilisés par les processus. Par exemple, pour déterminer les processus qui utilisent le port 35047 dans l'exemple précédent, lancez la commande suivante.
La sortie de la commande lsof indique que le port 35047 est utilisé pour la communication entre les processus dtexec et ttsession.
L'utilisation du programme lsof peut vous permettre de déterminer plus rapidement les dépendances entre systèmes ou entre applications nécessitant l'emploi d'un système de fichiers ou d'un réseau. Presque tout ce qui est signalé dans cette section peut être capturé à l'aide d'options du programme lsof.
Une fois la phase de planification et de préparation terminée, développez et mettez en oeuvre un profil de sécurité. Un profil de sécurité consiste en une configuration, des pilotes de sécurisation, par exemple, nom-{config|hardening|secure}.driver, des scripts et des fichiers nécessaires à la mise en oeuvre des stratégies de sécurité spécifiques à votre entreprise.
Personnalisez l'un des profils de sécurité fournis avec le logiciel Solaris Security Toolkit ou développez-en un nouveau. Les stratégies et les normes de sécurité, ainsi que les conditions requises pour les applications, diffèrent, même légèrement, d'une entreprise à une autre.
Pour personnaliser le un profil de sécurité, ajustez ses actions à l'aide de scripts finish, de scripts audit, de variables d'environnement, de fonctions de structure et de modèles de fichiers.
Pour de plus amples informations, reportez-vous aux chapitres suivants :
Si nécessaire, reportez-vous aux autres chapitres du manuel Solaris Security Toolkit 4.2 Reference Manual pour de plus amples informations sur les scripts, les fonctions de structure, les variables d'environnement et les fichiers. Il existe deux variables d'environnement qu'il est préférable de personnaliser : JASS_FILES et JASS_SCRIPTS.
Pour mettre en oeuvre des normes sur une majorité de plates-formes, tout en préservant les différences spécifiques à chacune, utilisez une technique connue sous le nom de profils de sécurité imbriqués ou hiérarchiques. Pour de plus amples informations, reportez-vous au manuel Solaris Security Toolkit 4.2 Reference Manual. Comparez le profil de sécurité résultant et les stratégies, normes et conditions requises de votre organisation pour garantir que des modifications ne sont pas apportées par inadvertance ou par erreur.
La procédure d'installation du logiciel Solaris Security Toolkit est la même, que le système soit déployé ou nouveau. Pour des instructions détaillées, reportez-vous au Chapitre 3.
Pour les systèmes déployés, certains cas particuliers peuvent rendre l'installation plus simple et plus rapide. Ces cas ne sont pas centrés sur le processus de sécurisation, mais sur les tâches qui précèdent et suivent l'installation.
Avant de sécuriser un système déployé, analysez et planifiez deux tâches significatives :
Ces tâches facilitent la détermination de l'état du système déployé et la résolution des problèmes de configuration pouvant se poser avant la sécurisation du système.
Cette tâche se concentre sur la planification de secours. En cas de problème, il est indispensable que la configuration et les données du système soient archivées sous une forme ou une autre. Vous devez effectuer les opérations suivantes :
Vous devez réaliser ces opérations avant toute modification significative de la configuration d'un système.
La vérification est une tâche presque aussi importante que la sauvegarde. La vérification permet d'assurer la stabilité et le fonctionnement du système avant la mise en oeuvre des modifications de configuration, telles que celles introduites par le processus de sécurisation. Le processus de vérification inclut les étapes suivantes :
Bien qu'il soit préférable de disposer d'un programme de test et d'acceptation bien défini, de tels plans ne sont pas toujours disponibles. Dans ce cas, testez logiquement le système en fonction de son utilisation. Cette tâche a pour objectif d'assurer que la configuration utilisée correspond bien à la configuration enregistrée.
Analysez tous les messages d'erreur ou d'avertissement qui s'affichent à l'initialisation du système ou au démarrage d'une application. Si vous ne parvenez pas à corriger les erreurs, consignez-les de manière à éviter qu'elle ne soient considérées comme des problèmes potentiels au cours du processus de sécurisation. Lorsque vous examinez les fichiers journaux, n'oubliez pas d'inclure les journaux du système, des services et des applications tels que :
Cette tâche est terminée quand vous redémarrez le système sans rencontrer de messages d'erreur ou d'avertissement, ni d'erreurs ou d'avertissements inconnus (tous avertissements ou erreurs connus sont documentées). Le système doit redémarrer dans un état connu et stable. Si vous découvrez, au cours d'une vérification, que les configurations exécutées et stockées du système ne sont pas les mêmes, réévaluez les stratégies et processus de contrôle des changements de l'organisation pour identifier le problème à l'origine de cette situation.
Les tâches suivant l'installation sont un prolongement des tâches précédant l'installation. Leur objectif est d'assurer que le processus de sécurisation n'a pas causé de nouvelles défaillances dans le système ou les applications. Cette tâche consiste avant tout à examiner les fichiers journaux du système et des applications. Les fichiers journaux créés après la sécurisation et la réinitialisation doivent être similaires à ceux qui avaient été collectés avant la sécurisation du système. Ils peuvent parfois contenir moins de messages parce que les services démarrés sont moins nombreux. Mais il est fondamental qu'il ne contiennent pas de nouveaux messages d'erreur ou d'avertissement.
Après avoir examiné les fichiers journaux, testez les fonctionnalités, car certaines applications pourraient rencontrer des problèmes sans consigner de messages dans le fichier journal. Pour de plus amples informations sur la vérification, reportez-vous à la section suivante.
La dernière tâche de ce processus consiste à vérifier que les applications et services offerts par le système fonctionnent tous correctement. Cette tâche vérifie également que le profil de sécurité a été correctement mis en oeuvre en conformité avec les stratégies de l'entreprise en matière de sécurité. Effectuez cette tâche de manière exhaustive et immédiatement après le redémarrage de la plate-forme sécurisée, afin d'assurer la détection des anomalies ou problèmes éventuels et leur correction immédiate. Cette procédure comporte deux tâches : vérification de l'installation du profil de sécurité et vérification des fonctionnalités des applications et des services.
Pour vérifier que le logiciel Solaris Security Toolkit a installé correctement le profil de sécurité sans erreurs, examinez le fichier journal de l'installation jass-install-log.txt. Ce fichier se trouve dans le sous-répertoire /var/opt/SUWWjass/runs, au sein du répertoire unique à chaque sécurisation ou audit (heure/date de démarrage de l'exécution).
Après avoir vérifié que le profil a été installé, évaluez la configuration de sécurité du système. Effectuez un examen manuel ou utilisez un outil d'automatisation du processus.
Pour vérifier les applications et les services de processus, lancez un plan de test et d'acceptation bien défini, afin de tester les différents composants d'un système ou d'une application, et de déterminer s'ils sont disponibles et s'ils fonctionnent correctement. En l'absence d'un tel plan, testez le système avec logique en fonction de son utilisation. L'objectif est de s'assurer que la sécurisation n'a pas altéré le fonctionnement des applications ou services.
Si vous découvrez qu'une application ou un service ne fonctionne pas correctement après la sécurisation du système, recherchez la cause du problème en examinant les fichiers journaux correspondants. Le plus souvent, vous pouvez utiliser la commande truss pour localiser le problème. Un fois le problème localisé, vous pouvez le cibler et remonter à la modification apportée par le logiciel Solaris Security Toolkit.
De nombreuses organisations commettent la même erreur qui consiste à prendre la sécurité en compte au moment de l'installation uniquement, puis de n'y revenir que rarement, voire jamais. La maintenance de la sécurité est un processus permanent. La sécurité d'un système doit être vérifiée périodiquement.
La maintenance d'un système sécurisé requiert une grande attention étant donné que la configuration de sécurité de tout système tend à s'ouvrir de plus en plus avec le temps. Par exemple, les failles du systèmes deviennent connues.
Les directives de base suivantes indiquent les tâches de maintenance de la sécurité d'un système :
Les patchs du SE Solaris risquent d'installer des packages supplémentaires et écraser des fichiers de configuration du système. Le logiciel Solaris Security Toolkit peut vous assister lors de l'application de patchs, parce qu'il prend en charge les exécutions répétées sur un système, afin que vous sécurisiez le système après l'installation de patchs. Exécutez le logiciel après l'installation de chaque patch, en utilisant les pilotes appropriés, pour vous assurer que la configuration demeure conforme aux stratégies de sécurité. Effectuez également un examen manuel du système, car la version de Solaris Security Toolkit utilisée pourrait ne pas prendre en charge les nouvelles fonctions ajoutées par les patchs installés.
Le logiciel Solaris Security Toolkit inclut des profils de sécurité par défaut que vous pouvez utiliser comme point de départ.
| Guide d'administration de Solaris Security Toolkit 4.2 | 819-3788-10 | |
Copyright © 2005, Sun Microsystems, Inc. Tous droits réservés.