Warum Sie zu Connext DDS Secure wechseln sollten

„Sicherheit sollte eingebaut und nicht festgeschraubt werden.“ Wahr. Sie haben es gehört. Ich habe es auch gehört. Da das IIoT schnell Realität wird, wird dieser Satz tatsächlich so oft wiederholt, dass ich mir Sorgen mache, dass er zu einem Klischee wird, das ein Gefühl der Dringlichkeit ohne wirkliche Potenz erzeugt. Aber warum wird die Sicherheit oft von vornherein angeschraubt? Wird uns das Verständnis der Gründe helfen, dies zu vermeiden? Hoffentlich. Es gibt viele Gründe, von wirtschaftlichen bis hin zu regulatorischen, pädagogischen und technischen Gründen, auf die ich in diesem Blogbeitrag nicht im Detail eingehen kann (weitere Details finden Sie im IISF).

In einigen Fällen wurden die Bedrohungslandschaft, die damit verbundenen Risiken und Sicherheitsüberlegungen bei der Entwicklung der Systemarchitektur nicht gut durchdacht. In anderen Fällen werden bestehende Systeme umfunktioniert, um unter völlig anderen Bedingungen mit völlig anderen Bedrohungen zu arbeiten. Sicherheitsanalysten lehnen solche Bemühungen oft und verständlicherweise ab. Das übergeordnete Management wird jedoch in der Regel von Marktkräften veranlasst, Entscheidungen zu treffen, wobei der Effizienz und der leistungsstarken Funktionalität eine höhere Priorität eingeräumt wird. Vielleicht ist die Sicherheit ein Overhead, über den Sie sich Sorgen machen müssen, sobald Sie das Basissystem in Gang gebracht haben. Oder vielleicht denken Sie, dass Ihr System „Luftspalten“ hat. Aufgrund der Kosten für die Neuarchitektur des Systems ist es zu diesem Zeitpunkt jedoch wahrscheinlich zu spät, um über die Sicherheit nachzudenken. Man würde also versuchen, sein Bestes zu geben, indem man die Sicherheit später hinzufügt, nachdem das Basissystem zum Laufen gebracht wurde. In vielen Fällen ist der Prozess zum späteren Hinzufügen von Sicherheit nicht genau definiert oder wird in Fällen, in denen bewährte Verfahren bekannt sind, nicht ordnungsgemäß befolgt. Warum sollten wir uns dann über den enttäuschenden Sicherheitsstatus im IIoT wundern?

Ein Teil der Herausforderung der Sicherheitstechnik besteht darin, Architekturen zu entwickeln, die einen akzeptablen Schutz vor Sicherheitsbedrohungen bieten, die auf Fehler, Unglück oder Böswilligkeit zurückzuführen sind, während gleichzeitig minimaler Aufwand für die Geschäftsfunktionen und die Leistung des Systems entsteht. Das klingt einfach, ist aber in der Praxis nur schwer umzusetzen – zumal Systeme komplexer und voneinander abhängiger werden und größere, vielfältigere Personengruppen an deren Realisierung arbeiten. Insbesondere bei IIoT-Systemen sollten Sicherheitsmaßnahmen im Rahmen der breiteren Beschränkungen der Interoperabilität, Leistung, Skalierbarkeit, Ausfallsicherheit, Sicherheit und Compliance in Umgebungen, in denen sich Sicherheitsbedrohungen und damit verbundene Risiken recht schnell ändern, in Betracht gezogen werden. Diese Überlegungen wurden bei der Entwicklung der DDS-Sicherheitsspezifikation und Connext® DDS Secure von RTI lebhaft diskutiert und berücksichtigt.

Wenn Sie bereits DDS-Anwender sind oder DDS evaluieren, sollten Sie unbedingt RTI Connext DDS Secure in Betracht ziehen. Im Folgenden erörtere ich, wie Connext DDS Secure Sicherheitskonfigurationen ermöglicht, die es Architekten und Ingenieuren ermöglichen, basierend auf Sicherheitsrisiken und Leistungsanforderungen das richtige Gleichgewicht zwischen Sicherheit und Leistung zu finden. Ich werde auch ein Beispiel für ein Forschungsprojekt anführen, das darauf abzielt, klinische Umgebungen sicher zu integrieren, um das Patientenergebnis signifikant zu verbessern.

Ist DDS-Sicherheit die richtige Lösung für Ihren Anwendungsfall?

RTI-Ingenieure verwenden normalerweise eine Faustregel, um zu sehen, ob die Architektur eines Kundensystems basierend auf DDS wirklich sinnvoll ist oder ob sie besser dran sind, ein anderes Konnektivitäts-Framework zu verwenden (siehe IICF für eine detaillierte technische Diskussion zu diesem Thema). Im Allgemeinen, wenn die Antwort auf mindestens drei der folgenden fünf Fragen „Ja“ lautet, wäre DDS unter anderen bestehenden Konnektivitäts-Frameworks das am besten geeignete Framework für das System:

1. Ist es ein großes Problem, wenn Ihr System für kurze Zeit nicht mehr funktioniert?
2. Haben Sie in den letzten zwei Wochen entweder "Millisekunde" oder "Mikrosekunde" gesagt?
3. Haben Sie mehr als 10 Software-Ingenieure?
4. Senden Sie Daten an viele Orte statt nur an einen (z. B. in die Cloud oder eine Datenbank)?
5. Implementieren Sie eine neue IIoT-Architektur?

