2 Installation sécurisée

Cette section détaille les processus de planification et d'implémentation à mettre en oeuvre pour garantir une installation et une configuration sécurisées. Elle décrit également plusieurs topologies de déploiement recommandées pour ACSLS.

Présentation de votre environnement

Les réponses aux questions suivantes peuvent vous aider à comprendre les exigences de sécurité :

Quelles sont les ressources à protéger ?

Les ressources principales gérées par ACSLS sont des bibliothèques de bandes, des lecteurs et des cartouches. Ces ressources doivent être protégées de tout accès malveillant ou par inadvertance. Empêchez par exemple les utilisateurs de se connecter à un autre serveur ACSLS par mégarde en associant des mots de passe différents aux ID utilisateur ACSLS sur les différents serveurs.

De quels utilisateurs les ressources doivent-elles être protégées ?

Il faut protéger les ressources de stockage sur bande des accès non autorisés internes aussi bien qu'externes.

Que peut-il se passer en cas de défaillance de la protection des ressources stratégiques ?

ACSLS peut monter des cartouches sur des lecteurs de bande. Si un utilisateur peut se connecter au lecteur de bande en passant par le chemin d'accès des données, il peut également lire les données sur la bande si celles-ci ne sont pas chiffrées.

Des utilisateurs ayant accès à la fois à ACSLS et à une bibliothèque de bandes peuvent insérer et éjecter des cartouches d'une bibliothèque de bandes.

Procédure recommandée pour la sécurisation d'ACSLS

Suivez cette procédure lors de la sécurisation d'ACSLS et des composants d'infrastructure requis afin d'assurer le bon fonctionnement d'ACSLS une fois les modifications effectuées :

• Installez ACSLS.

• Vérifiez qu'ACSLS fonctionne correctement. Pour cela, vérifiez la configuration et l'audit de bibliothèques, le montage et le démontage de bandes, l'insertion et l'éjection de bandes, ainsi que la sauvegarde et la restauration de la base de données.

• Implémentez les modifications pour renforcer la sécurité.

• Vérifiez qu'ACSLS fonctionne toujours correctement.

Sécurisation de la communication Internet d'ACSLS

Cette section décrit les recommandations de déploiement d'ACSLS pour sécuriser l'accès à Internet.

Sécurisation d'ACSLS et des bibliothèques de bandes derrière le pare-feu de l'entreprise

Le logiciel ACSLS et les bibliothèques de bandes qu'il prend en charge doivent être déployés derrière le pare-feu de l'entreprise. Si un utilisateur travaillant à distance a besoin de se connecter au serveur ACSLS, il peut y accéder en passant par un VPN.

Remarque :

Si vous disposez d'un pare-feu de périmètre IPv4, il doit être configuré pour rejeter tous les paquets sortants 41 du protocole IPv4 et les paquets 3544 du port UDP, afin d'empêcher que des hôtes Internet utilisent du trafic transitant par des tunnels IPv6 sur IPv4 pour atteindre des hôtes internes.

Option Firewall Security Option d'ACSLS

Si des applications clientes qui utilisent ACSLS pour le montage de bandes et la gestion de bibliothèques de bandes sont séparées d'ACSLS par un pare-feu, nous vous recommandons d'activer l'option Firewall Security Option. Même si les applications clientes ne sont pas séparées d'ACSLS par un pare-feu, l'implémentation de l'option Firewall Security Option sécurise davantage ACSLS en limitant les ports utilisés pour la communication entre ACSLS et ses applications clientes, comme illustré ci-dessous. C'est pour ces raisons que la variable statique CSI_FIREWALL_SECURE est, par défaut, définie sur TRUE dans ACSLS à partir de la version 8.1.

Pour plus d'informations, reportez-vous à l'annexe relative à l'option Firewall Security Option du guide de l'administrateur d'ACSLS.

Ports Ethernet utilisés pour la communication d'ACSLS

