Hallo

also es gibt eine interne DB, wo z.b. user-daten liegen

und es soll eine externe geschaffen werden, wo die gleichen user-daten liegen sollen.

aus sicherheitsgründen soll / muß diese trennung vorgenommen werden.

im externen / öffentlichen bereich können die user ihre daten bearbeiten / ändern.

und meine idee ist, einmal am tag z.b. einen cronjob laufen zu lassen, der die daten dann in der internen DB anpasst.

bzw. können die leute, die zugang zur internen haben, die DBs auch manuell per klick aktualisieren.

So, ich hoffe das war verständlich und mir kann jemand sagen, ob das so ein vernünftiger weg ist, oder was ich wie ändern sollte ?!?!?

Hallo,

darf man fragen, was das für sicherheitsrelevante Gründe sind und was bei dem Cronjob dann genau passieren soll?

Gruß,

Amica

das eine ist ne interne daten verwaltung - also mit allem was man an kritischen daten haben kann, bankverbindungen, steuernummern, kundendaten, umsätze, rechnungen etc.

und meine bekannten, für die ich das baue, wollen unbedingt eine trennung

beim cronjob sollen die daten die der kunde oder mitarbeiter ändert ( externe DB )

in der internen angepasst werden.

is das zu umständlich?

Werden im Cronjob dabei noch irgendwelche Sachen geprüft, bevor die Daten übernommen werden? Wenn ein User was ändert, tut er das ja in der externen DB. Wenn die dann mit der internen synchronisiert wird, landen die Daten ja trotzdem dort. Worin besteht der Vorteil, diese Daten nicht sofort in die interne einzuspielen?

Diese kritischen Daten sind doch trotzdem sicher, wenn das ordentlich programmiert ist. Wenn es nicht gut programmiert ist, besteht immer noch Gefahr, dass ein Angreifer manipulierte Daten in die externe einspielen kann, die dann bei der Synchronisation in die interne übernommen werden. Die Trennung alleine bringt imho keine zusätzliche Sicherheit.

Daher die Fragen: Was genau passiert bei dem Cronjob? Was macht der Cronjob in Bezug auf die Sicherheit anders als das dem User zur Verfügung stehende Änderungsskript? Inwiefern unterscheiden sich die beiden DBs inhaltlich überhaupt?

natürlich werden beim einholen in die interne nochmal die daten gecheckt.

das problem war, das vor 2jahren eine externe anwendung gehackt wurde, und die website bei einigen suchmaschinen als gefährdet gekennzeichnet war.

ich habe mit der externen seite nix zu tun. ud kann dazu nicht viel sagen.

aber deshalb legt man jetzt ganz besonderen wert auf die trennung von

extern zugänglich und besonders gefährdet

und intern besonders geschützt, auch wenn dies paranoid erscheint

und meine bekannten, für die ich das baue, wollen unbedingt eine trennung
Weil sie glauben auf einer Festplatte im Büro sind die Daten sicherer als auf einem Server im Internet? Das ist per se nicht der Fall und es sieht so aus als wärst du derjenige, der sie darüber aufklären sollte.
beim cronjob sollen die daten die der kunde oder mitarbeiter ändert ( externe DB )
Auf der internen DB wird also gar nicht gearbeitet (nur Backup) oder nur read-only? Dann kann das Synchronisieren per Cron einfach mit mysqldump erledigt werden.

das problem war, das vor 2jahren eine externe anwendung gehackt wurde, und die website bei einigen suchmaschinen als gefährdet gekennzeichnet war.

Das meine ich ja: Dann war es schlampig programmiert (oder mit zu schwachen Passwörtern gesichert). Mit einer ähnlich schlampigen Programmierung könnte ein Angreifer trotzdem die externe DB hacken und diese Benutzerdaten einsehen:

und es soll eine externe geschaffen werden, wo die gleichen user-daten liegen sollen.


Zurück zum Thema: Du kannst das mit einem Cronjob machen, kein Problem, aber deine Auftraggeber sollten sich durch diese (imho zu kurz gedachte) Trennung keine zusätzliche Sicherheit versprechen, sondern lieber darin investieren, die externe DB und die damit verbundenen Skripte sicher zu machen, als etwas unsicheres hin und her zu kopieren.

