22. december 2004 - 18:52Der er
16 kommentarer og 1 løsning
Sikkerhed i web-app med tilhørende MSSQL DB
Hej eksperter
Jeg har en række spørgsmål omkring sikkerhed, som jeg håber i kan være behjælpelige med. Jeg arbejder i C#, men hold jer ikke tilbage selvom i arbejder i andre sprog. Det her spørgsmål handler om hvordan højst mulig sikkerhed opnåes, det sprog specifikke kan vi altid tage ved en senere lejlighed.
1. Jeg har via mail spurgt et par hosting udbydere om det er muligt for udvedkommende at tvinge sig adgang til mine filer i mit domaine. Til dette svarer de blankt nej. Nu ligger landet imidlertid sådan, at jeg har en kammerat der fortæller mig at han ofte henter filer hvis der er noget kode han gerne vil se (php). Hvad er sandheden her... Kan man uden videre hente filer på disse servere og på denne måde få adgang til koden ? Og hvis man kan, kan C# koden så uden videre decompiles ?
Grunden til at dette er vigtigt for mig, er fordi jeg ønsker at beskytte min DB. Og hvis man kan få adgang til min source kode, så har man jo også adgang til alle nødvendige oplysninger til at connecte osv. til min DB.
2. Hvordan sikre jeg min MSSQL DB? Det bedste for mig ville være hvis jeg kunne låse den sådan at den kun kan tilgåes fra eks. én bestemt web-service eller lignende. Dette hjælper selvfølgelig igen intet hvis folk kan få adgang til mine filer (Spm 1).
3. Kan jeg bruge SSL mellem DB og eks. web-servicen ? Koster det meget på performancen ?
Denne DB indeholder meget vigtige oplysninger, men problemet er, at den skal kunne tilgåes af mange brugere via Internettet. Det nytter altså ikke noget at låse den sådan at det kun er én bestemt PC med ét bestemt software osv. der kan få adgang. Og det er desværre heller ikke nok at disse brugere kun kan læse fra DB'en. De er nød til at have metoder til rådighed hvor de også kan skrive til den. Ikke efter bedst befindende selvfølgelig, men "de" skal altså kunne skrive i DB'en. Og det er samtidlig lige præcis disse selv samme brugere der har interesse i at få fuld adgang til DB'en. Så det er altså folk jeg selv lader logge ind som godkendte brugere der vil forsøge at hacke min DB. Og DB'en indeholder faktisk oplysninger hvor det vil være næsten helt umuligt at tjekke om der er ændret noget, som ikke var tiltænkt.
Jeg har arbejdet med dette de sidste dage her, og nu vil jeg altså meget gerne have jeres ekspert idéer med i min pulje af idéer. Dette er måske egentligt mere en debat omkring sikkerhed end det er ja/nej spørgsmål, men jeg garanterer at der er flere point på vej, hvis vi i fællesskab kan finde frem til noget brugbart.
Denne side indeholder artikler med forskellige perspektiver på Identity & Access Management i private og offentlige organisationer. Artiklerne behandler aktuelle IAM-emner og leveres af producenter, rådgivere og implementeringspartnere.
1) Dit web hotel har ret. Din kammerat bilder dig noget ind. ASP, PHP, ASP.NET, JSP etc. sider kan man ikke se kilde tekst til (medmindre web server konfigurationen er total sindsyg).
3) Jeg mener ikke at man har mulighed for at kryptere forbindelsen mellem applikation og DB. Men det burde heller ikke være nødvendigt ved et fornuftigt opsæt.
3 fortsat) Hvis data er så sensitive skulel du måske overveje en inhouse løsning frmefor et web hotel. Udefrakommende kan ikke komme ind. Men system administrator hos dit web hotel er en helt anden sag.
Webhoteller har det med at sløse med opsætningen så andre kunder på samme webhotel kan tilgå dine filer. Som Arne siger: skal du være sikker, så er der kun een måde: egen server.
"Hvis du bruger integrated security så er der jo ikke noget password i koden anyway.".... Der stod jeg desværre af. Sry. Kan du uddybe en smule ?
"Et professionelt web hotel.......". Og hvilken udbyder bør jeg så vælge her ?
Det kommer over på egne servere, men lige pt er det ikke ret stort og der er derfor ikke økonomisk grundlag for den form for investering. (Ligesom der øjensynligt ikke er råd til programmører der ved nok om MSSQL og sikkerhed generalt i den slags apps)
Man kan tilgå en SQLServer på 2 måder: - SQLserver security hvor man sender brugernavn/password - integrated security eller NT security hvor det er brugernavnet applikationen kører under som verificeres uden at der sendes noget SQLServer password
Ja okay. Det var jeg faktisk godt lidt klar over, men jeg forstår det nok ikke helt. Er det ikke kun anvendeligt hvis brugerne kommer ind fra en app. der "kører på deres PC", eller kan det også bruges når de bare har adgang igennem deres Internet browser ?
Og hvis det er nok med browseren, begrænser det så ikke brugerene til Windows (NT, 2000, XP) ?
P.S. arne_v du har selvfølgelig point i skabet for det her, vil bare gerne vente med at uddele lidt endnu (minutter - timer), da spørgsmålet eller vises som besvaret. (Gør det ikke? ) :-)
Nu er jeg ikke IIS ekspert. Men jeg mener at du både kan sætte den til at bruge client PC'ens brugernavn for PC'ere på intranet hvilket naturligvis er Windows only - og sætte den til at bruge det brugernavn som IIS kører under og så er det ligegyldigt om folk kører Linux eller Mac.
IIS umiddelbart to måder at finde ud af hvilken bruger den skal køre under.
Normalt er Anonym Access, hvor man på forhånd har fortalt IIS'en hvilken bruger den skal køre under.
Og så er der så Ikke Anonym Access, som er det omvendte af det ovenstående ;)... denne kan dog køres i 4 modes (vist kun 3 i IIS 5.0).
Den første er normal clear text. Her bliver brugernavn og adgangdskode sendt fra klient til server i cleartext. Hvis denne benyttes anbefales det på det kraftigste af benytte sig af SSL. Denne metode kan desuden bruges af alle operativsystemer.
Den næste er en mere windows-specifik løsning, og bruger kryptering til at sende kodeord og password.
Den tredie er Digest Authentication som minder om NTLM hvor at en hashværdi af kodeordet, fremfor selve kodeordet bliver sendt. Dette kræver at brugerne findes i et AD
Og sidst, men ikke mindst, er det muligt at logge på via Passport.
Glædelig jul allesammen :D
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
