Laden...

Sicherer Zugriff auf Daten: WebService vs. Datenbank-Direktzugriff

Erstellt von Palladin007 vor 6 Jahren Letzter Beitrag vor 6 Jahren 5.097 Views
Palladin007 Themenstarter:in
2.078 Beiträge seit 2012
vor 6 Jahren

Als Ergänzung zum Thema Sicherheit:

Viel sicherer als der API-Weg, den MrSparkle beschreibt, geht vermutlich nicht.
Was mich daran stört, ist, dass ich im Client auch keine Daten abfragen kann, da ich die Datenbank dann auch wieder nach Außen sichtbar machen muss.

Mir fallen folgende Möglichkeiten ein:1.MrSparkles Weg: Ein Server mit API, nur dieser Server kann in der Datenbank lesen oder schreiben, ein Angreifer muss erst Zugriff auf diesen Server bekommen um an die Datenbank zu kommen und dann muss oder noch das DB-Passwort finden.
Das hat aber auch den Nachteil, dass Du auch die Daten vom Server erfragen musst und sowas wie ein ORM, was direkt zu Datenbank will, nicht geht. Im Bezug auf Sicherheit ist das wünschenswert, das mach alles aber auch wieder komplexer.

1.Ein Server mit API, der für alle Änderungen und den Zugriff auf sehr sensible Daten zuständig ist.
Die Datenbank kennt dann mehrere Benutzer, je einen für Server und Client. Der Server-User hat Schreibrechte, der Client-User nicht.
Auf diese Weise kann der Client ein ORM nutzen und wenn das Passwort für den Client-User entschlüsselt wird, tut das nicht so sehr weh, weil der User nicht schreiben darf.
Der Nachteil ist, dass die Datenbank wieder außerhalb des Servers sichtbar ist.

1.Eine Kombination aus Beidem. Der Client-User darf sehen, was er zwingend braucht. Sensible Daten, darf der Client-User nicht sehen, sondern nur der Server. Braucht der Client diese Daten, dann muss er einzeln danach fragen und bekommt dann auch nur das geliefert, was er braucht.

Ich persönlich würde Variante 3 nehmen.
Wenn aber selbst das Lesen in der Datenbank möglichst verhindert werden soll bzw. nur soviel sichtbar sein soll, wie notwendig, dann ist Variante 1 alternativlos.

Welche der Varianten für dich am besten geeignet ist, musst Du wissen.

PS:
Wenn doch Lese-Zugriff auf sensible Daten aus dem Client heraus möglich sein soll, dann könnte man das hinter weiteren DB-Usern verbergen. Z.B. gibt's dann einen Admin-Bereich, der einen eigenen Admin-User bekommt und dessen Passwort gar nicht gespeichert wird

16.806 Beiträge seit 2008
vor 6 Jahren

Bei einer ordentlichen API muss man NIE die Datenbank nach Außen sichtbar machen. NIE.
Eine Variante, die ein Datenbank-Expose erfordert, würde ich nie als akzeptabel betrachten

2.207 Beiträge seit 2011
vor 6 Jahren

Hallo zusammen,

auch wenn das Thema sehr interessant ist und ich auch Fragen zu

Was mich daran stört, ist, dass ich im Client auch keine Daten abfragen kann, da ich die Datenbank dann auch wieder nach Außen sichtbar machen muss. habe, können wir hier beim im Titel beschriebenen Thema bleiben?

@Palladin007: Wenn du einen extra Thread machen willst: Go for it. Wähle einen richtigen Titel und dann kann man dort diskutieren, was besser/schlechter ist.

Gruss

Coffeebean

Palladin007 Themenstarter:in
2.078 Beiträge seit 2012
vor 6 Jahren

Es ist immer abwägungssache, daher macht ein neuer Thread mMn. keinen Sinn.

@Abt:
Ich arbeite zur Zeit an einem Projekt, was an vielen Stellen sehr viele Daten anzeigen können muss.
Dazu nutzen wir die InstantFeedback-Tabellen von DevExpress, die in Zusammenarbeit mit einem ORM ganz hervorragende Arbeit leisten - und das bei wenig Aufwand.
Scrollen über mehrere 100.000e Zeilen mit vielen Joins, Filter-Einstellungen à la Excel, etc. funktionieren flüssig und beinahe ohne Verzögerung. Das will man bei der Datenmenge einfach nicht missen.

In so einem Fall finde ich es durchaus angebracht, dem Client Lese-Zugriff auf die Datenbank zu geben, besonders da das ganze Projekt nur im internen Netzwerk erreichbar ist und die Daten auch nicht so kritisch sind, dass sie niemand lesen darf.
Nur unbefugtes Schreiben würde weh tun, aber das darf sowieso nur der Server.

PS:
Und ja, zurück zum Thema 😄

16.806 Beiträge seit 2008
vor 6 Jahren

Ein ordentlich implementierter Service kann genauso hervoragende Performance an den Tag bringen. Nichts andere steckt hinter jedem Scrolling von großen Anwendungen wie Amazon und Co.
Auch hier für mich ein No Go direkten Zugriff auf die Datenbank zu gewähren.

Solche Grids sind ganz nett, wenn sie von einer lokalen Datenquelle leben wie ein Cache.
So ein Grid auf eine produktive Datenbank zu lassen: macht man nur aus Bequemlichkeitsgründen; ohne Auge für den Sicherheitsaspekt.

Eine Datenbank sollte nie von Außen zugreifbar sein. Das zeigt Dir auch jede entsprechende Referenzinfrastruktur.
In AWS und Azure gibts dafür eigene VNETs, sodass nur Applikationen auf der Plattform auf die DB zugreifen kann.
In anderen Umgebungen schafft man dafür eine entsprechende Zugriffsschicht über Firewalls und Co.

Auf der Datenbank kann man auch übrhaupt kein heute gängiges Verfahren von Authentication und Authorization wie Claims und Roles umsetzen.
In vielen Datenbanken (zB MongoDB) wurde aus diesen Gründen auch auf eine Benutzerverwaltung vollständig verzichtet: das gehört da einfach nicht rein.

Eine offene Datenbank ist immer eine potentielle Quelle für einen Leak.
Ausnahmlos immer.

5.657 Beiträge seit 2006
vor 6 Jahren

Hi Palladin007,

