On s'en doute, le FRCA présente
quelques limitations dont voici la liste
ci-après. Les limitations ont toutes une
même cause: FRCA est une tâche SLIC
fonctionnant au-dessous du MI et, par
conséquent, ne peut pas bénéficier de
certaines des SPI (System API) fournies
dans l'OS/400.
pas en charge
SSL/TLS (Secure Sockets Layer/Transport
Layer Security) ; par conséquent,
on ne peut pas valider le
cache FRCA pour les sessions ou les
ports qui utilisent SSL/TLS. La raison
en est que les applications au-dessus
du MI écrivent dans l’API Sockets,
qui est actuellement indisponible
pour FRCA. Vous pouvez configurer
FRCA pour utiliser un port non sécurisé
tel que le port 80, par exemple,
même dans le même serveur HTTP
qui est aussi à l’écoute sur un port
crypté SSL de 443. (A noter que vous
ne pouvez pas utiliser FRCA avec des
pages sécurisées.)
En raison de ces limitations,
on appliquera la règle
de base suivante pour FRCA :
on l’utilisera pour aider à servir
les portions publiques de
votre application Web, par
exemple, votre page d’accueil publique et tous les fichiers d’images
.gif et .jpg. Si et quand le client entre
une portion de votre application Web
sécurisée avec Basic Authentication ou
SSL/TLS, vous devez désactiver FRCA.
L'évolution du paysage des menaces et les conséquences sur votre infrastructure, vos outils de contrôles de sécurité IT existants. EPP, XDR, EDR, IA, découvrez la synthèse des conseils et recommandations à appliquer dans votre organisation.
