Gestion de services avec Sun Internet Administrator

Sun Internet Administrator assure une gestion centralisée sécurisée pour tous les services ISP, à la fois localement et sur un réseau d'hôtes. Il lance les IUG d'administration (lorsqu'elles sont présentes) de services individuels sur demande d'un administrateur autorisé. Des interfaces à ligne de commande peuvent également être employées lorsque cela est approprié.

Fonctions pour un environnement sécurisé

Sun Internet Administrator offre les fonctions de sécurité suivantes :

• Authentification d'administrateur. Les administrateurs doivent fournir un nom d'utilisateur et un mot de passe valides lors de l'accès à l'interface utilisateur graphique.

• Contrôle d'accès de l'administrateur. L'accès est contrôlé par un service ISP. Un administrateur autorisé à gérer des serveurs FTP sur le réseau peut ou non avoir également accès aux serveurs de groupes de discussion. Les administrateurs de console (ceux pouvant gérer des processus Sun Internet Administrator) ont accès à tous les services gérés par Sun Internet Administrator.

• Audit centralisé. Les actions des administrateurs sont consignées pour une traçabilité et une comptabilisation.

• Protection de vue privée et d'intégrité pour tout le trafic réseau. Le logiciel SKIP facultatif peut être configuré pour protéger toutes les connexions vers et depuis Sun Internet Administrator. SSL peut également être employé pour un trafic HTTP sécurisé.

Sun Internet Administrator supporte des services dans deux architectures : trois couches et deux couches. Seule l'architecture trois couches bénéficie de tous les avantages liés à la sécurité indiqués ci-dessus. Quatre types d'IU de service sont pris en charge :

• Les applications trois couches reposant sur un navigateur bénéficient de tous les avantages de sécurité offerts par Sun Internet Administrator.

• Les applications deux couches basées sur un navigateur ne peuvent pas exploiter la fonction d'ouverture de session unique, mais sont gérables par l'intermédiaire de Sun Internet Administrator. Si elles utilisent SWS pour supporter l'application d'administration, elles peuvent le configurer pour assurer l'authentification de l'administrateur. Pour plus de détails, reportez-vous au Chapitre 7. L'architecture deux couches est incluse pour supporter les anciennes applications.

• Les applications X bénéficient de tous les avantages d'une application trois couches.

• Les fonctions de ligne de commande (scripts, programmes ou toutes combinaisons) bénéficient de tous les avantages des applications trois couches. Ces applications peuvent être toutes enregistrées pour un service donné et gérées par Sun Internet Administrator, qui construit une interface Web aux programmes de ligne de commande.

Architecture d'application trois couches

L'architecture d'application trois couches basée sur un navigateur recommandé bénéficie de tous les avantages de sécurité de Sun Internet Administrator.

Figure 1-3 Architecture de service ISP trois couches

Tel qu'illustré dans la Figure 1-3, un administrateur exécute les opérations suivantes pour accéder aux fonctions d'administration des services :

1. A partir d'un navigateur, l'administrateur demande une URL spécifique (l'emplacement de la page d'interface utilisateur graphique principale de Sun Internet Administrator).

   L'AWC est téléchargé dans le navigateur client, où l'administrateur peut choisir un service à gérer.

2. Sun Internet Administrator invite l'administrateur à entrer un nom d'utilisateur et un mot de passe. L'administrateur n'a pas besoin d'utiliser un compte UNIX pour accéder à l'interface graphique utilisateur de la console ; un référentiel de services de répertoire (Sun Directory Services) gère les informations d'administrateur pour Sun Internet Administrator. Cette connexion doit être sécurisée à l'aide d'un protocole HTTP sécurisé.

   Le service sélectionné est traduit en une URL qui désigne l'ASCA du service. En réponse, l'interface utilisateur graphique de l'agent du serveur est téléchargée. A ce stade, le contrôle passe au programme d'administration de service.

3. Tout accès ultérieur est effectué directement entre le navigateur client et l'agent serveur du composant sur l'AWS.

   L'AWS authentifie l'administrateur par rapport aux services de répertoire et consigne chaque requête de l'administrateur. Si l'administrateur a un accès approprié, les requêtes sont passées à l'ASRA.

4. L'ASCA communique avec l'ASRA par l'intermédiaire d'un protocole choisi par le développeur du service. Des mesures de sécurité de niveau IP appropriées doivent être prises pour protéger cette connexion et son trafic.

   L'ASRA authentifie et consigne de nouveau chaque action de l'administrateur. Pour protéger les communications réseau, l'ISP peut ajouter un cryptage de niveau IP, si cela est désiré, en utilisant SKIP.

Les modules ASCA et ASRA pour programmes de ligne de commande et X sont fournis dans Solaris for ISPs. Sun Internet Administrator les utilise automatiquement lorsque vous enregistrez ces applications.

Architecture d'application deux couches

Pour certaines applications, surtout en ce qui concerne les services existants, une architecture deux couches garantissant l'accès par l'intermédiaire de Sun Internet Administrator est plus pratique. Ces services peuvent être gérés depuis Sun Internet Administrator, mais ne bénéficient pas des avantages de sécurité d'une ouverture de session et d'une connexion uniques.

Figure 1-4 Architecture de service ISP deux couches

Tel qu'illustré dans la Figure 1-4, un administrateur exécute les opérations suivantes pour accéder aux fonctions d'administration des services :

1. A partir d'un navigateur, l'administrateur demande une URL spécifique (l'emplacement de la page d'interface graphique de la console principale).

   Cette étape est la même pour l'architecture trois couches. L'AWC est téléchargé dans le navigateur client, où l'administrateur peut choisir un service à gérer.

2. Le service sélectionné est traduit en une URL, désignant l'ASRA du composant. Si l'interface utilisateur d'administration du service n'est pas basée sur le navigateur, d'autres protocoles peuvent être employés au choix du développeur.

3. Tout accès ultérieur s'effectue directement entre le navigateur client et l'agent distant du service. Des mesures de sécurité de niveau IP appropriées doivent être prises pour protéger cette connexion et son trafic.

   Dans une architecture deux couches, les services ne peuvent pas tirer parti de la fonction d'ouverture de session unique.