Je travaille actuellement sur une application WinForms .NET qui sera mise à la disposition des utilisateurs finaux. La question est la suivante: comment (meilleur) pour masquer la chaîne de connexion, de sorte que les pirates pirates, après avoir décompilé au programme, n'ont pas accès à ma base de données?
Je pensais créer un utilisateur qui n'utilisera que les procédures sur la base . P>
J'ai recherché dans l'ensemble du forum et a trouvé quelques commentaires sur la ressource, config.app, etc. p>
@PanagioSkanavos Exactement, ciblant la base de données MySQL p>
mais Ne protège pas 100%. P>
Y a-t-il une manière en 2019 qui vous protégera de donner le login et le mot de passe utilisé dans l'application? P>
Connection currently is in my c# code and looks like : string connectionstring = "Server = servername;Port=1111;Database=databasename;Uid=login;Pwd=password;Convert Zero Datetime=True";
4 Réponses :
Y a-t-il quelque titre en 2019 qui vous protégera de donner le Connexion et mot de passe utilisé dans l'application?
Bien sûr qu'il y a. Au lieu d'avoir cette chaîne de connexion dans votre code de supplication, faites-la avoir dans un fichier de configuration comme
web.config ouapp.config . Ensuite, vous pouvez utiliser Azure Key Key Vault ou la variable d'environnement Pour avoir complètement cette chaîne de connexion dans Key Vault et ne disposez que de l'URL de référence Vault Azure Key dans votre fichier de configuration.En savoir plus sur Key Vault HTTPS: // docs.microsoft.com/en-us/azure/key-vault/key-vault-whatie
par un des commentaires, si votre objectif final est de distribuer le
exe ; Ensuite, vous devez également avoir la chaîne de connexion dans le fichier de configuration et doit envisager de crypter et de stocker le crypté dans votre fichier de configuration. En savoir plus sur Configuration protégée https://docs.microsoft.com/en-us/azure/key-vault/key-vault-whatis
@John n'a pas d'importance. Key Vault fonctionne dans les deux cas
Je pense que c'est une application que OP distribue aux utilisateurs finaux, qui a accès à une sorte de base de données partagée. P.s. Je n'ai pas indiqué votre réponse.
@John C'est la manière dont les chaînes de connexion sont protégées depuis 2002. ne les cache pas masquez-les, utilisez l'authentification Windows ou chiffrer de chiffrer sections spécifiques du fichier de configuration. Ces choses sont disponibles depuis 2002. Le stockage des informations d'identification dans une coffre-clé Azure ou Amazon est la seule chose nouvelle
@Panagiotis, mais ce qui empêche une personne qui reçoit ou achète l'application cliente de simplement inverser l'ingénierie, d'accéder à KeyVault, puis d'extraire la chaîne de connexion de là?
@John que quelqu'un est le propriétaire de la base de données aussi. Le gars qui devra payer l'amende GDPR si quelque chose fuit. Si vous vous inquiétez des employés de lire la chaîne de connexion, pourquoi devraient-ils être en mesure de faire quelque chose de plus avec eux que ce qu'ils ne peuvent faire avec l'application? En d'autres termes, n'utilisez pas SA ou SYS en tant qu'utilisateur de l'application, utilisez un compte priviled minimum personnalisé
@John ces choses ne peuvent jamais être protégées et c'est pourquoi il y a des audits de sécurité et d'autres autres choses.
@Rahul c'est mon point. C'est exactement pourquoi la solution correcte pour OP est de ne pas donner à l'application cliente accès direct à la base de données, mais permettez plutôt à l'application cliente de la consommer via une API. Obliger l'application à aller à KeyVault pour obtenir la clé consiste simplement à ajouter plus de pas. N'oubliez pas que le plan actuel de l'OP implique de coder de manière difficile la chaîne de connexion dans l'application, qui suggère une base de données pour de nombreux clients.
Il existe des méthodes de la boîte pour chiffrer votre configuration. ASP.NET 2.0 a introduit une nouvelle fonctionnalité, appelée configuration protégée, qui vous permet de chiffrer des informations sensibles dans un fichier de configuration. Bien que principalement conçu pour ASP.NET, la configuration protégée peut également être utilisée pour chiffrer les sections de fichiers de configuration dans les applications Windows. Pour une description détaillée des capacités de configuration protégées, lisez ces deux articles de MSDN:
Si c'est crypté, il peut être déchiffré et la clé de déchiffrement sera disponible pour l'application, donc également à l'utilisateur final.
@ikkentim s'il vous plaît lire ces liens. Oui, il peut être déchiffré mais uniquement sur le serveur lui-même . C'est pourquoi ce type de cryptage est utilisé dans les applications Web. La clé utilisée est la propre clé de la machine, la même chose utilisée pour protéger vos informations de carte de crédit. En général, il est conseillé d'utiliser Comptes de domaine au lieu de comptes locaux et combinaisons utilisateur / mot de passe dans les applications Web.
@Panagiotis Quel serveur? Nous parlons d'une application client WinForms ici. De lire la question, op n'a aucun serveur autre que son serveur de base de données.
@John serveur de base de données . Et Config Encryption fonctionne pour tout fichier de configuration , pas seulement celles nommées web.config . Cela fonctionne sur n'importe quelle machine, pas seulement ceux qui exécutent un SKU de serveur
@Panagiotis Je ne comprends pas mal compris le cryptage de configuration, mais cela ne semble pas être ce que la question de l'OP est avec. Le problème de OP semble être que les utilisateurs finaux nécessitent des informations d'identification pour la base de données.
Il n'y a aucun moyen de garder votre chaîne de connexion en sécurité si vous intention de la machine cliente d'avoir accès à celui-ci
Peu importe la manière dont vous fournissez la chaîne de connexion au client, toute personne ayant une intention malveillante peut accéder à la mémoire de l'application et récupérer la chaîne de connexion au moment de l'exécution.
La chaîne de connexion n'est pas besoin pour rester en sécurité. Seulement les informations d'identification. Et oui, il existe des moyens de protéger toute la chaîne de connexion.
@PanagioSkanavos encore encore, si les informations d'identification sont chargées dans l'application à un moment donné, toute personne ayant une intention malveillante peut l'intercepter ou la lire à partir de la mémoire de l'application.
Pas vraiment. Vous n'avez pas besoin d'utiliser des informations d'identification lors de l'utilisation, par exemple de l'authentification Windows. Si ce "quelqu'un" a un tel accès à votre machine qu'il / elle peut installer un débogueur , il / elle a déjà accès à tout
@Panagiikanavos Si l'utilisateur devait être autorisé à accéder à Windows Auth (bien que hors de portée depuis cette question concerne MySQL), l'utilisateur aurait accès à la base de données de toute façon et OP ne serait probablement pas inquiet de partager la chaîne de connexion (sauf s'il souhaite pouvoir révoquer l'accès des utilisateurs individuels qui n'est pas vraiment possible avec une seule chaîne de connexion).
Je suggérerais d'utiliser une API pour interagir avec les données de la base de données. En utilisant un jeton qui est remis à l'utilisateur à l'aide du programme.
C'est ce que l'application de l'utilisateur fait déjà. L'ajout d'une "API" ne changera pas le fait que vous toujours besoin d'ajouter ce nom d'utilisateur / mot de passe quelque part. Ajout plus logiciel ne créera que plus les moyens des informations d'identification peuvent fuir
@Panagiotis Je pense que vous avez la mauvaise fin du bâton avec celui-ci. Imagine OP a créé Facebook mais dans une application WinForms. Votre solution consiste à faire entrer l'utilisateur dans les informations d'identification de la base de données Facebook lorsqu'elles ouvrent l'application.
@John ou j'ai peut-être utilisé toutes ces techniques pendant des années
@Panagiotis Vous proposez ensuite que chaque client / utilisateur final dispose d'un compte sur le serveur de base de données lui-même et des rôles sont créés pour ces utilisateurs?
Oui, c'est la même chose qui a été en place depuis de nombreuses années: ne donnez pas de code contenant des informations d'identification secrètes aux utilisateurs finaux. Fin de l'histoire. Si votre application client a besoin de parler à votre base de données, elle devrait le faire via une API que vous contrôlez.
Si vous êtes capable d'utiliser des informations d'identification Windows, vous n'avez pas besoin de stocker un ID utilisateur et un mot de passe. La chaîne de connexion ressemblerait à ceci comme suit: serveur = myserveraddress; base de données = mydatabase; fiducies_connectio n = true;
Y a-t-il un moyen en 2019 de la même manière qui fonctionnait parfaitement toutes ces années. ne pas masque la chaîne de connexion. NE PAS Utilisez un nom d'utilisateur / mot de passe, utilisez l'authentification Windows. chiffrer sections spécifiques, la façon dont les applications ASP.NET font depuis 2002.UID n'est pas utilisé dans SQL Server, cependant, je suppose que vous ciblez une base de données MySQL? S'il vous plaît être spécifique@Panagiotikanavos exactement, ciblant la base de données MySQL
@Adam MySQL peut Utiliser l'authentification Windows TOO . Que fait protège 100% contre les fuites d'identification. Vous n'avez pas expliqué ce que vous voulez vous protéger contre cependant? Pourquoi ne pas créer un compte minimal-privilège pour chaque utilisateur et les avoir entrez les informations d'identification lorsqu'elles démarrent l'application?
La première et la plus importante chose compte tenu de la sécurité est la suivante: "Là est Nul telle que 100% de sécurité". Alors que vous parlez de 0,1%? Vous devez savoir ce que vous voulez éviter.
@Adam En dehors de cela, Windows et .NET ont des mécanismes de protection des données à la machine et au niveau de l'utilisateur. Au lieu de stocker les informations d'identification de la chaîne de connexion, utilisez par exemple ProtectData pour chiffrer et protéger les informations d'identification après la première connexion réussie. Vous pouvez même utiliser le cryptage matériel via la même API à l'aide des pilotes appropriés.
@adam ce que Himbrombeere a dit, 100 fois plus. Qu'est-ce que voulez-vous protéger contre? Différentes techniques protègent contre différentes menaces. Combien coûte-t-il à l'échec aussi? Vous pouvez acheter un kilomètre par exemple, mais cela pourrait coûter plus cher que la licence pour SQL Server. Avoir des utilisateurs se connecter à chaque fois est beaucoup moins cher
@PanagioSkanavos Je souhaite protéger mon utilisateur de connexion et mon mot de passe sur ma base de données. Je peux créer un utilisateur et lui donner uniquement des subventions à exécuter la procédure stockée, mais cela ne modifie pas le fait que quelqu'un peut décompler et obtenir un mot de passe et une connexion.
@ADAM NE PAS Stockez ce mot de passe et ce login. Laissez l'utilisateur les saisir lorsqu'ils démarrent l'application. Ou configurer l'authentification Windows dans MySQL et oubliez les mots de passe complètement. Quant à ce
MySQL Enterprise Edition pour Windows prend en charge une authentification , vous pouvez télécharger la source de l'édition d'entreprise et la compiler vous-même.Comme @marvin et j'ai dit, vous devez créer une API Web pour interagir avec votre base de données. Vous pouvez ensuite avoir un mécanisme de connexion qui authentifie le client avec l'API et que vous avez ensuite des méthodes API qui obtiennent des modifications de données / effets sur votre base de données.
Mais lorsque le type d'utilisateur, mon compte doit obtenir des valeurs à partir de la base de données. Il est donc important que seul mon compte puisse obtenir cette information de la base de données