Ignorer les liens de navigation | |
Quitter l'aperu | |
Configuration et administration de Trusted Extensions Oracle Solaris 11.1 Information Library (Français) |
Partie I Configuration initiale de Trusted Extensions
1. Planification de la sécurité pour Trusted Extensions
2. Déroulement de la configuration de Trusted Extensions
3. Ajout de la fonction Trusted Extensions à Oracle Solaris (tâches)
4. Configuration de Trusted Extensions (tâches)
5. Configuration de LDAP pour Trusted Extensions (tâches)
Partie II Administration de Trusted Extensions
6. Concepts d'administration de Trusted Extensions
7. Outils d'administration de Trusted Extensions
8. Exigences de sécurité sur un système Trusted Extensions (présentation)
9. Exécution de tâches courantes dans Trusted Extensions
10. Utilisateurs, droits et rôles dans Trusted Extensions (présentation)
11. Gestion des utilisateurs, des droits et des rôles dans Trusted Extensions (tâches)
12. Administration à distance dans Trusted Extensions (tâches)
Administration à distance dans Trusted Extensions
Méthodes d'administration de systèmes distants dans Trusted Extensions
Configuration et administration à distance de systèmes dans Trusted Extensions (liste des tâches)
Activation de l'administration à distance sur un système Trusted Extensions distant
Configuration d'un système Trusted Extensions à l'aide de Xvnc pour un accès à distance
Connexion et administration d'un système Trusted Extensions distant
13. Gestion des zones dans Trusted Extensions
14. Gestion et montage de fichiers dans Trusted Extensions
15. Gestion de réseaux de confiance (présentation)
16. Gestion des réseaux dans Trusted Extensions (tâches)
17. Trusted Extensions et LDAP (présentation)
18. Messagerie multiniveau dans Trusted Extensions (présentation)
19. Gestion de l'impression étiquetée (tâches)
20. Périphériques dans Trusted Extensions (présentation)
21. Gestion des périphériques pour Trusted Extensions (tâches)
22. Audit de Trusted Extensions (présentation)
23. Gestion des logiciels dans Trusted Extensions
A. Stratégie de sécurité du site
Création et gestion d'une stratégie de sécurité
Stratégie de sécurité du site et Trusted Extensions
Recommandations relatives à la sécurité informatique
Recommandations relatives à la sécurité physique
Recommandations relatives à la sécurité du personnel
Violations de sécurité courantes
Références de sécurité supplémentaires
B. Liste de contrôle de configuration pour Trusted Extensions
Liste de contrôle de configuration de Trusted Extensions
C. Guide de référence rapide pour l'administration de Trusted Extensions
Interfaces d'administration dans Trusted Extensions
Interfaces Oracle Solaris étendues par Trusted Extensions
Renforcement des paramètres de sécurité par défaut dans Trusted Extensions
Options limitées dans Trusted Extensions
D. Liste des pages de manuel Trusted Extensions
Pages de manuel Trusted Extensions par ordre alphabétique
Pages de manuel Oracle Solaris modifiées par Trusted Extensions
Après l'activation de l'administration à distance et avant la réinitialisation du système distant sur Trusted Extensions, vous pouvez configurer le système à l'aide de la technologie VNC ou du protocole ssh.
|
Remarque - Consultez votre stratégie de sécurité pour déterminer les méthodes d'administration à distance possibles sur votre site.
Dans cette procédure, vous autorisez l'authentification basée sur des hôtes sur un système distant Oracle Solaris avant d'y ajouter la fonction Trusted Extensions. Le système distant est le serveur Shell sécurisé.
Avant de commencer
Le système distant est installé avec Oracle Solaris, et vous pouvez accéder à ce système. Vous devez être dans le rôle root.
Pour connaître la procédure, reportez-vous à la section Procédure de configuration de l’authentification basée sur l’hôte pour Secure Shell du manuel Administration d’Oracle Solaris 11.1 : Services de sécurité.
Remarque - N'utilisez pas la commande cat. Copiez et collez la clé publique via une connexion Shell sécurisé. Si votre client Shell sécurisé n'est pas un système Oracle Solaris, suivez les instructions de votre plate-forme permettant de configurer un client Shell sécurisé avec l'authentification basée sur des hôtes.
Une fois cette étape terminée, vous disposez d'un compte d'utilisateur sur les deux systèmes qui est habilité à prendre le rôle root. Les comptes reçoivent un UID, un GID et une assignation de rôle identiques. Vous avez également généré des paires de clé publique ou privée et partagé des clés publiques.
# pfedit /etc/ssh/sshd_config ## Permit remote login by root PermitRootLogin yes
Une étape ultérieure limite la connexion de root à un système et un utilisateur particulier.
Remarque - Etant donné que·l'administrateur prendra le rôle root, vous n'avez pas besoin d'assouplir la stratégie de connexion qui empêche la connexion à distance de root.
# svcadm restart ssh
# cd # pfedit .shosts client-host username
Le fichier .shosts autorise username du système client-host à prendre le rôle root sur le serveur, lorsque une clé publique ou privée est partagée.
# cp /etc/pam.d/other /etc/pam.d/other.orig
# pfedit /etc/pam.d/other ... # Default definition for Account management # Used when service name is not explicitly mentioned for account management # ... #account requisite pam_roles.so.1 # Enable remote role assumption account requisite pam_roles.so.1 allow_remote ...
Cette stratégie autorise username du système client-host à prendre un rôle sur le serveur.
# pfedit /etc/pam.d/other # Default definition for Account management # Used when service name is not explicitly mentioned for account management # ... #account requisite pam_roles.so.1 # Enable remote role assumption account requisite pam_roles.so.1 allow_remote # account required pam_unix_account.so.1 #account required pam_tsol_account.so.1 # Enable unlabeled access to TX system account required pam_tsol_account.so.1 allow_unlabeled
% ssh -l root remote-system
# svcadm enable -s labeld # /usr/sbin/reboot
Exemple 12-1 Affectation d'un type d'hôte CIPSO pour l'administration à distance
Dans cet exemple, l'administrateur utilise un système Trusted Extensions pour configurer un hôte Trusted Extensions distant. Pour ce faire, l'administrateur utilise la commande tncfg sur chaque système distant pour définir le type d'hôte du système homologue.
remote-system # tncfg -t cipso add host=192.168.1.12 Client-host
client-host # tncfg -t cipso add host=192.168.1.22 Remote system
Etant donné qu'un système sans étiquette peut également configurer l'hôte Trusted Extensions distant, l'administrateur conserve l'option allow_unlabeled dans le fichier pam.d/other de l'hôte distant.
La technologie VNC (Virtual Network Computing) connecte un client à un serveur distant et affiche le bureau du serveur distant dans une fenêtre sur le client. Xvnc est la version UNIX de VNC, laquelle est basée sur un serveur X standard. Dans Trusted Extensions, les clients de n'importe quelle plate-forme peuvent se connecter à un serveur Xvnc exécutant Trusted Extensions accéder au serveur Xvnc, puis visualiser et travailler dans un bureau multiniveau.
Pour plus d'informations, reportez-vous aux pages de manuel Xvnc(1) et vncconfig(1).
Avant de commencer
Vous avez installé et configuré Trusted Extensions sur ce système qui sera utilisé en tant que serveur Xvnc. La zone globale de ce système possède une adresse IP fixe, c'est-à-dire qu'elle n'utilise pas le profil de configuration réseau automatique, comme décrit dans la page de manuel netcfg(1M).
Ce système reconnaît les clients VNC par nom d'hôte ou par adresse IP. Plus précisément, le modèle de sécurité admin_low identifie explicitement ou à l'aide d'un caractère générique les systèmes susceptibles d'être des clients VNC de ce serveur. Pour plus d'informations sur la configuration de la connexion sécurisée, reportez-vous à la section Limitation des hôtes pouvant être contactés sur le réseau de confiance.
Si une session GNOME est en cours d'exécution sur la console du futur serveur Xvnc de Trusted Extensions, l'option Desktop Sharing (Partage du bureau) n'est pas activée.
Vous endossez le rôle root dans la zone globale du futur serveur Xvnc de Trusted Extensions.
# packagemanager &
Dans l'interface graphique du gestionnaire de packages, (Package Manager) recherchez les" vnc" et choisissez parmi les serveurs disponibles. Une première option est le logiciel du serveur TigerVNC X11/VNC.
Si vous ne parvenez pas à ouvrir l'interface graphique, ajouter le compte root local à la liste de contrôle d'accès du serveur X. Exécutez cette commande en tant qu'utilisateur ayant ouvert une session dans le serveur X.
% xhost +si:localuser:root
Pour plus d'informations, reportez-vous aux pages de manuel xhost(1) et Xsecurity(5).
Modifiez le fichier de configuration personnalisée GNOME Display Manager (gdm). Dans le fichier /etc/gdm/custom.conf, saisissez Enable=true sous le titre [xdmcp],
[xdmcp] Enable=true
Astuce - Enregistrez une copie du fichier Xsession d'origine avant d'apporter la modification.
DISPLAY=unix:$(echo $DISPLAY|sed -e s/::ffff://|cut -d: -f2)
Les fichiers à l'Étape 2 et à l'Étape 3 sont marqués avec un attribut de package preserve=true. Pour plus d'informations sur l'effet de cet attribut sur vos fichiers modifiés au cours des mises à niveau et des corrections de package, reportez-vous à la page de manuel pkg(5).
# svcadm enable xvnc-inetd
# svcadm restart gdm
Attendez environ une minute que le gestionnaire de bureau redémarre. Il est ensuite possible pour un client VNC de se connecter.
# svcs | grep vnc
Pour le système client, vous disposez d'un choix de logiciels. Vous pouvez utiliser le logiciel VNC à partir du référentiel Oracle Solaris.
Pour plus d'informations sur les événements d'audit de présélection par système et par utilisateur, reportez-vous à la section Configuration du service d’audit (tâches) du manuel Administration d’Oracle Solaris 11.1 : Services de sécurité.
% /usr/bin/vncviewer Xvnc-server-hostname
Pour les options de commande, reportez-vous à la page de manuel vncviewer(1).
Poursuivez la procédure de connexion. Pour une description des étapes restantes, reportez-vous à la section Connexion à Trusted Extensions du manuel Guide de l’utilisateur Trusted Extensions.
Exemple 12-2 Utilisation de Vino pour partager un bureau dans un environnement de test
Dans cet exemple, deux développeurs utilisent le service GNOME Vino pour partager l'affichage à partir du menu Launch (Lancer)→ System (Système)→ Preferences (Préférences)→ Desktop Sharing (Partage du bureau). En plus de ces étapes, ils assouplissent la stratégie Trusted Extensions en activant l'extension XTEST.
# pfedit /usr/X11/lib/X11/xserver/TrustedExtensionsPolicy ## /usr/X11/lib/X11/xserver/TrustedExtensionsPolicy file ... #extension XTEST extension XTEST ...
Cette procédure vous permet d'utiliser la ligne de commande et l'interface graphique txzonemgr permettant d'administrer un système Trusted Extensions distant.
Avant de commencer
L'utilisateur, le rôle et l'assignation de rôles sont définis de façon identique dans les systèmes locaux et distants, comme décrit dans la section Activation de l'administration à distance sur un système Trusted Extensions distant.
desktop $ xhost + remote-sys
Utilisez la commande ssh pour vous connecter.
desktop $ ssh -X -l identical-username remote-sys Password: Type the user's password remote-sys $
L'option -X permet d'afficher les interfaces graphiques.
Par exemple, prenez le rôle root.
remote-sys $ su - root Password: Type the root password
Vous êtes à présent dans la zone globale. Vous pouvez maintenant utiliser cette fenêtre de terminal pour administrer le système distant à partir de la ligne de commande. Les interfaces graphiques s'affichent sur votre écran. Reportez-vous à l'Exemple 12-3.
Exemple 12-3 Configuration des zones étiquetées sur un système distant
Dans cet exemple, l'administrateur utilise l'interface graphique txzonemgr pour configurer des zones étiquetées sur un système distant étiqueté à partir d'un système de bureau étiqueté. Comme dans Oracle Solaris, l'administrateur autorise le serveur X à accéder au système du bureau à l'aide de l'option -X de la commande ssh. L'utilisateur jandoe est défini à l'identique sur les deux systèmes et peut prendre le rôle remoterole.
TXdesk1 $ xhost + TXnohead4
TXdesk1 $ ssh -X -l jandoe TXnohead4 Password: Ins1PwD1 TXnohead4 $
Pour atteindre la zone globale, l'administrateur utilise le compte jandoe afin de prendre le rôle remoterole. Ce rôle est défini à l'identique sur les deux systèmes.
TXnohead4 # su - remoterole Password: abcd1EFG
Dans le même terminal, l'administrateur dans le rôle remoterole démarre l'interface graphique txzonemgr.
TXnohead4 $ /usr/sbin/txzonemgr &
Le gestionnaire de zones étiquetées (Labeled Zone Manager) s'exécute sur le système distant et s'affiche sur le système local.
Exemple 12-4 Connexion à une zone étiquetée distante
L'administrateur souhaite modifier un fichier de configuration sur un système distant sous l'étiquette PUBLIC.
L'administrateur dispose de deux options.
Soit il se connecte à distance à la zone globale, affiche l'espace de travail de la zone globale distante, modifie l'espace de travail sur l'étiquette PUBLIC, puis ouvre une fenêtre de terminal et modifie le fichier.
Soit il se connecte à la zone PUBLIC à l'aide de la commande ssh à partir d'une fenêtre de terminal PUBLIC, puis modifie le fichier.
Notez que si le système distant exécute un démon de service de noms (nscd) pour toutes les zones, et si le système distant utilise le service de noms de fichiers; le mot de passe de la zone PUBLIC distante est le mot de passe qui était en vigueur lors de la dernière réinitialisation de la zone. Si le mot de passe pour la zone PUBLIC distante a été modifié et si la zone n'a pas été réinitialisée après la modification, le mot de passe d'origine permet l'accès.
Erreurs fréquentes
Si l'option -X ne fonctionne pas, l'installation d'un package peut être nécessaire. Le transfert X11 est désactivé lorsque le binaire xauth n'est pas installé. La commande suivante permet de charger le fichier binaire : pkg install pkg:/x11/session/xauth.