Er zijn andere manieren om het te doen. Het hangt af van wie je denkt dat er komt na je verbindingsreeks en wat voor soort toegang en vaardigheidsniveaus ze zullen hebben. De verbindingsreeks zit daar ergens, hoe je het ook probeert te verbergen.
Wetende dat de verbindingsreeks kan worden gehackt, ga ik er altijd van uit dat deze wordt gehackt en neem ik aan de andere kant voorzorgsmaatregelen.
We doen verschillende dingen aan de kant van de DB-server om ervoor te zorgen dat, zelfs als de verbindingsreeks is gecomprimeerd, de gegevens nog steeds veilig zijn.
- De gebruiker die is gekoppeld aan de verbindingsreeks heeft vrijwel geen machtigingen op de server. De enige machtigingen die ze hebben zijn EXECUTE en CONTROL op het SCHEMA dat de opgeslagen procedures bevat.
- De enige toegang die de front-end heeft, is via opgeslagen procedures. We staan nooit toe dat de front-end SQL-strings opstuurt.
- De gegevens worden in een ander schema bewaard dan de uitvoerbare bestanden, in het DATA-schema heeft de gebruiker die is gekoppeld aan de verbindingsreeks GEEN rechten, ze kunnen er niet naar kijken, ruiken of aanraken.
- De opgeslagen procedures delegeren machtigingen aan een gebruiker die niet is ingelogd en die voldoende machtigingen heeft om de procedure uit te voeren. (MET UITVOEREN ALS 'Gebruiker zonder aanmelding')
Dit is ongeveer alles wat we kunnen doen. We hebben geen manier gevonden om te voorkomen dat de verbindingsreeks ergens op de een of andere manier wordt weergegeven.
In antwoord op de vraag die Alex hieronder stelde. (te lang voor een reactie)
Opmerking. Het volgende is voor MS SQL Server, het kan van toepassing zijn op andere DBMS-systemen, maar ik kan niet instaan voor andere.
Een database bevat een schema, het schema bevat databaseobjecten zoals tabellen, weergaven, opgeslagen procedures. Met de schmea kunt u databaseobjecten afschermen, bijvoorbeeld als u een groep tabellen had die iedereen mocht zien, dan konden ze dat in een GEMEENSCHAPPELIJK schema plaatsen, als u salarisinformatie had die u moest beveiligen, u zou kunnen plaatsen dat in een PAYROLL-schema. U kunt vervolgens verschillende beveiligingsmaatregelen op het SCHEMA plaatsen op basis van het type objecten dat zich erin bevindt. Grafisch zien ze eruit als mappen op een harde schijf en daaronder bevinden zich alle database-objecten die ze bevatten. Wanneer u uw server opstart, zijn er verschillende schema's die automatisch worden gemaakt. Degene waarmee u het meest bekend bent, is de DBO-schmea. Je bent je er misschien niet van bewust als je beheerder dat heeft ingesteld als je standaardschema.
Wat we doen is alle gegevens in een DATA-schmea plaatsen, dit betekent dat alleen tabellen zijn toegestaan. Dus als we een salarisdatabase hadden, zouden de gegevenstabellen in een schema met de naam dataPayroll terechtkomen.
Een opgeslagen procedure is een blok of blokken SQL-code die de databaseserver kan uitvoeren wanneer deze wordt aangeroepen. Het kan een gegevenstabel of een enkele waarde retourneren. Zie het als een methode in C#.
Opgeslagen procedures hebben invoer- en retourparameters die in de SQL-code worden gebruikt. Paramatarized Stored Procedures zijn een sterke verdediging tegen SQL Injection-aanvallen.
Onze protocal zegt dat de opgeslagen procedures en weergaven allemaal worden opgeslagen in een schema voorafgegaan door 'prog'. Dus in het geval van de salarisdatabase bevinden alle objecten die geen gegevens zijn, zich in het progPayroll-schema.
De gebruiker die wordt gedefinieerd door de Connection string heeft dan alleen Control en Execute permissies op het ‘prog’ Schema. Hierdoor kunnen ze de Opgeslagen Procedure aanroepen. De gebruiker die wordt gedefinieerd door de verbindingsreeks, wordt alle andere machtigingen geweigerd. Deze gebruiker wordt ook overal elders ALLE machtigingen geweigerd. In de Opgeslagen procedure wordt de toestemming om toegang te krijgen tot de gegevens gedelegeerd aan een NO LOGIN-gebruiker die toestemming heeft om de gegevens op te halen uit het 'data'-schema met behulp van het EXECUTE AS-commando.
Er is GEEN sql in de front-end. Het enige dat front-endprogrammeurs weten, is wat de naam is van de opgeslagen procedures, de parameters en de retourtypen en -waarden.
Op deze manier, zelfs als de aanvaller erin slaagt de verbindingsreeks uit je programma te halen, hebben ze nog steeds veel werk te doen om iets met je database te kunnen doen, aangezien de gebruiker die ze hebben alleen een opgeslagen procedure kan uitvoeren.
Als je geen idee hebt wat dit allemaal is, dan heb je echt een DB-programmeur nodig om je systeem voor je in te stellen.