Les sections suivantes fournissent des conseils pour sécuriser vos locataires Netskope Cloud Exchange.
Durcissement de l'hôte
Cloud Exchange fonctionne avec Docker sur un hôte Linux. Toutes les meilleures pratiques doivent être appliquées pour renforcer l'hôte sous-jacent à l'aide des critères CIS L1 pour Ubuntu ou Red Hat Enterprise Linux. Pour visionner une vidéo sur l'installation de l'AH, cliquez sur "play".
Gestionnaire des secrets
Une fois configuré, vous pouvez configurer les locataires Netskope, les dépôts de plugins personnalisés et les plugins à l'aide de secrets provenant de votre gestionnaire de secrets configuré.
Connectivité à l'échelle du système
La plateforme Cloud Exchange a besoin d'un accès à GitHub, Docker Hub, Netskope tenant, les plateformes des partenaires et d'autres plateformes tierces avec lesquelles vous souhaitez vous intégrer. Évaluez les configurations du réseau telles que la configuration du proxy HTTP, les règles du pare-feu, etc. pour vous assurer que la connectivité est disponible. La pile Cloud Exchange a besoin d'être connectée à ces URL publiques.
Pour récupérer des plugins tiers : https://github.com
Pour récupérer les alertes et les événements du locataire Netskope : https://*.<tenant-domain>
Pour récupérer des transactions web à partir de Netskope Log Streaming, reportez-vous à ces guides :
Pour envoyer des analyses au service AWS de Netskope : https://reporting.netskope.tech
Pour extraire des images Docker de Docker Hub (la connectivité à des hôtes supplémentaires peut être nécessaire car les images Docker seront derrière un CDN) :
-
- https://hub.docker.com
-
- https://auth.docker.io
-
- https://registry-1.docker.io
-
- https://index.docker.io/
-
- https://dseasb33srnrn.cloudfront.net/
-
- https://production.cloudflare.docker.com/
Si vous êtes derrière un serveur proxy HTTP ou HTTPS, par exemple dans le cadre d'une entreprise, vous devez ajouter la configuration du proxy dans le fichier de service Docker systemd. Se référer à https://docs.docker.com/config/daemon/systemd/#httphttps-proxy pour plus de détails.
Règles de pare-feu/proxy
Plages IP de Netskope
Si vous avez activé l’accès conditionnel avec des fournisseurs ou des applications SaaS pour les solutions Netskope, ou si vous devez utiliser une liste SSL par IP au lieu de domaines, voici la liste consolidée des adresses IP de Netskope (pour l’accès locataire depuis Cloud Exchange au cas où votre pare-feu ne prendrait pas en charge les règles basées sur FQDN). Abonnez-vous à ce lien en cliquant sur l’icône Suivre sur cette page : https://support.netskope.com/s/article/NewEdge-Point-of-Presence-Data-Plane-and-Management-Plane-Global-Edge-Expansion-Status-and-IP-Range.
Cloud Exchange Ports
| Port | Configurable ? | Description |
|---|---|---|
| 443/80 | Oui, pendant le script d'installation. | Utilisé pour accéder à l'interface utilisateur du CE. |
| 15672 | No. | Utilisé pour accéder au tableau de bord RabbitMQ. |
| 8000 | No. | Utilisé par le serveur de gestion Cloud Exchange pour obtenir l'utilisation des ressources des machines virtuelles et configurer le proxy et la configuration HA à l'aide de la communication TLS. |
Proxy Cloud Exchange
Cloud Exchange permet de configurer un proxy global qui peut être utilisé de manière sélective pour communiquer avec des ressources externes. Lorsqu'un proxy est disponible, utilisez l'outil de script de configuration de Cloud Exchange (à partir de la version 4.x) pour définir le proxy de manière globale.
Durcissement HA
- In order to establish the necessary connectivity between Docker services across various machines and facilitate the integration of nodes into the cluster, we have exposed the ports listed below from the Docker services. It is imperative that these ports remain accessible from all machines where the Cloud Exchange HA deployment is intended. To enhance security measures, it is also advisable to restrict access to these ports from other IP addresses.
These ports will be used for the clustering of the MongoDB and RabbitMQ services. Also the UI ports are required to perform a health check from all the machines.
Port
Configurable ?
Description
443/80
Oui, pendant le script d'installation.
Utilisé pour accéder à l'interface utilisateur du CE.
4369
Non
Un service de découverte de pairs utilisé par les nœuds RabbitMQ et les outils CLI.
5672
Non
Utilisé par les clients AMQP 0-9-1 et AMQP 1.0 sans TLS.
15672
Non
Clients API HTTP, interface de gestion et rabbitmqadmin sans TLS.
25672
Non
Utilisé pour la communication entre les nœuds et les outils CLI.
35672
Non
Utilisé pour la communication entre les nœuds et les outils CLI.
27017
Non
Le port par défaut pour les instances mongodb et mongos.
5761
Non
Utilisé par les clients AMQP 0-9-1 et AMQP 1.0 sans TLS.
15671
Non
Clients API HTTP, interface de gestion et rabbitmqadmin sans TLS
24007-24029
Non
Ports Glusterfs utilisés pour la communication entre les nœuds, les contrôles de santé, les démonstrations d'auto-réparation, la communication entre les briques.
8000
Non
Utilisé par le serveur de gestion Cloud Exchange pour obtenir l'utilisation des ressources des machines virtuelles et configurer le proxy et la configuration HA à l'aide de la communication TLS.
- L'installation et la configuration de GlusterFS se feront par l'intermédiaire de l'interface utilisateur et du serveur de gestion de Cloud Exchange, qui servira de stockage partagé et aura également des capacités HA. Toutes les machines virtuelles impliquées dans le cluster HA doivent être connectées à la base de données GlusterFS lors de la configuration HA.
Cloud Exchange comme durcissement de la VM
L'utilisateur par défaut est cteadmin ; cteadmin a tous les privilèges sudo et peut exécuter n'importe quelle commande en tant que root après avoir fourni le mot de passe.
OVA
- Il n'est pas nécessaire de disposer d'une connectivité docker ou github pour configurer obligatoirement le Cloud Exchange.
- Le mot de passe de maintenance ne sera pas visible dans .env une fois qu'il a été défini lors de la configuration de Cloud Exchange.
- L'utilisateur cteadmin par défaut ne peut exécuter qu'un ensemble prédéfini de commandes avec les privilèges sudo.
- L'utilisateur cteadmin peut exécuter des commandes sudo après avoir fourni le mot de passe cteadmin.
AMI
Il n'est pas nécessaire de disposer d'une connectivité docker ou github pour configurer obligatoirement le Cloud Exchange.
Azure
Il n'est pas nécessaire de disposer d'une connectivité docker ou github pour configurer obligatoirement le Cloud Exchange.
Limitation du taux de l'API CE (de l'interface utilisateur au backend)
- Cloud Exchange est limité à 100 demandes d'API par seconde.
- Cette limite de débit ne s'applique qu'aux communications entre Cloud Exchange UI et Backend.
Utilisateurs de Cloud Exchange
| Default Username | Mot de passe par défaut | Configurable ? | Description |
|---|---|---|---|
| admin | admin | Oui, il peut être modifié lors de la première connexion. | Utilisé pour accéder à l'interface utilisateur de Cloud Exchange. |
| user | – | Oui, via le mot de passe de maintenance lors de la configuration. | Utilisé pour accéder au tableau de bord RabbitMQ. |
| cteadmin | – | Oui, via le mot de passe de maintenance lors de la configuration. | Utilisé pour accéder à la base de données Mongo. |
Mécanisme de verrouillage de l'utilisateur
- Les utilisateurs peuvent effectuer jusqu'à 5 tentatives de connexion.
- Si un utilisateur ne parvient pas à se connecter au cours de ces 5 tentatives, son compte sera verrouillé pendant 2 minutes.
- À chaque série successive de 5 tentatives, la durée de verrouillage augmente progressivement.
- Pour la deuxième série de 5 tentatives de connexion infructueuses, soit 10 tentatives infructueuses, la durée du verrouillage sera de 5 minutes.
- Après trois séries de 5 tentatives de connexion infructueuses, soit 15 tentatives infructueuses, l'utilisateur se verra imposer une période de verrouillage plus longue, de 6 heures.
- Pour chaque série de 5 tentatives consécutives, jusqu'à ce que l'utilisateur réussisse à se connecter, la période de verrouillage sera de 6 heures.
- Une fois que l'utilisateur s'est connecté avec succès, le cycle se poursuit.
Politique stricte en matière de mot de passe pour l'utilisateur de Cloud Exchange
- Le mot de passe doit contenir au moins une lettre minuscule
- Le mot de passe doit contenir au moins une lettre majuscule.
- Le mot de passe doit contenir au moins un caractère spécial (par exemple #, @,)
- Le mot de passe doit contenir au moins un caractère numérique
- Le mot de passe doit comporter au moins 8 caractères
- Le mot de passe est composé de 72 caractères au maximum
Support IdP
Cloud Exchange prend en charge l'intégration avec les fournisseurs d'identité via SSO, bien que les utilisateurs puissent également être créés localement sur la boîte par l'option admin qui est connecté localement. Il n'y aura qu'un seul root admin. Le SSO doit être la principale méthode de connexion à l'EC et, lorsqu'il est disponible, il doit s'appuyer sur l'authentification multifactorielle. Il ne devrait pas y avoir d'autre local si possible, les utilisateurs sont définis.
Seuls les utilisateurs qui ont besoin de jetons doivent se voir attribuer des rôles qui incluent la création de jetons. Les rôles et les utilisateurs peuvent être configurés pour avoir un accès en lecture seule. Utilisez l'accès le moins privilégié pour créer des rôles avec un accès en lecture seule lorsque cela est possible pour la plupart des utilisateurs.
Gestion des mots de passe
Il n'existe actuellement aucun mécanisme permettant d'imposer des mots de passe complexes ou l'expiration des mots de passe dans Cloud Exchange. Là encore, le SSO est censé gérer ces exigences avancées en matière d'identité. Les informations d'identification du compte doivent avoir une date d'expiration et les utilisateurs doivent être invités à réinitialiser leur mot de passe SSO périodiquement.
L'administrateur d' origine doit modifier son mot de passe par défaut lors de la première session. Si d'autres utilisateurs doivent être définis localement, l'administrateur doit modifier périodiquement leurs mots de passe via l'interface graphique, bien que les utilisateurs puissent également être invités à modifier leurs mots de passe manuellement dans leurs propres sessions via le paramètre Settings > Account > Change Password.
Gestion des données d'identification
Les privilèges suivants sont requis avec le jeton v2 :
- Lecture + écriture /api/v2/policy/urllist
- Lecture + écriture /api/v2/policy/urllist/deploy
- Lecture + écriture /api/v2/policy/urllist/file
- Lecture + écriture /api/v2/incidents/uba/getuci
- Lecture + écriture /api/v2/ubadatasvc/user/uci
- Lire /api/v2/events/dataexport/events/alert
- Lire /api/v2/events/dataexport/events/application
- Lire /api/v2/events/dataexport/events/audit
- Lire /api/v2/events/dataexport/events/connection
- Lire /api/v2/events/dataexport/events/incident
- Lire /api/v2/events/dataexport/events/infrastructure
- Lire /api/v2/events/dataexport/events/network
- Lire /api/v2/events/dataexport/events/page
- Lire /api/v2/events/dataexport/alerts/compromisedcredential
- Lire /api/v2/events/dataexport/alerts/ctep
- Lire /api/v2/events/dataexport/alerts/DLP (Prévention des pertes de données)
- Lire /api/v2/events/dataexport/alerts/malsite
- Lire /api/v2/events/dataexport/alerts/malware
- Lire /api/v2/events/dataexport/alerts/policy
- Lire /api/v2/events/dataexport/alerts/quarantine
- Lire /api/v2/events/dataexport/alerts/securityassessment
- Lire /api/v2/events/dataexport/alerts/uba
- Lire /api/v2/events/dataexport/alerts/watchlist
- Lire /api/v2/events/dataexport/alerts/device
- Lire /api/v2/events/dataexport/alerts/content
Cryptage des journaux
Les logs gérés par Log Shipper ne sont pas persistés dans Cloud Exchange pendant les opérations normales. Les journaux sont récupérés et transmis par communication TLS.
Dans le cas où RabbitMQ envoie les messages sur le disque, les messages du journal sont stockés momentanément sur le disque.
Table of Acronyms
| Acronym | Description |
|---|---|
| AD | Active Directory |
| API | Interface de programmation d'applications |
| ARE | Bourse des risques de l'application |
| CE | Cloud Exchange |
| CLS | Cloud Log Shipper |
| CTE | Cloud Threat Exchange |
| CTO | Cloud Ticket Orchestrator |
| CIS | Norme de référence CIS |
| DLP (Prévention des pertes de données) | Prévention des fuites de données |
| IdP | Fournisseur d'identité |
| SSL | Secure Socket Layer |
| SSO | Signature unique |
| TLS | Sécurité de la couche transport |
| UI | Interface utilisateur |
| URE | Échange de risques entre utilisateurs |