Ankündigung

Einklappen
Keine Ankündigung bisher.

Daten unveränderlich speichern

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Daten unveränderlich speichern

    Hallo,

    Ich möchte gerne in den kommenden Monaten eine Anwendung entwickeln, bei der die Daten unveränderlich gespeichert werden.
    Einfaches Hashing oder Signierung zur Prüfung der Integrität reicht nicht aus, da Hash und Signatur "einfach" neu berechnet werden könnten.

    Hat sich von den Anwesenden schon mal einer mit sowas beschäftigt und kann mich auf mögliche Anlaufstellen und Lektüre verweisen?
    Mein erster Gedanke war natürlich eine Blockchain ähnlich den Bitcoins, da werde ich mich auch noch intensiver einlesen, vom ersten drüber Nachdenken scheint es aber wegen des notwendigen Minings eher ungeeignet zu sein.
    Grob gesagt müssten täglich bis zu mehrere tausend Datensätze unveränderlich gespeichert werden, das könnte möglicherweise schnell zu Problemen führen.

    Danke im Voraus für jeglichen Input.
    VokeIT GmbH & Co. KG - VokeIT-oss @ github

  • #2
    Blockchain ist meines Wissens nach das einzige Mittel, um Unveränderlichkeit auf demokratische Weise abzubilden. Da brauchst du aber eine kritische Usermasse für.

    Ich habe natürlich keine Idee, was du da vorhast. Mein erster Gedanke bei dem Titel war einem DB-User alle Rechte bis auf SELECT und INSERT zu nehmen

    Kommentar


    • #3
      Edit: da hat die Forensoftware allen Text nach dem Smiley verschluckt...

      Demokratisch muss es nicht sein, nur revisionssicher
      Soll eine Transaktion geändert werden wird ein Storno vermerkt und eine neue Transaktion erzeugt, die alte bleibt erhalten.
      Quasi Versionskontrolle mit Absicherung, dass da auch kein root dran rumgespielt hat.
      Werde mich weiter in BC vertiefen, vielleicht begegnet mir da auch noch ein performanter Ansatz möglichst ohne Mining, da es keine Serverfarm geben wird, das ganze muss (theoretisch) auf einem RasPi lauffähig sein.
      VokeIT GmbH & Co. KG - VokeIT-oss @ github

      Kommentar


      • #4
        Meinst du in diesem Zusammenhang die GoBD?

        Kommentar


        • #5
          Leider ja ^^
          VokeIT GmbH & Co. KG - VokeIT-oss @ github

          Kommentar


          • #6
            Hast hast du vor? Revisionssicher speichern im Sinne der GDPdU?

            Zitat von G.Schuster Beitrag anzeigen
            Demokratisch muss es nicht sein, nur revisionssicher
            Das ist ja der Witz. Du kannst nichts revisionssicher speichern.
            Git speichert revisionssicher. Aber du kannst trotzdem einzelne Revisionen löschen indem du die Git-Datei neu aufbaust und dabei die nicht-gewollten Daten weglässt (so funktioniert das tatsächlich auch, wenn ich da nicht irre).

            Bei Blockchain kannst du das nicht, weil du die Änderung dann auf allen Rechnern machen müsstest, auf denen eine Kopie der Datenbank liegt. Wenn das so im Kern der Software nicht aus der Ferne steuerbar ist, dann müssten die Parteien, die diese Kopie besitzen aktiv mitwirken, oder du müsstest kurzzeitig mehr Parteien ins Netz bringen, als es aktuell gibt, um die Änderung entgegen des willens der so entstandenen Minderheit durchzusetzen. Deswegen die kritische Masse.

            Zitat von G.Schuster Beitrag anzeigen
            Soll eine Transaktion geändert werden wird ein Storno vermerkt und eine neue Transaktion erzeugt, die alte bleibt erhalten. Quasi Versionskontrolle mit Absicherung, dass da auch kein root dran rumgespielt hat.
            Das kannst du nicht umsetzen.

            Du kannst eine Authorität ins Netz stellen. Wie ein SSL-Zertifikats-Provider quasi. Diese Authorität liefert dann als Beispiel immer eine Liste aller Änderungen in Form von Hashes deiner lokalen Datenbank und macht so jede Änderung sichtbar. Jede Änderung braucht aber vorab(!) einen generierten Hash des jeweiligen Datensatzes von dieser Authorität, da ein Datensatz ohne einen solchen Hash nicht als gültig anerkannt wird.

            Anders wüsste ich nicht, wie das gehen sollte. Du kannst keinen Selbstschutz in eine Datei einbauen. Würde es so eine Lösung geben, würde es keine raubkopierte Software mehr im Netz geben.

            Zitat von G.Schuster Beitrag anzeigen
            Werde mich weiter in BC vertiefen, vielleicht begegnet mir da auch noch ein performanter Ansatz möglichst ohne Mining, da es keine Serverfarm geben wird, das ganze muss (theoretisch) auf einem RasPi lauffähig sein.
            Wo hast du das mit dem Mining her? Das ist ein Währungsdings, um einen Gegenwert für die Währung zu stellen.

            Kommentar


            • #7
              Mit Mining beziehe ich mich auf die Berechnung neuer Blöcke, wie es im Wikipedia-Eintrag steht: https://de.m.wikipedia.org/wiki/Blockchain
              Kann gut sein, dass ich es falsch verstehe oder mit meinem Ansatz vollkommen daneben liege.
              Es geht zunächst nicht um ein verteiltes System, erstmal sollen die Daten unveränderlich auf einem Zielsystem abgelegt werden.
              War vielleicht auch etwas zu früh, dazu schon inns Forum zu schreiben, hatte noch nicht all zu viel Zeit, mich rein zu denken.
              VokeIT GmbH & Co. KG - VokeIT-oss @ github

              Kommentar


              • #8
                Warum kann es keine Archive-Storage-Engine von MySQL sein?

                Kommentar


                • #9
                  Kannte ich offen gestanden bisher nicht, nach kurzem Überfliegen lese ich aber Support für Replace-Statements.
                  Konnte jetzt auf die Schnelle nicht herausfinden, wie das die Engine handhabt, sollte es, wie in anderen Engines, über Delete-Insert laufen wäre Archive keine Option.
                  Hast du da zufällig Erfahrungen damit, rkr ?
                  VokeIT GmbH & Co. KG - VokeIT-oss @ github

                  Kommentar


                  • #10
                    Ich denke ich kann dem Ansatz von rkr folgen, Es sollte kein User die Daten ändern können, also auch der Chef nicht und auch nicht ein eventuell involviertes Wirtschaftsprüfungsinstitut. Ich denke damit ist dem dann genüge getan.

                    Bei der Archive Engine ist ein Delete nicht möglich, Auszug
                    The ARCHIVE engine supports INSERT, REPLACE, and SELECT, but not DELETE or UPDATE. I

                    Kommentar


                    • #11
                      Zitat von G.Schuster Beitrag anzeigen
                      Kannte ich offen gestanden bisher nicht, nach kurzem Überfliegen lese ich aber Support für Replace-Statements.
                      Konnte jetzt auf die Schnelle nicht herausfinden, wie das die Engine handhabt, sollte es, wie in anderen Engines, über Delete-Insert laufen wäre Archive keine Option.
                      Hast du da zufällig Erfahrungen damit, rkr ?
                      Es wundert mich auch gerade, dass REPLACE als Option erlaubt ist. Ein Replace macht im Hintergrund aber nur DELETE+INSERT. Wenn Delete also nicht geht, dann wäre das ja ok (es sollte dann nur ein INSERT stattfinden). Probier' es doch mal und sag ob das so funktioniert, wie gedacht.
                      Bei Archive wäre noch zu beachten, dass man keinen Index setzen kann. Wenn du also möglichst Performant noch mal an die Daten ran musst, würde ich Archive nur als zusätzliche Speicheroption empfehlen.

                      Ansonsten kannst du dir ja mal bigchaindb anschauen

                      Kommentar


                      • #12
                        G.Schuster Reicht es denn, dass du weißt, DAS etwas manipuliert wurde, um dann das System anhalten zu können, oder muss zu jeder Zeit die Datenintegrität vollständig gewährleistet sein?

                        Im ersten Fall könntest du eventuell durch eine Kombination aus Keyed-Hash / eine Signatur, evtl. Trigger, Transaktions-Counter /bzw. Transaction-Log und regelmäßiges Daten-Backup durch die Speicherung eines Wertes erkennen, dass jemand getrickst hat. Der, der den privateKey hat, könnte dann aber mit höhrem Aufwand die Daten wieder manipulieren.

                        Sprich: Bei jedem Query schaltest du ein Script bzw. einen Trigger vor, der aus gesendetem Query und aktuellem Zustand der (System)tabellen einen keyed-Hash / eine Signatur bildet, die man jederzeit verifizieren kann, so lange die Daten integer sind. Wird etwas an den Daten verändert, stimmt der Hash nicht mehr und das System hält an...


                        Tutorials zum Thema Technik:
                        https://pilabor.com
                        https://www.fynder.de

                        Kommentar


                        • #13
                          Du solltest Dir zu dem Thema professionelle Beratung holen.
                          Wir haben das Thema aktuell auch im Unternehmen und lassen uns beraten, weil da ne Menge mehr dran hängt, als man denkt.

                          Auch wenn der ein oder andere hier das kennt und bereits nach GoBD arbeitet, wird in Forendiskussionen so einiges untergehen ( unbeabsichtigt! ).
                          Das kann ärgerlich werden.
                          Competence-Center -> Enjoy the Informatrix
                          PHProcks!Einsteiger freundliche TutorialsPreComposed Packages

                          Kommentar


                          • #14
                            Danke für den bisherigen Input, war durch die Feiertage nur wenig am Rechner

                            Wie extrem das Ganze GoBD-konform werden wird/muss wird sich in den nächsten Planungsstufen zeigen, eine rechtliche Absicherung/Beratung wird, insoweit notwendig, sicherlich auch erfolgen.
                            Unabhängig davon, ob das konkrete Vorhaben letztendlich umgesetzt wird ist es natürlich auch so interessant, sich Gedanken zu den technischen Möglichkeiten zu machen.
                            Größtmögliche Integrität kann man ja doch immer mal wieder brauchen, wenn mit geschäftskritischen Daten gearbeitet wird.
                            VokeIT GmbH & Co. KG - VokeIT-oss @ github

                            Kommentar


                            • #15
                              Was heißt denn hier "unveränderlich"? Solange ich Schreibrechte habe, kann ich doch alles irgendwie verändern. Ich meine, die Veränderung muss ja nicht unbedingt Sinn machen. Einfach im Hash einen Buchstaben ändern und schon ist's geändert. Wenn die Daten geclont noch wo anders liegen, kann man wohl nachvollziehen, dass etwas geändert wurde. Die Änderung selber ließ sich dann aber nicht verhindern.

                              Gut, das war jetzt mal ein Schnellschuss. Vlt. habe ich das Thema aber auch nicht richtig verstanden.
                              [B]Es ist schon alles gesagt. Nur noch nicht von allen.[/B]

                              Kommentar

                              Lädt...
                              X