Titel

Verfahren zum Hinterlegen von Programmdaten in einer Datenbank

Die vorliegende Erfindung betrifft ein Verfahren zum Hinterlegen von Programmdaten in einer auf einem Rechensystem bereitgestellten Datenbank sowie ein Rechensystem und ein Computerprogramm zu dessen Durchführung.

Hintergrund der Erfindung

Für Produkte in sicherheitsrelevanten Bereichen, z.B. bei Fahrzeugen oder Maschinen, existieren je nach Domäne oder Anwendung Normen zur funktionalen Sicherheit. Dies betrifft nicht nur die Hardware, sondern auch die Software oder allgemein Programmdaten, dort insbesondere sog. Software-Integritäts-Level (SIL). Diese Normen beschreiben z.B. Anforderungen an den Software- Entwicklungsprozess und an die Daten- bzw. Softwarebereitstellung. Solche Normen sind z.B. die DIN EN ISO25519 für Landwirtschaft, die DIN EN ISO 13849 für Maschinen, oder die DIN EN ISO26262 für Automotive.

Während der Software-Entwicklung sind dabei je nach Norm unterschiedliche Qualitätsdaten zu erheben und nachzuweisen. Dies kann manuell oder auch automatisch erfolgen. Zu durchlaufende Qualitätsprüfungen (oder auch "Quality Gates") während der Entwicklung und vor Auslieferung der Software sind in der Regel im Software-Entwicklungsprozess des Herstellers verankert und damit unabhängig von Anforderungen aus den Normen der funktionalen Sicherheit.

Offenbarung der Erfindung Erfindungsgemäß werden ein Verfahren zum Hinterlegen von Programmdaten in einer Datenbank sowie ein Rechensystem und ein Computerprogramm zu dessen Durchführung mit den Merkmalen der unabhängigen Patentansprüche vorgeschlagen. Vorteilhafte Ausgestaltungen sind Gegenstand der Unteransprüche sowie der nachfolgenden Beschreibung.

Die Erfindung beschäftigt sich mit dem Hinterlegen (oder Einstellen bzw. Speichern) von Programmdaten in einer auf einem Rechensystem bereitgestellten Datenbank, insbesondere in der sog. Cloud, also einem z.B. über Internet erreichbaren Server. Die Programmdaten können dabei insbesondere Software wie eine Softwareanwendung oder eine Funktion hiervon umfassen, ebenso aber auch nur Daten, die z.B. im Rahmen von solchen Softwareanwendungen oder Funktionen verwendet werden, z.B. Karten oder Applikationskurven.

Ein Grund, weshalb Programmdaten, die z.B. für Steuergeräte in Fahrzeugen oder anderen Maschinen verwendet werden sollen, auf diese Weise hinterlegt bzw. bereitgestellt werden oder werden sollen, ist die Überlegung, dass eine Entwicklungs-Plattform geschaffen werden kann, die beteiligten Unternehmen (die die Programmdaten bereitstellen, also z.B. Software entwickeln) die Möglichkeit bietet, ihre Programmdaten (zentral) zu hosten und dann auf Anforderung an Kunden bzw. Anwender bereitzustellen bzw. herauszugeben. Hierfür muss aber herstellerübergreifend die Einhaltung von Sicherheitsnormen gewährleistet sein.

Die Hersteller bzw. Entwickler einer Softwareanwendung oder anderer Programmdaten kennen in der Regel die Sicherheitsanforderung des Endkunden an die Softwareanwendung bzw. Programmdaten nicht und haben daher meist auch kein direktes Interesse am Nachweis für eine oder mehrere domänen-spezifische Normen. Programmdaten wie Funktionen von und Daten für Softwareanwendungen unterliegen aber direkt oder indirekt gewissen Anforderungen der funktionalen Sicherheit. Ein direkter Bezug liegt vor, wenn die Programmdaten, wie eine Softwareanwendung oder eine von ihr bereitgestellte Funktion, selbst ein gewisses Gefährdungspotential aufweisen oder zur Abwendung eines Gefährdungspotentials dienen. Hierunter fallen z.B. Softwareanwendungen, die in einem Fahr- zeug Lenkbewegungen verursachen oder auf die Bremsen zugreifen. Ein indirekter Bezug liegt vor, wenn Programmdaten wie eine Softwareanwendung oder eine von ihr bereitgestellte Funktion selbst zwar kein Gefährdungspotential aufweisen bzw. zur Abwendung eines solchen dienen, aber im Zusammenhang mit einer solchen Softwareanwendung bzw. Funktion verwendet werden. Ein Beispiel hierfür wäre die Messung oder Anzeige von Entfernungen, z.B. zum nächsten Hindernis vor einem Fahrzeug. Dies ist an sich zwar nicht sicherheitsrelevant, wird aber für sicherheitsrelevante Funktionen wie z.B. einem rechtzeitigen Bremsen benötigt.

