mikrocontroller.net

Forum: Ausbildung, Studium & Beruf Wie mache ich eine messtechnische Softwarelösung nach ISO 9001 auditsicher?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Böser K. (Firma: UdSSR) (chromosoma)


Bewertung
0 lesenswert
nicht lesenswert
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:)

von Dunno.. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 :)

von (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Dunno.. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Böser K. (Firma: UdSSR) (chromosoma)


Bewertung
0 lesenswert
nicht lesenswert
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
von (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Gerd E. (robberknight)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Dunno.. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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..

von Dunno.. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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..

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
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.
von BonusGekoppeltAnGewinn (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rudolph (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
War nur eine Frage der Zeit bis der erste hipster Trotte mit blockchain 
ankommt. Blockchain ist NICHT manipulationssicher.

von Toralf Totmachov (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Hans (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Bimbo. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Messknecht (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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-/

von Hans (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Naja die "neue" 17025 hätte die 9001 gerne als grundlage...

Ganz rausgeschmissen ist das also nicht.

73

von vn nn (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von vn nn (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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
von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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
von vn nn (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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
von vn nn (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von vn nn (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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
von vn nn (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von vn nn (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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
von vn n. (wefwef_s)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Böser K. (Firma: UdSSR) (chromosoma)


Bewertung
0 lesenswert
nicht lesenswert
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
von Dirk (Gast)


Bewertung
0 lesenswert
nicht lesenswert
-> 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.

von Maxe (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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).

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.