Datenbanken Intern Extern syncronisieren ???

[rossixx]

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.

[AmicaNoctis]

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!

[rossixx]

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.

[unset]

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.

[AmicaNoctis]

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.

[rossixx]

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.

[unset]

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 …

[AmicaNoctis]

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?

[rossixx]

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 ?

[AmicaNoctis]

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.

[unset]

Dazu übrigens unbedingt Wissenswert: http://www.filges.de/infos/echte-dat...mgebungen.html