19
Domänenbeitritt verhindern
Guten Abend zusammen,
ich befasse mich gedanklich mit dem Thema Windows Domäne. Dazu ein hypothetisches Beispiel zu dem ich keine wirkliche Lösung bei meiner Suche gefunden habe.
Und zwar ist meine Überlegung das genaue Gegenteil von einem Domänenbeitritt: Das Verweigern eines Domänenbeitritts.
Folgende fiktive Situation: Ein Rechner der als Stand-Alone konzipiert ist wird bei einem Kunden aufgestellt. Der Rechner darf aus rechtlicher Sicht nach Auslieferung nicht verändert werden (Medizinprodukt) da sonst die Betriebserlaubnis erlöschen würde. Einige Kunden würden aber aufgrund der Netzwerkstruktur diesen Rechner dennoch in die Domäne aufnehmen und dadurch signifikante Änderungen am System vornehmen. Meine Überlegung war es nun, ob es eine Möglichkeit gib, lokal den Beitritt in eine beliebige Domäne zu verhindern. Leider habe ich nichts passendes gefunden, lediglich die Möglichkeit bestimmten Gruppen einer Domäne den Zugang zu einem Rechner zu verwehren aber nicht um keinerlei Domäne auf dem Gerät zuzulassen. Habe ich etwas übersehen oder bietet Microsoft diese Möglichkeit gar nicht an?
Schönen Abend und vielen dank im Voraus
ich befasse mich gedanklich mit dem Thema Windows Domäne. Dazu ein hypothetisches Beispiel zu dem ich keine wirkliche Lösung bei meiner Suche gefunden habe.
Und zwar ist meine Überlegung das genaue Gegenteil von einem Domänenbeitritt: Das Verweigern eines Domänenbeitritts.
Folgende fiktive Situation: Ein Rechner der als Stand-Alone konzipiert ist wird bei einem Kunden aufgestellt. Der Rechner darf aus rechtlicher Sicht nach Auslieferung nicht verändert werden (Medizinprodukt) da sonst die Betriebserlaubnis erlöschen würde. Einige Kunden würden aber aufgrund der Netzwerkstruktur diesen Rechner dennoch in die Domäne aufnehmen und dadurch signifikante Änderungen am System vornehmen. Meine Überlegung war es nun, ob es eine Möglichkeit gib, lokal den Beitritt in eine beliebige Domäne zu verhindern. Leider habe ich nichts passendes gefunden, lediglich die Möglichkeit bestimmten Gruppen einer Domäne den Zugang zu einem Rechner zu verwehren aber nicht um keinerlei Domäne auf dem Gerät zuzulassen. Habe ich etwas übersehen oder bietet Microsoft diese Möglichkeit gar nicht an?
Schönen Abend und vielen dank im Voraus
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1094795537
Url: https://administrator.de/contentid/1094795537
Ausgedruckt am: 21.11.2024 um 21:11 Uhr
19 Kommentare
Neuester Kommentar
Moin,
Windows 10 Home einsetzen
Oder einen Benutzer bereitstellen, der KEINE lokalen Adminrechte hat.
Fernab:
Mit IT-bezogenen Medizinprodukten habe ich (zum Glück) keine Berührungen, aber wie sind die Kisten sonst eingerichtet?
Wie patcht ihr eure Systeme, sodass die durch MS geschlossenen Lücken auch Einzug auf eure Systeme finden?
Wenn die nicht im Netz hängen, können die natürlich auch deutlich weniger angegriffen werden und dann erübrigt sich auch der Wunsch, einen Beitritt zur Domäne zu verhindern
Wenn es euren Kunden nur um die Update-Versorgung gehen sollte:
Einen Client kann man auch ohne Domänenbeitritt mit dem WSUS verbinden. Dazu einfach die richtigen RegKeys füllen.
Die Werte könnt ihr ja per PS-Script abfragen und dann bei Inbetriebnahme noch setzen.
Gruß
em-pie
Windows 10 Home einsetzen
Oder einen Benutzer bereitstellen, der KEINE lokalen Adminrechte hat.
Fernab:
Mit IT-bezogenen Medizinprodukten habe ich (zum Glück) keine Berührungen, aber wie sind die Kisten sonst eingerichtet?
Wie patcht ihr eure Systeme, sodass die durch MS geschlossenen Lücken auch Einzug auf eure Systeme finden?
Wenn die nicht im Netz hängen, können die natürlich auch deutlich weniger angegriffen werden und dann erübrigt sich auch der Wunsch, einen Beitritt zur Domäne zu verhindern
Wenn es euren Kunden nur um die Update-Versorgung gehen sollte:
Einen Client kann man auch ohne Domänenbeitritt mit dem WSUS verbinden. Dazu einfach die richtigen RegKeys füllen.
Die Werte könnt ihr ja per PS-Script abfragen und dann bei Inbetriebnahme noch setzen.
Gruß
em-pie
Zitat von @grmg2010:
Meine Überlegung war es nun, ob es eine Möglichkeit gib, lokal den Beitritt in eine beliebige Domäne zu verhindern.
Meine Überlegung war es nun, ob es eine Möglichkeit gib, lokal den Beitritt in eine beliebige Domäne zu verhindern.
Stringentes Anwenden von Cat9 hilft den Kunden zu überzeugen, daß die Kiste nicht in eine Domain darf. Den Netzwerkport zukleben hilft auch.
lks
Ja, Home ist naheliegend.
Aber sag an: welche Rechte hat der vermeintliche Gegner, ist der denn Domänenadmin? Und bist du auch selbst Admin der Domäne?
Man kann ja nicht-Domadnins das Aufnahmerecht entziehen.
Auch kannst du die Abmeldeberechtigungen auf diesem PC nehmen. Ebenso kann per Firewallregel der Zugang zum DC gesperrt werden. All das verhindert die Aufnahme.
Aber sag an: welche Rechte hat der vermeintliche Gegner, ist der denn Domänenadmin? Und bist du auch selbst Admin der Domäne?
Man kann ja nicht-Domadnins das Aufnahmerecht entziehen.
Auch kannst du die Abmeldeberechtigungen auf diesem PC nehmen. Ebenso kann per Firewallregel der Zugang zum DC gesperrt werden. All das verhindert die Aufnahme.
Min em-pie,
Home ist natürlich die Lösung
Der Benutzer, mit dem täglich gearbeitet wird hat keinerlei Administrationsrechte. Die Problematik dabei ist aber eher, da die Kunden die Rechner erwerben und damit dann auch theoretisch das machen können was sie möchten. Allerdings sollen wir dann Support bereitstellen, was wir aber schwer machen können das Konfigurationen von uns verändert werden könnten, abhängig der in der Domäne getzten Richtlinien.
Das System ist leider nicht komplett autark, da es mit anderen Servern bezüglich des Datenaustausches im Netzwerk kommunizieren müssen. Es ist aber auf Grundlage von Sisyphus des BSI gehärtet, alle unnötigen Komponenten Deaktiviert und die Firewall strikt konfiguriert, das nur die wirklich benötigen Dienste kommunizieren dürfen.
Automatische Updates sind auf den Systemen deaktiviert und zwar aus dem folgenden Grund: Da die Updates von Microsoft nicht immer fehlerfrei sind, kann dem Kunden nicht garantiert werden, dass das System fehlerfrei bei jedem Update funktioniert. Beispiel die Druckerpanne aus dem März hat bei den verwendeten Druckern schwarze Seiten geliefert.
Aus diesem Grund werden alle Updates zuerst auf Kompatibilität des Systems getestet und dann freigegeben. Je nach Dringlichkeit werden diese entweder vor Ort bei der Wartung des Produktes oder via Fernwartung eingespielt.
Home ist natürlich die Lösung
Der Benutzer, mit dem täglich gearbeitet wird hat keinerlei Administrationsrechte. Die Problematik dabei ist aber eher, da die Kunden die Rechner erwerben und damit dann auch theoretisch das machen können was sie möchten. Allerdings sollen wir dann Support bereitstellen, was wir aber schwer machen können das Konfigurationen von uns verändert werden könnten, abhängig der in der Domäne getzten Richtlinien.
Das System ist leider nicht komplett autark, da es mit anderen Servern bezüglich des Datenaustausches im Netzwerk kommunizieren müssen. Es ist aber auf Grundlage von Sisyphus des BSI gehärtet, alle unnötigen Komponenten Deaktiviert und die Firewall strikt konfiguriert, das nur die wirklich benötigen Dienste kommunizieren dürfen.
Automatische Updates sind auf den Systemen deaktiviert und zwar aus dem folgenden Grund: Da die Updates von Microsoft nicht immer fehlerfrei sind, kann dem Kunden nicht garantiert werden, dass das System fehlerfrei bei jedem Update funktioniert. Beispiel die Druckerpanne aus dem März hat bei den verwendeten Druckern schwarze Seiten geliefert.
Aus diesem Grund werden alle Updates zuerst auf Kompatibilität des Systems getestet und dann freigegeben. Je nach Dringlichkeit werden diese entweder vor Ort bei der Wartung des Produktes oder via Fernwartung eingespielt.
Zitat von @grmg2010:
Der Rechner darf aus rechtlicher Sicht nach Auslieferung nicht verändert werden (Medizinprodukt) da sonst die Betriebserlaubnis erlöschen würde.
Vereinheitlichter Schreibfilter (Unified Write Filter, UWF)Der Rechner darf aus rechtlicher Sicht nach Auslieferung nicht verändert werden (Medizinprodukt) da sonst die Betriebserlaubnis erlöschen würde.
Aufsetzen, WriteFilter aktivieren, feddisch, nach Reboot alles wieder so wie er aufgesetzt wurde, jegliche Änderung wieder futsch.
Zitat von @DerWoWusste:
Ja, Home ist naheliegend.
Aber sag an: welche Rechte hat der vermeintliche Gegner, ist der denn Domänenadmin? Und bist du auch selbst Admin der Domäne?
Man kann ja nicht-Domadnins das Aufnahmerecht entziehen.
Auch kannst du die Abmeldeberechtigungen auf diesem PC nehmen. Ebenso kann per Firewallregel der Zugang zum DC gesperrt werden. All das verhindert die Aufnahme.
Ja, Home ist naheliegend.
Aber sag an: welche Rechte hat der vermeintliche Gegner, ist der denn Domänenadmin? Und bist du auch selbst Admin der Domäne?
Man kann ja nicht-Domadnins das Aufnahmerecht entziehen.
Auch kannst du die Abmeldeberechtigungen auf diesem PC nehmen. Ebenso kann per Firewallregel der Zugang zum DC gesperrt werden. All das verhindert die Aufnahme.
Ja der "Gegner" ist die IT des Kunden, akso deren Domänen-Admins. Das Gerät selber ist als Stand-Alone konzipiert und gehört somit keiner Domäne an sondern seiner eigenen Workgroup.
Zitat von @149062:
Aufsetzen, WriteFilter aktivieren, feddisch, nach Reboot alles wieder so wie er aufgesetzt wurde, jegliche Änderung wieder futsch.
Zitat von @grmg2010:
Der Rechner darf aus rechtlicher Sicht nach Auslieferung nicht verändert werden (Medizinprodukt) da sonst die Betriebserlaubnis erlöschen würde.
Vereinheitlichter Schreibfilter (Unified Write Filter, UWF)Der Rechner darf aus rechtlicher Sicht nach Auslieferung nicht verändert werden (Medizinprodukt) da sonst die Betriebserlaubnis erlöschen würde.
Aufsetzen, WriteFilter aktivieren, feddisch, nach Reboot alles wieder so wie er aufgesetzt wurde, jegliche Änderung wieder futsch.
Darüber hatte ich auch nachgedacht, allerdings ändern sich im Betrieb einige Daten bzw werden Komponenten bei der Wartung eventuell geupdatet. aber dafür sollten sich ja Ausnahmeregelungen setzen lassen.
Hmm.. du könntest mal schauen, ob es hilft, die Firewall noch weiter zu parametrisieren:
Quelle: https://aventistech.com/2020/02/20/firewall-ports-required-to-join-ad-do ...
u.U. beisst sich das dann aber, wenn ihr auf Server zugreifen wollt, um Daten auszutauschen.
Wenigstens Port 53 (DNS) würde ich offen lassen sowie 445 (SMB, Net Logon)
"Versuch macht kluch"
Windows 10 Client can join to Windows 2019 AD Domain with the following Ports allow in Firewall
TCP 88 (Kerberos Key Distribution Center)
TCP 135 (Remote Procedure Call)
TCP 139 (NetBIOS Session Service)
TCP 389 (LDAP)
TCP 445 (SMB,Net Logon)
UDP 53 (DNS)
UDP 389 (LDAP, DC Locator, Net Logon)
TCP 49152-65535 (Randomly allocated high TCP ports)u.U. beisst sich das dann aber, wenn ihr auf Server zugreifen wollt, um Daten auszutauschen.
Wenigstens Port 53 (DNS) würde ich offen lassen sowie 445 (SMB, Net Logon)
"Versuch macht kluch"
Zitat von @em-pie:
Hmm.. du könntest mal schauen, ob es hilft, die Firewall noch weiter zu parametrisieren:
Quelle: https://aventistech.com/2020/02/20/firewall-ports-required-to-join-ad-do ...
u.U. beisst sich das dann aber, wenn ihr auf Server zugreifen wollt, um Daten auszutauschen.
Wenigstens Port 53 (DNS) würde ich offen lassen sowie 445 (SMB, Net Logon)
"Versuch macht kluch"
Hmm.. du könntest mal schauen, ob es hilft, die Firewall noch weiter zu parametrisieren:
> Windows 10 Client can join to Windows 2019 AD Domain with the following Ports allow in Firewall
> TCP 88 (Kerberos Key Distribution Center)
> TCP 135 (Remote Procedure Call)
> TCP 139 (NetBIOS Session Service)
> TCP 389 (LDAP)
> TCP 445 (SMB,Net Logon)
> UDP 53 (DNS)
> UDP 389 (LDAP, DC Locator, Net Logon)
> TCP 49152-65535 (Randomly allocated high TCP ports)
> u.U. beisst sich das dann aber, wenn ihr auf Server zugreifen wollt, um Daten auszutauschen.
Wenigstens Port 53 (DNS) würde ich offen lassen sowie 445 (SMB, Net Logon)
"Versuch macht kluch"
Es werden hauptsächlich DICOM Daten ausgetauscht, allerdings kann der Zugriff auf SMB-Freigaben auch erforderlich sein. Deshalb ist 445 einer der wenigen offen Ports, zumindest ausgehend. Ich werde das mit der noch weiter verfeinerten Firewall auf jeden Fall ins Auge fassen.
Zitat von @grmg2010:
Joa, kein Problem lässt sich einstellen und im Updateplan auch mit den Windows-Updates automatisiert einspielen.Zitat von @149062:
allerdings ändern sich im Betrieb einige Daten bzw werden Komponenten bei der Wartung eventuell geupdatet. aber dafür sollten sich ja Ausnahmeregelungen setzen lassen.Zitat von @149062:
Zitat von @grmg2010:
Joa, kein Problem lässt sich einstellen und im Updateplan auch mit den Windows-Updates automatisiert einspielen.Zitat von @149062:
allerdings ändern sich im Betrieb einige Daten bzw werden Komponenten bei der Wartung eventuell geupdatet. aber dafür sollten sich ja Ausnahmeregelungen setzen lassen.Setzt allerdings voraus, dass es sich um eine Enterprise Version handelt und keine Pro. Gut das Windows 10 IoT auch der Enterprise Gruppe zugeordnet ist.
Zitat von @grmg2010:
Ja der "Gegner" ist die IT des Kunden, akso deren Domänen-Admins. Das Gerät selber ist als Stand-Alone konzipiert und gehört somit keiner Domäne an sondern seiner eigenen Workgroup.
Ja der "Gegner" ist die IT des Kunden, akso deren Domänen-Admins. Das Gerät selber ist als Stand-Alone konzipiert und gehört somit keiner Domäne an sondern seiner eigenen Workgroup.
Die IT des Kunden ist quasi allmächtig. Da kannst Du eigentlich nichts verhindern. Aber du kannst durch genaue vertragliche Regelungen klarstellen, was erlaubt ist und was nicht, und welche Folgen (ggf Konventionalstrafen, Auspeitschung mit Cat9, etc.) das nach sich zieht.
lks
Zitat von @Lochkartenstanzer:
Die IT des Kunde ist quasi allmächtig. Da kannst Du eigentlich nichts verhindern. Aber du kannst durch genaue vertragliche Regelungen klarstellen, was erlaubt ist und was nicht, und welche Folgen (ggf Konventionalstrafen, Auspeitschung mit Cat9, etc.) das nach sich zieht.
lks
Zitat von @grmg2010:
Ja der "Gegner" ist die IT des Kunden, akso deren Domänen-Admins. Das Gerät selber ist als Stand-Alone konzipiert und gehört somit keiner Domäne an sondern seiner eigenen Workgroup.
Ja der "Gegner" ist die IT des Kunden, akso deren Domänen-Admins. Das Gerät selber ist als Stand-Alone konzipiert und gehört somit keiner Domäne an sondern seiner eigenen Workgroup.
Die IT des Kunde ist quasi allmächtig. Da kannst Du eigentlich nichts verhindern. Aber du kannst durch genaue vertragliche Regelungen klarstellen, was erlaubt ist und was nicht, und welche Folgen (ggf Konventionalstrafen, Auspeitschung mit Cat9, etc.) das nach sich zieht.
lks
DAs ist es eben, eigentlich müsste das vertraglich geregelt sein. Inwiefern dem auch so ist kann ich nicht beurteilen. Ich befürchte allerdings mehr als ein "Bite" wird nicht drin stehen
Naja erstmal vielen Dank an alle, es waren ein paar kontruktive Vorschläge dabei, auch wenn ich befürchte das sich an der Situation auch daurch nichts ändern wird da der Kunde Köig ist. Einen schönen abend noch.
Das mit dem Vertrag ist relativ einfach.
Dem Lieferschein/ der Rechnung den Passus einfügen
"Mit nicht abgestimmten und freigegebenen Änderungen an der Hardware/ Software inkl. Veränderungen am Betriebssystem erlischt jegliche Haftung seitens des Lieferanten. Im Schadensfall übernimmt ausschließlich der Kunde die Verantwortung".
Oder so ähnlich.
Zur Sicherheit aber noch mit eurem Rechtsverdreher des Vertrauens abstimmen. Nur, weil man etwas schreibt, hat es nicht unbedingt eine Rechtswirksamkeit...
Du/ Ihr habt in aller Regel ja solche und solche Kunden.
Ich frage unsere Lieferanten im Vorfeld "Darf ich euer System ins AD aufnehmen?" Bei Nein -> abgeschottetes VLAN, bei Ja -> anderes, weniger abgeschottetes VLAN.
Aber nicht jeder euerer Kunden hat vermutlich getrennte Netze...
Dem Lieferschein/ der Rechnung den Passus einfügen
"Mit nicht abgestimmten und freigegebenen Änderungen an der Hardware/ Software inkl. Veränderungen am Betriebssystem erlischt jegliche Haftung seitens des Lieferanten. Im Schadensfall übernimmt ausschließlich der Kunde die Verantwortung".
Oder so ähnlich.
Zur Sicherheit aber noch mit eurem Rechtsverdreher des Vertrauens abstimmen. Nur, weil man etwas schreibt, hat es nicht unbedingt eine Rechtswirksamkeit...
Du/ Ihr habt in aller Regel ja solche und solche Kunden.
Ich frage unsere Lieferanten im Vorfeld "Darf ich euer System ins AD aufnehmen?" Bei Nein -> abgeschottetes VLAN, bei Ja -> anderes, weniger abgeschottetes VLAN.
Aber nicht jeder euerer Kunden hat vermutlich getrennte Netze...
Zitat von @grmg2010:
DAs ist es eben, eigentlich müsste das vertraglich geregelt sein. Inwiefern dem auch so ist kann ich nicht beurteilen. Ich befürchte allerdings mehr als ein "Bite" wird nicht drin stehen
Zitat von @Lochkartenstanzer:
Die IT des Kunde ist quasi allmächtig. Da kannst Du eigentlich nichts verhindern. Aber du kannst durch genaue vertragliche Regelungen klarstellen, was erlaubt ist und was nicht, und welche Folgen (ggf Konventionalstrafen, Auspeitschung mit Cat9, etc.) das nach sich zieht.
lks
Zitat von @grmg2010:
Ja der "Gegner" ist die IT des Kunden, akso deren Domänen-Admins. Das Gerät selber ist als Stand-Alone konzipiert und gehört somit keiner Domäne an sondern seiner eigenen Workgroup.
Ja der "Gegner" ist die IT des Kunden, akso deren Domänen-Admins. Das Gerät selber ist als Stand-Alone konzipiert und gehört somit keiner Domäne an sondern seiner eigenen Workgroup.
Die IT des Kunde ist quasi allmächtig. Da kannst Du eigentlich nichts verhindern. Aber du kannst durch genaue vertragliche Regelungen klarstellen, was erlaubt ist und was nicht, und welche Folgen (ggf Konventionalstrafen, Auspeitschung mit Cat9, etc.) das nach sich zieht.
lks
DAs ist es eben, eigentlich müsste das vertraglich geregelt sein. Inwiefern dem auch so ist kann ich nicht beurteilen. Ich befürchte allerdings mehr als ein "Bite" wird nicht drin stehen
Dann wird es höchste zeit für die Anschaffung eines LART. Diesen erstmal an den eigenen Vertriebsmitarbeitern warmlaufen lasen und danach ggf. beim Kunden einsetzen.
lks
Moin, ganz ehrlich, ich verstehe das Problem nicht. Medizingeräte benötigen eine Zulassung nach MPG. Darin wird als Teil des Medizingerätes der Rechner in GENAU der Konfiguration (sowohl Software als auch HW) zugelassen. Werden daran Änderungen vorgenommen erlischt die Zulassung und das Medizingerät darf nicht mehr verwendet werden. Setzen das Arzt oder das KH es dennoch weiter ein, ist das juristisch ein Tanz auf dem Vulkan!
Wenn der Betreiber dieses Wissen nicht hat, sollte er den Job wechseln!
Zur Not das ganze noch mal mit in die Verträge schreiben und dein Problem ist gelöst.
Wenn der Betreiber dieses Wissen nicht hat, sollte er den Job wechseln!
Zur Not das ganze noch mal mit in die Verträge schreiben und dein Problem ist gelöst.
1
Hallo,
Der Aufwand ist für den Hersteller sicherlich höher, aber für uns stellt dieses Vorgehen den einzig sinnvollen Weg dar. Medizinprodukte die Daten erfassen können heute kaum noch sinnvoll isoliert betrieben werden. Der Hersteller hat für einige (besonders teure) Geräte sogar ein Upgrade Windows 7 -> Windows 10 LTSB angeboten.
Das einzige, was bisher nicht klappt, ist, dass die Zulassung immer noch keine Deutsche Tastatur einschließt.
Grüße
lcer
Zitat von @n.o.b.o.d.y:
Moin, ganz ehrlich, ich verstehe das Problem nicht. Medizingeräte benötigen eine Zulassung nach MPG. Darin wird als Teil des Medizingerätes der Rechner in GENAU der Konfiguration (sowohl Software als auch HW) zugelassen. Werden daran Änderungen vorgenommen erlischt die Zulassung und das Medizingerät darf nicht mehr verwendet werden. Setzen das Arzt oder das KH es dennoch weiter ein, ist das juristisch ein Tanz auf dem Vulkan!
Wenn der Betreiber dieses Wissen nicht hat, sollte er den Job wechseln!
Zur Not das ganze noch mal mit in die Verträge schreiben und dein Problem ist gelöst.
Wir betreiben nach MPG zugelassene Geräte eines Herstellers der das aus meiner Sicht sauber wie folgt gelöst hat:Moin, ganz ehrlich, ich verstehe das Problem nicht. Medizingeräte benötigen eine Zulassung nach MPG. Darin wird als Teil des Medizingerätes der Rechner in GENAU der Konfiguration (sowohl Software als auch HW) zugelassen. Werden daran Änderungen vorgenommen erlischt die Zulassung und das Medizingerät darf nicht mehr verwendet werden. Setzen das Arzt oder das KH es dennoch weiter ein, ist das juristisch ein Tanz auf dem Vulkan!
Wenn der Betreiber dieses Wissen nicht hat, sollte er den Job wechseln!
Zur Not das ganze noch mal mit in die Verträge schreiben und dein Problem ist gelöst.
- Windows 10 LTSB mit aktiviertem Windows Update (über MS oder WSUS möglich)
- der Domänenbeitritt ist explizit erlaubt
- sämtliche einzustellenden GPOs sind mit zulässigen Optionen explizit beschrieben (etliche Seiten im Handbuch)
- bestimmte andere Einschränkungen ((nicht) erlaubte Drittanbietersoftware, etc. ) sind ebenfalls beschrieben
Der Aufwand ist für den Hersteller sicherlich höher, aber für uns stellt dieses Vorgehen den einzig sinnvollen Weg dar. Medizinprodukte die Daten erfassen können heute kaum noch sinnvoll isoliert betrieben werden. Der Hersteller hat für einige (besonders teure) Geräte sogar ein Upgrade Windows 7 -> Windows 10 LTSB angeboten.
Das einzige, was bisher nicht klappt, ist, dass die Zulassung immer noch keine Deutsche Tastatur einschließt.
Grüße
lcer
Moin,
naja, da muss man halt immer unterscheiden, wie „nahe“ die Medizingeräte am Patienten verwendet werden. Das ist bei einem Ultraschall ggf. ganz was anderes als z.B. Großgeräten wie einem MRT oder CT. Aber solange ihr die Freigabe vom Hersteller habt, ist das ja i.O. Wobei bei in Netzwerken eingebunden Medizingeräten gerne mal vergessen wird, die ISO 80001 zu beachten.
Grüße von der Küsten
Ralf
naja, da muss man halt immer unterscheiden, wie „nahe“ die Medizingeräte am Patienten verwendet werden. Das ist bei einem Ultraschall ggf. ganz was anderes als z.B. Großgeräten wie einem MRT oder CT. Aber solange ihr die Freigabe vom Hersteller habt, ist das ja i.O. Wobei bei in Netzwerken eingebunden Medizingeräten gerne mal vergessen wird, die ISO 80001 zu beachten.
Grüße von der Küsten
Ralf