Ein weiterer indirekter Bezug liegt vor, wenn die Programmdaten in einer Software-Hardware-Einheit (z.B. in einem Steuergerät oder einem abgekapselten Teil davon, aber auch auf jedem anderen beliebigen Speicher wie einer Datenbank) zusammen mit anderen Programmdaten wie einer Softwareanwendung oder einer von dieser bereitgestellten Funktion liegen, die ein Gefährdungspotential aufweist bzw. zur Abwendung eines solchen dient. Dieser Aspekt ist vom Gesichtspunkt der funktionalen Sicherheit und der daraus abgeleiteten Sicherheits- bzw. Integritätsanforderungen her gesehen ein besonders kritischer. Es wird nämlich unterstellt (oder muss unterstellt werden), dass beliebige Programmdaten, die ohne nachgewiesene Trennung in einer Software-Hardware-Einheit mit anderen Programmdaten, Softwareanwendungen oder Funktionen liegen, diese hinsichtlich der gewährleisteten Sicherheitsanforderungen „kontaminieren“.

Die Folge davon ist, dass alle Programmdaten dieser Hardware-Software-Einheit den Softwareintegritätslevel der Programmdaten mit der niedrigsten Integritätseinstufung einnehmen. In der Konsequenz muss eine solche Kontamination der in der Cloud bzw. der Datenbank liegenden Programmdaten verhindert werden.

Vor diesem Hintergrund wird folgendes Vorgehen für das Hinterlegen - bzw. Einstellen oder Speichern - von Programmdaten wie z.B. einer Softwareanwendung in einer auf einem Rechensystem bereitgestellten Datenbank für z.B. späteres Herunterladen vorgeschlagen, das automatisiert von dem Rechensystem (also sozusagen von der Cloud bzw. dem zugrundliegenden Server oder Serververbund) durchgeführt wird. Das Rechensystem ist hierzu entsprechend in ein Netzwerk einzubinden. Zunächst werden die Programmdaten empfangen, ebenso wie Referenzdaten mit Informationen über die Programmdaten sowie über Sicherheitsanforderungen an die Programmdaten.

Diese Referenzdaten können von dem Entwickler oder Hersteller, von dem die Programmdaten bereitgestellt werden, ebenfalls bereitgestellt werden. Beides, Programmdaten und Referenzdaten, kann dann z.B. über eine geeignete Schnittstelle wie z.B. ein Web-Interface an das Rechensystem übermittelt werden. Die Referenzdaten umfassen dabei zwei verschiedene Arten von Informationen, nämlich solche, die (direkt) mit den Programmdaten assoziiert sind (sog. "Kontext-Katalog"), sowie solche, die dessen Sicherheitsanforderungen betreffen. (sog. "Sicherheitsanforderungs-Katalog").

Die Informationen über die Programmdaten umfassen z.B. die verantwortlichen Hersteller der Programmdaten, verwendete Normen, die Version der Programmdaten, einen eindeutigen Identifier für die Version sowie mitgelieferte Kataloge "(Kontext-Katalog", "Sicherheitsanforderungs-Katalog") (für z.B. kryptographische Prüfsummen), Zeitpunkte, Gültigkeit, oder Selbsteinstufung des Software- Integritätslevels der Programmdaten. Hier kann allgemein auch von einem "Kontext-Katalog" gesprochen werden. Die Informationen über die Sicherheitsanforderungen an die Programmdaten umfassen z.B. eine Beschreibung der Konformität mit Sicherheitsanforderungen aus anzuwenden Normen, z.B. die eingangs schon genannte DIN EN ISO25519 für Landwirtschaft, die DIN EN ISO 13849 für Maschinen oder die DIN EN ISO26262 für Automotive. Die Erstellung auf Seiten des Zulieferers (also des Herstellers der Programmdaten) sollte bevorzugt auf automatisierten Auswertungen der Programmdaten (oder Software) und der Qualitäts-Artefakte (z.B. Testprotokolle, Testdesigndokumente, Softwartedesigndokumente, statische und dynamische, automatisiert ablaufende, Code-Checker, sowie Reviews) sowie einer Konformitätsüberprüfung der Software- Entwicklungsprozesse erfolgen.

