Laden...

Wie realisiert man die ADO.NET Sicherheit?

Erstellt von NixC# vor 4 Jahren Letzter Beitrag vor 4 Jahren 1.574 Views
N
NixC# Themenstarter:in
3 Beiträge seit 2019
vor 4 Jahren
Wie realisiert man die ADO.NET Sicherheit?

Hallo,

ich arbeite mich gerade in ADO.NET ein und dabei frag ich mich, wie dort die Sicherheit gewährleistet wird.

Wenn ich einen Datenbank Server habe und viele Clients die auf die selbe Datenbank zugreifen, dann muss doch auch jeder Client das Passwort und den User kennen.

Wenn in der Client Application also im Code irgendwo das Passwort und der User gespeichert wird, kann man das doch sehr einfach mit einem decompiler offen gelegt werden.

Wie wird das gelöst oder denk ich da nur falsch ?

Schon mal vielen Dank für die Antworten

T
2.219 Beiträge seit 2008
vor 4 Jahren

I.d.R. indem die Clients nicht auf die Datenbank direkt zugreifen sondern ihre Daten über z.B. einen Webservice abrufen.
Nur dieser greift direkt auf die Datenbank zu.
Der Webservice hat dann die Zugangsdaten z.B. in einer Config liegen.
Die Kontrolle über den Webservice solltest du dann haben.
Die Clients kennen dann nur noch die API gegen die diese arbeiten, nie aber die Datenbank oder die Strukturen deiner Datenbank.

Du solltest dir mal das Thema Api Entwicklung in dem Zuge anschauen, dann sollte dir einiges klar werden.
Ansonsten wäre es ziemlich fahrlässig in der heutigen Zeit eine Datenbank offen ans Netz zu hängen.
Eine Datenbank darf niemals in einer nicht vertrauenswürdigen Umgebung wie z.B. dem Internet direkt errreichbar sein!

Im Idealfall ist der DB Server dann auf einem Server in einem internen Netzwerk während der Webserver ein externes Netzwerk hat für die Kommunikation mit den Clients und ein internes Netzwerkanbindung zum Netz mit dem DB Server.
Alles andere wäre aus heutiger Sicht absolut fahrlässig!

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

N
NixC# Themenstarter:in
3 Beiträge seit 2019
vor 4 Jahren

Danke für die schnelle Antwort.
So macht es dann schon mehr Sinn.
Also verwendet man ADO.NET dann eher bei Webservice.
Hab jetzt mal ein bisschen über wcf und Webservice gegoogelt.
Da gibt es doch bestimmt schon fertige Lösungen für einen Datenbankzugriff.
Nach was muss ich da suchen?

Ich finde die Lösung mit dem Passwort im Config file eigentlich nicht sicher.
Da finde ich, dass es sicherer wäre das Passwort im Code des Webservice zu verstecken.
Dann bräuchte ein Angreifer das Passwort vom Server und müsste dann noch den Code durchsuchen.

T
2.219 Beiträge seit 2008
vor 4 Jahren

Wenn du mit fertigen Lösungen sowas wie OR Mapper meinst, dann ja.
ADO .NET ist hier die Low Level Eben von .NET wo du dich eben um das erzeugen der Verbindung und ausführen der Befehle sowie das schreiben der Befehle selbst kümmern musst.

OR Mapper nehmen dir hier schon viel Arbeit ab bis hin zum kompletten Verzicht auf SQL Anweisungen die dann via Reflections bzw. durch ein entsprechende Modell generiert und ausgeführt werden.
Ein Beispiel dafür wäre Entity Framework (Core) was in .NET Core bzw. mit 3.1 auch wieder mit dem .NET Standard und somit wieder mit dem .NET Framework läuft.

Ansonsten gibt es auch noch als leichtgewichtige Alternative z.B. Dapper wo du dich aber um den Verbindungsaufbau und auf SQL Anweisungen konzentrieren musst.
Kann aber auch vorteilhaft sein, wenn es eben um die beste Performance und Optimierung der SQL Anweisungen geht.

