De- oder Zentralität?

[Alexander (HH)]

Moin Moin!

Warum willst Du interne Daten ins Internet stellen?

Gehostet, weil das abrufen der Emails von außen auf einem betriebsinternen Server sicherlich langsam wäre. (DSL 16.000).

Definitiv nicht. Emails kommen nicht als riesiger Stream, sondern in überschaubaren Häppchen. Insbesondere, wenn der Provider schon einen guten Spam-Filter hat, kommen kaum unnütze Daten über die Leitung. Wenn die Leitung sehr eng wäre, könnte man per QoS E-Mails in der Priorität etwas nach unten setzen, dann stören die beim Surfen nicht.

Wobei bald auf 50.000 umgestiegen wird mit etwa 10Mbit Upstream.

Mein Arbeitgeber: DSL 6000 für ca. 100 Leute, darüber läuft sämtlicher Verkehr ins und aus dem Internet, Surfen, Mailen, VPN, was auch immer. Und das reicht. Klar, mehr Bandbreite macht mehr Spaß. Aber die Leitung ist nicht störend langsam.

[...] hätte bei weitem (richtig konfiguriert) einen höheren Sicherheitsaspekt.

Richtig. Und du überschätzt die Bandbreitenanforderung für Mails gewaltig. Summier mal auf, wie groß alle Mails eines Tages sind, und teile das durch 86400 Sekunden. (Statistisch ist das nicht ganz sauber, aber ein guter Daumenfaktor.)

Bei Bugzilla dachte ich, dass man dies evtl. auf die Firmenwebseite integriert (deshalb gehostet). Wo Kunden dann direkt die Fehler eintragen können.

Das werden sie nicht tun; nicht in einer Form, mit der ihr arbeiten könnt. Fehlermeldungen von Kunden durchlaufen den Kundendienst ("Support"); die Support-Leute tragen qualifiziert in Bugzilla (Trac, whatever) ein. Für bekannte Fehler, die ber Workaround zu erschlagen sind, sollten die Supporter den Workaround im Bugzilla auch gleich finden.

(Sonst müsste ich HTTP vom betriebsinternen Server freigeben oder die Kundenfehler kommen auf dem gehosteten Server auf die DB und ich muss von Betriebsintern irgendwie auf die Daten zugreifen).

Prinzipiell die richtige Idee, aber 99% aller Kunden-Fehlermeldungen werden sinngemäß "Scheißsystem geht nicht. Schrott." lauten. Der Haupt-Job der Support-Leute ist es, den Kunden von der Palme zu holen. Dann müssen sie eine brauchbare (sprich: nachvollziehbare) Fehlerbeschreibung aus dem Kunden rauskitzeln, und ganz am Rande, und längst nicht immer, müssen sie den Fehler beheben können.

Und interne Issues gehen die Kunden nichts an.