ich muß Abt und Coffeebean hier zustimen. Auf Datensicherheit zu verzichten "weil Performance" bzw. "weil DevExpress" ist kein gutes Argument.

Weeks of programming can save you hours of planning

Palladin007 Themenstarter:in
2.078 Beiträge seit 2012
vor 6 Jahren

"offen" im Sinne von "offen nur im internen Netzwerk"
Von außerhalb sieht die niemand.

Aber ja, es ist Bequemlichkeit, auf der anderen Seite aber auch berechtigte bzw. benötigte Zeitersparnis.
Mag sein, dass es sicherer wäre, die Datenbank ganz zu verbergen, allerdings muss man dann auch einige Funktionen von z.B. DevExpress im Prinzip neu bauen.
Leider sind das unter anderem auch Funktionen, die es überhaupt ermöglicht haben, das Projekt in der kurzen Zeit aufzubauen.

Man kann nicht jedes Projekt riesig groß aufziehen, nur weil es sicherer ist.
Es passiert ganz schnell, dass so ein Projekt den finanziellen oder zeitlichen Ramen sprengt und damit gestorben ist.
Da kann es besser sein, abzuwägen, ob sich dieser große Mehraufwand für ein bisschen mehr Sicherheit lohnt.
Es tut nicht weh, wenn da jemand in der Datenbank liest, soll er das doch machen, sind sowieso nur langweilige Verwaltungs-Daten.

Der Nachteil durch ein derartigen Aufbau ist dagegen viel größer:*Deutlich höhere Entwicklungs-Kosten *Deutlich größeres Fehler-Risiko, während Lösungen wie die von DevExpress zig fach getestet sind *Deutlich verzögerter Go-Live
Und dieser Punkt wäre fatal, unser heute größte Kunde hatte nämlich nicht vor, noch ein Jahr zu warten.

Der Nachteil wäre nämlich gewesen: Kein Projekt

Allgemein waren meine Vorschläge auch nur als Ideen gemeint, nicht als Richtlinie.
Ich hab auch dazu geschrieben, dass es ein größeres Risiko ist, die Datenbank sichtbar zu machen, auch wenn es nur Lese-Zugriff ist.
Für kleinen Unternehmen, die gar nicht das Geld oder die Zeit haben, kann das durchaus interessant sein.

Welche der Varianten am besten geeignet ist, musst jeder selbst wissen.
Ich werfe nur die Idee dazu in den Raum.

16.806 Beiträge seit 2008
vor 6 Jahren

Ich bin selbst im Consulting tätig und kenne die Anforderungen Zeit/Geld vs. Sicherheit vs. Qualität nur zu gut.
Das ist für mich ein Paradebeispiel, dass Geld- und Zeitdruck andere Dinge (fahrlässig) vernachlässigt.

Deutlich höhere Entwicklungs-Kosten

Nö. Dazu gibts schon "fertige" Komponenten wie OData, wovon man nur noch IQueryable implementieren muss und man bekommt den Rest fast geschenkt.

Deutlich größeres Fehler-Risiko, während Lösungen wie die von DevExpress zig fach getestet sind

Dazu enthalte ich mich besser.

Diese Komponenten sind aber allgemein nicht dazu da, dass damit dann die Sicherheit einer Anwendung sinkt.
Dann wurden sie einfach durch Bastelei nur dafür missbraucht.

Ihr habt im Endeffekt ein Projekt angenommen und dafür Sicherheitsrisiken in Kauf genommen.
Die meisten erfolgreichen Angriffe auf europäische Netzwerke (Unternehmen) erfolgen übrigens von Innen, oft eigene Mitarbeiter - nicht von Außen.
Der Faktor "ist ja das eigene Netz" ist nichts anderes als ein (oft fahrlässiger) Trugschluss.

Der nächste Punkt ist die Abhängigkeit: wird das Schema geändert muss jeder Client aktualisiert werden.
In großen Umgebungen bzw. bei größeren Unternehmen darf das nicht passieren.

Klar, kleine Kunden sind auch ein Faktor.
Aber bitte bedenkt, dass wir hier in einem öffentlichen Forum sind und die Leute/Leser verantwortungsvoll auf eine Schiene bringen müssen.
Da kann es in meinen Augen nicht sein, dass empfohlen wird, dass die Leute direkt mit der Datenbank kommunizieren sollen. So wird sch* Software draus.

P
1.090 Beiträge seit 2011
vor 6 Jahren

Na ja Datensicherheit kostet auch immer Geld und Zeit. Wenn ich sie nicht brauche und es keine Anforderung des Kunden ist. Wie so sie umsetzen?

Wenn sie eine Anforderung ist, ist es keine Frage ist der WebService die Sicherere alternative. Und grundlegend Bevorzuge ich auch die WebService Variante. Die hat auch noch ein paar andere Vorteile.

Wir haben uns aber auch schon bewusst, gegen einen bestehenden WebService entschieden. Da ging es um die Erfassung Produktions Daten von Maschinen. Und bei einer Maschiene kommen die Schon im Millisekunden Takt. Und ein direkter Datenbankzugriff ist einfach schneller. (Amazon greift ja mit ihren Service denke ich nicht direkt jedes mal auf die Datenbank zu sondern Cachen die Daten.)
Dann ist die Wartung eines zusätzlichen Services ein wenig aufwändiger. Bei Fehlern muss immer geschaut werden, wo lag es jetzt. Hat der Client die Daten falsch an den Service gesendet oder der Service die Daten falsch an die DB usw. Der Service muss Versioniert werden. Und wenn wirklich ein wirklich gleichzeitig ein Update gemacht werden musste bei uns immer ein C# und ein C++ Entwickler zum Kunden. Datenbanken können beide.

Aber im Endeffekt muss man sich die Verschiedenen Tier Architekturen im Zusammenhang mit den Anforderungen anschauen. Und dann genau Abwegen was man braucht. Es hat halt alles seine Vor und Nachteile.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

16.806 Beiträge seit 2008
vor 6 Jahren

Wie so sie umsetzen?

Woher soll der Kunde, der vielleicht Lebensmittel oder Maschinen herstellt, sowas wissen? Der will vielleicht einfach nur eine Software haben und für ihn ist es selbstverständlich, dass diese sicher sein muss - ohne dass er es explizit erwähnt.
Ich hab fast wöchentlich Anforderungen auf dem Tisch, die die Eierlegende-WOllmilchsau definiert.
Da muss man den Kunde an die Hand nehmen und ihn auf die Gleise bringen.
Wie soll er was formulieren, von dem er in 90% der Fälle null oder nur wenig Ahnung hat? Genau deswegen wendet er sich ja an Berater.

