Best Practice für Entwicklernetz

[luckyspiff]

Hallo,

sorry, falls ich hier im falschen Forum bin, eigentlich geht's mir um ein Netzwerkthema... kann gerne verschoben werden, falls es woanders besser aufgehoben ist.

Ich würde einfach gerne mal wissen, wie die "best practices" und "no gos" beim Aufbau eines Entwicklernetzes sind. Es geht um ein Unternehmen mit ein paar tausend Mitarbeitern, etwa 50-100 sollen im Entwicklernetz landen.

Der Betrieb von Rechenzentren und Office-Arbeitsplätzen wird ja gemeinhin ein sehr hoher Security-Level gefahren, d.h. jegliche Admin-Accounts, Kommunikation nach außen usw. unterbunden.

Für die Entwicklung neuer Software braucht man zum Teil aber eher "Laborbedingungen", d.h. konkret mehr Zugriffe nach Außen und auch Installationsrechte.

Wie wird so ein "Entwicklernetz" in der Praxis realisiert? Ich stelle mir hier so etwas wie eine DMZ vor, die nach außen relativ offen ist aber mit den anderen internen Netzen nur sehr kontrolliert kommunizieren kann. Oder ist das mit einem VLAN besser möglich?

Sinnvoll wäre natürlich auch mit einer Workstation im Entwicklernetz an die Office-Resourcen zu kommen, im Prinzip ginge das auch über Terminal-Server-Protokoll (Microsoft pusht hier wohl VDI).

Würde hier einfach mal hören wollen, was "best practices" sind, was absolute No-Gos sind. Gerne auch mit Links auf entsprechende andere Foren / Wikipedia (hab da bisher nur recht wenig gefunden).

Danke schon mal für Euren Input!

 

[OpamitKruecke]

Bei Unternehmen wie Siemens wird das Entwicklungsnetz mittels Firewalls abgetrennt vom restlichen Netzwerk gefahren d.h. Wie eine Fremdfirma behandelt .


Gesendet von iPad mit Tapatalk

 

[fax668]

WIr haben für unser Testnetzwerk ein separates Netzwerk (VLAN). Vom Testnetzwerk hat man keinerlei Zugriff auf das interne Netzwerk. Wer ins Testnetzwerk will, braucht eine extra Maschine und einen Ethernetport, auf den das Testnetzwerk geschaltet ist. Die eigentlichen Entwicklermaschinen haben vollen Zugriff auf das interne Netzwerk, aber bei uns können auch alle anderen Mitarbeiter eingeschränkte Adminrechte auf ihren Rechnern bekommen.

 

[teqqy]

Tendenziell würde ich sagen kommt es drauf an wie groß die Firma ist und ob sie etwaigen Regulierungen seitens Behörden unterliegt.

Bei kleinen Softwarebutzen die ne neue App für irgendwas schreiben wird sicherlich ne eigene VM im normalen Netzwerk reichen. Wir haben allerdings ein Kunden der ein komplett eigenes Netzwerk für die Entwicklung hat. Die teilen sich mit der normalen Produktivumgebung gar nix, keine Internetleitung, kein Switch, nix.

Pauschal würde ich auch mit mind. VLANs arbeiten und beide Netze voneinander trennen. Aber auch hier kommt es darauf an was und wie entwickelt wird. Sicherheit ist gut, bringt nur nix wenn sich die Mitarbeiter Wege suchen diese zu umgehen. Und das liegt fast in der Natur von Mitarbeitern.

 

[konfetti]

Je nach Durchführung müsste man das halt etwas genauer betrachten.

...
Wie wird so ein "Entwicklernetz" in der Praxis realisiert? Ich stelle mir hier so etwas wie eine DMZ vor, die nach außen relativ offen ist aber mit den anderen internen Netzen nur sehr kontrolliert kommunizieren kann. Oder ist das mit einem VLAN besser möglich?
...

Die Unterschiede sind Dir klar? - ein VLAN ist erstmal ein eigenständiges Netz, das kann auch eine DMZ sein... DMZ ist nur ein Wort, für eine Zone, die sich i.d.R. an der Firewall befindet und ein Security-Level von 50 hat - Outside (Internet) meist 0 oder 1 und inside enstpricht 100.

Wir haben z.B. 3 DMZ für diverse Anbindungen zu Partnern und Systeme die aus dem Internet erreichbar sein sollen.
Für die Server und sonstige produktive Systeme sowie Verwaltungsnetze und Technik gibt es eigene Interne Netze, die über die Firewall geroutet werden und hier auch Zugriffe einschränken

Für unser Labor haben wir an der Firewall eigene Regeln, bestimmte Personen können da von ihrem Arbeitsplatz aus direkt hin. Ansonsten ist die Entwicklungsumgebung mit verschiedenen Zugangspunkten ausgestattet, die auch verschiedene Möglichkeiten bieten um Außenstellen nachzubilden oder auch ein Abbild der Produktiven Umgebung für Testzwecke.