• Les ports suivants sont utilisés sur le serveur ACSLS. Assurez-vous que les éventuels pare-feux sont configurés pour permettre au trafic d'accéder à ces ports. Cela concerne notamment les pare-feux implémentés par ipfilter sous Solaris ou par iptables sous Linux.

  • 22 dans les deux directions – utilisé pour l'accès ssh.

  • 111 Portmapper, sauf si Portmapper a été désactivé.

  • 115 utilisé pour SFTP (Secure File Transfer Protocol).

  • 161 port par défaut pour l'agent SNMP d'ACSLS - get/set/walk.

  • 162 port par défaut pour l'agent SNMP d'ACSLS - déroutements.

    Remarque :

    Les ports utilisés par l'agent SNMP d'ACSLS peuvent être configurés à l'aide de la commande : AcslsAgtdSnmpConf [ -p port ] [-t trap port] [-d].  L'option -d affiche le paramétrage actuel.  Après avoir modifié les paramètres du port, vous devez redémarrer l'agent à l'aide de la commande agentRegister.

  • 5432 port par défaut pour la communication interne entre ACSLS et la base de données PostgreSQL (la variable d'environnement PGPORT pour l'ID utilisateur acsss).

    Si le port 5432 est déjà utilisé, le premier numéro de port supérieur disponible est utilisé.

    Remarque :

    Il suffit que le port 5432 soit accessible à partir de localhost (127.0.0.1).

  • 7001 et 7002 - utilisé par WebLogic et l'interface graphique d'ACSLS.

  • 30031 ou port d'écoute CSI d'ACSLS, défini par CSI_INET_PORT.

  • 50003 port utilisé pour la communication interne depuis l'interface graphique et les composants Java d'ACSLS vers le traitement ACSLS hérité. Il ne peut pas être configuré.

• Pour permettre aux applications clientes de communiquer avec ACSLS par le biais de l'ACSAPI, les ports suivants doivent être ouverts :

  • L'application cliente doit pouvoir communiquer avec le port d'écoute CSI d'ACSLS. Par défaut, il s'agit du port 30031, qui est défini par la variable statique CSI_INET_PORT.

    La commande suivante exécutée depuis le shell Unix permet d'identifier les ports utilisés par ACSLS pour écouter les demandes des clients ACSAPI :

    rpcinfo -p | egrep "300031 | 536871166"

    Les ID des ports sont listés dans le dernier champ de l'affichage.

  • Le client ACSAPI (un serveur NetBackup ou SAM-QFS par exemple) définit son port entrant fixe à l'aide de la variable d'environnement SSI_INET_PORT. Spécifiez un port compris entre 1024 et 65535, à l'exception des ports 50001 et 50004. Le serveur ACSLS doit pouvoir communiquer avec ce port.

    Remarque :

    Sur un serveur client ACSAPI, les ports 50001 and 50004 sont utilisés pour la communication inter-processus entre le domaine AF_INET et le mini journal des événements ainsi que pour la communication entre les applications clientes et SSI.

  Pour plus d'informations sur la communication entre les applications clientes et ACSLS, reportez-vous à l'annexe relative à l'option Firewall Security Option du guide de l'administrateur d'ACSLS.

• Si le composant XAPI est installé, le serveur XAPI utilise un port d'écoute fixe pour recevoir les demandes TCP entrantes des clients ELS. Le port d'écoute XAPI est défini par la variable statique XAPI_PORT. XAPI_PORT est renseigné par défaut par 50020. Il doit être compris entre 1024 et 65535, et ne peut pas entrer en conflit avec un autre port utilisé par ACSLS ou d'autres applications.

  Pour plus d'informations sur XAPI_PORT, reportez-vous à l'annexe relative à l'interface client XAPI du guide de l'administrateur ACSLS. Cette annexe fournit également des détails sur l'affichage et la définition de la variable statique XAPI_PORT.

• Les ports suivants doivent être ouverts dans une bibliothèque SL8500 ou SL3000 :

  ACSLS communique avec ces ports grâce aux connexions Ethernet 2A et 2B d'une bibliothèque SL8500 ou SL3000. Si la communication est bloquée entre ACSLS et ces ports, ACSLS ne peut pas gérer la bibliothèque.

  • 50001 – Utilisé pour toutes les communications normales entre ACSLS et la bibliothèque

  • 50002 – Utilisé par ACSLS HA pour déterminer si le noeud HA de rechange peut communiquer avec la bibliothèque avant le basculement sur le noeud de rechange.

Configuration des pare-feux qui s'exécutent sur le serveur ACSLS

Parallèlement aux pare-feux externes, il est possible d'implémenter une protection par pare-feu sur votre serveur ACSLS au moyen d'ipfilter sous Solaris ou d'iptables sous Linux. Cette section indique comment gérer ces pare-feux qui s'exécutent sur votre serveur ACSLS.

