Wat is die beste manier om verbindingstring in .NET DLL's te stoor?

Question

Die toepassing wat my span tans ontwikkel, het 'n DLL wat gebruik word om alle databasistoegang uit te voer.Die toepassing kan nie 'n vertroude verbinding gebruik nie, want die databasis is agter 'n firewall en die domeinbediener nie.Dit blyk dus dat die verbindingstring 'n DB-gebruikersnaam en wagwoord moet hê.Die DLL het tans die databasisverbindingstring hard gekodeer, maar ek wil dit nie doen wanneer ons begin nie, aangesien die samestelling uitmekaar gehaal kan word en die gebruikersnaam en wagwoord net daar in die oopte sal wees.

Een van die vereistes is dat die wagwoord een keer elke paar maande verander moet word, so ons sal dit na ons interne gebruikersbasis moet uitrol.

Is daar 'n manier om die wagwoord geïnkripteer te stoor op so 'n manier wat ons maklik na die hele gebruikersbasis kan versprei sonder om dit in die vergadering te stoor?

OPDATEER:Dankie aan almal wat geantwoord het.Ek sal probeer om van die vrae aan my terug te antwoord...Die data-DLL word deur beide ASP.NET WebForms en VB.NET WinForms gebruik.Ek verstaan ​​dat toepassings hul eie konfigurasielêers kan hê, maar ek het niks op konfigurasielêers vir DLL'e gesien nie.Ongelukkig kan ek nie by die werk by die Jon Galloway-pos uitkom nie, so ek kan nie oordeel of dit sal werk nie.Uit 'n ontwikkelingsoogpunt wil ons nie webdienste intern gebruik nie, maar sal dit dalk een of ander tyd volgende jaar aan derde partye verskaf.Ek dink nie nabootsing sal werk nie, want ons kan nie die gebruiker deur die firewall verifieer nie.Aangesien 'n gebruiker (of voormalige gebruiker) 'n aanvaller kan wees, hou ons dit van almal af!

Answer 1

Ek is nie seker nie, maar ek glo jy kan dit in 'n konfigurasielêer plaas en die konfigurasielêer enkripteer.

Opdateer:Sien Jon Galloway se plasing hier.

Answer 2

Neem net aan dat die slegte ouens die geloofsbriewe uit jou konfigurasielêer SAL kry.Dit beteken dat hulle by jou databasis kan aanmeld en doen waartoe daardie gebruiker ook al in staat is.Maak dus net seker dat die gebruiker niks sleg kan doen nie, soos om direk toegang tot die tabelle te kry.Maak daardie gebruiker net in staat om sekere gestoorde prosedures uit te voer en jy sal in beter vorm wees.Dit is een plek waar sprocs skyn.

Answer 3

Ek haat dit om dit te sê, maar sodra jy iets op 'n kliëntmasjien plaas, gaan sekuriteit vir daardie data by die venster uit.

As jou program daardie string gaan dekripteer, moet jy aanvaar dat 'n aanvaller dieselfde kan doen.Om 'n ontfouter aan jou program te koppel sal een manier wees.

Om die verbindingstring op 'n bediener te stoor, en dit deur 'n webverbinding te verkry, klink goed, totdat jy besef dat jy sekuriteit ook op daardie webverbinding nodig het, anders kan 'n aanvaller net sowel jou program naboots en met die webverbinding praat.

Laat ek 'n vraag vra.Vir wie steek jy die verbindingstring weg?Die gebruiker of 'n aanvaller?En as die gebruiker, hoekom?

Answer 4

Daar is ook 'n paar ander idees.Jy kan altyd nabootsing gebruik.U kan ook die Enterprise Library's (Common Library) gebruik.

<section name="enterpriseLibrary.ConfigurationSource" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ConfigurationSourceSection, Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
<enterpriseLibrary.ConfigurationSource selectedSource="Common">
<sources>
  <add name="Common" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource, Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
    filePath="Config\Exception.config" />
</sources>

Answer 5

.NET ondersteun enkripsie op konfigurasiewaardes soos hierdie.Jy kan dit in 'n konfigurasielêer laat, maar geïnkripteer.

Answer 6

Jy wil die DLL kan versprei met al die opstelinligting op 'n konfigureerbare plek, maar die feit is dat jy nie een van die handige .NET-konfigurasielêers vir 'n DLL kan hê nie, tensy jy iets pasgemaak doen.

Miskien moet jy heroorweeg watter verantwoordelikheid jou DLL moet hê.Sou dit moontlik wees, of sinvol wees om te vereis dat die verbindingstring deur die gebruiker van jou biblioteek deurgegee word?Maak dit regtig sin dat jou DLL 'n konfigurasielêer lees?

Answer 7

As die toepassing 'n ASP.NET-toepassing is, enkripteer dan net die verbindingstringe-afdeling van u web.config.

As die toepassing 'n kliënttoepassing is wat op verskeie masjiene loop, in plaas daarvan om die verbindingstring plaaslik te stoor, oorweeg dit om 'n webdiens of 'n ander soort veilige meganisme te gebruik om dit sentraal te stoor.Dit sal makliker opdaterings in die toekoms vergemaklik en jy stoor nie die verbindingstring plaaslik nie.

Net 'n paar gedagtes.

Opgedateer: @lassevk

“Om die verbindingstring op 'n bediener te stoor, en dit deur 'n webverbinding te verkry, klink goed, totdat jy besef dat jy sekuriteit ook op daardie webverbinding nodig het, anders kan 'n aanvaller net sowel jou program naboots en met die webverbinding praat. "

Sekuriteit op die webdiens was implisiet.Afhangende van die tipe ontplooiing is daar talle opsies...byvoorbeeld kliënt kant sertifikate.

Answer 8

Verskeie opsies:

1. Stoor in web.config en enkripteer
2. Stoor in dll en verduister (dotfuscator)
3. Stoor een in web.config (geënkripteer natuurlik) en rus in die databasis (as jy veelvuldige moet gebruik en enkripsie/dekripsie word 'n pyn)