Wenn Du den Elektriker kommen lässt, dann ist doch für Dich auch selbstverständlich, dass er die Kabel nach aktuellen, gesetzlichen Bestimmungen (die er kennt, aber nicht Du) verlegt und nicht etwa einfach die offenen Kupferkabel von der Decke hängen lässt, oder?
Das sagst dem ja auch nicht explizit.

Du bist als Entwickler auch in der Pflicht zu beraten (daher auch der Name Berater/Consultant).

Ich sehe das leider immer wieder, wie die gesamte Entwickler/Berater-Branche einfach als negativ empfunden wird, weil gepfuscht wird.
Da wird das Unwissen der Kunden ausgenutzt, diese nicht ordentlich beraten und man bastelt irgendwas, weil das ist ja egal, was dann nach der Projektzeit passiert.

Klar gibt es nicht nur schwarze Schafe, und das will ich Paladin auch gewiss nicht vorwerfen, also nicht falsch verstehen, aber allgemein auf die Branche gesehen empfinde ich das als extrem unseriös und unverantwortlich.

P
1.090 Beiträge seit 2011
vor 6 Jahren

Woher soll der Kunde, der vielleicht Lebensmittel oder Maschinen herstellt, sowas wissen? Der will vielleicht einfach nur eine Software haben und für ihn ist es selbstverständlich, dass diese sicher sein muss - ohne dass er es explizit erwähnt.

Ich hab ja nicht gesagt das man einen Kunden nicht beraten soll und offensichtliche Sicherheitslücken im System nicht schließen soll. Aber die Sicherheit und Beratung, sollten auch mit ihr Verbundene Kosten in Relation gesetzt werden. Der Lebensmittel Hersteller möchte von mir sicher nicht eine Stunde hören wie Sicher meine Software für seine Arbeitszeit Erfassung ist.

Die meisten erfolgreichen Angriffe auf europäische Netzwerke (Unternehmen) erfolgen übrigens von Innen, oft eigene Mitarbeiter - nicht von Außen.
Der Faktor "ist ja das eigene Netz" ist nichts anderes als ein (oft fahrlässiger) Trugschluss.

Der wird sich aber auch nicht für die Daten der Arbeitszeit Erfassung interessieren.
Und ob da jetzt ein WebService der im Intranet auf einem Server läuft wirklich viel mehr Sicherheit bring ist Fraglich. Snoden hat ja beim NSA auch Daten mitgehen lassen.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

Palladin007 Themenstarter:in
2.078 Beiträge seit 2012
vor 6 Jahren

Und genau das, was Palin schreibt, ist der Punkt.
Nur weil wir Entwickler sind, können wir uns nicht gleich den goldenen Sicherheits-Standard leisten.
Das kann man vielleicht, wenn "Amazon", "Google" oder "Microsoft" heißt und Probleme mit Geld und Manpower tot schmeißen kann, alle anderen "normalen" Unternehmen müssen mit dem zurecht kommen, was sie haben.

Aber bitte bedenkt, dass wir hier in einem öffentlichen Forum sind und die Leute/Leser verantwortungsvoll auf eine Schiene bringen müssen.
Da kann es in meinen Augen nicht sein, dass empfohlen wird, dass die Leute direkt mit der Datenbank kommunizieren sollen. So wird sch* Software draus.

Es ist aber auch so, dass in einem öffentlichen Forum nicht nur Leute unterwegs sind, die sich große Projekt leisten können.
Meiner Meinung nach ist es daher am wichtigsten, die möglichen Optionen aufzuzeigen und für die Vor- und Nachteile zu sensibilisieren.
Ein Berater - und in gewisser Weise ist jeder hier in diesem Forum eine Art Berater - kann ohne tiefgreifendes Detail-Wissen keine klare Empfehlung geben, aber er kann die Möglichkeiten mit Vor- und Nachteilen anbieten.

Wenn sich jemand dann für die weniger sichere Variante entscheidet, dann vermutlich mit bestem Wissen und Gewissen - oder trotzdem.

PS:
Das OData interessiert mich aber schon. 😄
Kannst Du dazu eine gute Quelle empfehlen?
Es schadet nie, solche Technologien für neue Projekte im Hinterkopf zu behalten.

5.657 Beiträge seit 2006
vor 6 Jahren

Na ja Datensicherheit kostet auch immer Geld und Zeit. Wenn ich sie nicht brauche und es keine Anforderung des Kunden ist. Wie so sie umsetzen?

Das ist genau die Einstellung, die dann direkt zu so etwas führt: Software zur Auswertung der Bundestagswahl unsicher und angreifbar

Eine ganze Kette aus eklatanten Schwachstellen vom Update-Server des Herstellers, über die Software selbst bis hin zu den exportierten Wahlergebnissen, ermöglicht uns die Demonstration von gleich drei praktisch relevanten Angriffsszenarien

Datensicherheit? Brauchen wir doch nicht.

Wenn die Anforderungen des Kunden explizit ausschließt, Vorkehrungen dafür zu treffen (z.B. indem kein Server für den Betrieb eines Services zur Verfügung gestellt wird), dann kläre ich den Kunden auf, und lasse mir das schriftlich bestätigen. So liegt die Verantwortung allein beim Kunden, der ausreichend über die Tragweite dieser Entscheidung informiert wurde. Und im Zweifelsfall bin ich in der Lage, das auch nachzuweisen.

Was das Ganze mit Snowden zu tun haben soll, erschließt sich mir nicht. Er hat, soweit ich weiß, keine Sicherheitslücke in einer Software ausgenutzt (aber dafür viele Sicherheitslücken bekannt gemacht).

Weeks of programming can save you hours of planning

16.806 Beiträge seit 2008
vor 6 Jahren

Das typische Snowden Beispiel kommt wohl, da irgendwie die Argumente ausgehen, nich? 😉
Völlig an den Haaren herbei gezogen. Das hat überhaupt nichts mit Software-Lecks zutun gehabt, sondern mit physikalischen Zugriff auf Systeme.
Das ist ein ganz anderer Faktor, den eine Software so in der Art gar nicht abdecken kann. Das ist ein organisatorischer Faktor, dass zB. nie eine Person alleine physikalisch Zugriff auf Systeme haben darf, sondern immer eine zweite Person mit im Rechenzentrum dabei sein muss.