• Gestion d'ipfilter sous Solaris :

  Pour plus d'informations, consultez les pages de manuel relatives à ipf et à ipfilter.

  • Le pare-feu ipfilter est activé (ou désactivé) par 'root' à l'aide de la commande :

    svcadm enable ipfilter (svcadm disable ipfilter)

  • Pour connaître le statut actuel d'ipfilter :

    svcs ipfilter

  • Les stratégies de pare-feu sont définies dans le fichier : /etc/ipf/ipf.conf

    Pour permettre à des composants hébergés sur l'hôte local de communiquer librement (ACSLS et WebLogic par exemple, ou l'interface graphique et la base de données ACSLS), insérez une instruction semblable aux suivantes :

    pass in quick from 127.0.0.1 to 127.0.0.1

    ou

    pass in quick from 127.0.0.1 to all

    Vous devez définir des stratégies qui autorisent l'accès à tous les ports requis pour ACSLS. Par exemple, pour inclure une stratégie qui permet à des navigateurs Web distants d'accéder à l'interface graphique d'ACSLS, vous devez ouvrir les ports 7001 et 7002.

    pass in quick from any to any port = 7001

    pass in quick from any to any port = 7002

    Une fois que vous avez identifié les ports utilisés par ACSLS pour écouter les demandes émanant de clients ACSAPI, insérez des instructions 'pass in quick' pour chacun de ces ports.

    Il peut être nécessaire d'inclure une instruction 'pass in quick' pour le port Portmapper RPC : 111.

    La dernière instruction de l'ensemble de règles proposé, "block in from any", indique qu'aucun trafic ne doit atteindre l'hôte, sauf si cela a été expressément autorisé dans une instruction précédente.

• Gestion d'iptables sous Linux :

  • Le pare-feu iptables est activé (ou désactivé) par 'root' à l'aide de la commande :

    service iptables start (service iptables stop)

  • Pour vérifier le statut d'iptables :

    service iptables status

  • Le fichier de stratégie pour iptables est /etc/sysconfig/iptables :

    Vous devez définir des stratégies qui autorisent l'accès à tous les ports requis pour ACSLS. Par exemple, pour inclure une stratégie qui autorise l'accès http/https distant à l'interface graphique d'ACSLS, vous devez mettre à jour ce fichier afin d'insérer des exceptions pour les ports 7001 et 7002 à l'aide d'instructions telles que les suivantes :

    -A input -p tcp --dport 7001 -j ACCEPT

    -A input -p tcp --dport 7002 -j ACCEPT

    Une fois que vous avez identifié les ports utilisés par ACSLS pour écouter les demandes émanant de clients ACSAPI, vous devez ajouter des exceptions pour chacun de ces ports au fichier de stratégie iptables. Il peut être nécessaire d'inclure une instruction d'exception pour le port Portmapper RPC : 111.

Installation et configuration de Solaris

Cette section indique comment installer et configurer Solaris de façon sécurisée.

Voici quelques recommandations :

• Appliquez tous les correctifs de sécurité importants au système d'exploitation et aux services installés avec ce dernier. Appliquez ces correctifs de façon sélective, car l'application de toutes les mises à jour disponibles risque d'installer de nouvelles fonctionnalités et même de nouvelles versions du SE avec lesquelles ACSLS et ACSLS HA n'ont pas été testés.

• Désactivez telnet et rlogin. A leur place, utilisez ssh. Désactivez également ftp et utilisez à sa place sftp.

  Désactivez les services telnet, rlogin et ftp en émettant les commandes suivantes en tant qu'utilisateur root.

  Pour voir tous les services :

  svcs

  Pour désactiver telnet, rlogin et ftp :

  svcadm disable telnet

  svcadm disable rlogin

  svcadm disable ftp

• Ne désactivez pas ssh. Il est préférable que les utilisateurs se connectent à distance à ACSLS à l'aide de ssh et non à l'aide de telnet ou rlogin. Ne désactivez pas non plus sftp.

• ACSLS nécessite rpc-bind. Ne le désactivez pas.

  Si Solaris est installé avec l'option Secure by Default (sécurisé par défaut), vous devez modifier une propriété de configuration réseau pour rpc-bind pour permettre aux clients ACSAPI d'envoyer des demandes à ACSLS.

  Pour plus d'informations, reportez-vous à la section décrivant l'installation de Solaris dans le chapitre traitant de l'installation d'ACSLS sur Solaris dans le manuel d'installation d'ACSLS.

• Certains ports Ethernet sur le serveur ACSLS doivent être ouverts pour permettre la communication avec ACSLS. Les applications clientes utilisent des ports Ethernet spécifiques pour communiquer avec ACSLS, et ACSLS communique avec des ports spécifiques sur les bibliothèques de bandes. Reportez-vous à la section Ports Ethernet utilisés pour la communication d'ACSLS pour connaître les ports qui doivent être disponibles pour la communication d'ACSLS. Sur le serveur ACSLS, assurez-vous qu'ipfilter est configuré de manière à permettre au trafic d'accéder aux ports utilisés par ACSLS.

