Wir sind eine mittlegroße Halbleiterfirma, die in den letzten Jahren gut gewachsen ist und nun in die "erwachsene" Welt eintritt. Immer mehr kriegen wir externe Audits, und wurden deshalb vor kurzen nach ISO 9001 Zertifiziert. Bei uns, in der Qualifikation, gibt es einige eigene Hardware/Softwarelösungen: Messgeräte/Messstände die wir in-house programmiert haben und einige HL-Bauteile auf Herz und Nieren testen. Immer öfter fragen die Auditoren, wie wir unsere eigene Messsysteme pflegen. Insbesonderes sind folgende Themen wichtig: - Versionsüberwachung - Absicherung der Konfigurationsdatei (wie stelle ich sicher, dass die Bauteile bei den richtigen Einstellungen/Bedienungen gemessen wurden) - Wie kann ich den Kunden garantieren, dass keiner die Messdatei manuell nachher verändert hat etc. Mein Chef hat mir gestern gesagt: "Böser K., überleg dir mal, wie wir das bis zum nächsten Audit klären". Ich bin Entwicklungsingenieur im Bereich der Messtechnik und habe von Audits keine Ahnung:) Folgendes hab ich mir überlegt: Nach jeder Postenmessung (100+ Wafer, ca. 100000 Bauteile) wird eine SHA256 Hash von der Konfigurationsdatei und der Messdatei automatisch erstellt und sicher in "Read Only" Modus gespeichert. So kann der Auditor, wir und der Kunde nach X Jahren immer noch feststellen, ob sich plötzlich irgendwas bei den Messbedingungen verändert hat. Genau so wird die eigentliche Messdatei gegen spätere Änderungen geschützt. Aber wo speichere ich die Datei? Kann ich die bei uns auf dem Server lagern? Wäre vllt. eine Cloud-Lösung besser (SO können unsere Kunden jederzeit drauf zugreifen)? Meine konkrete Fragen: - Wie finde ihr die Idee? - Gibt es schon eine seriöse, kommerzielle Softwarelösung die genau das macht was ich beschrieben habe? - Habt ihr bessere Vorschläge? Freue mich auf ein Feedback:)
Böser K. schrieb: > Aber wo speichere ich die Datei? Kann ich die bei uns auf dem Server > lagern? Böser K. schrieb: > Habt ihr bessere Vorschläge? Ja! Ein Datenbanksystem was nicht nur den prüfablauf bzw die prügparameter, sondern auch die Messwerte beinhaltet. Das schöne ist, dass du so jederzeit Schwankungen in deiner Produktion auch ansehen und erkennen kannst. Die Messwerte, prüfparameter und ihre Grenzwerte versionierst du durch die Datenbank genau so wie du die eigentliche Software durch eine softwareversionierung versionierst. Wenn deine prufsysteme sich die Software und prüfpläne jeweils aktuell vom Server holen, ist sowohl ne schnelle Änderung als auch die konsistente Versionshaltung sichergestellt! Systeme gibt's wie Sand am Meer. Eigenbau geht auch, fällt aber nicht vom Himmel, dafür ist man dann flexibel. Es muss nicht immer aegis sein :)
Hallo, ist es möglich gleich bei der Messung die Daten der Konfigdatei mit zuspeichern, so dass die Konfigdaten gleich mit der Messung verheiratet werden? Habt ihr ein DMS-System. (Dokumenten-Management-System)? Hier gibt auch käufliche Lösungen. Hier automatisch die Datei vom Messsystem nochladen lassen. Dort wird sie automatisch versioniert und gesichert. So kann man sie vor Manipulation sichern. (In den Systemen wird benutzerfreundlichgleich ein Hash gebildet, das ganze gesichert und dieses übernimmt die DMS-Software bzw. der Anbieter dieser Software, so dass ihr nur die Schnittstelle für den automatischen Upload bereitstellen müsst. Die Suchfunktion ist dann sehr benutzerfreundlich. Ganz elementare Punkte scheint ihr ja gelöst zu haben, da diese Fragen nicht erwähnt wurde: Sind die Messmittel genau im Protokoll mit ihren Messunsicherheiten vermerkt? Sind alle Messmittel kalibriert? Ist die Kalibrierung auf eine Daaks Akkreditierte Stelle mit auf die PTB rückführbaren Prüfnormlen geprüft? usw.
CÄ schrieb: > Sind die Messmittel genau im Protokoll mit ihren Messunsicherheiten > vermerkt? Hat das wirklich schon jemand bei dir verlangt? Höchstens ein Kundenwunsch? Bei uns reicht eigentlich der vorhandene Daaks und ne allgemeine Aussage zu verwendeten Messmitteln bzw Unsicherheit, aber nicht extra pro Prüfprotokoll? Messmittel an sich werden dann gesondert nachgehalten und sozusagen über den verwendungsort implizit referenziert.
Dunno.. schrieb: > Ein Datenbanksystem was nicht nur den prüfablauf bzw die prügparameter, > sondern auch die Messwerte beinhaltet. Ja, ein Datenbanksystem versucht unsere IT schon seit...5-7 Jahren einzurichten :D Manche Anlagen sind schon an DB angebunden, aber nur wenige, sehr teure Messsysteme die wir komplett gekauft haben. CÄ schrieb: > Habt ihr ein DMS-System Wir haben ein IMS, nicht sicher ob es das gleiche ist. Dort werden die Messdaten auch automatisch hochgeladen, aber die lassen sich nachher verändern. So haben schon manche hochrangige Genies aus Sales and Co. die Messdateien ändern lassen, damit die Aubeute besser wird und man mehr verkaufen kann. Ja, sowas gibt es auch....
:
Bearbeitet durch User
Dunno.. schrieb: > CÄ schrieb: >> Sind die Messmittel genau im Protokoll mit ihren Messunsicherheiten >> vermerkt? > > Hat das wirklich schon jemand bei dir verlangt? Höchstens ein > Kundenwunsch? Ganz konkret verfolgt mich genau dieser Wunsch sogar seit meinem Studium. Dies war sogar schon die Forderung von meinem Prof. im Messtechniklabor. Seit dem hab ich dieses immer gleich mit in die Risikobetrachtung einfließen lassen. Eine Risikobetrachtung ist übrigens auch eine Forderung der 9001 seit der Version 2015. d.h. zum Beispiel misst du 100V mit einer Abweichung von 1% und hat dein Messgerät eine Unsicherheit von 0,1% musst du vereinfacht gesagt die Grenze zwischen 99,1 und 100,9V festlegen und nicht zwischen 99 und 101V. Genau dieses wurde mir (zugegeben bei Ableitwertmessungen, Abschaltbedingugnen im Personenschutzbereich vom VDE Prüfer bei der Baumusterfreigabe einer Spannungsquellen) verlangt. Und zwar mit Verweis auf die 9001 Punkt Risikobetrachtung Messunsicherheitseinpflege in Dokumentation und Grenzwertvorgaben. Ich kenne auch, dass das genaue Messmittel aufgeschrieben wird. Hintergrund. Ihr habt zwei Messgeräte gleichen Typs. Jetzt kommt raus, dass eines dieser Messmittel falsch gemessen habt (defekt war). Nehmt ihr es genau, müsst ihr alle Messungen dieses Messmittels seit der letzten Überprüfung wiederholen oder als unsicher kennzeichnen. Habt ihr nicht den Typ festgelegt (Inkl. Serialnr des Messgerätes) müsst ihr theoretisch alle Messungen, wo dieses Messmittel eingesetzt worden sein könnte als unsicher deklarieren und ggf. wiedeeholen.
Böser K. schrieb: > CÄ schrieb: >> Habt ihr ein DMS-System > > Wir haben ein IMS, nicht sicher ob es das gleiche ist. > > Dort werden die Messdaten auch automatisch hochgeladen, aber die lassen > sich nachher verändern. So haben schon manche hochrangige Genies aus > Sales and Co. die Messdateien ändern lassen, damit die Aubeute besser > wird und man mehr verkaufen kann. > > Ja, sowas gibt es auch.... Ein IMS ist ein integriertes Managementsystem Bei einem DMS dokumenten Managementsystem ist gerade der Vor- oder Nachteil, dass eben die Dokumente nicht geändert werden können. Beim ändern wird einen neue Version angelegt. Die alte kann aber nicht gelöscht werden bzw. man kann immer noch auf die alte VErsion zurückspringen. So kann der Kunde, Auditor oder hier die ganze Datenhistorie sehen. d.h. wurde z.B. etwas geändert, da ihr z.B. anmerkt, dass dieser Wert nicht relevant ist, oder die Vorgabe fü rden Kunden nachträglich geändert wurde seht ihr, dass die lteversion die Messung als Fehler deklariert, das 2. Dokument die Messung nach händischer Änderung als i.O. gekennzeichnet ist und im Idealfall hat der Sachbearbeiter die Email vom Kunden hinterlegt, der mit der Messwertausweitung einverstanden war und deshalb die händische nachträgliche Anpassung korrekt war. Aber alle Versionen ist einsehbar mit Historie.
Böser K. schrieb: > Nach jeder Postenmessung (100+ Wafer, ca. 100000 Bauteile) wird eine > SHA256 Hash von der Konfigurationsdatei und der Messdatei automatisch > erstellt und sicher in "Read Only" Modus gespeichert. Das ist schon mal gar nicht schlecht. Es könnte aber z.B. jemand hergehen und nachträglich sowohl die Daten als auch den Hash zueinander passend verändern. Dagegen gibt es 2 Lösungen: 1. Du holst Dir einen externen Zeitstempeldienst mit ins Boot der Dir einen kryptographisch signierten Zeitstempel auf Deinen SHA256 Hash gibt. Siehe: https://en.wikipedia.org/wiki/Trusted_timestamping https://www.freetsa.org/index_en.php 2. Blockchain. Du nimmst also einfach den SHA256 Hash von der vorigen Messreihe und fügst ihn an den Anfang der Daten der nächsten Messreihe hinzu. Damit wird der Hash immer über die Messdaten und den vorigen Hash erzeugt, die Hashes damit verkettet. Wenn jemand also Messdaten von vor einem Jahr nachträglich verändern will, müsste er auch alle darauffolgenden Messdaten mit verändern damit die Manipulation nicht auffällt.
CÄ schrieb: > Hintergrund. Ihr habt zwei Messgeräte gleichen Typs. [..] Ist bei uns sichergestellt über die Information welches Messmittel (SN) wann wo verbaut war (die rotieren zb bei Kalibrierung). Da ich zum Prüfergebnis aus der DB weiß wann und wo es aufgenommen wurde, könnte ich bei Nichtbestehen der Kalibrierung exakt sagen welche Prüflinge betroffen sind. Das Prüfergebnis selbst weiß aber nichts davon. Das mit der Risikobetrachtung ist interessant. Vermutlich bei uns nicht soo wichtig weil die Messgeräte deutlichst präziser sind als die Grenzwerte.. aber das ist nicht mein Fachgebiet..
Böser K. schrieb: > Ja, ein Datenbanksystem versucht unsere IT schon seit...5-7 Jahren > einzurichten :D Naja, von ner IT würde ich höchstens erwarten dass sie die Maschine auf dem das läuft warten und mir vielleicht noch die Datenbankinstanz zur Verfügung stellen. Den ganzen Rest sehe ich eher als Thema für ne Softwareentwicklung..
DMS ist ja schon gefallen, ein anderer Begriff ist revisionssicheres Archiv. Mal bei IT/Buchhaltung nachfragen. Wie Du Manipulationen verhindern kannst? Meist gar nicht, aber Mal mit 2 Leuten den ganzen Prozess durchgehen und bei Zugriffsrechten zum Ändern 4-augen + loggen.
Beitrag #6139368 wurde von einem Moderator gelöscht.
Gerd E. schrieb: > Du nimmst also einfach den SHA256 Hash von der vorigen Messreihe und > fügst ihn an den Anfang der Daten der nächsten Messreihe hinzu. Damit > wird der Hash immer über die Messdaten und den vorigen Hash erzeugt, die > Hashes damit verkettet. Wenn jemand also Messdaten von vor einem Jahr > nachträglich verändern will, müsste er auch alle darauffolgenden > Messdaten mit verändern damit die Manipulation nicht auffällt. Sehr guter Weg.
War nur eine Frage der Zeit bis der erste hipster Trotte mit blockchain ankommt. Blockchain ist NICHT manipulationssicher.
Böser K. schrieb: > Immer öfter fragen die Auditoren, wie wir unsere eigene Messsysteme > pflegen. Insbesonderes sind folgende Themen wichtig: > > > - Versionsüberwachung > > - Absicherung der Konfigurationsdatei (wie stelle ich sicher, dass die > Bauteile bei den richtigen Einstellungen/Bedienungen gemessen wurden) > > > - Wie kann ich den Kunden garantieren, dass keiner die Messdatei manuell > nachher verändert hat etc. Häh?! das Wichtigste fehlt der Kalibrierungsplan, also welche Prüfmittel unterliegen einer regelmäßigen Kalibrierung und welche nicht und ist eine fristgerechte Kalibrierung termingerecht sichergestellt. Der Rest ist mit dem Prüfprotokoll abzuhandeln, das kann separat zu den roh-messdaten abgespeichert sein, das erschwert die nachträgliche Veränderung des Messergebnisses. Ansonsten das übliche, Prüfsumme bilden, backups ziehen, Zugangssicherung zum Serverraum. Und natürlich hat es auchen einen Prüfplan auf papier der die (wichtigsten) Einstellungen und Prüfmittel (Inventarnummer!) nennt. Respektive Screenshoots zur Überprüfung derselben enthält. Messkabel sollten auch inventarisiert sein und Referenzmessung mit "golden Sample" macht sich auch gut zur Absicherung des Messung/Prüfung.
Im Prinzip musst du nur Prozesse haben die "sauber" sind. Zieh dir mal die ISO 17025 rein. Da geht's genau um so dinge wie Wie wird Kalibriert Wer darf Kalibrieren Wer darf welches Messmittel bedienen Was passiert falls mal was daneben geht ... 73
Böser K. schrieb: > Immer mehr kriegen wir externe Audits, und wurden deshalb vor kurzen > nach ISO 9001 Zertifiziert. Ein großer Fehler. Vielleicht nicht für den Geldbeutel, aber für die Nerven.
Nun, ISO9001 ist ja das Papier nicht mehr wert, auf dem es steht ;-( Schau dir mal die 17025 an... Dann weist du, wohin du steuern musst 8-/
Naja die "neue" 17025 hätte die 9001 gerne als grundlage... Ganz rausgeschmissen ist das also nicht. 73
Böser K. schrieb: > - Absicherung der Konfigurationsdatei (wie stelle ich sicher, dass die > Bauteile bei den richtigen Einstellungen/Bedienungen gemessen wurden) > > - Wie kann ich den Kunden garantieren, dass keiner die Messdatei manuell > nachher verändert hat etc. Append-only-Filesysteme, Hash-gesichteres Logfile, etc. Gerd E. schrieb: > Blockchain. Bitte erzeähl uns mehr. Was soll ihm eine Blockchain bringen, außer einen Sieg im Bullshitbingo? Gerd E. schrieb: > Du nimmst also einfach den SHA256 Hash von der vorigen > Messreihe und fügst ihn an den Anfang der Daten der nächsten Messreihe > hinzu. Damit wird der Hash immer über die Messdaten und den vorigen Hash > erzeugt, die Hashes damit verkettet. Wenn jemand also Messdaten von vor > einem Jahr nachträglich verändern will, müsste er auch alle > darauffolgenden Messdaten mit verändern damit die Manipulation nicht > auffällt. Das hat nichts, aber auch gar nichts mit einer Blockchain zu tun. Das ist ein ganz normales kryptografisch gesichertes Logfile. Allerdings hast du insofern recht, dass genau dieser Lösungvorschlag der richtige ist. Deswegen braucht er auch keine tolle Blockchain (auch wenn irgendwelche Verkäufer ihm das sicher gerne einreden würden). Surety (www.surety.com, "Surety is the leading provider of technology to protect the integrity of digital information") publiziert seit 1995 übrigens einfach wöchentlich die verkettete Prüfsumme ihrer Logfiles im Anzeigenteil der New York Times um deren Integrität nachzuweisen. Da man davon ausgehen kann, dass sämtliche Ausgaben der NYT irgendwo archiviert werden, eine elegante Lösung um die Prüfsummen bei einer unabhängigen Instanz für (fast) die Ewigkeit zu publizieren. Man sieht, sowas wie eine Blockchain brauchst du nicht. Ein paar Zeilen Shellscript und eine paar Euro im Jahr für Zeitungsannoncen, mehr braucht es nicht. Freut natürlich die teuren Blockchain-Consulter nicht. Wenn du es selbst nicht implementieren willst, kannst du natürlich auch genau das als Dienstleistung von Surety einkaufen: http://surety.com/digital-copyright-protection/prove-ownership Wahrscheinlich gibts was ähnliches sogar von SAP, wenn man drauf steht. Rudolph schrieb: > War nur eine Frage der Zeit bis der erste hipster Trotte mit blockchain > ankommt. Blockchain ist NICHT manipulationssicher. Vor allem ist es ganz einfach das falsche Werkzeug für dieses Problem. Messknecht schrieb: > Nun, ISO9001 ist ja das Papier nicht mehr wert, auf dem es steht ;-( Und trotzdem steht das Management drauf.
BTW, am einfachsten wäre es sogar, "git" dafür zweckzuentfremden. Jede Revision ist per Hash identifizierbar, der sowohl von den aktuellen Änderungen, als auch allen Änderungen davor abhängig ist. Du kannst die Daten also nicht nachträglich manipulieren, ohne dass alle darauffolgenden Einträge ungültig werden. Also Messprotokoll einfach in git ablegen, und den Hash der obersten Revision periodisch für die Kunden publizieren oder bei einem Notar hinterlegen.
vn nn schrieb: > Append-only-Filesysteme, Hash-gesichteres Logfile, etc. > > Gerd E. schrieb: >> Blockchain. > > Bitte erzeähl uns mehr. Was soll ihm eine Blockchain bringen, außer > einen Sieg im Bullshitbingo? Na das wäre der theoretisch zur Zeit auf der Erde erreichbare Maximalzustand von "Append-Only" und "manipulationssicher", wenn dieses Maximum gefordert ist dann gehts nicht anders. Natürlich keine eigene private Blockchain die nur im eigenen Serverraum existiert (wie es sich die ganzen Bullshit-Bingoisten meist vorstellen, das wäre in der Tat nutzloser Bullshit) sondern da müsste er schon auf einer der großen etablierten internationalen Blockchains mitreiten um sich deren Manipulationssicherheit zunutze zu machen. Halte ich aber für totalen Overkill bei sowas banalem und unwichtigem wie Konfig-Dateien die eh keiner fälschen will.
:
Bearbeitet durch User
vn nn schrieb: > Das hat nichts, aber auch gar nichts mit einer Blockchain zu tun. Das > ist ein ganz normales kryptografisch gesichertes Logfile. Dieses Konzept ist auch unter dem Namen "Blockchain" bekannt, daher vermutlich Deine Verwirrung. > Surety (www.surety.com, "Surety is the leading provider of technology > to protect the integrity of digital information") publiziert seit 1995 > übrigens einfach wöchentlich die verkettete Prüfsumme ihrer Logfiles Klingt nach Blockchain, allerdings eine private, wenns noch sicherer sein soll würd ich eine öffentliche Blockchain nehmen.
:
Bearbeitet durch User
Bernd K. schrieb: > vn nn schrieb: >> Append-only-Filesysteme, Hash-gesichteres Logfile, etc. >> >> Gerd E. schrieb: >>> Blockchain. >> >> Bitte erzeähl uns mehr. Was soll ihm eine Blockchain bringen, außer >> einen Sieg im Bullshitbingo? > > Das wäre der theoretisch zur Zeit auf der Erde erreichbare > Maximalzustand von "Append-Only" und "manipulationssicher". Was genau ist daran manipulationssicherer als Hash Chain und die Hashes regelmäßig publizieren? Im billigsten Fall wäre das git + Anzeigenteil einer beliebigen deutschen Tageszeitung. Bernd K. schrieb: > Halte ich aber für totalen Overkill bei sowas banalem und unwichtigem > wie Konfig-Dateien die eh keiner fälschen will. Sie ist schlichtweg das falsche Werkzeug. BTW, es geht nicht ums fälschen von Configfiles, sondern von Messprotokollen. Und dass Messprotokolle nachträglich verändert werden, um Qualitätsprobleme zu verschleiern, ist nun wirklich nicht so weit hergeholt...
vn nn schrieb: > Im billigsten Fall wäre das git + Anzeigenteil > einer beliebigen deutschen Tageszeitung. Klar. Git ist ja schließlich auch eine Blockchain. Aber nur die Hashes im Anzeigenteil zu veröffentlichen reicht nicht, jeder muß es im Zweifel auch selbst nochmal nachprüfen können und dazu mußt Du das ganze Repository zugänglich machen.
:
Bearbeitet durch User
Bernd K. schrieb: > Dieses Konzept ist auch unter dem Namen "Blockchain" bekannt, daher > vermutlich Deine Verwirrung. Nein. Nochmal, eine Hashchain hat nichts mit dem Hype-Bullshit namens Blockchain zu tun. Hashchains gibt es seit Jahrzehnten. Google es halt, wenn du den Unterschied nicht kennst. Wikipedia sollte als Einstieg für dich ja reichen... https://en.wikipedia.org/wiki/Hash_chain#Hash_chain_vs._blockchain https://en.wikipedia.org/wiki/Linked_timestamping Blockchains dienen dazu, dass Parteien, die sich gegenseitig nicht trauen, einen Konsens finden, z.B. per Proof of Work (mit allen bekannten Sicherheitsproblemen). Um ein Logfile abzusichern, reicht ein verketteter Hash, der an die andere Partei weitergegeben oder gar publiziert wird. Wofür soll das Proof of Work benötigt werden? Bernd K. schrieb: >> Surety (www.surety.com, "Surety is the leading provider of technology >> to protect the integrity of digital information") publiziert seit 1995 >> übrigens einfach wöchentlich die verkettete Prüfsumme ihrer Logfiles > > Klingt nach Blockchain, allerdings eine private, wenns noch sicherer > sein soll würd ich eine öffentliche Blockchain nehmen. Nein, immer noch nicht. Den Service gibts schon, lang bevor Hipster von Blockchain geträumt haben, und das Blockchain-Merkmal der Konsensfindung fehlt komplett (weil nicht nötig). "private Blockchain", der größte Bullshit überhaupt. Mit wem willst du Konsens finden, wenn du alleine bist? Und was soll genau an Blockchain sicherer sein? Marketing scheint zu funktionieren...
Bernd K. schrieb: > vn nn schrieb: >> Im billigsten Fall wäre das git + Anzeigenteil >> einer beliebigen deutschen Tageszeitung. > > Klar. Git ist ja schließlich auch eine Blockchain. Natürlich. Git ist also eine Blockchain. Für dich ist vermutlich alles eine Blockchain, wo irgendwie ein Hash drinnen steckt? Bernd K. schrieb: > Aber nur die Hashes im Anzeigenteil zu veröffentlichen reicht nicht Ach ne? Sag bloß? Bernd K. schrieb: > jeder muß es im Zweifel auch selbst nochmal nachprüfen können und dazu > mußt Du das ganze Repository zugänglich machen. Unfug, natürlich nicht. Wenn du es richtig machst, deckst du das Problem rein über die Prüfsummen ab. Schließlich interessiert es den jeweiligen Kunden ja nur, ob seine eigenen Daten manipuliert wurden, nicht die der anderen. Und das lässt sich über etwas Prüfsummenmagie erledigen.
vn nn schrieb: > Wofür soll das Proof of Work benötigt werden? Gar nicht. Das ist vollkommen separat, Blockchain ist einfach nur eine Kette von Hashes über Datenblöcke und den Hash des Vorgängers. Es ist nur ein neuer Name für das selbe alte Konzept. PoW kann man separat anflanschen wenn man es braucht (z.B. wenn unvertraute Parteien ebenfalls selbsständig Datensätze anfügen können sollen wie das im Fall einer öffentlichen Kryptowährung der Fall ist).
Ich würde mich für das konkrete Problem daran orientieren wie es andere geschafft haben ihr Zertifikat zu bekommen und nicht wesentlich weiter gehen als das womit sich der Auditor typischerweise bereits zufrieden gibt und nicht versuchen Luftschlösser zu bauen nach denen gar keiner verlangt hat, noch dazu keine bereits existierenden nochmal selber from scratch versuchen nachzubauen und dabei katastrophal zu scheitern. Am Ende ist es eh nur ein Zettel Papier auf dem irgendwas bescheinigt wird und alle geben sich damit zufrieden. Wie das Zertifikat zustande kam und ob es überhaupt gerechtfertigt ist interessiert hinterher keinen mehr.
:
Bearbeitet durch User
Für dich ist also tatsächlich alles, was auch nur im entferntesten mit Hashes zu tun hat, plötzlich "Blockchain". Gut zu wissen, dass Marketing funktioniert... Aber wenigstens merkst du selbst schon in Ansätzen, dass Marketingbullshit aufsitzt, und einfach nur jahrzehntealte Konzepte einen neuen, tollen Hypenamen bekommen.
Bernd K. schrieb: > Am Ende ist es eh nur ein Zettel Papier auf dem irgendwas bescheinigt > wird und alle geben sich damit zufrieden. Wie das Zertifikat zustande > kam und ob es überhaupt gerechtfertigt ist interessiert hinterher keinen > mehr. Genau. Und dann wundern wir uns, dass Zetifikate in der Praxis nix wert sind, weil alle so denken wie du: "egal, Hauptsache das Papier haben wir, egal ob das ganze was bringt". Hat bei Boeing und beim brasilianischen Staudamm sicher auch wer gedacht, als sie sich die Sicherheit zertifizieren liesen.
vn nn schrieb: > Für dich ist also tatsächlich alles, was auch nur im entferntesten mit > Hashes zu tun hat, plötzlich "Blockchain". Nein, ich gehe einfach nach Definition des Begriffs. Warum Du immerzu auf "Hype" herumreitest erschließt sich mir nicht. Man kann die Dinge auch einfach nüchtern als das sehen was sie sind.
vn nn schrieb: > Genau. Und dann wundern wir uns, dass Zetifikate in der Praxis nix wert > sind, Doch, die sind Geld wert. Man kann sich in die "Wert"-schöpfungskette in der diese Papierzettel entstehen und gehandelt werden einklinken und daran bare Münze verdienen. > weil alle so denken wie du: "egal, Hauptsache das Papier haben > wir, egal ob das ganze was bringt". Willkommen in der Realität.
:
Bearbeitet durch User
Bernd K. schrieb: > Nein, ich gehe einfach nach Definition des Begriffs. "Begriffsdefinition" dafür zu verwenden, dass man nachträglich halt einen Marketingnamen auf jahrzehntealte Technologie draufpappt, ist dann doch etwas mutig. Und nein, git würde wohl kaum jemand außer dir und Marketingmenschen als Blockchain bezeichnen. Bernd K. schrieb: > Warum Du immerzu > auf "Hype" herumreitest erschließt sich mir nicht. Weil wild irgendwelche Dinge als Blockchain zu bezeichnen, nur weil das gerade hip ist, genau das ist. Bernd K. schrieb: > Man kann die Dinge > auch einfach nüchtern als das sehen was sie sind. Mach ich doch. Bernd K. schrieb: > Doch, die sind Geld wert. Man kann sich in die "Wert"-schöpfungskette in > der diese Papierzettel entstehen und gehandelt werden einklinken und > daran bare Münze verdienen. Eigentlich sollte man meinen, dass eindeutig zu erkennen war, dass ich mich auf den praktischen und nicht auf den finanziellen Wert irgendwelcher wischiwaschi-Blankoschecks beziehe. Scheinbar nicht für dich. Wundert mich jetzt nicht. Bernd K. schrieb: >> weil alle so denken wie du: "egal, Hauptsache das Papier haben >> wir, egal ob das ganze was bringt". > > Willkommen in der Realität. Wie unschwer zu erkennen war, ist mir das schon bewusst dass das die Realität ist, das bedeutet aber nicht, dass man das auch noch fördern sollte...
Das ist natürlich eine sehr interessante Discussion über Blockchain and co. Aber gerade das wollte ich vermeiden? Leider ist ein DMS keine Lösung für uns, zumindest jetzt. Zu viel Aufwand, sicherlich recht teuer und generell ein Overkill für das Problem. Die SHA und Time Stamp von Surely ist sicherlich interessant. Wie kann ich das mir vorstellen... D.h. die Datei wird von Surely software signiert, und diese Signatur ist eine SHA checksum. Zusätzlich sagt Time Stamp wann die Datei signiert wurde. Also zu jeder Messdatei gehören zwei Signaturen... D. H. jemand von uns macht dieses Signatur nach einer Messung und lagert die hashes irgebdwo auf dem Server. Entweder bei uns intern, oder irgendwo in Cloud, für mehr Transparenz... Evtl. Können wir Dateien direkt an den Kunden mit der Ware mitschicken (zusammen mit der restlichen Dokumentation). Klingt gut und elegant.
:
Bearbeitet durch User
-> Versionsüberwachung Github, SVN etc >Absicherung der Konfigurationsdatei (wie stelle ich sicher, dass die >Bauteile bei den richtigen Einstellungen/Bedienungen gemessen wurden) Was meinst Du hier genau? Normalweise werden Messgeräte gegen die angegeben Spezifikationen von einem akkreditieren Labor in einem definierten Zyklus geprüft und ein Zertifikat ausgehändigt, wenn Ihr zu viel Geld habt könnt Ihr auch ein DKD Labor nehmen. Die bieten meistens auch eine Messmittelverwaltung an mit Datenbankanbindung, aber bindet zu stark, deshalb lieber eine eigene Datenbank. >- Wie kann ich den Kunden garantieren, dass keiner die Messdatei manuell >nachher verändert hat etc. >Nach jeder Postenmessung (100+ Wafer, ca. 100000 Bauteile) wird eine >SHA256 Hash von der Konfigurationsdatei und der Messdatei automatisch >erstellt und sicher in "Read Only" Modus gespeichert. Ihr hortet tausende Messdateien? Wie sperrt Ihr den eine komplette Produktion nachträglich, hier sollte eine Datenbank erstellt werden. Die Serverlogs zeigen die Veränderungen somit hast du bewiesen, dass die Messwerte nicht verändert wurden, aber auch das lässt sich aushebeln, wie so viele Sachen. Ihr solltet euch ein ISO9001/17025 Consultor zulegen, weil er die Prozesse mit euch zusammenaufstellt für die ganzen Anforderungen der Normen, welches das wichtigste ist, ausserdem ist er bei den Audits dabei. Der Consultor wird keine 365 Tage im Jahr benötigt, sondern jedes mal ein paar Monate vorher und ein paar Wochen danach.
Böser K. schrieb: > Die SHA und Time Stamp von Surely ist sicherlich interessant. Wie kann > ich das mir vorstellen... D.h. die Datei wird von Surely software > signiert, und diese Signatur ist eine SHA Ich glaub du hast eine falsche Vorstellung von den Anforderungen. Es geht hier nicht um Datensicherheit, sondern Prozesssicherheit. Das heisst es reicht ein System wo die Personen, die Daten eingeben, diese nicht mehr unbemerkt aendern koennen. Das heisst nicht, das niemand auf der Welt (z.b. die Haus-IT) das nicht koennen darf. Ist wie bei Scannerkassen, falsch gescannte Ware kann von der Kassiererin nicht mehr geloescht werden, sondern nur storniert. Der Scan als auch das Storno bleiben im System erhalten. Dazu braucht es keine Hashes und keine Blockchain. Im Grunde koennte man deine ISO-relevanten Aufzeichnungen auch handschriftlich mit einem dokumentenechten Stift in einem Logbuch fuehren. >- Absicherung der Konfigurationsdatei (wie stelle ich sicher, dass die Bauteile bei den richtigen Einstellungen/Bedienungen gemessen wurden) Da brauchts Qualitaeter, die dafuer explizit verantwortlich sind. Qualitaetsrelevante Einstellungen muessen im Vorraus definiert sein und lassen sich nur mittels derer Login-Daten veraendern. Wie alles wird jede Aenderung geloggt, auch, wer die Aenderung vorgenommen hat. Dann gibts eine Art Qualitaetsabnahme, wo die Werte kontrolliert werden. Kommt aber immer darauf an, ob die Chargen einmalig durchlaufen, oder wiederholt ueber einen langen Zeitraum. Die Prozesseinstellungen nehmen nicht die Qualitaeter vor. >- Wie kann ich den Kunden garantieren, dass keiner die Messdatei manuell nachher verändert hat etc. Das macht man wieder dadurch, dass die verantwortlichen Mitarbeiter eben keine Moeglichkeit haben, das vom System ausgespukte Messprotokoll zu veraendern. Die Maschine darf also keine Excelltabelle ausspucken, mithilfe derer der Mitarbeiter dann ein Protokoll bastelt. Die Maschine darf auf kein Protokoll im Word-Format ausspucken, wo der Mitarbeiter dann noch ein paar Eintraege vornimmt. Sondern die Eintragungen muessen der Maschine/ der Messsoftware uebergeben werden und die erstellt daraus das fertige Protokoll (z.B. als PDF).
Beitrag #6157895 wurde von einem Moderator gelöscht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.