upps

der "interne Server" wird natürlich zum arbeiten verwendet.

es geht glaube ich vor allem um die trennung von extern und intern.

da die befürchtung besteht, das der öffentliche bereich geknackt werden könnte.
und in diesem fall wären nur die nicht-kritischen daten betroffen.

oder würdet ihr z.b. ne buchhaltungssoftware freischalten, das die mitarbeiter ihre daten ändern können ?!?!

zumal die geänderten daten - grundsätzlich überprüft werden müssen. also nicht nur per skript auch per mitarbeiter.

z.b.

2 neue datensätze in der DB
5 datensätze geändert
anzeigen der datensätze etc.

oder würdet ihr z.b. ne buchhaltungssoftware freischalten, das die mitarbeiter ihre daten ändern können ?!?!

Die Mitarbeiter sollen dafür gefälligst auf Arbeit kommen ;) Aber ich würde ggf. den Klienten ein Login zur Verfügung stellen, so dass sie ihre Daten ändern können. Die DB dafür hätte ich trotzdem intern, die Skripte die auf diese DB zugreifen würde ich auf den Bastion Host legen und damit nach außen zur Verfügung stellen. Wo läge da das Problem? Selbst wenn einer das DB-Passwort erraten würde, müsste er erstmal in die demilitarisierte Zone eindringen, um auf die DB zugreifen zu können.

Anstatt Alchemie zu fröhnen und mystisch-komplex die Datenhaltung aufzusplitten, sie dann aber mehr oder weniger stümperhaft wieder zusammenzuführen, würde ich lieber ein paar Mark in die Hand nehmen und jemanden engagieren, der Ahnung davon hat, wie man ein Netzwerk sauber und effektiv abschirmt bzw. schützt – und natürlich auch entsprechend fähige Entwickler einsetzen bzw. den bestehenden Schulungen oder Ausbildung bezahlen, sofern sie keine Ahnung haben. Für mich wirkt das vorgehen nämlich reichlich kopflos und mehr wie eine "Probieren wir es mal so"-Entscheidung.

hört sich soweit gut an.

da es aber eine mittlere katastrophe gab und nicht geklärt werden konnte, wo die sicherheitslücke lag.

also bei den normalen mitarbeitern, bei den webdesignern / programmierern oder externe webanwendungen...

und genau deswegen diese trennung als logische sicherheitsstufe. vielleicht sind ja auch die zuständigen für den externen ( webbereich ) nachlässig.

also ich hab nicht die zeit deren skripte zu checken.

vielleicht ist das auch ne grundsatzdiskussion, wie arbeiten mit externen firmen bzw. entwicklern ???

da es aber eine mittlere katastrophe gab und nicht geklärt werden konnte, wo die sicherheitslücke lag.
Die eigentliche Katastrophe ist eigentlich, dass das nicht ermittelt wurde. Woher wollt ihr wissen, dass die Sicherheitslücke nicht weiterhin existiert. Das ist nicht nur meinem persönlichem Empfinden nach fahrlässig, sondern wird im Falle eines Falles auch vor Gericht nicht großartig anders aussehen!

Ich frag mich ernsthaft, was da unternommen wurde? Wurde der Service umgehend eingestellt. Wurde einfach nichts gemacht? Das Einfallstor ist ja offensichtlich nie geschlossen worden.

vielleicht ist das auch ne grundsatzdiskussion, wie arbeiten mit externen firmen bzw. entwicklern ???
Das macht eigentlich früher oder später bzw. im großen oder kleinen Ausmaße jeder. Aber auch hier: Fähige Leute aussuchen. Nicht den erstbesten Oberstufler in den Sommerferien nehmen, der das ganze für 5 EUR die Stunde macht.

nein ermittelt wurde die sicherheitslücke nicht.

aber dafür der gesamte webspace gelöscht, da niemand mit sicherheit sagen konnte, was das problem verursacht hat.