Déterminez votre stratégie d'audit Solaris. Reportez-vous à la section "Audit dans Oracle Solaris" du manuel "Administration d'Oracle Solaris : Services de sécurité" pour savoir quels événements soumettre à un audit, où enregistrer les journaux d'audit et comme passer en revue les journaux d'audit.

Installation et configuration de Linux

Suggestions pour l'installation et la configuration sécurisées de Linux :

• Appliquez tous les correctifs de sécurité importants au système d'exploitation et aux services installés avec ce dernier. Appliquez ces correctifs de façon sélective, car l'application de toutes les mises à jour disponibles risque d'installer de nouvelles fonctionnalités et même de nouvelles versions du SE avec lesquelles ACSLS et ACSLS HA n'ont pas été testés.

• Assurez-vous que telnet et rlogin ne sont pas installés ou qu'ils sont désactivés. A leur place, utilisez ssh.

  Assurez-vous également que ftp n'est pas installé ou qu'il est désactivé. A sa place, utilisez sftp.

  Pour voir tous les services, connectez-vous en tant qu'utilisateur root et :

  service –-status-all

• Pour supprimer des services de manière permanente, utilisez :

  svccfg delete -f service-name

• Ne désactivez pas ssh. Il est préférable que les utilisateurs se connectent à distance à ACSLS à l'aide de ssh et non à l'aide de telnet ou rlogin. Ne désactivez pas non plus sftp.

• Les services réseau, plus précisément rpcbind, doivent être activés pour permettre la communication client ACSLS.

  Sous Linux, lancez rpc avec l'indicateur –i.

• Certains ports Ethernet sur le serveur ACSLS doivent être ouverts pour permettre la communication avec ACSLS. Les applications clientes utilisent des ports Ethernet spécifiques pour communiquer avec ACSLS, et ACSLS communique avec des ports spécifiques sur les bibliothèques de bandes. Reportez-vous à la section Ports Ethernet utilisés pour la communication d'ACSLS pour connaître les ports qui doivent être disponibles pour la communication d'ACSLS. Sur le serveur ACSLS, assurez-vous que iptables est configuré de manière à permettre au trafic d'accéder aux ports utilisés par ACSLS.

Audit de la sécurité de Linux

Déterminez vos stratégies d'audit pour Linux. Reportez-vous à la section relative à la configuration et à l'utilisation de l'audit du guide de sécurité de la version 6 d'Oracle Linux pour savoir quels événements soumettre à un audit, où enregistrer les journaux d'audit et comme passer en revue les journaux d'audit.

Les journaux système et commandes suivants peuvent être utiles pour examiner la sécurité de Linux :

• Affichez var/log/secure en tant que root pour voir l'historique des tentatives de connexion et les messages d'accès.

• La commande 'last | more' fournit un historique des utilisateurs connectés.

• Le journal /var/log/audit/audit.log.[0-9] consigne les tentatives d'accès qui ont été rejetées par SE Linux. Vous devez être un utilisateur root pour les voir.

Sécurité SELinux

ACSLS 8.4 est conçu pour fonctionner dans des environnements équipés du module optionnel Security Enhanced Linux. SELinux fournit un contrôle d'accès aux fichiers, aux répertoires et aux autres ressources système qui dépasse le niveau de protection standard des environnements Unix. Outre l'accès par autorisation propriétaire-groupe-public, SELinux inclut un contrôle d'accès basé sur les rôles des utilisateurs, les domaines et les contextes. L'agent qui applique le contrôle d'accès à toutes les ressources système est le noyau Linux.

L'utilisateur root sur un système Linux peut activer ou désactiver l'application à l'aide de la commande setenforce.

setenforce [Enforcing | Permissive | 1 | 0 ]

Utilisez Enforcing ou 1 pour placer SELinux en mode "Appliqué" (Enforcing). Utilisez Permissive ou 0 pour placer SELinux en mode "Permissif" (Permissive).

Servez-vous de la commande getenforce pour voir le statut d'application actuel du système.