Mit Google oder Microsoft muss man sich auch nicht messen. Aber man muss sich die Vision abschauen.
Seid euch bewusst, dass auch kleine Unternehmen der Datenschutz-Grundvordnung unterliegen und hier sogar kleine Leaks 300.000€ Strafe bedeuten können.
Der Kunde, egal wie klein oder wie "uninteressant" die Daten auch sein mögen, kann bei einer entsprechenden Verletzung schnell auch sehr schmerzhafte Zahlungen kommen.

Gerade das Thema Arbeitszeiterfassung sind personenbezogene Daten und sind ganz besonders wichtige Daten eines Unternehmens.
Das gleiche gilt für den öffentlichen Dienst und die Verwaltung von Bürgerdaten. Das ist was anderes als die Inventarliste einer Bücherei.

Sorry, ich finde das einfach fahrlässig - und manche Argumentationspunkte auch einfach unseriös - weil hier Sicherheitsfaktoren runter argumentiert werden.
Wir reden hier ja auch nicht unbedingt von offensichtlichen Sicherheitslücken. Wir reden hier von Umsetzungswegen, die leider oft in Projekten gewählt werden, weil sie für den Projektzeitraum/Budget günstiger waren - trotz bewusst geringerer Sicherheit, und trotz der Tatsache, dass langfristig ein höherer Aufwand was Wartung und Sicherheit betrifft.

Sidekick:
Da haben die Unternehmen "Angst" vor der Cloud, aber ein offen erreichbarer SQL Server ist kein Problem.
Das ist so ein Faktor, der das ganze wirklich ad absurdum führt.
Aber gut, davon lebt in Endeffekt zB. auch https://haveibeenpwned.com/

Ich hab da ehrlich gesagt einen anderen Anspruch an die Kundenberatung.

Palladin007 Themenstarter:in
2.078 Beiträge seit 2012
vor 6 Jahren

Und was ist, wenn der Kunde man selbst ist?
Internes Netz, interne Nutzung, interne Verwaltung, keine personen bezogene Daten, ...

Es mag sein, dass man als Außenstehender gerne das Thema Sicherheit ganz groß hoch hält, weil das funktioniert immer.
Niemand kann Sicherheit als unwichtig "runter argumentieren".
Aber hast Du schon mal bedacht, dass in manchen Fällen die Sicherheit wirklich nicht von Bedeutung ist?

Beispiel: Fuhrpark-Verwaltung
Da steht dann drin, welche Fahrzeuge wo geparkt sind, wann das letzte mal der Tüv gemacht wurde, wann ein Fahrzeug verplant ist, etc.
So eine Anwendung dient nur zur Vereinfachung der Arbeit einiger Mitarbeiter, weil die das Gleiche sonst in Excel machen müssten.
Hier ein Projekt überdimensioniert zu planen, sodass es abgelehnt wird, sorgt nur dafür, dass weiter mit Excel gearbeitet wird und das ist noch unsicherer.

Welcher Angreifer schaut sich denn Fuhrpark-Daten an und wen interessiert es, wenn diese Daten geleakt werden?
Würde es ernsthaft interessieren, hier den Lese-Zugriff auf die Datenbank zu unterbinden?
Nein, das interessiert niemanden.

Wir reden hier nicht von Software, die Konto-Daten verwaltet oder Wahl-Ergebnisse auswertet.
Wir reden von Software, die irgendwer entwickeln will und wir wissen nicht, wie wichtig das Thema Sicherheit wirklich ist, denn das kann nur der Fragesteller entscheiden.
Natürlich kann man in großen Aufsätzen erklären, dass das unbedingt notwendig ist, aber im schlimmsten Fall erreicht man damit, dass das Projekt stirbt.
Hat man mit der Beratung dann geholfen? Nein!

Gute Beratung ist Fall bezogen, man verallgemeinert nicht.
Und wenn man den konkreten Fall nicht (im Detail) kennt, dann zeigt man eben die Möglichkeiten sowie deren Vor- und Nachteile auf.

H
523 Beiträge seit 2008
vor 6 Jahren

Ich bin absolut pro Api für den Zugriff auf die Datenbank, aber:

Wenn man Angst vor den eigenen Mitarbeitern hat, dann lassen sich die Clients doch auch mit Windows-Boardmitteln oder entsprechenden Systemen wie z. B. Citrix so einschränken/gestalten, dass der jeweilige Benutzer keinen Blödsinn machen kann falls er an Zugangsdaten des Datenbanksystems gelangt.

P
1.090 Beiträge seit 2011
vor 6 Jahren

Irgendwie hab ich das Gefühl wir reden da ein einander Vorbei.

Fangen wir mal ganz unten an.

Ich hab mir vor Grob 10 Jahren eine Charakter Verwaltung für AD&D geschrieben. Da hab ich auch den SQL Server verwendet und das Password in Klartext in in die Config Geschrieben. Seher ich auch heute noch kein Problem. Auch wenn ich jetzt wohl eine Web Lösung erstellen würde, da ist aber der Hauptgrund nicht die Sicherheit der Daten, sondern das ich von Unterschiedlichen Geräten drauf zugreifen kann.

Dann gibt es natürlich am anderen Ende auch hochsensible Daten. Wie Snowden z.B. da ist dann aber ein Webservice auch keine Ausreichende Absicherung mehr.

Und das zwischen gibt es viele Abstufungen. Was für einen da die Beste Lösung ist muss man halt in Einzelfall betrachten.

Wie gesagt ich Persönlich bin im Allgemeinen auch für einen WebService, da er auch höhere Sicherheit liefert. Ich halte aber das Argument, das jeder zugriff auf eine Datenbank nur über einen Service laufen darf. Weil man sonst unsichere Software Programmiert für falsch.

Ich stelle jetzt auch einfach mal die Hypothese in den Raum, dass ein schlecht Programmierter WebService deutlich gefährlicher sein kann als eine gut Programmierte Client Lösung.

Grundlegend geht es doch darum zu gegebenen Anforderungen die möglichst Beste Lösung zu finden. Und wenn ich mich von vorneherein festlege, das es ein Webservice sein muss, schließe ich viele Möglichkeiten aus.

