Cet article s'adresse aux équipes prévoyant d'utiliser Microsoft SQL Server ou Microsoft Azure SQL comme workspace.
Pour aider à sélectionner l'espace de travail approprié, voici une liste de préoccupations et la liste des espaces de travail pouvant servir dans un tel contexte.
Lors du choix d’un workspace non local, il est important de tenir compte de la sécurité des données à la fois au repos et en transit. Il est fortement recommandé de chiffrer davantage les données à l’aide d’une clé maîtresse pour les solutions basées sur des fichiers ou, pour les workspaces avancés, d’un fournisseur de sécurité, afin de garantir que seules les personnes autorisées peuvent accéder aux données.
Pour bénéficier de fonctionnalités de sécurité avancées comme le chiffrement au repos et en transit, l'accès restreint à la base de données et le chiffrement à connaissance nulle, envisager nos workspaces Team natifs.
| Préoccupation | Microsoft SQL Server | Microsoft Azure SQL |
|---|---|---|
| Base de données inaccessible aux utilisateurs finaux | Note 1Note 2 | Note 1 |
| Comptes Active Directory utilisés pour l'authentification | X | |
| Données stockées localement | X | |
| Journaux d'activité | X | X |
| Données accessibles à l’échelle mondiale | Note 3 | X |
| Cache local optionnel des connexions | X | X |
Les administrateurs peuvent créer des comptes utilisateur final sans partager de mots de passe en important une définition d'espace de travail verrouillée pour chaque utilisateur. Cependant, ce processus implique un effort manuel important de la part de l'administrateur.
La sécurité intégrée est une technologie Microsoft permettant d'accéder à une instance SQL Server sans transmettre d'identifiants, en s'appuyant sur le jeton d'authentification de l'environnement Windows. Cela permet aux utilisateurs de se connecter directement à la base de données à l'aide d'autres outils, mais il ne faut pas l'utiliser si l'on souhaite empêcher l'accès direct à la base de données.
Notre espace de travail SQL Server offre une troisième option d'authentification, Personnalisée (Devolutions), permettant d'emprunter l'identité d'un utilisateur sans révéler les identifiants utilisés pour se connecter à la base de données. Pour plus d'informations, consulter Gestion des utilisateurs.
Exposer une base de données à Internet est possible, mais le chiffrement SSL/TLS est nécessaire pour sécuriser le trafic et atténuer les risques tels que les attaques DDoS. Les services infonuagiques comme Azure en font une priorité. Par défaut, le pare-feu doit bloquer tout le trafic au départ, puis on ajoute des exceptions et règles selon les besoins. Ouvrir seulement les ports essentiels, les ajouter à la liste des exceptions et filtrer les requêtes entrantes selon leur origine.
Cet article s'adresse aux équipes prévoyant d'utiliser Microsoft SQL Server ou Microsoft Azure SQL comme workspace.
Pour aider à sélectionner l'espace de travail approprié, voici une liste de préoccupations et la liste des espaces de travail pouvant servir dans un tel contexte.
Lors du choix d’un workspace non local, il est important de tenir compte de la sécurité des données à la fois au repos et en transit. Il est fortement recommandé de chiffrer davantage les données à l’aide d’une clé maîtresse pour les solutions basées sur des fichiers ou, pour les workspaces avancés, d’un fournisseur de sécurité, afin de garantir que seules les personnes autorisées peuvent accéder aux données.
Pour des fonctionnalités de sécurité améliorées telles que le chiffrement au repos et en transit, le contrôle d'accès restreint à la base de données, et le chiffrement à connaissance nulle, considérer nos espaces de travail Équipe native.
| Préoccupation | Microsoft SQL Server | Microsoft Azure SQL |
|---|---|---|
| Base de données inaccessible aux utilisateurs finaux | Note 1Note 2 | Note 1 |
| Comptes Active Directory utilisés pour l'authentification | X | |
| Données stockées localement | X | |
| Journaux d'activité | X | X |
| Données accessibles à l’échelle mondiale | Note 3 | X |
| Cache local optionnel des connexions | X | X |
Les administrateurs peuvent créer des comptes utilisateur final sans partager de mots de passe en important une définition d'espace de travail verrouillée pour chaque utilisateur. Cependant, ce processus implique un effort manuel important de la part de l'administrateur.
La sécurité intégrée est une technologie Microsoft permettant d'accéder à une instance SQL Server sans transmettre d'identifiants, en s'appuyant sur le jeton d'authentification de l'environnement Windows. Cela permet aux utilisateurs de se connecter directement à la base de données à l'aide d'autres outils, mais il ne faut pas l'utiliser si l'on souhaite empêcher l'accès direct à la base de données.
Notre espace de travail SQL Server offre une troisième option d'authentification, Personnalisée (Devolutions), permettant d'emprunter l'identité d'un utilisateur sans révéler les identifiants utilisés pour se connecter à la base de données. Pour plus d'informations, consulter Gestion des utilisateurs.
Exposer une base de données à Internet est possible, mais le chiffrement SSL/TLS est nécessaire pour sécuriser le trafic et atténuer les risques tels que les attaques DDoS. Les services infonuagiques comme Azure en font une priorité. Par défaut, le pare-feu doit bloquer tout le trafic au départ, puis on ajoute des exceptions et règles selon les besoins. Ouvrir seulement les ports essentiels, les ajouter à la liste des exceptions et filtrer les requêtes entrantes selon leur origine.