Trois modules de stratégie SELinux sont chargés dans le noyau lorsque vous installez ACSLS : allowPostgr, acsdb et acsdb1. Ces modules fournissent les définitions et les exceptions à l'application nécessaires pour permettre à ACSLS d'accéder à sa propre base de données et aux autres ressources système lorsque l'application de SELinux est active. Une fois ces modules installés, vous pouvez effectuer toutes les opérations ACSLS normales, y compris des opérations sur la base de données telles que bdb.acsss, rdb.acsss, db_export.sh et db_import.sh, sans avoir à désactiver l'application de SELinux.

Pour plus d'informations, reportez-vous à la section relative à SELinux dans l'annexe traitant du Dépannage dans le guide de l'administrateur de StorageTek ACSLS 8.4.

Installation et configuration d'ACSLS

Cette section explique comment installer ACSLS de manière sécurisée.

Installation standard d'ACSLS

En effectuant une installation standard d'ACSLS, vous êtes certain de disposer de tous les composants nécessaires.

Si vous migrez d'une version d'ACSLS vers une version supérieure du logiciel, passez en revue le paramétrage des variables dynamiques et statiques afin de décider si vous souhaitez opter pour des options plus sécurisées, en particulier en ce qui concerne l'option Firewall Secure Option.

Utilisation de mots de passe fiables pour les ID utilisateur ACSLS

ACSLS nécessite les ID utilisateurs ACSLS : acsss, acssa et acsdb. Choisissez des mots de passe fiables et modifiez-les régulièrement.

Limitation de l'accès aux fichiers d'ACSLS

En règle générale, ACSLS limite l'accès à ses fichiers au groupe acsls, qui inclut les ID utilisateur acsss, acssa, acsdb et root. Certains fichiers de la base de données et de diagnostic sont seulement accessibles par un ID utilisateur acsls unique. ACSLS fonctionne avec un paramètre umask de 027.

Il n'est pas recommandé de rendre les fichiers ACSLS lisibles ou inscriptibles par tous. Cependant, la définition de paramètres d'accès plus restrictifs que les paramètres par défaut peut entraîner l'échec de fonctions d'ACSLS.

Définition de "root" en tant qu'ID utilisateur effectif pour trois fichiers ACSLS

Le script d'installation recommande aux clients de définir l'id utilisateur effectif 'root' (setuid) dans trois fichiers exécutables dans le système de fichiers /export/home/ACSSS :

• acsss  (Ce fichier binaire doit être exécuté avec des privilèges 'root' parce qu'il sert à démarrer et arrêter les services système requis par l'application ACSLS.)

• db_command  (Ce fichier binaire démarre et arrête le moteur de base de données PostgreSQL qui contrôle et gère la base de données ACSLS.)

• get_diags  (Ce fichier binaire est appelé par un client pour rassembler des informations de diagnostic système complètes qui peuvent être demandées lors d'une conversation téléphonique avec le service d'assistance.)

Lors de l'installation d'ACSLS avec pkgadd, la question suivante s'affiche : Do you want to install these as setuid/setgid files? En répondant y, vous permettez aux utilisateurs du groupe acsls d'exécuter ces trois commandes, même si les utilitaires effectuent certaines opérations système nécessitant des privilèges root.

Vérification des paramètres des variables statiques et dynamiques d'ACSLS

Les variables statiques et dynamiques d'ACSLS contrôlent le comportement de nombreuses fonctions d'ACSLS. Définissez ces variables à l'aide de l'utilitaire acsss_config. Ce document décrit le paramétrage sécurisé d'un grand nombre de ces variables. Si vous répondez par un point d'interrogation (?) après avoir affiché les options d'une variable à l'aide de acsss_config, des explications détaillées relatives à la variable s'affichent. Ces informations sont également disponibles dans le chapitre relatif à la configuration des variables contrôlant le comportement d'ACSLS du guide de l'administrateur d'ACSLS.

Configuration de WebLogic

A partir de la version 8.1, ACSLS utilise WebLogic en tant que serveur Web. WebLogic est installé en même temps qu'ACSLS.

Reportez-vous à Oracle Fusion Middleware; Understanding Security for Oracle WebLogic Server 11g Release 1 (10.3.6) pour connaître les options permettant de sécuriser un serveur WebLogic ainsi que les possibilités de pistes d'audit avec WebLogic.

Recours à l'utilitaire userAdmin.sh d'ACSLS pour créer et gérer les utilisateurs de l'interface graphique d'ACSLS

L'utilitaire userAdmin.sh piloté par menus permet d'administrer les mots de passe des utilisateurs de l'interface graphique d'ACSLS. Vous pouvez ajouter, supprimer et lister les utilisateurs ainsi que modifier les mots de passe des utilisateurs. WebLogic doit être en cours d'exécution pour permettre l'accès à l'utilitaire. Si WebLogic n'est pas en cours d'exécution, l'utilitaire démarre l'application et attend son arrivée en ligne avant d'afficher le menu.

