Es gibt andere Möglichkeiten, dies zu tun. Es hängt davon ab, wer Ihrer Meinung nach nach Ihrer Verbindungszeichenfolge kommt und welche Art von Zugriff und Fähigkeiten sie haben werden. Die Verbindungszeichenfolge ist irgendwo da drin, egal wie Sie versuchen, sie zu verstecken.
Da ich weiß, dass die Verbindungszeichenfolge gehackt werden könnte, gehe ich immer davon aus, dass sie gehackt wird, und treffe am anderen Ende Vorkehrungen.
Wir tun mehrere Dinge auf der Seite des DB-Servers, um sicherzustellen, dass die Daten auch dann noch sicher sind, wenn die Verbindungszeichenfolge komprimiert wird.
- Der Benutzer, dem die Verbindungszeichenfolge zugeordnet ist, hat praktisch keine Berechtigungen auf dem Server. Die einzigen Berechtigungen, die sie haben, sind EXECUTE und CONTROL auf dem SCHEMA, das die Stored Procedures enthält.
- Der einzige Zugriff, den das Front-End hat, erfolgt über gespeicherte Prozeduren. Wir erlauben dem Frontend niemals, SQL-Strings zu senden.
- Die Daten werden in einem anderen Schema gehalten als die ausführbaren Dateien, im DATA-Schema hat der mit der Verbindungszeichenfolge verknüpfte Benutzer NULL Berechtigungen, er kann sie nicht ansehen, riechen oder berühren.
- Die gespeicherten Prozeduren delegieren Berechtigungen an Benutzer ohne Anmeldung, die über ausreichende Berechtigungen zum Ausführen der Prozedur verfügen. (MIT AUSFÜHREN ALS 'Benutzer ohne Anmeldung')
Das ist alles, was wir tun können. Wir haben keine Möglichkeit gefunden, zu verhindern, dass die Verbindungszeichenfolge irgendwo offengelegt wird.
Als Antwort auf die Frage, die Alex unten gestellt hat. (zu lang für einen Kommentar)
Notiz. Das Folgende gilt für MS SQL Server, es kann auf andere DBMS-Systeme zutreffen, aber ich kann nicht für andere bürgen.
Eine Datenbank enthält Schema, das Schema enthält Datenbankobjekte wie Tabellen, Ansichten, gespeicherte Prozeduren. Das Schema ermöglicht es Ihnen, Datenbankobjekte einzuzäunen, wenn Sie beispielsweise eine Gruppe von Tabellen hatten, die jeder sehen durfte, dann könnten Sie sie in ein ALLGEMEINES Schema einfügen, wenn Sie Gehaltsabrechnungsinformationen hätten, die Sie sichern müssten, könnten Sie sie einfügen das in ein PAYROLL-Schema. Sie können dann je nach Art der darin enthaltenen Objekte verschiedene Sicherheitsmaßnahmen für das SCHEMA festlegen. Grafisch sehen sie wie Ordner auf einer Festplatte aus und darunter befinden sich alle Datenbankobjekte, die sie enthalten. Wenn Sie Ihren Server hochfahren, gibt es mehrere Schemas, die automatisch erstellt werden. Das Schema, mit dem Sie am besten vertraut sind, ist das DBO-Schmea. Sie sind sich dessen möglicherweise nicht bewusst, wenn Ihr Administrator dies als Ihr Standardschema eingerichtet hat.
Was wir tun, ist, alle Daten in ein DATA-Schmea zu platzieren, das bedeutet, dass nur Tabellen erlaubt sind. Wenn wir also eine Gehaltsabrechnungsdatenbank hätten, würden die Datentabellen in ein Schema namens dataPayroll gehen.
Eine gespeicherte Prozedur ist ein oder mehrere Blöcke von SQL-Code, die der Datenbankserver ausführen kann, wenn er aufgerufen wird. Es kann eine Datentabelle oder einen einzelnen Wert zurückgeben. Betrachten Sie es als eine Methode in C#.
Gespeicherte Prozeduren haben Eingabe- und Rückgabeparameter, die im SQL-Code verwendet werden. Paramatisierte gespeicherte Prozeduren sind eine starke Abwehr gegen SQL-Injection-Angriffe.
Unser Protokoll besagt, dass die gespeicherten Prozeduren und Ansichten alle in einem Schema gespeichert sind, dem „prog“ vorangestellt ist. Im Fall der Gehaltsdatenbank befinden sich also alle Objekte, die keine Daten sind, innerhalb des progPayroll-Schemas.
Der durch die Verbindungszeichenfolge definierte Benutzer hat dann nur Steuerungs- und Ausführungsberechtigungen für das „prog“-Schema. Dadurch können sie die gespeicherte Prozedur aufrufen. Dem durch die Verbindungszeichenfolge definierten Benutzer werden alle anderen Berechtigungen verweigert. Diesem Benutzer werden auch überall sonst ALLE Berechtigungen verweigert. In der gespeicherten Prozedur wird die Berechtigung zum Zugriff auf die Daten an einen NO LOGIN-Benutzer delegiert, der die Berechtigung zum Abrufen der Daten aus dem „Daten“-Schema mit dem EXECUTE AS-Befehl hat.
Es gibt KEIN SQL im Frontend. Alles, was die Frontend-Programmierer wissen, ist der Name der gespeicherten Prozeduren, der Parameter und der Rückgabetypen und -werte.
Selbst wenn es dem Angreifer gelingt, die Verbindungszeichenfolge aus Ihrem Programm herauszukitzeln, hat er auf diese Weise noch viel Arbeit vor sich, um irgendetwas mit Ihrer Datenbank tun zu können, da der Benutzer, den er hat, nur eine gespeicherte Prozedur ausführen kann.
Wenn Sie keine Ahnung haben, was dieses Zeug ist, dann müssen Sie wirklich einen DB-Programmierer finden, der Ihr System für Sie einrichtet.