...
Sinnvoll wäre natürlich auch mit einer Workstation im Entwicklernetz an die Office-Resourcen zu kommen, im Prinzip ginge das auch über Terminal-Server-Protokoll (Microsoft pusht hier wohl VDI).
...

Sinnvoll wäre erst mal zu schauen, welche Dienste dort benötigt werden. - Im Zweifel würde ich wohl die Umgebung dort nachbauen, je nach der Gefährdungsbeurteilung kann es sein, das es ja nicht gewünscht ist, direkt von dort aus zuzugreifen.

 

[gea]

Entscheident sind ja wohl zwei Aspekte, die dazu führen, ein Entwicklernetz zu kapseln

- Es gibt Firmengeheimnisse im Entwicklernetz.
Es ist ja durchaus bekannt, dass man das normale Firmennetz nicht wirklich als "vertrauenswürdig" sehen darf

- Es gibt "unsichere Dienste" im Entwicklernetz die Dienste im normalen Firmennetz kompromittieren können

In beiden Fällen muss man die Verbindungen ins Firmennetz oder ins Internet mit einer Firewall regulieren oder kontrollieren.

 

[luckyspiff]

Vielen Dank schon mal für die bisherigen Antworten.

Zum Hintergrund: es geht um Entwicklung in einem Unternehmen mit ca. 4000 Mitarbeitern, davon knapp 10% in der IT. Die Branche ist zwar keine Behörde aber doch sehr stark regulatorischen Vorschriften unterworfen.

Die IT entfällt jetzt etwa zur Hälfte in Betrieb und Entwicklung, die ja bekanntlich sehr unterschiedliche Ziele verfolgen: der Betrieb will eben einen sicheren und geregelten Betrieb sicherstellen, die Entwicklung muss (jedenfalls zum Teil) einfach innovativ neue Dinge einführen und ausprobieren können, gerade, da es auch im Cloud-Lösungen geht, wo man auch mal mit noch nicht in Produktion befindlichen Tools und/oder Root-Rechten arbeiten muss (ich nenne das immer "Laborumgebung").

Bisher sind Entwicklerarbeitsplätze bei uns ganz normale Office-Arbeitsplätze. In den letzten Jahren wurde aber die diversen Sicherheits-Maßnahmen immer weiter ausgedehnt. Admin-Accounts auf den Arbeitsplätzen gibt es nun schon ein paar Jahre nicht mehr, der Internet-Proxy filtert immer restriktiver, so dass nicht nur Downloads gesperrt sind sondern auch nun auch diverse Entwicklungstools nicht mehr arbeiten und (Security-)Updates der Entwicklungswerkzeuge nicht funktionieren. USB-Ports sind natürlich auch gesperrt. Man hat zum Surfen zwar mal einen Browser in einer VM-Sandbox eingeführt, damit kommt man dann auch auf Seiten wie Facebook oder ebay, damit kann man sich ggf. die Zeit vertreiben, aber für die Entwicklung hilft das leider gar nichts. Kurz: es ist zwar sicher, aber man kann einfach nicht vernünftig arbeiten.

Die Forderung nach einem Entwicklernetz schwebt zwar schon lange im Raum, wurde bisher aber nie umgesetzt oder eingeplant, mit der Begründung, dass dies zu Aufwändig wäre usw. Als Workaround gibt es spezielle Laptops mit direktem Internet-Zugang (DSL-Anschluss), die aber überhaupt keine Verbindung ins restliche Firmennetz haben.

Letztenendes ist mir klar, dass es keine 100% Sicherheit gibt wenn man irgendwie einen Zugang zum Internet hat, trotzdem muss es doch praktikable Lösungen geben, die es erlauben die Office-Infrastruktur nutzen zu können und trotzdem einen vernünftigen Entwicklerarbeitsplatz nutzen zu können. Hier suche ich einfach nach Best Practices oder umsetzbaren Lösungen.

 

[fax668]

Ich weiß, dass z.B. Ericsson ausschließlich auf VMs entwickelt. Die VMs oder auch Terminalserver laufen dann in einem abgetrennten Netz, das vom internen Netzwerk erreichbar ist, aber nicht umgekehrt. Die Entwickler haben normale Bürorechner und loggen sich dann mit einem Client auf den benötigten Rechnern ein.

 

[luckyspiff]