L'utilitaire userAdmin.sh doit être exécuté par l'utilisateur root et nécessite une authentification acsls_admin. Le compte utilisateur acsls_admin est configuré pendant l'installation d'ACSLS.

Utilisation de l'interface graphique d'ACSLS

Pour utiliser l'interface graphique d'ACSLS, vous devez installer la dernière version de JRE et accéder à l'interface graphique via un navigateur.

Installation de la dernière version de JRE sur les systèmes client de l'interface graphique

Assurez-vous que la dernière version de l'environnement d'exécution Java (JRE) est installée sur les systèmes qui utiliseront l'interface graphique d'ACSLS pour accéder à ACSLS.

Accès à l'interface graphique d'ACSLS

Ouvrez votre navigateur et saisissez une URL contenant l'adresse du nom d'hôte du serveur ou l'adresse IP au format suivant :

https://myAcslsHostName.myDomainName:7002/SlimGUI/faces/Slim.jsp ou https://127.99.99.99:7002/SlimGUI/faces/Slim.jsp

Il est recommandé d'utiliser un nom d'hôte complet ou l'adresse IP de la machine hôte. Certaines pages, notamment les pages d'aide d'ACSLS, ne s'affichent pas correctement si l'URL ne peut pas être complètement résolue par WebLogic.

Si vous utilisez http sur le port 7001, WebLogic vous redirige automatiquement sur https sur le port 7002.

Etant donné que WebLogic utilise le protocole sécurisé https, il est possible que votre navigateur vous informe que le certificat de sécurité du site n'a pas été enregistré et qu'il n'est donc pas sécurisé. Si vous êtes certain que l'URL correspond à votre machine ACSLS locale, vous pouvez continuer sans risque. L'écran de connexion doit ensuite s'afficher.

Utilisation de l'interface graphique d'ACSLS

Pour accéder à AcslsDomain dans WebLogic, utilisez le protocole sécurisé https. Ce protocole utilise une communication chiffrée entre le navigateur et le serveur à l'aide de clés privées et de certificats numériques. Voici les options permettant d'obtenir un certificat numérique :

Certificat de démonstration ACSLS

ACSLS est livré avec un certificat appelé "certificat de démonstration". Il fournit un niveau minimal de sécurité par cryptage, qui permet aux utilisateurs de commencer à utiliser l'interface graphique d'ACSLS sans avoir recours à des étapes de configuration supplémentaires. Lorsque l'interaction client avec la bibliothèque ACSLS a entièrement lieu au sein d'un intranet sécurisé, cette méthode de certification de démonstration est généralement suffisante. Toutefois, cette méthode utilise une clé de cryptage 512 bits qui n'est pas prise en charge sur certains navigateurs, notamment Internet Explorer et FireFox version 39 et suivantes.

Configuration d'un certificat numérique autosigné

Le guide d'installation d'ACSLS fournit aux administrateurs d'ACSLS une méthode détaillée permettant de configurer un certificat numérique autosigné d'une longueur de 2 048 bits. Dans la section intitulée "Configuration d'une clé de cryptage SSL", cette méthode fournit un certificat pris en charge sur tous les navigateurs. Il est conseillé aux utilisateurs qui accèdent à un site https avec un certificat autosigné de ne pas poursuivre sur le site s'ils ne sont pas sûrs que la ressource Web est un site sécurisé. En ce qui concerne les utilisateurs d'ACSLS et le serveur de contrôle de bibliothèque, ce niveau de sécurisation est généralement bien compris et dans la plupart des cas, il n'est pas nécessaire que le site prouve son intégrité à l'aide d'une vérification de signature tierce.

Certificats numériques signés par une autorité de signature tierce

Il appartient à chaque site client de déterminer s'il doit fournir une authentification de certificat émise par une autorité de signature tierce telle que Verisign ou Entrust.net. La procédure de génération d'un certificat numérique signé de ce type est décrite dans le document en ligne d'Oracle, Configuring Identity and Trust on :

http://docs.oracle.com/cd/E13222_01/wls/docs92/secmanage/identity_trust.html

Installation d'ACSLS HA

Si vous utilisez la solution haute disponibilité d'ACSLS, suivez les instructions de la documentation détaillant l'installation, la configuration et les opérations du cluster ACSLS-HA.