Die Programmdaten sowie die Referenzdaten (mit beiden Arten von Informationen) werden dann auf einem Eingangsbereich zwischengespeichert. Der Eingangsbereich wird - wie auch die Datenbank - von dem Rechensystem bereit- gestellt, aber getrennt von der Datenbank. Es handelt sich aber ebenfalls um einen Speicher. Durch diesen von der Datenbank getrennten Eingangsbereich wird sichergestellt, dass die Programmdaten nicht in einer Hardware-Software-Einheit zusammen mit anderen Programmdaten oder sonstiger Software liegen, sodass eine Kontamination ausgeschlossen wird. Eine Trennung des Eingangsbereichs von der Datenbank bzw. von Teilen der Datenbank kann z.B. physisch, also mit separaten Speichereinheiten, erfolgen, oder aber auch über eine Software, die entsprechende Partitionen erstellt. Hier muss die Software dann aber der entsprechenden Sicherheitsanforderung, in der Praxis der höchsten verfügbaren, genügen und dafür freigegeben sein.

Nachfolgend werden die Informationen in den Referenzdaten auf eines oder mehrere Kriterien überprüft. Zweckmäßig ist die Überprüfung auf mehrere Kriterien, und zwar sowohl bei den Informationen über die Programmdaten als auch bei den Informationen über Sicherheitsanforderungen an die Programmdaten. Dies kann als zweistufige Prüfung erfolgen, sodass zunächst die Informationen über die Programmdaten auf wenigsten ein Kriterium überprüft werden, danach die Informationen über Sicherheitsanforderungen an die Programmdaten auf wenigsten ein Kriterium.

Die Überprüfung der Informationen über die Programmdaten kann als Kriterium z.B. umfassen, dass die empfangene Version der Programmdaten (wie sie in den Informationen enthalten ist) einer bestimmten oder vorgegebenen Version entspricht. Beispielsweise kann vorgesehen sein, dass das Kriterium als nicht erfüllt gilt, wenn Programmdaten mit gleicher Versionsnummer vom selben Hersteller bereits in der Datenbank vorhanden sind. Weitere Kriterien können z.B. eine eindeutige Zugehörigkeit der Programdaten oder von den schon erwähnten Katalogen zur Version der empfangene Programmdaten sein. Zur Überprüfung kann z.B. ein Abgleich zwischen hinterlegten Anforderung mit den Anforderungen zu den hochgeladenen Programmdaten erfolgen, und zwar insbesondere automatisiert.

Wenn das eine oder zumindest eines der mehreren Kriterien nicht erfüllt ist, werden die Programmdaten nicht in der Datenbank gespeichert und insbesondere auch aus dem Eingangsbereich entfernt. Wenn eine Anzahl an Einstellversuchen, bei denen von einem bestimmten Hersteller (oder Anbieter) empfangene Programmdaten Kriterien nicht erfüllen, eine vorbestimmte Anzahl übersteigt, kann insbesondere vorgesehen werden, dass weitere Einstellversuche dieses bestimmten Herstellers von dem Rechensystem nicht mehr zugelassen (also blockiert) werden. Auch dies kann bei den beiden Stufen bzw. bei den beiden Arten von Informationen nochmals konkretisiert werden.

