Sensible Daten vor Angriff schützen

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • Sensible Daten vor Angriff schützen

    Hallo zusammen,

    derzeit entwickele ich ein PHP Script, welches neben anderen sensiblen Kundendaten auch Bankdaten (über figo) der Kunden speichert (Umsätze, Bankingpasswort).

    Da ich mich außer mit globalen Sicherheitsthematiken wie sql injection nicht gerade in der Abschottung der Daten auskenne, wollte ich euch mal fragen, wie ihr vorgehen würdet, da man ja bei fahrlässiger Sicherung der Firmen/Kundendaten schon fast mit einem Bein im Knast steht X/

    Hoster ist All inkl, Deutsches Unternehmen, ist ja erstmal alles schon serverseitig gesichert.

    Hatte jetzt gedacht, ein Backend für die Nutzer zu erstellen, wo sie einmal die Daten eingeben und diese dann auf einen anderen Host in eine Datenbank geschrieben werden und nicht mehr auf dem "Hauptsystem" wo die Domain drauf läuft.

    Der Cronjob und das Script welcher die neusten Umsätze lädt würde auch auf dem Zweitsystem laufen mit Verzeichnisschutz und Bankingpasswort sowie Benutzername am besten noch in unterschiedlichen Datenbanken/Tabellen, damit diese erstmal nicht sichtbar zusammengehören bei einem Diebstahl. Zudem hat nur localhost Zugriff auf die Datenbank, also auch wenn die DB Daten bekannt wären, könnte man von extern keinen Zugriff haben.

    Rein die Ergebnisse des Cronjobs werden dann an die Hauptdatenbank gesandt, welche vom Backend aufgerufen werden können.

    Denke ich da vielleicht 1. zu kompliziert oder 2. auch zu naiv, dass nun die Daten ja "in einem geschlossenen Bereich" stehen und somit für Angreifer nicht aufrufbar?

    Bin mir da total unsicher, habe einen riesen Mehrwert für Kunden aber will auch ruhig schlafen können!

    PS: Vielleicht ist oder muss ja auch das Bankingpasswort verschlüsselt gespeichert werden? Weiß dann nur nicht, wie ich die figo Schnittstelle ansprechen soll?

    Wäre super, wenn ihr mir sagen könnt, ob mein Ansatz sicherheitstechnisch ausreicht oder ich mir tatsächlich einen Sicherheitsexperten zur Rate ziehen sollte, der täglich nichts anderes macht :)

    Danke!
    Tobbe5 8)

    The post was edited 1 time, last by Tobbe5 ().

  • moin,

    wenn es um solche Daten geht, solltest du diese immer verschlüsselt in der Datenbank speichern, denn egal, wie die Datenbank geschützt ist, man muss immer von der Möglichkeit ausgehen,d ass die Daten gestohlen werden können, ganz wird dies nicht vermeidbar sein (siehe prominente Beispiele, vond enen man immer wieder hört).

    Du solltest die Daten mit einem Verfahren verschlüsseln, in dem du einen einzigartigen nur fürdein System passenden Schlüssel hast (mit irgendwelchen einfachen Sachen ahst du hier nichts getan).

    Das Passwort solltest du möglichst nicht nur verschlüsseln, sondern hashen. Der Vorteil daran ist, dass man die gehashten Daten nicht einfach wieder entschlüsseln kann. Umgangssprachlich sagt man auch "einwegverschlüsselung". Wenn die Daten gehasht in der Datenbank stehen bedeutet dies einen unheimlichen Aufwand, dies zurückzurechnen und ist auch nicht mit einem einfachem Algorythmus zu 100% möglich, man kann lediglich mögliche Passwortgleichheiten herausfinden, dies aber ebenfalls nur mit enormen Rechenaufwand. Da ein Hash eine feste Länge, unabhängig des zu hashenden Werts hat, kann man sich ja denken, dass ein Hashwert theoretisch unendlich viele Werte bedeuten können. man rechnet lediglich die wahrscheinlichsten aus. Somit musst du dass Passwort, was zum Login eingegeben wird natürlich nach dem Absenden ebenfalls im gleichem Verfahren hashen und diesen Hash mit dem aus der Datenbank vergleichen. Nur sofern dies noch nicht schon gemacht wurde.

    Für alle anderen Daten, die wieder im System ausgegeben werden, muss natürlich eine Verschlüsselung her, die auch wieder entschlüsselt werden kann, möglichst nur durch dein System (Mal so in ednRaum geworfen: Blowfish).

    Gruß,
    Dennis