Overview
Netskope DSPM (également connu sous le nom de Netskope One DSPM) est déployé sous forme d’application SaaS et exploite Amazon Web Services (AWS) pour offrir une échelle et une sécurité optimales à nos clients.
Application & Architecture Sidecar
Le DSPM Netskope utilise une architecture de collection flexible. Il s'agit d'un ou plusieurs side-cars qui se connectent à vos magasins de données pour collecter des échantillons de données et d'un service DLP (Prévention des pertes de données) qui classe les données collectées. Les deux modèles appliquent le même principe de confidentialité des données : seuls les résultats de classification, jamais les données sensibles elles-mêmes, quittent votre réseau.
Netskope DSPM prend en charge deux modèles de déploiement pour la classification des données sur site :
- Single Appliance (Standard): Regroupe à la fois les services DLP (Prévention des pertes de données) et side-car dans une seule machine virtuelle. Il s'agit de la méthode recommandée pour la plupart des clients, car elle simplifie le déploiement grâce à une seule image, une seule commande CLI et une seule clé de licence. Pour en savoir plus : Déployer l’appliance unique DSPM.
- Distributed Deployment (Advanced): Déploie séparément l’appareil DLP (Prévention des pertes de données) et les side-cars. Ce modèle est conçu pour des scénarios de balayage à grande échelle nécessitant une mise à l’échelle indépendante des ressources DLP (Prévention des pertes de données) et sidecar. Pour en savoir plus : déployez l’appliance DLP (Prévention des pertes de données) pour DSPM.
Connectivité des appliances DLP (Prévention des pertes de données) (déploiement distribué)
Dans le modèle de déploiement distribué, les side-cars fonctionnent en conjonction avec une appliance DLP (Prévention des pertes de données) déployée séparément pour classer vos données. Dans le modèle à appliance unique, ces composants s'exécutent sur la même machine virtuelle et communiquent localement.
L’architecture applique les règles suivantes :
- Network location: L’appliance DLP (Prévention des pertes de données) doit résider dans le même réseau que les sidecars qu’il dessert.
- Communication: Le sidecar envoie les données samples à l’appliance DLP (Prévention des pertes de données) pour classification via HTTPS (port 443).
- Privacy: Le sidecar télécharge uniquement les résultats de classification dans l’application Netskope DSPM. Le système ne stocke jamais les échantillons de données réels utilisés pour l’analyse.
- Appliance linking: Vous devez relier chaque pool de side-car en DSPM à un appareil DLP (Prévention des pertes de données). Un seul appareil DLP (Prévention des pertes de données) peut servir plusieurs sidecars, tant que vous enregistrez leurs pools de sidecars à la même adresse d’appareil.
- Scaling limitation: Vous ne pouvez pas faire tourner plusieurs appliances DLP (Prévention des pertes de données) derrière un équilibreur de charge pour l’échelle horizontale.
Déploiement et scalabilité du sidecar
Dans le modèle Single Appliance, le sidecar est intégré et ne nécessite pas de déploiement séparé. Dans le modèle distribué, vous déployez les sidecars séparément et pouvez être mis à l’échelle horizontale en ajoutant plus d’instances.
Un seul sidecar scanne efficacement plusieurs archives de données dans son environnement installé. En général, on déploie un sidecar par réseau isolé (par exemple, VNet, VPC). L’application Netskope DSPM balance automatiquement les analyses de charge sur tous les sidecars en bonne santé de chaque pool de side-parks.
- Recommended environment: Kubernetes (grâce à son support pour la surveillance de la santé et l’auto-scalabilité).
- Alternative environment: Si Kubernetes n’est pas disponible, vous pouvez déployer des sidecars dans n’importe quel environnement compatible Docker.
Typical Resource Requirements (per sidecar):
- CPU: 4 CPU
- RAM: 16 GB
- Disk Space: 100 GB
- Capacity: Chaque sidecar disposant des ressources ci-dessus peut supporter des scans quotidiens pour 50-100 medium-sized data stores (environ 1 million d’objets).
Pour plus de détails sur la création et la gestion des pools de sidecars, voir Aperçu de l’administration des sidecars DSPM.
Le diagramme suivant illustre une architecture distribuée typique. Les déploiements sur réseaux privés ou environnements cloud (tels qu’AWS, GCP ou Azure) suivent une structure comparable utilisant leurs services conteneurs respectifs :
Mise en réseau & Échantillonnage
Les clients se connectent à l'application DSPM de Netskope via un navigateur web en utilisant un nom d'hôte spécifique au locataire. Nous utilisons un équilibreur de charge d'application (ALB) pour décharger le SSL et acheminer les demandes vers le serveur. Cet ALB est la seule entrée publique de notre environnement SaaS.
Votre locataire Netskope DSPM spécifique au client peut initier des connexions à l'internet pour les besoins suivants :
- Connexion aux magasins de données configurés dans l’application Netskope DSPM (ces connexions proviennent d’une liste d’adresses IP statiques, que vous pouvez utiliser comme liste de permis)
- Envoi d’alertes déclenchées par les politiques DSPM de Netskope à des destinations telles que AWS SNS, Google Pub/Sub, webhooks génériques ou votre serveur de messagerie préféré
- Importation de données spécifiques d’employés depuis un annuaire externe, tel que l’annuaire universel Okta
Nous prenons des mesures supplémentaires pour garantir la sécurité de vos données par never storing the data samples used during our analysis. Cela garantit que vos données restent toujours sécurisées et privées.
Exigences de pare-feu et de sortie
Les déploiements DSPM nécessitent des configurations d’évacuation et de port. Les exigences spécifiques dépendent de votre modèle de déploiement :
- Single Appliance: Les trois ensembles de configurations (applicationDSPM , sidecar et service DLP (Prévention des pertes de données)) s’appliquent au même hôte.
- Distributed Deployment: Chaque composant (DSPM application, sidecar et appareil DLP (Prévention des pertes de données)) nécessite sa propre configuration de sortie distincte.
Pour en savoir plus : Paramètres du pare-feu pour les instances hébergées par DSPM.
Résumé architectural
Cette conception de l'architecture garantit que Netskope DSPM :
- analyse toutes les interactions au sein de votre archive de données, que ce soit via des outils BI, des clients SQL ou des lignes de commande SQL
- ne bloque aucune requête
- ne ralentit pas l’exécution d’aucune requête
- n’écrit pas dans votre mémoire de données
- ne stocke que des métadonnées et ne conserve pas de copies d’échantillons de données sensibles