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.
Dans ce rapport, basé sur 25 critères, Forrester Consulting passe au crible les 14 principaux fournisseurs de services de réponse aux incidents de cybersécurité du marché. Cette analyse complète permet aux professionnels de la sécurité et de la gestion des risques d’évaluer et de sélectionner les solutions les plus adaptées à leurs besoins.