Fällt die Überprüfung der Informationen über die Programmdaten negativ aus, d.h. ist wenigstens eines dieser Kriterien nicht erfüllt, so kann nicht nur vorgesehen sein, die Programmdaten aus dem Eingangsbereich zu entfernen (also zu löschen), sondern auch, dass z.B. ein Bericht generiert und an die verantwortlichen Instanzen auf Seiten der Hersteller (bzw. Anbieter) von Programmdaten und Rechensystem (dort z.B. der Betreiber) gesendet wird. Diese Berichte können auch in einem Log-Profil für jeden Hersteller gesammelt werden. Bei Überschreiten einer vorbestimmten Menge an fehlerhaften Einstellungen in den Eingangsbereich kann dieser nicht nur für den Hersteller blockiert werden. Auch hier kann ein Bericht generiert und an die verantwortlichen Instanzen, wie vorstehend schon genannt, gesendet werden. Auf diese Weise kann verhindert werden, dass z.B. wenig vertrauenswürde Hersteller oder Anbieter in Zukunft keine Programmdaten mehr auf diesem Wege bereitstellen können.

Ist die Überprüfung in der erste Stufe hingegen erfolgreich, d.h. sind alle nötigen Kriterien bei den Informationen über die Programmdaten erfüllt, kann in der zweiten Stufe die Überprüfung der Kriterien der Informationen über Sicherheitsanforderungen an die Programmdaten erfolgen. Hier können die Kriterien z.B. umfassen, dass abhängig von der verwendeten Norm zur funktionalen Sicherheit, Datum, Integritäts-Klasse oder sonstiger Parameter vorgegebene oder geforderte Werten erfüllt sind. Beispielsweise kann z.B. vorgesehen sein, dass bestimmte Dokumente zum Design der Programmdaten (oder Software) vorliegen, z.B. auch mit einem bestimmten Inhalt. Zudem kann in diesem Zusammenhang geprüft werden, welche Sicherheitsanforderung die Programmdaten letztlich erfüllen, um zu entscheiden, ob oder wo genau die Programmdaten gespeichert werden sollen. Sind die Überprüfungen fehlerhaft, d.h. ist wenigstens eines dieser Kriterien nicht erfüllt, so kann (auch an dieser Stelle) ein Bericht generiert und an die verantwortlichen Instanzen, wie vorstehend schon genannt, gesendet werden. Auch können hier die Berichte in einem Log-Profil für jeden Hersteller gesammelt werden. Bei Überschreiten einer vorbestimmten Menge an fehlerhaften Einstellungen, was in dieser zweiten Stufe insbesondere Verletzungen der Software- Integritätsanforderungen entspricht, kann der Eingangsbereich für den Hersteller blockiert werden. Auch hier kann ein Bericht generiert und an die verantwortlichen Instanzen, wie vorstehend schon genannt, gesendet werden.

Sind hingegen alle Überprüfungen erfolgreich, d.h. sind alle nötigen Kriterien erfüllt, wird ein Sicherheitsverzeichnis erstellt, das zumindest einen Teil der Informationen in den Referenzdaten, vorzugsweise sämtliche darin enthaltenen Informationen (beider Arten) umfasst. Ebenso können aber z.B. ein Datum und/oder ein Ergebnis der Überprüfung, ggf. auch eine Klassifizierung der Sicherheitsanforderung für die überprüften Normen auf Seiten des Rechensystems darin umfasst sein. Die Programmdaten werden dann in einem einer Sicherheitsanforderung der Programmdaten entsprechenden Teilbereich der Datenbank gespeichert und damit für z.B. ein späteres Herunterladen bzw. Beziehen durch einen Kunden oder Anwender bereitgestellt. In diesem Zusammenhang ist es auch zweckmäßig, wenn die Datenbank mehrere, voneinander getrennt bereitgestellte, Teilbereiche aufweist, die zum Speichern von Programmdaten mit verschiedenen Sicherheitsanforderungen vorgesehen sind. Das Sicherheitsverzeichnis kann dann später z.B. dazu verwendet werden, damit ein Kunde überprüfen kann, ob die Programmdaten seine gewünschten Sicherheitsanforderungen erfüllen oder nicht.