vor gericht soll sowas erst gar nicht gehen. denn wie gesagt, die internen daten dürfen nicht verloren gehen, komme was da wolle.

und oberstufler oder berufsneulinge arbeiten eigentlich nicht in diesen bereichen.

aber ist das mit den zwei DBs und verschiedenen Servern nachvollziehbar oder paranoid oder einfach zu aufwendig ???

aber ist das mit den zwei DBs und verschiedenen Servern nachvollziehbar oder paranoid oder einfach zu aufwendig ???

Nachvollziehbar ist es für mich nicht (aus genannten Gründen). Paranoid wäre es eventuell, wenn es was bringen würde, tut es aber nicht, daher ist es eher eine naive Idee. Zu aufwändig ist es auch, vor allem, weil der Aufwand keinen nennenswerten Nutzen bringt.

und oberstufler oder berufsneulinge arbeiten eigentlich nicht in diesen bereichen.
Das war natürlich nur stellvertretend für "Den erst besten" gemeint.

aber ist das mit den zwei DBs und verschiedenen Servern nachvollziehbar oder paranoid oder einfach zu aufwendig ???
Für mich erschließt sich hier kein Nutzen.

OK.

ich versteh die benannten punkte.

und wenn ich davon ausgehen würde, das alle immer 100% sicher programmieren ( wie ihr ?! )

würde ich vermutlich auch für eine Server eine DB stimmen.

aber leider kann oder will sich hier keiner auf das 1er modell verlassen.

mehr arbeit klar. mehr sicherheit??? das wird gehofft.

-------------------------

nur so als beispiel das 1server 1DB modell, die externe firma übersieht ein sicherheitsloch, zack alle daten futsch.

beim 2er modell, bin ich nunmal der mitverantwortliche und werde zusehen, das genau das nicht passiert. in meinem verantwortungsbereich.

und selbst wenn im externen was schief läuft, sind die daten noch intern vorhanden.

--------------------------

und bei anderen jobs, gab es firmen, die hatten ihre db grundsätzlich von allem getrennt auch vom internet. und eine person war nur zuständig alle daten in diese einzutragen. sowas nenne ich auch umständlich.

und selbst wenn im externen was schief läuft, sind die daten noch intern vorhanden.

Dafür gibt es Dumptimer oder andere Backup-Lösungen, die man sowieso immer haben sollte!

OK. Ich habe ein einsehn - ich bin paranoid, da ich den externen nicht traue. und somit das zweier modell unterstütze.

ABER,

was ist mit datendiebstahl ? da hilft auch kein backup.

und wenn ich davon ausgehen würde, das alle immer 100% sicher programmieren ( wie ihr ?! )
Davon gehe ich nicht aus (und das wird auch niemand, der auch nur halbwegs professionell arbeitet), aber ich versuche mangelnde Sicherheit nicht mithilfe von –*wie eben schon erwähnt –*fragwürdigen Konstrukten auszugleichen.

mehr arbeit klar. mehr sicherheit??? das wird gehofft.
Und hier ist das Problem: Du weißt es doch gar nicht. Meiner Meinung nach sehe ich keine höhere Sicherheit. Daten sind auf beiden Seiten deiner Struktur vorhanden. Ob ich nun Bestand A oder Bestand B auslese und damit evtl. eine Handvoll Datensätze unterschiedlich sind, ist mir egal, wenn ich da dran will.

Bevor ich ein Konzept umsetze, stelle ich zunächst sicher, dass das, was ich damit erreichen will, auch erreicht wird. Auf gut Glück "mal etwas probieren" wird euch neben zusätzlicher Arbeit auch noch den Anschein von Sicherheit bringen, der fatal sein kann.

nur so als beispiel das 1server 1DB modell, die externe firma übersieht ein sicherheitsloch, zack alle daten futsch.
Dafür gibt es Backups. Worum geht's denn nun? Dass die Daten nicht gelöscht werden? Dass die Daten nicht manipuliert werden? Dass die Daten nicht gestohlen werden? So oder so, dein Modell bietet – zum wiederholten male – keinen Mehrwert dahingehend.