p.s.
Das Snowden Beispiel habe ich bewusst herangezogen, nach dem der eigenen Mitarbeiter zur Sprache gebracht wurde. Und meines Wissens ist er aktuell die größte Schwachstelle und nicht die Software sondern der Mensch. Weil es einfacher ist über ihn an die Nötigen Informationen zu kommen, als über die Software.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

T
2.219 Beiträge seit 2008
vor 6 Jahren

@Palin
Ich hatte deinen Post gestern abgend schon gelesen, aber eine Argumente, wie auch Abt schon schreibt, sind nicht passend.

1.Der Thread Titel lautet "Sicherer Zugriff auf Daten: WebService vs. Datenbank-Direktzugriff". Dein Snowden Argument ist hier also nicht sinnvoll. Auch das Thema Mitarbeiter sind auch eine Gefahrenquelle, passt nicht zu dem Thema.

Hier geht es um den Datenzugriff von (externe) Webs/Apps.
Diese sollten i.d.R. immer über Webservices laufen.
Dies hat nicht nur mit der Sicherheit zu tun, sondern auch andere Aspekte wie dem korrekten Datenzugriff und Rechteverwaltung etc.

2.Deine Beispiel mit deinem AD&D Charakter Tool kann ich hier verstehen. In diesem Punkte, da es nur ein Tool von dir zu sein scheint und auch nur von dir genutzt wird, kannst du deinen Sicherheitsaspekt gerne vernachlässigen.

Sobald aber andere Benutzer dieses Tool verwenden und ihre Daten bei dir speichern, bist du auch für die Datensicherheit und den Datenschutz verantwortlich.
Und hier würde ich als Nutzer erwarten, dass die Daten gesichert und auch vor Fremdzugriffen geschützt werden.
Entsprechend musst du, sobald jemand mit deinem Webs/Apps arbeitet und seine Daten hinterlegt, auch dich um das Thema Sicherheit und Datenschutz kümmern.

3.Gerade die Absicherung der DB durch einen Webservice, ist erst der eigentliche Gewinn.
Dies als ""Ist kein Argument" abzutun, ist schon eine fatale Fehleinschätzung.
Wenn du deine DB schon ins offene Netz hängst, hast du eine Angriffsfläche geschaffen.
Sobald jemand deine DB von extern sieht, kann er diese Angreifen.

Mit einem internen Netzwerk für die DB + den Webserver der dann von extern Verfügbar ist, schottest du deine DB sicher ab und bietest von extern keine Angriffsfläche.
Entsprechend sollte man die DB NIE nach extern freigeben.

Zusätzlich sollte man auch noch die bekannten Default Ports der Datenbank ändern, nur für den Fall das es sogar jemand in das interne Netz schafft.

Hier würde ich sogar soweit gehen und sagen, hängt niemals deine Datenbank nach extern.
Auch bei meinem privaten Homeserver wurden sämtliche Default Ports von bekannten Programmen, meist nur SSH aber teilweise auch Postgresql etc., abgefragt und versucht Zugang zu bekommen.
Sobald was am Netz hängt, kommen auch irgendwann Bots o.ä. um die Dienste zu knacken.

3.Um das Thema Snowden noch einmal anzuschneiden. Snowden saß bei der NSA und konnte die Daten direkt per wget aus dem unternen Netz abgrasen. Hier war er als vertrauenswürdig eingestuft und konnte deshalb recht einfach schalten und walten.
Aber das ist ein Thema für sich, da es hier um den Datenzugriff von Mitarbeitern geht.
Hier hat man immer das Problem, dass ein guter Mitarbeiter an einem schlechten Tag viel Schaden anrichten kann. Dafür wurde auch erst in der letzten Woche ein Admin in den USA belangt.
Bei Snowden ist es aus Sicht der USA natürlich ein Vertrauensbruch sowie Verrat an den USA.
Aus unsere Sicht war es zwar Verrat, aber er tat es aus guten Gewissensgründen, was bei Diensten wie der NSA und CIA schon was heißt.

Aber das ist, wie gesagt, ein Thema für sich und hat mit dem Topic nichts zu tun.
Ich möchte damit nur nochmal bekräftigen, dass dies kein Argument Pro DB Zugriff/Pro Webservice Zugriff ist!

4.Bitte erläute uns mal, wie genau ein schlecht programmierter Service besser sein soll als ein gut programmierter Client?
Ich behaupt einfach mal, beides ist schei**e!
Aber die DB im Client quasi offen zu lesen in dem man dort alle Abfragen und Strukturen ablegt, halte ich für viel gefährlicher als einen schlechten Service.
Den hier hat der Angreifer quasi den Fahrplan für deine DB, während er beim Service erst einmal alles erforschen und per Try/Error Verfahren deine DB Struktur ermitteln kann.
Wenn man hier nicht alles falsch macht, dann kann man hier entsprechend duch Fehlermails etc. schon den Angriff direkt feststellen und Massnahmen ergreifen.
Wenn deine DB direkt von extern angegriffen wird, müsstest du die DB runterfahren oder die Verbindungen kappen.
Wäre noch schlimmer als den Webservice entsprechend abzuschalten und anzupassen.

Entsprechend kann ich auch hier dein Argument weder nachvollziehen und als Argument für den DB Zugriff anerkennen.
Genau wie Abt wehre ich mich mir allen Mitteln, wenn ein Kunde direkten DB Zugriff will.
Wenn ein Kunde von extern auf unsere DB und somit auch auf sensible Daten anderer Kunden zugreifen will, dann kann man dies niemals gut heißen.

@Palladin007
Hier muss ich dein Argument mit dem Fuhrpark-Verwaltung aufgreifen.
Wir entwickeln hier eine solche Verwaltung.
Diese wird von uns als Produket für viele Kunden angeboten.
Sprich, wir haben ein Web mit Mandanten(unseren Kunden).

Dort hinterlegt sind sensible Daten wie Kundenstammdaten, Mitarbeiter, Standorte.
Diese sind für eine Tourenplanung des Kunden notwendig.
Entsprechend wären auch hier die Daten extrem abzusichern.
Deshalb gibt es auch nur Zugriff auf Daten per Webservice oder nur auf Dateien, die wir durch Tasks auf unseren Servern exportieren und dem Kunden dann per Email/SFTP etc. bereitstellen.

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.

709 Beiträge seit 2008
vor 6 Jahren