Auf diese Weise kann also erreicht werden, dass Programmdaten wie Softwareanwendungen oder Funktion oder sonstige Daten hierfür derart in der Datenbank gespeichert und bereitgestellt werden können, dass eine Kontamination von Programmdaten mit höheren Sicherheitsanforderungen durch Programmdaten mit geringeren Sicherheitsanforderungen sicher vermieden wird. Ein besonders relevanter Aspekt des vorgeschlagenen Vorgehens ist dabei das erwähnte Sicherheitsverzeichnis bzw. dessen Erstellung. Dieses enthält insbesondere Informationen zur Software-Integrität, Software-Zuverlässigkeit (Reliability), Daten-Integrität sowie zum Kontext (Version der Software, Markt, Datum, Gültigkeitsdauer, Anbieter). Anhand dieser Informationen kann die Zulässigkeit des Einsatzes der Programmdaten für ein bestimmtes Level der funktionalen Sicherheit automatisch bestimmt werden, es können die Annahmen (Delivery) in ein zentrales Software-Repository (die Datenbank) gesteuert werden, und es kann darüber letztlich auch die Auslieferung (Deployment) an einen Kunden bzw. dort in ein lokales Software-Repository gesteuert werden. Ein zentraler Punkt hierbei ist auch die Kontrolle, Einordnung und ggf. Zurückweisung von Programmdaten mit aus Sicherheits-Gesichtspunkten ungenügenden Integritätsanforderungen.

Ein erfindungsgemäßes Rechensystem z.B. ein Server, ist, insbesondere programmtechnisch, dazu eingerichtet, ein erfindungsgemäßes Verfahren durchzuführen.

Auch die Implementierung eines erfindungsgemäßen Verfahrens in Form eines Computerprogramms oder Computerprogrammprodukts mit Programmcode zur Durchführung aller Verfahrensschritte ist vorteilhaft, da dies besonders geringe Kosten verursacht, insbesondere wenn ein ausführendes Rechensystem noch für weitere Aufgaben genutzt wird und daher ohnehin vorhanden ist. Geeignete Datenträger zur Bereitstellung des Computerprogramms sind insbesondere magnetische, optische und elektrische Speicher, wie z.B. Festplatten, Flash-Speicher, EEPROMs, DVDs u.a.m. Auch ein Download eines Programms über Computernetze (Internet, Intranet usw.) ist möglich.

Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung.

Die Erfindung ist anhand eines Ausführungsbeispiels in der Zeichnung schematisch dargestellt und wird im Folgenden unter Bezugnahme auf die Zeichnung beschrieben. Kurze Beschreibung der Zeichnungen

Figur 1 zeigt schematisch einen Ablauf eines erfindungsgemäßen Verfahrens in einer bevorzugten Ausführungsform.

Ausführungsform(en) der Erfindung

Figur 1 zeigt schematisch einen Ablauf eines erfindungsgemäßen Verfahrens in einer bevorzugten Ausführungsform, und zwar insbesondere anhand eines Rechensystems 120, das entsprechend dazu eingerichtet ist.

Beispielsweise will ein Hersteller oder Anbieter 100 (Entwickler) von z.B. einer bestimmten Softwareanwendung für ein Steuergerät eines Fahrzeugs oder einer bestimmten Funktion hierfür Programmdaten 110, z.B. eine Softwareanwendung oder Funktion oder auch bestimmte Daten hierfür, in z.B. einer aktuellen Version für Kunden zur Verfügung stellen. Dies soll auf dem Rechensystem 120 bzw. dort einer Datenbank 130 erfolgen, von wo die Programmdaten 110 dann z.B. heruntergeladen werden können.

Im Rahmen der Erfindung soll, wie erwähnt, erreicht werden, dass diese Programmdaten 110 nicht von anderen Programmdaten mit niedrigeren Sicherheitsanforderungen (z.B. gemäß Software-Integritäts-Level) kontaminiert werden oder andere Programmdaten mit höheren Sicherheitsanforderungen kontaminieren. Hierzu stellt der Anbieter 100 neben den Programmdaten 110 selbst auch noch Referenzdaten zur Verfügung, die einerseits Informationen 112 über die Programmdaten 110 sowie Informationen 114 über Sicherheitsanforderungen an die Programmdaten 110 umfassen.

