Lorsqu'un utilisateur se connecte à un réseau d'entreprise via un client VPN d'entreprise, voici ce que le dispositif VPN enregistre :
L'administrateur de ce réseau privé sait que l'utilisateur a ouvert la porte à 12:15:05, mais, dans la plupart des cas, il n'a aucune visibilité sur ce qu'il a fait ensuite. Une fois à l'intérieur de ce réseau privé, les utilisateurs peuvent accéder aux outils internes, aux données sensibles et aux environnements de production. Pour éviter cela, il faut procéder à une segmentation complexe du réseau et souvent à des modifications des applications côté serveur. La journalisation des actions qu’un individu effectue à l’intérieur de ce réseau est encore plus difficile.
Cloudflare Access n'améliore pas la journalisation du VPN ; il remplace ce modèle. Cloudflare Access sécurise les sites internes en évaluant l’identité et la permission pour chaque requête, et pas seulement la connexion initiale. Au lieu d'un réseau privé, les administrateurs déploient des applications d'entreprise derrière Cloudflare en utilisant notre DNS fiable. Les administrateurs peuvent alors intégrer le SSO de leur équipe et créer des règles spécifiques aux utilisateurs et aux groupes pour contrôler qui peut accéder aux applications derrière la passerelle d'accès.
Lorsqu'une requête est adressée à un site via Access, Cloudflare invite le visiteur à se connecter avec un fournisseur d'identité. Access vérifie ensuite l'identité de cet utilisateur par rapport aux règles configurées et, en cas d’autorisation, autorise la requête à continuer son cheminement. Access effectue ces vérifications pour chaque requête faite par un utilisateur de manière transparente pour l'utilisateur final.
Cependant, depuis que nous avons lancé Access, notre journalisation a ressemblé à la capture d'écran ci-dessus. Nous avons capturé le moment où un utilisateur s'est authentifié pour la première fois dans la passerelle, sans aller plus loin. A partir d'aujourd'hui, nous pouvons donner à votre équipe une vue d'ensemble de chaque requête adressée à chaque application.
Nous sommes heureux d'annoncer que vous pouvez désormais capturer les journaux de chaque requête effectuée par un utilisateur et adressée à une ressource derrière Cloudflare Access. En cas d'urgence, comme dans le cas d'un ordinateur portable volé, vous pouvez désormais auditer chaque URL demandée au cours d’une session. Les journaux sont centralisés en un seul endroit, que vous utilisiez plusieurs fournisseurs de SSO ou que vous sécurisiez plusieurs applications, et la plateforme Logpush de Cloudflare peut les envoyer à votre SIEM pour les conserver et les analyser.
Vérification de chaque connexion
Cloudflare Access apporte les améliorations de vitesse et de sécurité que Cloudflare apporte aux sites publics et applique ces leçons aux applications internes utilisées par votre équipe. Pour la plupart des équipes, il s'agissait d'applications qui existaient traditionnellement derrière un VPN d'entreprise. Une fois qu'un utilisateur avait rejoint ce VPN, il se trouvait à l'intérieur de ce réseau privé, et les administrateurs devaient prendre des mesures supplémentaires pour empêcher les utilisateurs d'atteindre des éléments auxquels ils ne devaient pas avoir accès.
Access renverse ce modèle en supposant qu'aucun utilisateur ne devrait pouvoir atteindre quoi que ce soit par défaut ; en appliquant une solution de confiance zéro aux outils internes utilisés par votre équipe. Avec Access, lorsqu'un utilisateur demande le nom d'hôte de cette application, la requête passe d'abord par Cloudflare. Nous vérifions si l'utilisateur est authentifié et, si ce n'est pas le cas, nous l'envoyons à votre fournisseur d'identité comme Okta ou Azure ActiveDirectory. L'utilisateur est invité à se connecter, et Cloudflare évalue ensuite s'il est autorisé à accéder à l'application demandée. Tout cela se passe à la périphérie de notre réseau avant qu'une requête ne touche votre serveur d’origine, et pour l'utilisateur, cela ressemble au flux SSO transparent auquel il s'est habitué pour les applications SaaS.
Lorsqu'un utilisateur s'authentifie auprès de votre fournisseur d'identité, nous auditons cet événement comme une connexion et le rendons disponible dans notre API. Nous saisissons l'e-mail de l'utilisateur, son adresse IP, l'heure à laquelle il s'est authentifié, la méthode (dans ce cas, un flux Google SSO), et l'application qu'il a pu atteindre.
Ces journaux peuvent vous aider à suivre chaque utilisateur qui s'est connecté à une application interne, y compris les sous-traitants et les partenaires qui peuvent utiliser différents fournisseurs d'identité. Cependant, cette journalisation s'est arrêtée à l'authentification. Access n'a pas enregistré les étapes suivantes d'un utilisateur donné.
Vérification de chaque requête
Cloudflare sécurise à la fois les sites exposés à l'extérieur et les ressources internes en triant chaque requête dans notre réseau avant même de l'envoyer à votre serveur d’origine. Des produits comme notre WAF appliquent des règles pour protéger votre site contre les attaques comme l'injection SQL ou le cross-site scripting. De même, Access identifie qui est derrière chaque requête en évaluant chaque connexion qui transite par la passerelle.
Une fois qu'un membre de votre équipe s'authentifie pour accéder à une ressource derrière Access, nous générons un jeton pour cet utilisateur qui contient son identité SSO. Le jeton est structuré comme JSON Web Token (JWT). La sécurité JWT est une norme ouverte pour la signature et le chiffrement des informations sensibles. Ces jetons fournissent un mécanisme sécurisé et dense en informations qu'Access peut utiliser pour vérifier les utilisateurs individuels. Cloudflare signe le JWT en utilisant une paire de clés publique et privée que nous contrôlons. Nous nous appuyons sur la signature RSA avec SHA-256, ou RS256, un algorithme asymétrique, pour effectuer cette signature. Nous fournissons la clé publique afin que vous puissiez également valider son authenticité.
Lorsqu'un utilisateur demande une URL donnée, Access ajoute l'identité de l'utilisateur de ce jeton comme en-tête de la requête, que nous enregistrons ensuite lorsque la requête passe par notre réseau. Votre équipe peut collecter ces journaux dans votre SIEM tiers ou votre destination de stockage préférés par le biais de la plate-forme Cloudflare Logpush.
Cloudflare Logpush peut être utilisé pour rassembler et envoyer des en-têtes de requêtes spécifiques à partir des requêtes adressées aux sites derrière Access. Une fois activé, vous pouvez ensuite configurer la destination où Cloudflare doit envoyer ces journaux. Une fois activés avec le champ d'identité de l'utilisateur Access, les journaux seront exportés vers vos systèmes en JSON comme les journaux ci-dessous.
{
"ClientIP": "198.51.100.206",
"ClientRequestHost": "jira.widgetcorp.tech",
"ClientRequestMethod": "GET",
"ClientRequestURI": "/secure/Dashboard/jspa",
"ClientRequestUserAgent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.87 Safari/537.36",
"EdgeEndTimestamp": "2019-11-10T09:51:07Z",
"EdgeResponseBytes": 4600,
"EdgeResponseStatus": 200,
"EdgeStartTimestamp": "2019-11-10T09:51:07Z",
"RayID": "5y1250bcjd621y99"
"RequestHeaders":{"cf-access-user":"srhea"},
}
{
"ClientIP": "198.51.100.206",
"ClientRequestHost": "jira.widgetcorp.tech",
"ClientRequestMethod": "GET",
"ClientRequestURI": "/browse/EXP-12",
"ClientRequestUserAgent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.87 Safari/537.36",
"EdgeEndTimestamp": "2019-11-10T09:51:27Z",
"EdgeResponseBytes": 4570,
"EdgeResponseStatus": 200,
"EdgeStartTimestamp": "2019-11-10T09:51:27Z",
"RayID": "yzrCqUhRd6DVz72a"
"RequestHeaders":{"cf-access-user":"srhea"},
}
Dans l'exemple ci-dessus, l'utilisateur a d'abord visité la page d'accueil d'une instance Jira. La requête suivante a été faite à un ticket Jira spécifique, EXP-12, environ une minute après la première requête. Grâce à la journalisation par requête, les administrateurs d'Access peuvent passer en revue chaque requête effectué par un utilisateur une fois authentifié lorsqu’un compte est compromis ou un dispositif volé.
Les journaux sont cohérents dans toutes les applications et pour tous les fournisseurs d'identité. Les mêmes champs standards sont capturés lorsque les entrepreneurs se connectent avec leur instance AzureAD à votre outil de chaîne logistique, de la même manière que lorsque vos utilisateurs internes s'authentifient avec Okta à votre Jira. Vous pouvez également compléter les données ci-dessus avec d'autres détails de la requête comme le chiffrement TLS utilisé et les résultats WAF.
Comment utiliser ces données ?
Les capacités de journalisation en mode natif des applications hébergées varient énormément. Certains outils fournissent des enregistrements plus robustes de l'activité des utilisateurs, mais d'autres nécessiteraient des modifications de code côté serveur ou des solutions de contournement pour ajouter ce niveau de journalisation. Cloudflare Access peut éviter à votre équipe d'avoir à faire ce travail en introduisant la journalisation dans une passerelle unique qui s'applique à toutes les ressources qu’elle protège.
Les journaux d'audit peuvent être exportés vers des outils SIEM tiers ou des buckets S3 pour l'analyse et la détection d'anomalies. Les données peuvent également être utilisées à des fins de contrôle en cas de perte ou de vol d'un appareil de l'entreprise. Les équipes de sécurité peuvent ensuite les utiliser pendant leurs investigations pour recréer les sessions des utilisateurs à partir des journaux.
Quoi de plus ?
Tout client d'entreprise dont le Logpush est activé peut maintenant utiliser cette fonction sans frais supplémentaires. Des instructions sont disponibles ici pour configurer le Logpush et une documentation supplémentaire ici pour activer l'accès aux journaux par requête.