Soweit ich das sehe, geht es bei der Abtrennung von einem Entwicklernetz primär um diese Aspekte:
1. will man "geheime" Daten nicht in Falsche Hände oder nach außen lassen
2. will man "Schädlinge" aus dem Internet nicht nach innen lassen
3. will man verhindern, dass durch Experimente/Fehler/Absicht irgendwelche Produktions-Server lahmgelegt werden (vor ein paar Jahren hatten wir mal einen ungewollten selbstgemachten Denial-Of-Service, weil ein falsch Konfigurierter Dienst Broadcasts im Loop verschickt hat)

Ich weiß, dass z.B. Ericsson ausschließlich auf VMs entwickelt. Die VMs oder auch Terminalserver laufen dann in einem abgetrennten Netz, das vom internen Netzwerk erreichbar ist, aber nicht umgekehrt. Die Entwickler haben normale Bürorechner und loggen sich dann mit einem Client auf den benötigten Rechnern ein.

Ob VM oder nicht spielt hier ja erstmal keine Rolle (wobei mit VMs das Aufsetzen standardisierter Entwicklungsumgebungen einfacher wird, siehe z.B. Vagrant), nur wenn ich im Entwicklernetz Zugriff auf Resourcen im Internet brauche (Labor!) und vom internem Netz auf das Entwicklernetz Zugriff habe, sind die Schädlinge ja auch ganz schnell im internen Netz...

Vielleicht muss man auch noch mal zwischen Entwicklungs- und Laborumgebung unterscheiden? Bei "normaler" Entwicklung, Wartung oder Weiterentwicklung von Software wird ja auch nicht unbedingt das gleiche gebraucht wie wenn es darum geht komplett neue Architekturen / Systeme aufzusetzen oder zu evaluieren.

Eine entscheidende Frage ist dann wohl auch, wie man gezielt die Übergänge zwischen den Netzen (halbwegs) absichern kann oder wie viel Vertrauen man den Mitarbeitern an der Übergangsstelle hat. Sobald z.B. eine ssh-Verbindung oder ein Filetransfer möglich ist, kann man mit mehr oder weniger Aufwand natürlich alles durch tunneln was schädlich ist.

 

[besterino]

Die Entscheidung steht und fällt mit den Anforderungen an die primäre bzw. produktive Umgebung. Wenn die Anforderungen mit denen und den "Gefahren" des Entwicklungsnetzes inkl. mit Kompromissen in Einklang zu bringen sind, kannst Du halt mischen - aber auch da kommen die Regeln aus dem Produktivbereich und nicht umgekehrt. Sprich: darf dir der Produktivbereich auch mal abhimmeln und ist ein Rollback aus Backup zur Not ok, musst Du halt "nur" sicherstellen, dass deine Entwicklungsumgebung das Backup nicht himmelt... Da gibbet aber kein allgemeingültiges "best practice", sondern nur saubere Definition der Anforderungen und dann der richtigen Lösung/Umsetzung.

Wirklich safe ist halt nur 100% Nachbau der Produktivumgebung, dann auch mit Dummy-Daten, wo's eben auch nicht wirklich schlimm ist, wenn sie weg (oder woanders) sind. (Dafür gibt's ja auch z.B. Tools, um Datenbanken mit Schrott zu füllen - der dann aber bisweilen sogar zu Testzwecken wieder auswertbar ist.) Wie Du das dann machst (virtuell / metall) hängt dann auch wieder davon ab, was Du machen MUSST für den zu entwickelnden Kram (lies: Anforderungen!).

 

[fax668]

Hier wird jetzt aber ein bisschen viel durcheinander gewürfelt. Wir haben z.B. vier Netzwerke:
- Internes Büronetzwerk
- Produktivnetzwerk. Das ist strikt von den anderen Netzwerken getrennt.
- Entwicklungsnetzwerk. Streng genommen haben wir zwei davon. Eines in dem Entwickler frei Software installieren können, Adminrechte haben, etc. und eines in dem die Continuous Integration und das Versionsmanagement läuft. Das zweite ist wesentlich strenger geregelt, um zu vermeiden, dass unser Source Code oder die kompilierten Programme kontaminiert werden.
- Testnetzwerk. Weitestgehend von den anderen Netzwerken getrennt, weil dort teilweise alte, unsichere Software laufen muss, z.B. alte Windowsversionen, auf denen getestet werden muss.

 

[l0n]

Ich kenne die Trennung der Netze auch nur durch VLAN's und/oder entsprechendes Routing...

Da war Best Practise auch das die Maschinen normale Office Rechner waren und dann entsprechende VM's liefen auf die man per SSH oder RDP kam. Entwicklungsstände kamen auf einen Git-Server im Netz, dadurch waren auch Backups per Snapshot sehr angenehm
Soweit ich mich richtig erinnere waren nur die Management Interfaces der vSphere Hosts im normalen Netz ( bzw. Admin-LAN) und als Admin kam man per Horizion-Client drauf (nur die WebView Variante!) wenn eine VM einen Macken hatte...