wznutzer 33 Geschrieben 3. Juli Melden Teilen Geschrieben 3. Juli Hallo und guten Tag, mich würde interessieren wie die Zugriffe von externen Dienstleister / Freelancer bei euch geregelt sind. Ich hatte das bisher nicht. Aber nun sollen auch externe Dienstleister Zugriff auf unsere ERP-Lösung erhalten. Die Leute sind nicht am Standort. Möglicheit 1 So handhaben wie alle anderen Kollegen im Außendienst auch, also VPN oder RDS-Gateway mit MFA und Zugriff auf einen RD-Sessionhost. ==> Gefällt mir irgendwie gar nicht, weil es halt "externe" sind und die Kollegen das z. B. nur mit per Azure verwalteten Geräten machen. Die "externen" wollen aber ihre eigenen Geräte nutzen. Möglichkeit 2 Ich bastel mir ein separates VLAN in das sich die Externen einwählen können, die haben dann ein eigenes AD, einen eigenen RD-Sessionhost und es gibt "nur" die Tür SQL-Server für das ERP in das Produktivnetz. ==> Gefällt mir von der Trennung her gut, aber es ist halt auch Aufwand. Möglichkeit 3 Eine andere Lösung die ich derzeit noch nicht kenne? Es geht um 4 Leute. Der RD-Sessionhost wäre in allen Fällen "nur" per HTML5-Client für den RD-Gateway erreichbar. Applocker usw. ist sowieso auf den RD-Sessionhost aktiv. Grüße und noch einen schönen Tag. Zitieren Link zu diesem Kommentar
Sunny61 804 Geschrieben 3. Juli Melden Teilen Geschrieben 3. Juli Bei uns ist das im Einsatz: https://guacamole.apache.org/ Anmeldung 2FA. Von dort aus geht es weiter via RDP auf den Server, auf den der Dienstleister zugreifen muss. Die Konten sind dauerhaft gesperrt und werden nur auf Anforderung für die benötigte Dauer freigegeben. Die Frirewallfreigaben für die RDP-Verbindung können natürlich auch dauerhaft deaktiviert werden und nur für die Zeit der Verbindung freigeschaltet werden. Zitieren Link zu diesem Kommentar
wznutzer 33 Geschrieben 3. Juli Autor Melden Teilen Geschrieben 3. Juli vor 13 Minuten schrieb Sunny61: Bei uns ist das im Einsatz: https://guacamole.apache.org/ Das ist dann eher das Szenario, dass ein Dienstleister bei einem ganz bestimmten Problem (z. B. Hersteller von ERP-Software usw.) hilft, richtig? Bei mir sind es eher Vertriebler, Marketing, die im ERP-System dauerhaft mitarbeiten sollen. Aber danke für den Tipp, ich habe schon davon gehört, aber nicht gedacht, dass das breit verwendet wird. Zitieren Link zu diesem Kommentar
Sunny61 804 Geschrieben 3. Juli Melden Teilen Geschrieben 3. Juli Grundsätzlich ist es egal wohin du die User umleitest, entweder per RDP oder VNC auf einen Server/Client oder einen Link zu einem Webserver zur Verfügung stellen. Guacamole stellt nur eine Website zur Verfügung, der Rest ist dein Problem. Und natürlich gibst Du nur jedem User den Link/die Verbindung frei, die er auch nutzen soll. Zitieren Link zu diesem Kommentar
magheinz 108 Geschrieben 4. Juli Melden Teilen Geschrieben 4. Juli Wir haben zwei citrix-worker, auf die externe per MFA zugreifen können. Von dort aus könne sie dann weiter, so auch immer sie hinmüssen. Dafür haben die dienstleister bei uns AD-Konten. 1 Zitieren Link zu diesem Kommentar
wznutzer 33 Geschrieben 4. Juli Autor Melden Teilen Geschrieben 4. Juli Ich muss mir das nochmals überlegen, ob ich da nicht ein wenig übertreibe. Die vorgeschlagenen Lösungen basieren ja darauf, dass die externen User im Prinzip wie interne behandelt werden. Evtl. mit zeitlicher Beschränkung oder auch nicht. Aber sie sind im Netz und können dann das tun was eben User tun können die im internen Netz sind. Ich unterstelle den externen weniger Achtsamkeit als den direkt angestellten Kollegen und will die gar nicht im Netz haben. Vielleicht liege ich da aber falsch. Sinn war war zu erfahren, wie das sonst so gehandhabt wird. Vielen Dank dafür. Zitieren Link zu diesem Kommentar
Nobbyaushb 1.448 Geschrieben 4. Juli Melden Teilen Geschrieben 4. Juli Die kannst du auf einem RDS doch einschränken wie du willst! Hatte ich in meinem letzten Job auch so gemacht... Zitieren Link zu diesem Kommentar
Squire 245 Geschrieben 4. Juli Melden Teilen Geschrieben 4. Juli @Sunny61 ... Guacamole hört sich sehr spannend an. Kannte ich bisher noch nicht ... muss ich mal ausprobieren! 1 Zitieren Link zu diesem Kommentar
wznutzer 33 Geschrieben 5. Juli Autor Melden Teilen Geschrieben 5. Juli vor 11 Stunden schrieb Nobbyaushb: Die kannst du auf einem RDS doch einschränken wie du willst! Habe ich irgendwie einen Knoten im Kopf, ob das reicht. Applocker, hoffentlich korrekt konfiguriert keine Ordner auf C:\ anlegen keine cmd.exe kein Internet eigenes VLAN und nur zulassen was für das AD, Virenscanner, den Remote-Zugriff und die ERP-Software nötig ist. Zugriff nur auf die ERP-Anwendung (Remote-App) Ich überlege, ob ich in das VLAN einen schreibgeschützten DC packen kann. Dann darf der RDS nur mit dem RODC kommunizieren. Bringt ein schreibgeschützter DC im separaten "extern VLAN" in solch einem Szenario einen Sicherheitsvorteil? Zitieren Link zu diesem Kommentar
testperson 1.623 Geschrieben 5. Juli Melden Teilen Geschrieben 5. Juli vor 2 Minuten schrieb wznutzer: Bringt ein schreibgeschützter DC im separaten "extern VLAN" in solch einem Szenario einen Sicherheitsvorteil? Nein. (Es sei denn du stellst den physikalisch an einen unsicheren Ort.) Sollte der RODC das Kennwort für einen User nicht gecached haben, macht er ein Passthrough zu einem RWDC. Zitieren Link zu diesem Kommentar
wznutzer 33 Geschrieben 5. Juli Autor Melden Teilen Geschrieben 5. Juli vor 2 Minuten schrieb testperson: Nein. (Es sei denn du stellst den physikalisch an einen unsicheren Ort.) Sollte der RODC das Kennwort für einen User nicht gecached haben, macht er ein Passthrough zu einem RWDC. D. h. die Überlegung, dass ein evtl. kompromittierter RDS "nur" mit einem RODC und nicht mit den anderen RWDC kommunizieren darf ist praktisch wertlos? Würde der RODC kompromittiert, ist es dann nicht egal ob dieser physikalisch oder virtuell an einem "unsicheren Ort" steht? Zitieren Link zu diesem Kommentar
magheinz 108 Geschrieben 5. Juli Melden Teilen Geschrieben 5. Juli vor 16 Stunden schrieb wznutzer: Ich unterstelle den externen weniger Achtsamkeit als den direkt angestellten Kollegen und will die gar nicht im Netz haben. Vielleicht liege ich da aber falsch. Sinn war war zu erfahren, wie das sonst so gehandhabt wird. Vielen Dank dafür. Ich sehe das genau andersherum. Die externen kann man viel eher in die Haftung nehmen und das wissen die. Abgesehen davon ist das ganze natürlich davon abhängig, was die externen alles machen sollen. Bei uns gibt es externe, die deutlich mehr Rechte haben als die User. Das liegt einfach daran, welche Aufgaben die haben. Zitieren Link zu diesem Kommentar
testperson 1.623 Geschrieben 5. Juli Melden Teilen Geschrieben 5. Juli RODC -> Diebstahlschutz, falls die Hardware geklaut wird. Dann können "nur" die zwischengespeicherten Credentials attackiert werden. Zitieren Link zu diesem Kommentar
magheinz 108 Geschrieben 5. Juli Melden Teilen Geschrieben 5. Juli vor 49 Minuten schrieb wznutzer: Habe ich irgendwie einen Knoten im Kopf, ob das reicht. Applocker, hoffentlich korrekt konfiguriert keine Ordner auf C:\ anlegen keine cmd.exe kein Internet eigenes VLAN und nur zulassen was für das AD, Virenscanner, den Remote-Zugriff und die ERP-Software nötig ist. Zugriff nur auf die ERP-Anwendung (Remote-App) Ich überlege, ob ich in das VLAN einen schreibgeschützten DC packen kann. Dann darf der RDS nur mit dem RODC kommunizieren. Bringt ein schreibgeschützter DC im separaten "extern VLAN" in solch einem Szenario einen Sicherheitsvorteil? Klär ab was die wirklich brauchen. Wenn die nur innerhalb der Anwendung arbeiten sollen, dann mag das so gehen. Wenn die aber z.B. Schnittstellen bauen sollen von der ERP zu irgendwas anderem, dann kann es gut sein, dass die mehr Rechte brauchen. Zitieren Link zu diesem Kommentar
wznutzer 33 Geschrieben 5. Juli Autor Melden Teilen Geschrieben 5. Juli vor 11 Minuten schrieb magheinz: Klär ab was die wirklich brauchen. Tatsächlich nur ERP (Vertrieb, Marketing) keine Dienstleister die irgendwas an der Infrastruktur mitarbeiten müssen. 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.