Jump to content

Konten für externe "Mitarbeiter" / Freelancer usw.


Empfohlene Beiträge

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.

 

Link zu diesem Kommentar
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.

Link zu diesem Kommentar
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. 

Link zu diesem Kommentar
vor 15 Minuten schrieb magheinz:

Liegts an der Hitze hier bei mir?

Kleines Missverständnis, alles gut :D.

 

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 :thumb1: 

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.

Link zu diesem Kommentar
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? 

Link zu diesem Kommentar
Geschrieben (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 von wznutzer
Link zu diesem Kommentar
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 :grins2:.

Grüße an alle

Link zu diesem Kommentar
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.

Link zu diesem Kommentar
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.

Link zu diesem Kommentar
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. 

Link zu diesem Kommentar

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...