Ja, hier will ich noch nicht tief einsteigen, da ich noch nicht die Zeit gefunden hatte, mich in Bugzilla einzuarbeiten. Davor will ich mir noch VPN anschauen, wie die Applikation (Bsp. normale Software oder Webapps (192.168.1.0) dann von außen (wenn ich mit VPN das betriebsinterne Netz verbunden habe), aufzurufen ist. (Ist ja nicht wie ein Webserver)

Der Witz am VPN ist, dass es - sobald das VPN sauber läuft - kein "außen" mehr gibt. Der über VPN eingewählte Rechner ist ein vollwertiges Mitglied des internen Netzes. Er nutzt den DNS des internen Netzes, kommt auf alle (nicht von Firewall-Regeln verrammelten) Systeme drauf, und kann alle Software nutzen, die über TCP/IP oder UDP/IP kommuniziert. Auch Windows packt seit etwa Windows 95 seine kruden RPC-, File- und Print-Dienste brav in TCP- und UDP-Pakete. Und außer in sehr wenigen Spezialfällen gilt das auch für so ziemlich jede Software, die sich als Netzwerk-fähig bezeichnen läßt.

Oder, es läuft auf einer VM, so dass ich die VM aufrufe.

Du rufst keine VM auf. Ändere Dein Bild einer VM: Eine VM ist keine Anwendung wie Firefox, Word oder Excel. VMs sind kleine Noname-Rechner, sicher untergebracht in der großen Zauberkiste des fetten VirtualBox- bzw. VMware-Servers. An den Rechnern hängt ein KVM-Adapter, mit dem Du auf VGA, Maus und Tastatur zugreifen kannst, außerdem eine Fernsteuerung für Netzschalter und Reset-Taster.

Natürlich kannst Du Bugzilla in eine VM packen. Aber es gibt exakt gar keinen Unterschied im Umgang zu einem Bugzilla, der auf einem dedizierten Rechner irgendwo in einem Rack oder auf einem Regal läuft.

Der einzige Unterschied für Administratoren ist, dass sie die Maschine, auf der der Bugzilla läuft, nicht direkt anfassen können.

(Hinzu kommt dann noch, dass die Software(s) ja für mehrere Mitarbeiter (je nach Account) zugänglich sein muss)
. Hier muss ich nach den Anforderungen etwas tiefer einsteigen und mich einlesen.

Jau. Single Sign On geht mit IE und mit neueren Firefox-Versionen wohl recht schmerzlos, wenigstens unter Windows; dem Apachen verpaßt man ein passendes Modul, dass NTLM-Auth beherrscht und gegen das Active Directory prüft. Bugzilla selbst verläßt sich bezüglich der Anmeldung dann komplett auf den Apachen und bekommt von diesem nur noch den Namen des angemeldeten Benutzers weitergereicht.

Andere Web-basierte Anwendungen werden analog konfiguriert, so dass sie sich auf den Apachen verlassen oder wenigstens Logins am zentralen LDAP-Server prüfen

Ja, ich hatte mich falsch ausgedrückt. Ich meinte damit, dass man einmal das Betriebssystem sichern könnte, einmal die Daten/Dokumente oder eine VM (wo dann die Daten und Dokumente drin sind). Die VM ist ja, wie du bereits erwähnt hast, wenige oder nur eine große Datei. Eigentlich sind die Daten und Dokumente eh betriebssystemunabhängig, aber innerhalb einer VM würde sich alles aber besser mit anderen Programmer besser portieren.

Du hast für das Backup von VMs zwei grundlegend unterschiedliche Möglichkeiten:

Entweder sicherst Du im Rahmen des normalen Host-Backups auch die Dateien, die die Virtualisierungssoftware auf dem Host hinterläßt; idealerweise sorgst Du dafür, dass während des Backups die VMs diese Dateien nicht verändern (Pause-Funktion oder notfalls Snapshot-Funktion).

Oder Du nimmst die Arbeitsdateien der Virtualisierungssoftware explizit vom Backup des Hosts aus und sicherst jede VM separat, mit Backup-Software, die innerhalb der VM läuft.

Für meine Zwecke reicht der erste Weg. Dabei schalte ich vor Beginn des nächtlichen Backups alle laufenden VMs auf Pause (virtuelle CPU steht still), und nach Ende des Backups eine halbe bis zwei Stunden später wecke ich die VMs wieder auf.

Für den Transport auf einen anderen Host friert man den aktuellen Zustand der VM ein, schafft die Dateien auf den anderen Host, und taut die VM dort wieder auf. ESX und VirtualBox haben die Funktion eingebaut, bei VMware Server geht das, so weit ich mich erinnere, nur manuell.

Privat nutze ich Virtualbox auf meinem Notebook. Erfahrungen damit, wie man die VM über ein Netzwerk aufruft habe ich nicht. Sollte aber weniger das Problem sein. Das Image/VDI liegt einfach nur entfernt, wenn man es im Virtualbox-Frontend einbindet.

So ungefähr. Man hat die VM-Dateien auf einem zentralen Storage-System, dass sich die Hosts teilen. Maximal einer der Hosts läßt die VM dann tatsächlich laufen. Das "rüberbeamen" ist so darauf beschränkt, CPU- und RAM-Zustand in eine Datei zu schreiben, die Virtualisierung auf Host 1 anzuhalten und auf Host 2 wieder aufzunehmen.

Ohne zentrales Storage-System müßte man tatsächlich die ganzen Dateien einer VM hin und her kopieren. Das ginge auch, wäre aber drastisch langsamer.

Wenn Du spielen willst, friere eine VM auf Deinem Rechner ein (VBoxManage controlvm spiel-vm savestate), kopiere das gesamte VM-Verzeichnis auf einen anderen Rechner, und starte die VM dort wieder (nachdem Du sie dort eingebunden hast).

Wenn Du etwas näher an die Realität kommen willst, befasse dich mit der Teleporting-Funktion. Dazu brauchst Du einen gemeinsamen Fileserver und mindestens zwei VirtualBox-Hosts.

VPN starten, Browser starten, auf der Standard-Startseite auf "Webmail" klicken.

Ja, das schaue ich mir wie bereits erwähnt an, wie Applikationen oder Webappliaktionen aufzurufen sind. (Ist ja nicht so einfach wie Netzlaufwerk einbinden). [...]

Wenn man sich per VPN eingewählt hat, ist man "innen" im Netz. Keine Extrawürste, kein Umlenken für VPN nötig. Und natürlich kann man auch Netzlaufwerke per VPN einbinden.

Das einzige Sicherheitsrisiko ist ein zusätzlicher Weg aus dem mobilen Rechner heraus ins Internet, der die normale Abschirmung des internen Netzes "überbrückt" und so zu einem Leck bzw. Einfallstor für Malware wird. Daher sollte ein sauber konfigurierter VPN-Client absolut keinen Datenverkehr außerhalb des VPN-Tunnels erlauben. Das bedeutet z.B., dass sich ein Kollege per VPN an einem normalen DSL-Anschluß einwählt, und danach surfen, mailen, chatten und so weiter nur noch durch den VPN-Tunnel läuft und ggf. von der Firewall in der Firma geblockt wird.

VPN verrammelt auch den Webmailer in einem Bereich, an den "kein Böser" [...] von außen herankommt. [...]

Das stimmt. Erst müsste das VPN geknackt werden + zusätzlich noch das Passwort für die Groupware. (Wobei es ja dort mehr zu sehen gibt, als nur die Groupware)

Richtig. Das VPN ist extrem kritisch. Daher sollte es sehr gründlich dokumentiert und verifiziert sein. Es ist keine Schande, sich dafür externes Know-How einzukaufen. Wenn man es ganz korrekt machen will, läßt man Unternehmen 1 das Zeug komplett aufbauen und Unternehmen 2 den Aufbau testen (mit Penetrationstests).

Auch sollte klar dokumentiert sein, wie man mit Mitarbeitern umgeht, die VPN-Zugang haben und die vor die Tür gesetzt werden sollen. Wann und wie sperrt man den VPN-Zugang eines Mitarbeiters?

Vermutlich wird das VPN mit einer Kombination aus Token und Passwort abgesichert sein, das ist Stand der Technik. Daher muß ebenso klar dokumentiert sein, wie man mit einem verlorenen Token umgeht. Wie kann das schnellstmöglich gesperrt werden, wie bekommt der Kollege einen neuen Token, wie wird der neue Token am System angemeldet und dem Kollegen zugeordnet?

Welche Leute haben "die Macht" über das VPN? Ich würde da mindestens zwei Leute vorsehen, die sich gegenseitig ersetzen können. Es darf nie vorkommen, das beide gleichzeitig in Urlaub oder krank sind.

Tip 1, noch aus Studentenzeiten: Sorge dafür, dass Du zu jeder Zeit irgendetwas präsentieren kannst. Bei Software-Entwicklung darf das, was Du zeigst, durchaus bei jedem dritten Klick abstürzen und rauchende Trümmerlandschaften hinterlassen, sofern man den Fortschritt zur Vorversion erkennen kann, die bei jedem zweiten Klick alles in Asche verwandelte. Idealerweise zeigst Du natürlich nur die Dinge, die keine Ruinen produzieren. Oder beim Debugging eine lange Liste von Dingen, die Du bereits ausgeschlossen hast.

Ja, bei mir wird am Anfang noch viel Einlesen/Einlernen und eher wenig Fortschritt zu erkennen sein.

Genau deswegen solltest Du aber immer etwas Präsentierbares haben. Sei es ein kleines Labor-Netz mit VMs und VPN, sei es einfach nur eine rohe Präsentation, in der Du den aktuellen Stand kurz beschreibst.

Wenn das ganze jedoch mal funktioniert, dann wird man sicherlich auch den Merhwert sehen. Und wenn das Ding mal läuft, kann ich mich fortlaufend immer tiefer einarbeiten und weiter lernen und verbessern.

Du machst Dich damit quasi unentbehrlich. Das sichert den eigenen Job.

Aber denke auch daran, dass Du eine komplette EDV kaum alleine aufbauen und betreiben kannst. Versuche, das in einem kleinen Team (wenigstens zu zweit) zu erledigen. VPN ist ein relativ abgeschlossenes Thema, VMs ebenso. Das kann man auch mal jemandem übergeben. Bau Dir einen Stellvertreter auf.

Alexander