Compréhension de l'examen de site privé

ASoC propose la fonctionnalité Dynamic Application Security Testing (DAST) depuis un scanner cloud tel que SaaS. Cette capacité exige que le scanner cloud puisse accéder à l'application testée. Il est possible d'examiner sans problème des applications Web disponibles au public. Cependant, l'examen de site privé n'est possible qu'après avoir ajouté des composants réseau (tels que des VPN ou des proxy) ou modifié le réseau pour permettre au scanner d'accéder au serveur hôte de l'application Web.

Création de tunnels PSS

Notre solution pour l'examen de site privé (PSS) n'implique aucune modification spéciale au niveau du réseau du client, ni aucune autre susceptible de présenter un risque pour le réseau. Le client PSS défini dans le réseau du client nécessite uniquement un accès sortant vers Internet (soit directement, soit via un proxy HTTP) et un accès vers le site examiné.

La solution consiste en deux nœuds finaux (serveur et client) qui créent un tunnel TCP/IP initié par le nœud final du côté du client.

Serveur de tunnel

Ce nœud final réside dans le réseau SaaS à côté du scanner. Il est uniquement démarré au démarrage d'un nouvel examen. Le serveur a deux « côtés » qui consistent à écouter les connexions (serveurs dos à dos).

  • Le premier écoute les connexions entrantes provenant du client du tunnel. Il s'agit du côté tunnel.
  • Le second écoute les connexions entrantes provenant du scanner. A cette fin, il imite un proxy HTTP. Il s'agit donc du côté proxy.

Lorsque des connexions provenant du client sont disponibles, le scanner envoie les demandes au côté proxy, qui font ensuite l'objet d'une redirection de port vers les connexions entrantes du côté tunnel. Lorsque le client envoie des réponses, elles sont transférées jusqu'au scanner en passant par le côté proxy.

Client de tunnel

Ce nœud final réside dans le réseau du client et génère les connexions TCP/IP vers le serveur. Il remplit la même fonction que le serveur de tunnel, sauf qu'il se compose de deux ensembles de connexions client (clients dos à dos). Le client de tunnel dispose également de deux « côtés ».

  • Le côté tunnel est un ensemble de connexions initiées vers le serveur de tunnel.
  • Le côté client est l'ensemble de connexions initiées vers le serveur examiné (directement ou via un proxy).

Le client de tunnel réalise la redirection de port.

AppScan Presence

Le tunnel d'examen de site privé repose sur un mécanisme contrôlé par SaaS appelé AppScan Presence : un canal de communication qui reçoit des tâches à réaliser depuis le service cloud, et qui déclenche la réalisation de ces tâches par des gestionnaires. Le service Presence est un service d'interrogation qui interroge constamment le service cloud à propos de tâches à l'aide d'une communication HTTP sécurisée.

Le service AppScan Presence sert uniquement à extraire des tâches du service SaaS, à télécharger les informations requises pour gérer la tâche et à déclencher le gestionnaire. Dans ce cas, la tâche est gérée pour le client de tunnel et les informations extraites sont les données requises pour le démarrage des connexions du client de création de tunnel jusqu'au serveur.

Réalisation d'un examen

Pour réaliser un examen, il est nécessaire de démarrer le client de tunnel et de le connecter à un serveur. Cette tâche est réalisée par la structure AppScan Presence.

La structure AppScan Presence se compose d'un service Presence qui s'exécute sur la machine du tunnel de client. Le service Presence interroge le serveur SaaS Presence, qui s'exécute sur le cloud et qui indique le moment où un examen est prêt à être exécuté. L'échange entre les services se compose des détails de l'examen, y compris de l'adresse IP du serveur de tunnel auquel le client doit se connecter. En outre, il reçoit des informations qui lui permettent d'identifier positivement le serveur auquel il se connecte. Vous trouverez davantage d'informations dans la section Remarques sur la sécurité ci-après.

Dès qu'un utilisateur a demandé un examen privé et a sélectionné une instance Presence par laquelle l'examen doit être réalisé, un agent d'examen est affecté et le serveur de tunnel de cet agent est démarré. Ensuite, une tâche est mise en file d'attente dans le serveur SaaS. Cette tâche est acceptée par le service Presence, qui lance ensuite un client de tunnel contenant les informations de connexion pertinentes.

Remarques sur la sécurité

Deux importants aspects de sécurité sont pris en compte : le réseau du client et la sécurité de la connexion du tunnel.

La solution n'implique aucune modification au niveau du réseau du client. Il est important de noter que l'instance AppScan Presence et le client du tunnel PSS ne nécessitent aucune concession spéciale. Ainsi, le client peut appliquer les règles de sécurité organisationnelle sur la machine hôte qui exécute l'instance AppScan Presence et le client du tunnel PSS. Le pare-feu organisationnel ne nécessite aucune modification (comme l'autorisation des connexions entrantes sur certains ports ou adresses IP).

La seule exigence est la présence d'un accès à Internet pour permettre au service Presence de contacter le service SaaS. La machine doit être en mesure d'accéder au site examiné.

ID Presence

Chaque service Presence dispose d'une clé unique qui lui sert d'ID. Elle sert à identifier l'instance Presence et à lui fournir les tâches d'examen correctes. Il est possible de renouveler la clé à tout moment, pour ainsi se conformer aux règles de sécurité organisationnelle qui exigent des mises à jour périodiques. Dès qu'une clé est renouvelée sur le serveur, l'instance Presence cesse de recevoir des tâches jusqu'à ce que la clé soit physiquement placée sur la machine Presence.

Certification croisée

Il est essentiel que le serveur de tunnel et le client de tunnel puissent compter l'un sur l'autre, afin de prévenir tout accès extérieur au réseau privé depuis un emplacement non validé. Lorsqu'un examen est prêt à être exécuté et que le serveur de tunnel est démarré, il génère deux certificats : l'un pour lui-même et l'autre pour le client. Le certificat du serveur en plus du certificat côté client et de la clé privée sont transmis au client de tunnel avec les détails de la tâche d'examen (via la communication entre le service Presence et le service SaaS). Le serveur et le client de tunnel peuvent ensuite valider l'identité de la connexion à distance.

Les certificats sont invalidés dès que l'examen est terminé et ne sont plus réutilisés, même dans le cas d'un nouvel examen.

Le certificat est conforme aux dernières normes NIST et FIPS qui sont mises à jour occasionnellement (algorithme de chiffrement, algorithme de hachage et longueur de clé).

Protection des données en transit

Les certificats échangés sur le serveur ne sont pas seulement pour l'identification et la validation mutuelles. Les données dans le tunnel même sont cryptées à l'aide de ces certificats. Les données passées à travers ce tunnel sont composées des requêtes et réponses entre le scanner et l'application de test, et sont donc sensibles. Pour protéger les données, ces dernières sont cryptées en transit entre les extrémités du tunnel à l'aide de ces certificats à exécution unique.