beim 2er modell, bin ich nunmal der mitverantwortliche und werde zusehen, das genau das nicht passiert. in meinem verantwortungsbereich.
Du bist, wenn du an der Entwicklung beteiligt bist, so oder so mitverantwortlich. Wenn dein Dienstleister scheiße baut, dann bist du immer noch derjenige, der dafür grade stehen muss, warum du dir grade den ausgesucht hast. Und wenn du wirklich so viel Angst davor hast, dass der Dienstleiter unfähig ist: Warum wird nicht jemand geholt, der Ahnung davon hat? Ich habe dich hier nicht dannach fragen sehen …

und bei anderen jobs, gab es firmen, die hatten ihre db grundsätzlich von allem getrennt auch vom internet. und eine person war nur zuständig alle daten in diese einzutragen. sowas nenne ich auch umständlich.
Ja, und auch hier ist der Mehrwert fraglich.

was ist mit datendiebstahl ? da hilft auch kein backup.

Das ist richtig, aber dagegen kann man vorsorgen. Wenn die DB nur Logins von localhost aus erlaubt, muss der Datendiebstahl über die Skripte erfolgen und die kann man dagegen absichern. Wenn man dann noch den FTP-Zugang auf den Server nur über SSL erlaubt, kann auch niemand eigene Skripte hochladen. Dann noch Benutzerpasswörter prüfen und nur sichere Passwörter zulassen und wer dann noch reinkommt, hat es sich verdient. ;)

es soll um den schutz vor ungewollten löschen, auslesen und ändern der daten gehen.

ich verstehe eure kritikpunkte. aber wie schon geschrieben, gegen einen diebstahl hilft kein backup.

und ich bin für den / die externen nicht verantwortlich, das ist die geschäftsleitung. die wollten / wollen die trennung.

mal vom mehraufwand abgesehen. geht es hier vielleicht auch darum, grundsätzlich die internen daten intern zu halten.

ja und jetzt könnte der vorschlag kommen, die DB so zu konfigurieren, das die externen nur die tabellen zu sehen bekommen, die sie sollen. bzw. die rechte die sie brauchen.

naja vielleicht will ja der eine oder andere am samstag nochmal drüber reden, wenn die zeit übrig sein sollte.

ich verstehe eure kritikpunkte. aber wie schon geschrieben, gegen einen diebstahl hilft kein backup.
du verstehst offensichtlich nicht, dass auch diese Trennung nicht gegen Diebstaht hilft …

und ich bin für den / die externen nicht verantwortlich, das ist die geschäftsleitung. die wollten / wollen die trennung.

Hast du sie schon darüber aufgeklärt, dass das nach deiner fachlich fundierten Meinung keinen Sicherheitsvorteil bringt?

die fachleute seit ihr, deshalb stelle ich das hier zur diskussion.

ich bin nur für interne skripte zuständig.

also mal abgesehen von der sicherheitsfrage. wenn man der externen firma bzw. programmierer keinen zugang zu den internen daten gewähren will.

wie würde dann ein optimales system aussehen ?

die fachleute seit ihr, deshalb stelle ich das hier zur diskussion.

ich bin nur für interne skripte zuständig.

also mal abgesehen von der sicherheitsfrage. wenn man der externen firma bzw. programmierer keinen zugang zu den internen daten gewähren will.

wie würde dann ein optimales system aussehen ?

Genau so, nur dass man denen dann nicht die echten Zugangsdaten gibt oder nur welche für eine Mock-DB. Wenn die fertig sind, tauscht man dann die DB-Credentials gegen die des Live-Systems aus. Wenn die was ändern müssen, macht man es über CSV/SVN, so dass die nur Patches schicken, und nur jemand autorisiertes die dann ins echte System einpflegt. So haben die keine Möglichkeit, die DB-Credentials in den Skripten zu sehen und arbeiten selbst nur mit einer lokalen Kopie davon.

Dazu übrigens unbedingt Wissenswert: http://www.filges.de/infos/echte-daten-in-testumgebungen.html