Seid euch bewusst, dass auch kleine Unternehmen der Datenschutz-Grundvordnung unterliegen und hier sogar kleine Leaks 300.000€ Strafe bedeuten können.

Gefühlt gibt es folgende ungeschriebene Regel: Je größer deine Firma ist, je größer die Menge an gestohlenen Daten und je sensibler die Information, desto weniger passiert. Dann reicht eine plumpe Entschuldigung aus. Dass das Strafen nach sich zieht, habe ich in nahezu keinem Fall gelesen.

16.806 Beiträge seit 2008
vor 6 Jahren

Also dieser physikalische Zugriff und selbst genutzte + betriebene Software im Kämmerlein beachte ich mal nicht, weil das ist Off-Topic und hat mit dem Thema an für sich nichts am Hut.
Das lenkt ab.

Ein Unternehmen hat i.d.R. fast keine Software, die nicht relevante Daten hat.
Selbst wer welches Buch aus der Abteilungsbibliothek ausgeliehen hat, sind defacto personenbezogene Daten.
Ein Fuhrpark, das erst mal nur Autos verwaltet, hat doch sicherlich auch eine Mietliste - und wenn nicht, dann ist die bei einer Anfrage schnell da. Und dann? Anwendung neu entwickeln?

Der Mehraufwand eine API heute zu schreiben, bei all den technologien und technischen Optionen ist irrelevant gegenüber einem Client.
Es kann auch nicht 1:1 vergleichen werden, was Aufwand bedeutet, weil der Faktor Betrieb, Wartung, Erweiterbarkeit in der Softwarewelt ebenfalls große Rollen spielen als nur Zeit.

Wie schnell so eine API mit einem Client geschrieben ist, sieht man in meinem IdentityServer4 Beispiel (IdentityServer4 Plattform Beispiel basierend auf .NET Core und ASP.NET Core).
Da wird der API-First-Gedanke gespinnt, die API direkt mit einem SDK entwickelt.
Das SDK TasApiSDK) basiert auf einem Basispaket (BaseApiSDK), das PUT, POST, GET DELETE jeweils serialisiert zur Verfügung stellt und mit wenigen Zeilen Code hat das SDK direkt einen entsprechenden Desktopanwendung (AdminConsoleApp) um zugreifen oder Dinge wieder senden zu können.

Und das API Resultat kann dann zB. an eine fertige Grid-Komponente gebunden werden, ebenso die Commands an das SDK über Client.

Absolut keine Zauberei und kein echter Mehraufwand, der eine Sicherheitsverringerung und zukünftige Aufwandsererhöhung durch Anpassung gerechtfertigt.
Im Gegenteil: meiner Erfahrung nach ist es auf diesem Prinzip viel einfacher weitere Software Features zu implementieren, als mit einem Anwendungs-Datenbank-Direktzugriff.

Ich sehe also weder der Faktor Zeit noch der Faktor Aufwand als ein Grund, dass ein Direktzugriff auf die Netzwerk-Datenbank in Unternehmen legitim ist.
Hab bisher auch kein Argument gehört, bei dem ich mir gedacht hab: Ja, für das Szenario eines Unternehmens: vielleicht.

Ich weiß, dass ich hier Überzeugungsarbeit leisten muss, wie bei allem, das nicht nach Standard F verläuft - mach ich nicht zum ersten Mal.
Man wird auch nicht jeden überzeugen können. Damit muss ich auch leben.

Dass das Strafen nach sich zieht, habe ich in nahezu keinem Fall gelesen.

Ein entsprechendes Gesetz (§ 26 BDSG), das Strafen wirklich nach sich zieht, gibt es auch erst seit Mitte(?) diesen Jahres.
Hier reicht es prinzipiell schon, wenn die Rechte auf einen Ordner von personenbezogenen Daten nicht ausreichend hoch sind und es jemanden gibt, der das anzeigt (Wo kein Kläger, da kein Richter - was bestimmt in 90% der Fällen zutrifft. Aber niemand will die 10% sein.).

In der Software-Entwicklung gibt es eigentlich nur zwei Dinge: es ist sicher, oder es ist nicht sicher.
Der Faktor Infrastruktur kann eine Software nicht abdecken.

Es ist also bei einer Kontrolleinheit eines Atomkraftwerks oder Datenbanken eines Geheimdienstes ein völlig anderes Schutzlevel zu gewährleisten als bei einer Fuhrparksoftware - einfach schon aus Infrastruktursicht. Software kann hier gar nicht genug machen, weil Software keine physikalische Trennung ermöglicht.
Das zu vermischen: macht kein Sinn.

P
1.090 Beiträge seit 2011
vor 6 Jahren

@T-Virus

zu 1:
Um mich da mal zu wieder holen der Zugriff über einen Webserver ist sicher. Da besteht hier auch kein Diskussions bedarf. Ich hab hier jetzt auch keine andere Aussage gelesen.

Was mich stört ist das daraus grob abgeleitet wird: Jeder zugriff auf eine Datenbank darf nur über einen Service laufen.

Ob da ein Service wirklich immer die Beste Lösung ist, möchte ich einfach. Deswegen denke ich ist es Sinnvoller sich im Einzelfall anhand der Anforderungen zu entscheiden.

zu 2:
Wenn wir beide es so sehen das bei dem AD&D Charakter Tool der direkte Zugriff kein Problem ist. Haben wir ja schon einen zugriff gefunden bei dem es OK es. Es muss also nicht mehr jeder sein.

Was meine Freunde angeht. Die Daten sind dann auf meinen Labtop und da ist der zugriff durch mein Password geschützt. Mehr Sicherheit bietet dir dein Handy auch nicht bei dem Schutz der Persönlichen Daten deiner Freunde.

Und meine einige meiner Freunde benutzen WhatsApp, da hat mich auch keiner Gefragt ob sie WhatsApp meine Datengeben dürfen.

zu 3:
Zu drei Abt hat den Internen Mitarbeiter in Spiel gebracht, der das Intranet Unsicher macht. Wie Snowden zeigt ist das aber ein Grundlegendes Problem. Was nicht direkt was mit Service oder nicht zu tun hat.

