testperson 1.618 Geschrieben 8. Juli Melden Teilen Geschrieben 8. Juli Du meinst diese Liste: Security guidelines for system services in Windows Server 2016 | Microsoft Learn Was aktuelleres und offizielles gibt es AFAIK nicht. 1 Zitieren Link zu diesem Kommentar
magheinz 108 Geschrieben 8. Juli Melden Teilen Geschrieben 8. Juli vor einer Stunde schrieb Sunny61: Weniger ist mehr. Es gab mal ein Excel Sheet von MS mit den Diensten, die man abschalten kann, finde ich auf die Schnelle nicht mehr. Alternativ: https://www.der-windows-papst.de/2019/12/01/windows-server-unnoetige-dienste-abschalten/ https://www.der-windows-papst.de/2020/12/15/windows-server-unwichtige-dienste-abschalten/ https://gist.github.com/GavinEke/abfc2a547aea74b9d74a2c0c598f3fd7 Das muss natürlich jeder selbst entscheiden, welche Dienste er deaktiviert. unser VM-Template ist nach Franky erst mal grundsätzlich gehärtet. Da sind einige Dienste ausgeschaltet. https://www.frankysweb.de/windows-server-2022-absichern-hardening/ vor 3 Stunden schrieb wznutzer: Die kaufmännische Seite hat da Verträge, aber ein Vertrag ist für meine Bedenken nur dazu da um einen Schuldigen zu finden. Er verhindert ja nichts. Da packt man halt Vertragsstrafen, NDAs etc mit rein. Wenn die aber wirklich nur die Webschnittstelle brauchen, dann pack denen doch eine Linuxkiste mit Browser und lokalen usern hin Da würde ich mir diesen ganzen Windows-Absicherungsstress ersparen. Die Kiste packst du in ein eigenes VLAN und lässt nur http(s) zu dem ERP und DNS zu deinen Nameservern zu. Zugang per VPN nur auf genau diesen einen Linuxrechner. 1 Zitieren Link zu diesem Kommentar
wznutzer 33 Geschrieben 8. Juli Autor Melden Teilen Geschrieben 8. Juli vor 21 Minuten schrieb magheinz: Wenn die aber wirklich nur die Webschnittstelle brauchen, dann pack denen doch eine Linuxkiste mit Browser und lokalen usern hin Ob mir das hilft muss ich noch überlegen. Die ERP-Software hat keine Webschnittstelle (Windows-Forms-Anwendung). Die Webschnittstelle wäre der HTML5-Client der auf einem RDS-Gateway installiert werden kann, aber auch der macht ja dann "nur" RDP in "mein" Netz. Der HTML5-Client wäre in diesem Fall nur ein Gimmick. Sicherheitstechnisch bringt mir das nur was, wenn ich den Zugang hinter einen Azure-App-Proxy packe. Dann gibt es einen regulären Microsoft-Login mit ein einzutippenden Zahl, während die RDS-MFA "nur" eine Pushnachricht ist. Zitieren Link zu diesem Kommentar
Sunny61 804 Geschrieben 8. Juli Melden Teilen Geschrieben 8. Juli vor 1 Stunde schrieb testperson: Du meinst diese Liste: Security guidelines for system services in Windows Server 2016 | Microsoft Learn Was aktuelleres und offizielles gibt es AFAIK nicht. Ja, es gab aber auch mal ein Excel Sheet dazu. ;) Sollte ich es noch finden, häng ich es hier dran. ;) Zitieren Link zu diesem Kommentar
magheinz 108 Geschrieben 8. Juli Melden Teilen Geschrieben 8. Juli Am 5.7.2024 um 13:38 schrieb wznutzer: Für das was getan werden muss, ist jedoch ein Browser ausreichend Hast du doch geschrieben. Was ist jetzt nötig für den Zugriff aus ERP? Ein Browser oder eine Windowsanwendung? Liegts an der Hitze hier bei mir? Zitieren Link zu diesem Kommentar
Dukel 448 Geschrieben 8. Juli Melden Teilen Geschrieben 8. Juli Mit HTML5 meint der TO das RDS Webserver/RDS Host. Der externe MA soll auf RDS via Browser Zugreifen und die Anwendung selber ist eine Windows GUI Anwendung. Zitieren Link zu diesem Kommentar
magheinz 108 Geschrieben 8. Juli Melden Teilen Geschrieben 8. Juli vor 11 Minuten schrieb Dukel: Mit HTML5 meint der TO das RDS Webserver/RDS Host. Der externe MA soll auf RDS via Browser Zugreifen und die Anwendung selber ist eine Windows GUI Anwendung. Ah ok. Ist wirklich zur warm hier... Man könnte versuchen die Applikation als Remoteapp von der Linuxkiste zu starten. Vorteil wäre, die Dienstleister hätten dann zwar ein AD-Konto, aber keinen direkten Zugriff auf die Windowsumgebungen. Manche Firewalls haben sowas such direkt als Clientless-VPN o.ä. integriert. Zitieren Link zu diesem Kommentar
wznutzer 33 Geschrieben 8. Juli Autor Melden Teilen Geschrieben 8. Juli vor 15 Minuten schrieb magheinz: Liegts an der Hitze hier bei mir? Kleines Missverständnis, alles gut . vor 8 Minuten schrieb Dukel: Mit HTML5 meint der TO das RDS Webserver/RDS Host. Der externe MA soll auf RDS via Browser Zugreifen und die Anwendung selber ist eine Windows GUI Anwendung. Ja, genau vor 4 Minuten schrieb magheinz: Vorteil wäre, die Dienstleister hätten dann zwar ein AD-Konto, aber keinen direkten Zugriff auf die Windowsumgebungen. Ich denke über so Sachen nach, dass z. B. über die ERP-Anwendung ein FileDialog geöffnet werden kann und darin dann ein fast vollwertiger Explorer zur Verfügung steht, was irgendwie dann auch Zugriff auf die Umgebung ist. Ich weiß ja nicht, was die bösen Buben alles können, aber einige von denen können wohl viel. Zitieren Link zu diesem Kommentar
magheinz 108 Geschrieben 8. Juli Melden Teilen Geschrieben 8. Juli vor 2 Stunden schrieb wznutzer: Ich denke über so Sachen nach, dass z. B. über die ERP-Anwendung ein FileDialog geöffnet werden kann und darin dann ein fast vollwertiger Explorer zur Verfügung steht, was irgendwie dann auch Zugriff auf die Umgebung ist. Ich weiß ja nicht, was die bösen Buben alles können, aber einige von denen können wohl viel. Das klingt mir langsam nach einem organisatorischen, statt nach einem technischen Problem. Wenn da so viel Misstrauen ist, dann müssen diese Leute halt unter Aufsicht arbeiten. Abgesehen davon: die sehen doch auch im Explorer nur die Dinge, zu denen sie Zugriff haben. Wie oft arbeiten die denn in dem System? Kann man da nicht jemanden drannsetzen, der die Sessions begleitet? Zitieren Link zu diesem Kommentar
wznutzer 33 Geschrieben 9. Juli Autor Melden Teilen Geschrieben 9. Juli (bearbeitet) vor 16 Stunden schrieb magheinz: Das klingt mir langsam nach einem organisatorischen, statt nach einem technischen Problem. Ich sehe das nur als technisches Problem. Externe Vertriebler, Marketingleute arbeiten täglich mehrere Stunden im ERP. Die Aufgabe ist nun: Stelle einen Bereich für das ERP zur Verfügung in dem möglichst nichts passieren kann, auch wenn die Zugangsdaten in die Hände einer Ransomware-Group fallen. Die externen Vertriebler sind anständige Leute und machen nichts böses, die sind nur vielleicht mal unachtsam. Warum der Unterschied zu eigenen Leuten? Eigene Leute arbeiten auf zugenagelten und überwachten Geräten. Die Externen arbeiten auf irgendwas, weil die das wollen und sonst nicht für uns arbeiten. Und wir alle wissen, dass die Geschwister "Ich habe doch nur..." und "Ich wollte nur kurz..." der Anfang vom Übel sein können. Vielen Dank nochmals für die Tipps und die rege Teilnahme bearbeitet 9. Juli von wznutzer Zitieren Link zu diesem Kommentar
Dukel 448 Geschrieben 9. Juli Melden Teilen Geschrieben 9. Juli Wie sieht die Applikation aus? Ist das eine Client / Server oder Client / DB Anwendung? Könnte man die Client Applikation den Anwendern bereitstellen? Dann wird nur der Zugriff auf den Server / die DB benötigt. Zitieren Link zu diesem Kommentar
wznutzer 33 Geschrieben 9. Juli Autor Melden Teilen Geschrieben 9. Juli Gerade eben schrieb Dukel: Wie sieht die Applikation aus? Ist das eine Client / Server oder Client / DB Anwendung? Könnte man die Client Applikation den Anwendern bereitstellen? Dann wird nur der Zugriff auf den Server / die DB benötigt. Windows-Forms-Anwendung (*.exe, *.dll). Grundsätzlich würde das gehen, z. B. VPN mit MFA und dann die Anwendung auf MS SQL und ein paar Verzeichnisse. Habe ich schon getestet. Die Performance ist allerdings schlecht und die Anwedung kommt nicht mit Verbindungsabbrüchen zurecht (z. B. Mobilfunk im Zug). Der RDS HTML5 Client kommt ziemlich gut mit Verbindungsabbrüchen zurecht. Ich mache das so: separater RDS im eigenen Netzwerksegment RDS mit Applocker, kein Internet, Verhaltensüberwachung usw. RDS darf nur mit DB und AD sprechen AD mal mit Purple Knight oder Forest Druid, PingCastle checken (win-win sozusagen) HTML5-Client hinter Azure App-Proxy. Das streichelt etwas die Paranoia, weil die MFA des RDS-Gateway "nur" eine Nachricht zur Bestätigung ist und nicht wie der MS-Login mit einer individuellen Zahl . Grüße an alle Zitieren Link zu diesem Kommentar
magheinz 108 Geschrieben 9. Juli Melden Teilen Geschrieben 9. Juli vor einer Stunde schrieb wznutzer: Ich sehe das nur als technisches Problem. Externe Vertriebler, Marketingleute arbeiten täglich mehrere Stunden im ERP. Und die vertreiben und bewerben die Produkte in eurem Namen? vor einer Stunde schrieb wznutzer: Die Aufgabe ist nun: Stelle einen Bereich für das ERP zur Verfügung in dem möglichst nichts passieren kann, auch wenn die Zugangsdaten in die Hände einer Ransomware-Group fallen. Die externen Vertriebler sind anständige Leute und machen nichts böses, die sind nur vielleicht mal unachtsam. Dann gib ihnen keine Rechte auf Laufwerke. Das ist doch nichts anderes als bei internen Mitarbeitern. vor einer Stunde schrieb wznutzer: Warum der Unterschied zu eigenen Leuten? Eigene Leute arbeiten auf zugenagelten und überwachten Geräten. Die Externen arbeiten auf irgendwas, weil die das wollen und sonst nicht für uns arbeiten. Und wir alle wissen, dass die Geschwister "Ich habe doch nur..." und "Ich wollte nur kurz..." der Anfang vom Übel sein können. Die externen arbeiten doch auch auf einem zugenagelten und überwachten Gerät. Halt mehrere an einem, also einem Terminalserver. Womit sie darauf zugreifen, spielt doch sicherheitstechnisch keine Rolle. Alternativ stell ihnen die gleichen Geräte wie den internen zur Verfügung und mach bei denen dann RDP auf. Zitieren Link zu diesem Kommentar
wznutzer 33 Geschrieben 9. Juli Autor Melden Teilen Geschrieben 9. Juli vor 16 Minuten schrieb magheinz: Die externen arbeiten doch auch auf einem zugenagelten und überwachten Gerät. Halt mehrere an einem, also einem Terminalserver. Womit sie darauf zugreifen, spielt doch sicherheitstechnisch keine Rolle. Ich glaube, wir ticken hier einfach anders. Für mich spielt es eine Rolle wie wahrscheinlich es ist, dass Zugangsdaten abgegriffen werden können. Im einen Fall wird bereits auf den zugreifenden Geräten versucht das Abgreifen von Zugangsdaten zu verhindern. Im zweiten Fall gibt es diese Hürde nicht und ich rechne mit einem höheren Risiko von kompromittierten Zugangsdaten. Zitieren Link zu diesem Kommentar
NorbertFe 1.968 Geschrieben 9. Juli Melden Teilen Geschrieben 9. Juli vor 11 Minuten schrieb wznutzer: Ich glaube, wir ticken hier einfach anders. Für mich spielt es eine Rolle wie wahrscheinlich es ist, dass Zugangsdaten abgegriffen werden können. Ich glaube nicht. Die Frage ist eher, wo du das Risiko siehst, bzw. wie du etwas verhindern willst, wenn du den Zugriff von BYOD zulassen musst. Also entweder die Leute arbeiten mit BYOD dann hast du auf dieses Gerät eben keine "administrative Verwaltungsmöglichkeit" und musst primär deinen Dienst schützen. Und das wäre dann eben ein html5 client der im Browser dieses BYOD läuft. Was dann innerhalb der HTML Session 5 machbar ist, hast du doch wiederum voll in der Hand. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.