Wie erwähnt, können die Informationen 112 über die Programmdaten 110 z.B. die verantwortlichen Hersteller (dies kann einer sein, denkbar sind aber auch mehrere Hersteller) der Programmdaten, verwendete Normen, die Version der Programmdaten, einen eindeutigen Identifier für die Version sowie mitgelieferte Kataloge, Zeitpunkte, Gültigkeit, oder Selbsteinstufung des Software- Integritätslevels der Programmdaten umfassen. Informationen 112 stellen damit einen "Kontext-Katalog" dar. Die Informationen 114 über Sicherheitsanforderungen an die Programmdaten 110 können z.B. eine Beschreibung der Konformität mit Sicherheitsanforderungen aus anzuwenden Normen umfassen. Für das Beispiel eines Fahrzeugs ist dies z.B. die DIN EN ISO26262 für Automotive.

Die Programmdaten 110 und die Referenzdaten bzw. Informationen 112, 114 werden von dem Rechensystem 120 empfangen und dort zunächst auf einem Eingangsbereich 122, also einem entsprechenden Speicher oder Speicherbereich zwischengespeichert. Hierzu kann der Anbieter 100 die Daten z.B. über ein Web-Interface oder eine andere geeignete Schnittstelle an das Rechensystem übermitteln.

Die Informationen 112, 114 in den Referenzdaten werden dann auf bestimmte Kriterien überprüft. Dies erfolgt bevorzugt in zwei Stufen. Zunächst werden in einer ersten Stufe die Informationen 112 über die Programmdaten 110 hinsichtlich zumindest eines Kriteriums 140 überprüft. Wie erwähnt, kann hier z.B. geprüft werden, ob die vorliegende Version der Programmdaten schon in der Datenbank 130 vorhanden ist. Wenn nicht alle nötigen Kriterien erfüllt werden, werden die Programmdaten 110 aus dem Eingangsbereich 122 gelöscht. Gleiches kann für die Referenzdaten gelten.

Wenn die Kriterien 140 allerdings erfüllt sind, können in der zweiten Stufe die Informationen 114 über Sicherheitsanforderungen an die Programmdaten 110 hinsichtlich zumindest eines Kriteriums 142 überprüft werden. Wie erwähnt, kann hier z.B. geprüft werden, ob die bei der verwendeten Norm zur funktionalen Sicherheit, also z.B. der DIN EN ISO26262 oder DIN EN ISO25519, geforderten Werte bei den Programdaten 110 eingehalten werden, beispielsweise das Vorliegen bestimmter Dokumente zum Design.

Wenn auch Kriterien 142 erfüllt sind, wird ein Sicherheitsverzeichnis 150 erstellt, das z.B. sämtliche Informationen 112 und 114 umfasst sowie z.B. auch ein Datum und ein Ergebnis der Überprüfung, ggf. auch eine Klassifizierung der Sicherheitsanforderung für die überprüften Normen. Die Programmdaten 110 werden dann in einem einer Sicherheitsanforderung der Programmdaten entsprechenden Teilbereich 124 der Datenbank 130 gespeichert. Andere Programmdaten mit anderen Sicherheitsanforderungen würden z.B. in einem der Teilbereiche 126 oder 128 gespeichert. Auf diese Weise wird sichergestellt, dass die Programmdaten 110 nicht von anderen Programmdaten mit niedrigeren Sicherheitsanforderungen kontaminiert werden oder andere Programmdaten mit höheren Sicherheitsanforderungen kontaminieren.

Das Sicherheitsverzeichnis 150 kann ebenfalls zusammen mit den Programmdaten 110 in dem Teilbereich 124 gespeichert werden, ggf. aber auch an einer anderen Stelle und dann mit den Programmdaten 110 verknüpft werden.

Ein Kunde oder Anwender kann die Programmdaten 110 aus der Datenbank 130 nun bei Bedarf herunterladen, z.B. auf ein Steuergerät 160 eines Fahrzeugs. Der Kunde wird dabei bestimmte Anforderungen an die Programmdaten hinsichtlich der Sicherheitsanforderungen haben. Anhand des Sicherheitsverzeichnisses 150 kann der Kunde dabei überprüfen, ob die Programdaten 110 seinen gewünschten Sicherheitsanforderungen entsprechen. Falls dem so ist, kann er sie herunterladen, andernfalls kann er davon absehen. Dieser Vorgang der Überprüfung kann z.B. auch automatisiert erfolgen.