Zum Passwort:
Gerade bei .NET ist es sinnlos das Passwort im Code zu "verstecken".
Die Anwendungen könnten mit einfahen Tools wie ILSpy einfach durchsucht werden und sind somit anfällig für solche "Tricks".
Dies ist sogar absolut fahrlässig, da man den Code auch z.B. bei öffentlichen Platformen wie GitHub hochlädt.
Dort kam es schon häufiger zu Datenreichtum, weil viele Entwickler teilweise ihre Livezugangsdaten dort im Code hinterlegt hatten.
Auch sind dort teilweise Zugangsdaten sowie Email hinterlegt.
Ebenfalls kann dann der Connection String nicht umkonfiguriert werden.
Entsprechend müsstest du alle Tools, die einen Hardcoded Zugang haben, neu builden und verteilen.
Aber einer bestimmten Projekt Größe ist dies kein vertretbarer Aufwand!

Der Connection String, der dann auch die Zugangsdaten enthält, gehört immer in eine saubere Config.
Alles andere, eben wie Hardcoden von Zugangsdaten, geht schon in Richtung Pfusch.
Es gibt hier z.B. noch die Möglichkeiten die entsprechenden Einträge zu Verschlüsseln, entsprechende Lösungen musst du dir mal suchen.

Wenn der Angreifer schon auf deinem Webserver sitzt, hast du schon einen Dammbruch.
Da spielt es auch keine Rolle mehr ob du dein Passwort irgendwo hard codest.
Dies ist dann aber ein Hinweis für schlechte Sicherheit deiner Systeme.
Wenn man hier radikal sein will, dürften sich nur Benutzer mit entsprechendem Benutzername und Pubic Key sowie extra einem Passwort anmelden.
Damit sind z.B. Brute Force auf Benutzername und Passwort von vornherein sinnlos.

Ebenfalls gelten noch grundsätzliche Sicherheitshinweise, wie bestimmte Software wie z.B. SSH nicht auf den Standard Ports laufen zu lassen, kein Root Login und auch Hilfstools wie fail2ban um eben Bruteforce Attacken zu erschweren.

Schon dadurch kann man sich viel Ärger vom Hals halten, dies ist dann aber eben nur der erste Schritt.
Sicherheit muss von Anfang an ein Teil deines Konzepts sein, nicht erst nach dem ersten Dammbruch oder mitten im Projektverlauf!

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

P
441 Beiträge seit 2014
vor 4 Jahren

Wenn du eine neue Applikation anfängst oder eine alte modernisierst, solltest du nicht mehr über WCF nachdenken.
Hier gibt es moderne Ansätze durch ASP.NET Core Web API (oder Technologieneutral REST API), Graph QL, ODATA oder auch gRPC, je nachdem was für deinen Anwendungsfalls das beste ist.

16.806 Beiträge seit 2008
vor 4 Jahren

Ein Beispiel dafür wäre Entity Framework (Core) was in .NET Core bzw. mit 3.1 auch wieder mit dem .NET Standard und somit wieder mit dem .NET Framework läuft.

Nur der Formulierung wegen: das hat auch vorher funktioniert.
Es gab nur den Fall, dass EFCore 3.0 den .NET Standard 2.1 wollte; mit EFCore 3.1 wird auch wieder .NET Standard 2.0 (und damit .NET Framework) unterstützt.
An für sich hat aber EFCore immer .NET Standard in einer gewissen Version unterstützt bzw. war darauf ausgelegt.

Dies ist sogar absolut fahrlässig, da man den Code auch z.B. bei öffentlichen Platformen wie GitHub hochlädt.

Wenn Credentials wenigstens sauber in den Settings hinterlegt ist, dann kann das GitHub erkennen und warnen (bzw. ist das ein Teil von Git; die Git Secrets).
Trotzdem ist das im Rahmen von .NET nicht empfohlen.
Für solche Vorhaben gibt es die .NET User Secrets, sodass man niemals irgendwo fest hinterlegen muss - nicht mal während der Entwicklung.