Wenn Sie Frage 1 mit Ja beantworten, haben Sie strenge Anforderungen an Verfügbarkeit und Fehlertoleranz. DDS bietet bereits Funktionen, die bei diesen Anforderungen sehr hilfreich sind, einschließlich des vollständigen Peer-to-Peer-Betriebs (also ohne Single Points of Failure) und mehrerer relevanter Parameter, einschließlich Eigentums-, Haltbarkeits-, Lebendigkeits- und Fristen-QoS-Richtlinien. Darüber hinaus ermöglicht DDS Security die Trennung von DDS-Domänen, die Authentifizierung von DDS-Teilnehmern, die Autorisierung zum Veröffentlichen oder Abonnieren von DDS-Themen und die Authentifizierung von DDS-Nachrichten, bevor Daten von der Middleware an übergeordnete Anwendungen weitergegeben werden. Diese Funktionen ermöglichen die Verhinderung und/oder die signifikante Abschwächung der Auswirkungen einiger Klassen von Denial-of-Service (DOS)-Angriffen. Diese Funktionen in Verbindung mit geeigneten Zugriffskontrollmaßnahmen auf Netzwerk-, Betriebssystem- und Anwendungsebene würden einen besseren Schutz gegen potenzielle DoS-Angriffe in DDS-basierten Systemen bieten.

Wenn Sie Frage 2 mit Ja beantworten, besteht die Möglichkeit, dass Sie erhebliche Echtzeitanforderungen haben. In solchen Fällen möchten Sie die Sicherheit Ihres DDS-Systems basierend auf Risiko- und Leistungsanforderungen optimieren. Zum Beispiel ist es Ihnen vielleicht egal, dass ein Temperaturmesswert von einem Sensor in einem öffentlichen Raum verschlüsselt und vertraulich übertragen wird, aber Sie interessieren sich wahrscheinlich für die Authentizität dieser Messwerte. Mit DDS Security können Sie solche Konfigurationen definieren und erzwingen, ohne Änderungen an Ihrem Anwendungscode vorzunehmen.

Eine positive Antwort auf Frage 3 bedeutet wahrscheinlich, dass Sie die Kosten für die Interoperabilität zwischen Softwareentwicklungsteams minimieren möchten, die jeweils an unterschiedlichen Aspekten eines ziemlich großen Softwareprojekts arbeiten. Das datenzentrierte Design von DDS ermöglicht es Softwareteams, sich darauf zu einigen, welche Daten (d. h. Typen und Themen) wie verteilt werden sollen (d. h. mit welchen QoS-Einstellungen), ohne dass notwendigerweise Datenverarbeitungs-APIs offengelegt werden müssen. In ähnlicher Weise ermöglichen DDS-Sicherheitskonfigurationen für integrierte Plugins (z. B. Domänen-Governance- und Teilnehmerberechtigungsdateien) die Definition von Sicherheitsrichtlinien für die Datenverteilung. Diese expliziten Richtlinien werden basierend auf Ihren Datenmodellen erstellt und wie Sie DDS-Domänen schützen möchten. Diese Richtlinien können unabhängig von Sicherheitsingenieuren und Systemarchitekten überprüft und basierend auf Risikoanalysen und Leistungsanforderungen neu angepasst werden, ohne Änderungen am Anwendungscode vorzunehmen.

Eine positive Antwort auf Frage 4 bedeutet wahrscheinlich, dass Sie Multicast optimal für eine wesentlich effizientere Datenbereitstellung nutzen möchten. Im Gegensatz zu beliebten Lösungen auf Transportebene wie TLS/DTLS, die die Vorteile von Multicast nicht nutzen können, ist DDS Security mit integrierter Multicast-Unterstützung ausgestattet, die eine optimierte Datenbereitstellungsleistung ermöglicht.

Wenn Ihre Antwort auf Frage 5 positiv ist, haben Sie die Möglichkeit, Sicherheit einzubauen, ohne sich zu viele Gedanken über den Umgang mit Legacy-Code machen zu müssen. Gleichzeitig stehen auf Ihrer Anforderungsliste wahrscheinlich Skalierbarkeit, Interoperabilität und die Vermeidung von Anbieterbindung. DDS ist eine der zentralen Konnektivitätstechnologien für das IIoT (weitere Informationen finden Sie unter IICF) und basiert auf einem öffentlich verfügbaren Satz von Spezifikationen. Darüber hinaus verwendet DDS Security eine steckbare Architektur mit standardisierten APIs für Authentifizierung, Autorisierung, Kryptographie, Datenkennzeichnung und Protokollierung. Diese Funktionen, zusammen mit der Unterstützung expliziter und granularer Sicherheitsrichtlinien für die Datenverteilung, machen DDS zu einem starken Kandidaten für IIoT-Systeme der nächsten Generation, die es ermöglichen, Sicherheit in Ihre Systemarchitektur zu integrieren und nicht darauf zu verankern.

Das hört sich alles interessant an, aber nutzt jemand DDS Security? Die Antwort ist ein starkes Ja. RTI Connext DDS Secure wurde bereits von einer Reihe unserer kommerziellen und staatlichen Kunden evaluiert und verwendet. Wir haben das Feedback, das wir von diesen Early Adopters erhalten haben, in unsere Produktlinie übernommen. In Fällen, in denen weitere Klarstellungen oder Aktualisierungen der DDS-Sicherheitsspezifikation erforderlich waren, haben wir die Probleme der DDS-Community zur Verfügung gestellt, um den Standard weiter zu verbessern.

Beispiel:DDS-Sicherheit für sichere Interoperabilität medizinischer Geräte

Ein interessantes Beispiel, das die Vorteile von DDS und DDS-Sicherheit zeigt, zeigt sich im Kontext von Integrated Clinical Environments (ICE). Das ICE-Framework, wie es durch den ASTM F2761-09-Standard definiert ist, bietet einen Ansatz für die Integration heterogener medizinischer Geräte und die Koordinierung i

[1] [2] 下一页