zu 4:
Schlecht Programmierte Service.
Also was ich ein paar mal gesehen hab bei Webseiten. Das bei Bereichen für die es im Frontend für den Benutzer keinen Link gab. Keine Authentifizierung und Autorisierung gemacht wurde, weil gesagt wurde. Der Benutzer kennt ja den Link nicht und erraten wird er ihn schon nicht. Halte ich für ganz schlecht und da ist die Sicherheit jeder Datenbank deutlich höher.

Ein anderes Beispiel ist wenn ein Service den ganzen Content zurück gibt und dann erst der Client schaut ob der Benutzer den Inhalt sehen darf. Kann man hier bei der WAZ sehen. Wenn ihr da im richtigen Moment das laden der Seite anhaltet, könnt ihr den ganzen Bezahlartikel Kosteten los Lesen. Ich hab zwar gedacht das wäre ein Fehler. Aber als ich die WAZ dazu angeschrieben hab. Meinten die das ist so gewollt. Naja Lese ich halt weiter Kostenlos.

p.s.
Es geht mir dabei auch nicht die Datenbank Extern zugänglich zu machen. Da sollte man auf jeden Fall einen Service verwenden. Es geht mir um DB im Intra Net und auf lokalen Maschien. Und da denke ich ist auch meist der Service die bessere Lösung. Ich will nur nicht ausschließen, dass es da gute Grunde geben kann doch direkt auf die DB zuzugreifen.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

16.806 Beiträge seit 2008
vor 6 Jahren

Kein Mensch redet von *Jeder Zugriff nur über einen Service*.
Der Service muss ja auch *direkt* auf die Datenbank zugreifen.

Das inhaltliche Thema seit Anfangan - und von dem hier alle reden, aber Du leider irgendwie ausweichst - ist:
*Kein Zugriff auf eine DB umsetzen, der ein Expose eines Datenbankservers ins Netzwerk/Internet erfordert.*

Auf den Rest geh ich nicht ein: vollkommen offtopic.

T
2.219 Beiträge seit 2008
vor 6 Jahren

@Palin
Ich muss mich Abt hier anschließen.
Du wirfst hier dein Topic in den Thread, dass wieder ein anderes/eigenes Thema ist.

Es geht hier nicht um interne Netze oder lokale DBs.
Bei solche Sachen, kannst du wie bei deinem AD&D Charakter Tool es hand haben wie du willst.
Wenn da, wie schon in meinem letzten Post, nichts mit personenbezogenen Daten oder andere schützenswerten Daten liegt, kannst du die direkt im internen Netz oder deiner lokalen Maschine nutzen wie du willst.
Dort lohnt sich ein Service nicht, wenn deine Tools wissen was sie machen.

Aber wie geschrieben, geht es hier um das offene legen von sensiblen Datenbanken in das offene Netz.
Entsprechend bitte das Thema bei behalten.

Auch WhatsApp gehört hier nicht rein.
Wenn du es nicht nutzen willst, nimm es nicht.
Wenn es dir nicht passt, dass deine Daten von Facebook abgegrast werden, nutze es nicht.
Wenn du nicht willst, dass deine Freunde dich dort adden und deine Daten abgegrast werden, nutze es nicht und wehre dich per Datenschutz.
Deine Daten gehören immer noch dir und Facebook muss diese löschen, wenn du dies willst.

Deine Beispiele mit schlechten Service, sind keine passenden Beispiele.
Dies betrifft das Frontend und hat nichts mit einem Service oder einer DB direkt zu tun.
Wenn der Content durch JS erst ausgeblendet wird oder ich per Link auf eine ungeschützte Seite komme ohne Anmeldung, dann liegt der Content schon beim Client und ist somit schon am Service und aus der DB vorbei.
Somit ist das kein Service sondern einfach ein Frontend, was man sauber umgesetzt hat.
Dies sollte man dem Hersteller melden und ihn auf diese Lücke und die Möglichkeit dies ausnutzen zu können aufmerksam machen.

Anbei zu deiner Info zur WAZ.
Wenn du hier kostenlos Premium Angebote schnorrst, machst du dich strafbar.
Da du hier eine offene Lücke wissentlich ausnutzt, kann ich mir kaum vorstellen, dass der WAZ dies gefällt.

Also solltest du dies dringend unterlassen.
Nur als guter Rat gemeint, da die Leute auch bezahlt werden wollen.
Würde mir auch nicht gefallen, wenn ich einen Nachrichten Dienst anbiete und jemand sich per Lücke einfach meinen bezahlten Inhalte kostenlos zieht.

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.

16.806 Beiträge seit 2008
vor 6 Jahren

Anbei zu deiner Info zur WAZ.
Wenn du hier kostenlos Premium Angebote schnorrst, machst du dich strafbar.
Da du hier eine offene Lücke wissentlich ausnutzt, kann ich mir kaum vorstellen, dass der WAZ dies gefällt.

Na ma aufm Boden bleiben.
Die ganzen Zeitungen verwenden Mechanismen, die sicherlich kein Straftatbestand sind, wenn man sich mit der Technik auskennt und einfach das Script blockiert.

Die wissen das alle, was sie da verwenden und wissen auch, dass so und so viel Prozent den oft sehr simplen Mechanismus einfach umgehen.

D
985 Beiträge seit 2014
vor 6 Jahren

Zumal der gesamte Content lesbar zu jedem ausgeliefert wird.

Und warum machen die das so? Weil nur so google & Co. den kompletten Artikel auch indizieren können 😉

Die Grundintention ist also, dass das auch lesbar sein soll.

P
1.090 Beiträge seit 2011
vor 6 Jahren

Ich sehe also weder der Faktor Zeit noch der Faktor Aufwand als ein Grund, dass ein Direktzugriff auf die Netzwerk-Datenbank in Unternehmen legitim ist.
Hab bisher auch kein Argument gehört, bei dem ich mir gedacht hab: Ja, für das Szenario eines Unternehmens: vielleicht.

Also der SQL Admin wird wohl häufiger direkt auf die Datenbank zugreifen.

Ich hab mal ein Programm geschrieben, was was Daten aus einer alten Datenbank in eine neue Importiert hat. Da hab ich auch direkt auf die Datenbank zugegriffen.

Import von Massendaten kann ein Grund sein.

Und ich hab mal ein Szenario gesehen, bei dem Außendienst Mitarbeiter Lokal eine DB hatten, die Synchronisiert wurde wenn sie wider im Firmen Netzwerk waren. Da gab es auch einen direkten Zugriff auf dem Server.