Der Connection String, der dann auch die Zugangsdaten enthält, gehört immer in eine saubere Config.

.. und zwar nicht in eine Datei, sondern in die User Secrets.

Hab jetzt mal ein bisschen über wcf und Webservice gegoogelt.

WCF ist eine abgekündigte Technologie.

In .NET verwendet man vor allem ASP.NET Core bzw. auch Frameworks wie NancyFX für APIs.
Hier werden verschiedene Protokolle und Standards unterstützt; von weit verbreitet Json-basierten APIs, mit REST-Standardisierung, OData, gRPC und WebSockets.
Deckt alles ab, was man für eine moderne API braucht.

Edit: siehe auch Papst-Antwort 😃 Kommt davon wenn man zwischen Antwort öffnen und Abschicken noch schnell unterwegs geht.

PS: ADO.NET ist prinzipiell nur ein Provider.
In .NET gibt es von Microsoft zwei ADO.NET SQL Clients:

  • System.Data.SqlClient
  • Microsoft.Data.SqlClient

System.Data.SqlClient ist der alte Client, der nicht mehr weiter entwickelt wird - aber noch von gewissen Technologien wie Linq2Sql verwendet werden.

Microsoft.Data.SqlClient ist der moderne Client, der darüber hinaus auch Features wie Always Encrypted unterstützt und daher auch für Datenbanken mit GDPR-Anforderungen, die über Always Encrypted erfüllt werden, verwendet werden kann.
Er ist auch Teil von EF Core seit 3.0.

N
NixC# Themenstarter:in
3 Beiträge seit 2019
vor 4 Jahren

Danke für die vielen Antworten und guten Erklärungen.
Das mit dem Passwort ist nun klar.

Hätte mir nicht so schnell ein Buch über WCF kaufen soll. Das geht nun wieder zurück.

Hab jetzt mal ein bisschen über ASP.NET recherchiert und bin auf folgendes Tutorial gestoßen.

https://docs.microsoft.com/en-us/aspnet/core/tutorials/first-web-api?view=aspnetcore-3.1&tabs=visual-studio

Ist dieses vorgehen noch aktuell? oder empfehlt ihr mir was anderes?

Ist ziemlich schwer bei den ganzen Begriffen und Techniken noch durchzublicken.

16.806 Beiträge seit 2008
vor 4 Jahren

ASP.NET Core ist die aktuelle Technologie in der .NET Welt. Daher ja.
Tutorials sind i.d.R. recht simpel und zeigen grundlegende Wege und Konzepte - nicht unbedingt Real-World Samples; das wäre zu komplex.

In diesem Fall ein einfaches ASP.NET Core Tutorial, das sich an einer Json-basierten HTTP-API nach REST orientiert.
https://restfulapi.net/

Im Web wirst Du mit vielen Konzepten, Protokollen und Frameworks zutun haben.
Es ist prinzipiell durchaus notwendig, dass Du die verschiedenen Grundkonzepte verstehst, um eine ordentliche und sichere API schaffen zu können.

Bei APIs ist das nun mal vor allem:

  • HTTP + HTTP/2
  • REST
  • Json + XML
  • OpenID und OAuth 2 für Identity und Authorisierung

Falls Du Dir ein paar Samples anschauen willst: die letzten 2 Jahre hab ich zum Thema Modern API Development auf .NET verschiedene Vorträge gehalten.
Sample Code der verschiedenen Stufen (von einfacher API hin zu Hypermedia APIs) ist hier zu finden: https://github.com/BenjaminAbt/2018-Talks-ModernApiDevelopment
Der Quellcode beinhaltet darüber hinaus das Grundkonzept eines modernen Mediator-Patterns, was am Anfang ungewöhnlich aussieht - aber absolut, gerade für Webservices, zu empfehlen ist.