Kurze Informationen für Administratoren, die das Nexus Kliniksystem (KIS) betreuen. Ein Blog-Leser hat mich über eine private Nachricht auf Facebook über ein Problem informiert (danke). Für das KIS kam ein neues Service Release heraus (muss April 2024 sein). Dazu schrieb der Leser: "Wer Nexus als KIS einsetzt, benötigt mit dem neuesten Service Release eine CA. Ein Identity Provider, der als Feature zusätzlich installiert werden muss (übernimmt der Support) erfordert dieses auf dem Webserver der Middleware. Wer also keine CA hat, steht mal eben vor einem fetten Problem. Vorher war ein Self Signed Cert noch ok." Vielleicht hilft es weiter.
Anzeige
Sorry, ich finde die Beiträge meistens interessant und verständlich – gerade wenn man über den Tellerrand hinausschauen will. Aber hier bestehen die Sätze nur aus Fachbegriffen (vgl. CA). Ein "Weiterreichen" von Nachrichten, finde ich zu etwas dünn.
Wer beruflich mit Systemen wie Nexus zu tun hat, der verfügt (hoffentlich) über ein ausreichendes Fachwissen, um mit dem Begriff CA etwas anfangen zu können. Der Umgang mit Zertifizierungsstellen (CA) ist IT 1-mal-1, weil einem heutzutage quasi überall Zertifikate begegnen.
Die Zielgruppe wird durch das Thema Nexus getriggert und kann mit diesem kleinen Schubs dann eigenständig loslaufen und ist sensibilisiert, dass es bei einem Update einen entsprechenden Stolperstein gibt. Eine eigene CA aufzusetzen und die Zertifizierungskette z.B. per GPO zu verteilen ist machbar, aber nichts was man auf einem Samstag im Rahmen eines Updates "mal eben nebenbei" einführen möchte.
Hier sind im wesentlichen Leser unterwegs, welche vom Fach sind und über entsprechendes Hintergrundwissen / Fachwissen verfügen. Das ist auch ein Grund warum ich hier so gerne lese. In den Kommentaren finden sich sehr oft hilfreiche Infos.
Was Günter nicht leisten kann, ist alle Themen auf eine Art Grundlagenlevel aufzuarbeiten und die Hintergründe detailliert zu erläutern. An dieser Stelle greift die Eigenverantwortung sich in das Thema einzuarbeiten.
Insofern empfinde ich die Kritik in einem Fachblog als etwas deplatziert.
Ja, das kann ich nachvollziehen. Danke!
wie wäre es mit certificate authority ?
Im Regefall hat man bei einem Einsatz von Active Directy die interne CA direkt mit eingerichtet oder man schei*t auf jegliches Security und verteilt dutzende / hunderte SelfSigned Zertifikate per GPO.
Wundert mich immer weniger, dass Krankenhäuser so oft verschlüsselt werden. Und nein, die AD interne CA kostet keinen Cent extra, muss nur einmal ordentlich eingerichtet werden.
Und btw: CA = Certificate Authority, ein Dienst / Service mit man innerhalb der Domain Zertifikate er- und ausstellen kann, denen dann die Client vertrauen, da man nur noch Root-Zertifikat auf die Clients verteilen muss und nicht jedes Zertifikat einzeln. Durch das zentrale Management kann man auch gezielt einzelne Zertifikate wiederrufen. Das ist eigentlich eine Standard-Funktion die man im AD aktiv haben muss (aber bitte die Webregistrierung deaktiviert lassen :D )
Eine interne CA benötigt man heute eigentlich immer, da immer mehr Anwendungen webbasiert arbeiten. Bei uns kann man z.B. die E-Mail-Archivierung über den Webbrowser aufrufen oder Auswertungen aus dem ERP-System im Webbrowser erstellen. Auch ein interner Exchange-Server benötigt valide Zertifikate.
-> Alles was normale Anwender nutzen muss sauber mit Zertifikaten versehen sein
Bringt man den Leute nämlich bei die Zertifikats-Warnungen von Outlook oder die Warnung im Webbrowser einfach wegzuklicken, dann hat man schon verloren.
Hat man Dienste, welche auch von Dritten verwendet werden können, dann ist die Verwendung einer externen CA Pflicht, so dass auch Kunden keine Warnung bekommen. Die interne CA ist eben nur intern.
Was man diskutieren kann ist, ob wirklich jedes Management-Interface der IT über Zertifikate der internen CA verfügen muss oder ob es an dieser Stelle auch ein self-signed Zertifikat tut.
Hat man 50 DECT-Sender von ASCOM, dann müsste man dafür 50 Zertifikate ausstellen, installieren und regelmäßig wechseln.
Leider unterstützen viele Geräte eben keine automatische Verlängerung von Zertifikaten und erzeugen so eine Menge Handarbeit. Dazu kommt dann noch, dass die akzeptierte Lebensdauer von Zertifikaten in Webbrowsern rückläufig ist. Man muss öfter wechseln, was den Arbeitsaufwand weiter erhöht.
Sind diese Geräte ein einem eigenen VLAN separiert und nur der IT zugänglich, so ist der Sicherheitsgewinn zwischen beiden Varianten aus meiner Ansicht nach ehr gering.
Gutes Beispiel mit den DECT Antennen (wir haben auch Ascon), die haben leider schon diverse Probleme mit Zertifikaten >2048bit, sind halt schon was älter. Aber: man kann die Zertfikate auch via Script erstellen und zusammen mit Azubi ist auch an den stellen ein Austausch schnell gemacht. Sehe so etwas eher als reguläre Arbeit statt eines extra Aufwands
Bei solchen Geräten nutzen wir allerdings auch längere Laufzeiten für Zertifikate, ebenso bei Management-Interfaces usw. Und das mit den Browser: leider wahr.
Wir tauschen die Zertifikate z.B. am iDRAC immer aus, Laufzeit auf 5Jahre und damit die gesamte geplante Lebensdauer des Gerätes. Da die eh in einem dedizierten Netz sind, ist es mehr für uns in der IT-Abteilung, damit bei einem Zugriff keine Fehlermeldung erhält (man spart sich dann die Klicks – wir sind ja faul :D )
Lediglich Webserver, Client/Server usw. laufen mit max. 2 Jahren. Für alles externe haben wir Verträge mit öffentlichen CAs
Ps. Wer nicht mit openssl sich eine CA selbst bauen möchte, kann das auch per GUI über https://www.hohnstaedt.de/xca/ machen. Wir erstellen hiermit Wildcard-SAN-Zertifikate. Damit kann man auch den Nutzungszweck und das Erneuern easy steuern.