Da sind s ein paar Szenarien die mir direkt einfallen. Ich denke da finden sich aber noch ein paar mehr.

Ums noch mal klarzustellen ich sehe auch in Geschätzt 99% der Fälle eine Lösung mit einem Service als Besser an. Ich halte es nur für Falsch von Vorneherein andere Lösungen auszuschließen.

Was den Faktor Zeit und Aufwand angeht. Der ist natürlich Relative gering wenn man Ahnung von der Materie hat. Wenn man aber nur Desktop- und Datenbankentwickler hat ist der Einarbeitungsaufwand auch nicht zu unterschätzen. Und wenn man das Fehler rein baut, weil man nicht genug Ahnung hat kann eine ein WebService schon recht anfällig sein.

Kein Mensch redet von Jeder Zugriff nur über einen Service.
Der Service muss ja auch direkt auf die Datenbank zugreifen.

Hatte ich vorher ja schon in Ähnlicher Form geschrieben. Nur ohne die Entsprechenden Stellen BOLD zu schreiben.

Ich halte aber das Argument, das jeder zugriff auf eine Datenbank nur über einen Service laufen darf. Weil man sonst unsichere Software Programmiert für falsch.

Das inhaltliche Thema seit Anfangan - und von dem hier alle reden, aber Du leider irgendwie ausweichst - ist:
*Kein Zugriff auf eine DB umsetzen, der ein Expose eines Datenbankservers ins Netzwerk/Internet erfordert.*

Datenbanken im Internet zu Exposen habt Palladin007 Explizit ausgeschlossen.

"offen" im Sinne von "offen nur im internen Netzwerk"
Von außerhalb sieht die niemand.

Und ich habe dann auch noch mal darauf hingewiesen. Das auch ich nicht von Externen (Internet) Datenbanken rede.

Es geht mir dabei auch nicht die Datenbank Extern zugänglich zu machen. Da sollte man auf jeden Fall einen Service verwenden.

Also von uns Beiden Kommt eine relative klare Abgrenzung von was wir nicht Reden. Und ich soll jetzt am Thema vorbei reden. OK wie du meinst.

Ich probiere mal eine Formulierung finden, auf die wir uns vielleicht einigen können.

Internet: NIE ohne Service. (Ich denke mal da sind wir uns einig),

Intranet: Ist meist die beste Lösung ein Service. Es kann aber auch Lösungen geben bei der, der direkte zugriff die bessere Lösung ist. Man muss es halt im Einzelfall betrachten. (Ich hoffe mal dass, das eine Formulierung ist mit der du leben kannst. Wenn du möchtest kannst du es natürlich gerne noch mal Konkretisieren. Solange da nicht „NIE ohne Service“ heraus kommt. Werde ich dem wohl zustimmen.)

Lokal: Ein Service macht da nicht wirklich einen Unterschied. Wer möchte kann auch direkt auf die DB zugreifen. (Da du, nach deine Aussage, nie davon geredet hast weiß ich nicht was deine Meinung dazu ist. Also hoffe ich mal das die Formulierung passt.)

@T-Virus
Nein es sind keine Schlechten Beispiel. Selbst wenn das Frontend wirklich schlecht ist. Darf ein Service nicht einfach Daten herausgeben, die nicht für den Benutzer gedacht sind. Wenn du einen Webservice bietest kann Theoretisch erst mal jeder darauf zugreifen und gegebenenfalls sein eigenes Frontend schreiben. Ja hier gibt es Möglichkeiten das einzuschränken. Trotzdem sollte ein Service so Programmiert sein das er es nicht einschränkt.

Was die WAZ angeht. Ich hab sie über das Problem informiert . Und die haben mir zurück geschrieben das sie teils noch Kostenpflichtige Inhalte gratis freigeben. Wenn ich es nutze würde (es ist mir einfach zu Aufwändig) denke ich hätte ich rechtlich relative wenig zu befürchten. Grundlegend könnte man mir noch anprangern, dass ich es hier in dem Forum veröffentliche habe. Und da ich aber die WAZ schon vor über 6 Monaten über das Problem Informiert habe, hatten sie auch genug Zeit es zu beheben.

Ich denke mal der wichtige und richtige Schritt war es die WAZ davon in Kenntnis zu setzten. Im Zweifel hab ich sie ja damit sogar vor Schaden bewahrt.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

P
1.090 Beiträge seit 2011
vor 6 Jahren

Ich brauch einfach zulange um Beiträge zu schreiben.

@Sir Rufo
Mit der Problematik hab ich mich jetzt noch nicht beschäftigt, ich will ja im allgemeinen den Zugriff einschränken.
Aber da ich google Bots den zugriff auf meine Seite Verbieten kann. Denke ich, ich kann auch den umgekehrten Schritt machen und ihnen Inhalte zur Verfügung stellen dehnen ich anderen nicht zur Verfügung stelle.

Beim Spiegel z.B. funktioniert es nicht so einfach. Ja ich hab es ausprobiert als ich gesehen hab, das es bei der WAZ so einfach Funktioniert. Da es aber beim Spiegel für mich komplizierter ist, hab ich es da auch nicht mehr weiter Versucht.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

16.806 Beiträge seit 2008
vor 6 Jahren

Also der SQL Admin wird wohl häufiger direkt auf die Datenbank zugreifen.

Leider, Palin, versuchst Du hier dauernd mit irgendwelchen Argumenten wie diesem hier zu kommen, die mit dem Thema NICHTS, aber auch GAR NICHTS zutun haben. Das ist auch nicht das erste mal. Leider, leider bin ich wieder drauf reingefallen.
Den Rest hab ich ab diesem Satz nicht mehr gelesen. Völlig am Thema vorbei.

Aber um auch das zu beantworten: ja, ein Admin greift direkt auf die Datenbank zu, in dem er sich via RDP oder VNC / VPN auf die Maschine schaltet und lokal das SMS startet. Extern geht in einem ordentlichen Netzwerk nicht, weil die Datenbank nicht exposed ist.

Daher: an dem Punkt klinke ich mich wieder aus.
Schade, hätte ne gute, fruchtbare Diskussion werden können. So nicht.

P
1.090 Beiträge seit 2011
vor 6 Jahren

Das du nicht alles liest was ich schreibe. Ist mir auch schon vorher Aufgefallen.

Das ist sollte aber nicht mein Problem sein.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern