Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Ãœberarbeitung
Nächste Überarbeitung
Vorhergehende Ãœberarbeitung
Nächste Überarbeitung Beide Seiten der Revision
netz:firewall [2014/07/25 08:40]
tstrauf [2. FAQ (Frequently Asked Questions)]
netz:firewall [2019/05/17 09:47]
tstrauf
Zeile 1: Zeile 1:
-====== Instituts-Firewall am Gauß-IT-Zentrum ​======+====== Instituts-WLAN ======
  
 ===== 1. Instituts-Firewall am Gauß-IT-Zentrum ===== ===== 1. Instituts-Firewall am Gauß-IT-Zentrum =====
Zeile 92: Zeile 92:
 (Die Verantwortung und Gewähr über Richtigkeit der Inhalte dieser Seiten trägt die Firma Cisco Systems.) (Die Verantwortung und Gewähr über Richtigkeit der Inhalte dieser Seiten trägt die Firma Cisco Systems.)
  
-Grundsätzlich handelt es sich um eine so genannte "​Stateful Firewall",​ die technologisch dem aktuellen Stand entspricht. Die FWSMs sind in der Lage, Protokolle von Layer 2 – 7 zu filtern bzw. auf Protokollkonformität zu inspizieren. Sie können damit also von Regeln für beispielsweise GRE-Tunnelling über einfache Regeln, die sämtlichen Verkehr zwischen bestimmten IP-Adressen auf Layer 3 regeln bis hin zu solchen Konfigurationen,​ die bestimmte HTTP- oder FTP-Direktiven prüfen und einschränken,​ alles konfigurieren was Sie als notwendig erachten. Selbstverständlich ist die Firewall so auch in der Lage nicht nur bei TCP, sondern auch bei UDP-Protkollen oder FTP den Verbin- dungsaufbau ​komplett zu verfolgen, so dass Kommunikationspartner,​ die eine Verbindung in einer Richtung aufgebaut haben, (temporär für die Dauer der Session) auch in umgekehrter Richtung Daten austauschen können, ohne dass spezielle Regeln in Rückrichtung nötig wären.+Grundsätzlich handelt es sich um eine so genannte "​Stateful Firewall",​ die technologisch dem aktuellen Stand entspricht. Die FWSMs sind in der Lage, Protokolle von Layer 2 – 7 zu filtern bzw. auf Protokollkonformität zu inspizieren. Sie können damit also von Regeln für beispielsweise GRE-Tunnelling über einfache Regeln, die sämtlichen Verkehr zwischen bestimmten IP-Adressen auf Layer 3 regeln bis hin zu solchen Konfigurationen,​ die bestimmte HTTP- oder FTP-Direktiven prüfen und einschränken,​ alles konfigurieren was Sie als notwendig erachten. Selbstverständlich ist die Firewall so auch in der Lage nicht nur bei TCP, sondern auch bei UDP-Protkollen oder FTP den Verbindungsaufbau ​komplett zu verfolgen, so dass Kommunikationspartner,​ die eine Verbindung in einer Richtung aufgebaut haben, (temporär für die Dauer der Session) auch in umgekehrter Richtung Daten austauschen können, ohne dass spezielle Regeln in Rückrichtung nötig wären.
  
 </​columns>​ </​columns>​
Zeile 112: Zeile 112:
 **A**: Nein. Zum einen ist die Syntax der Konfiguration mit an Sicherheit grenzender Wahrscheinlichkeit nicht kompatibel, und zum anderen hat es sich als sinnvoll erwiesen, wenn zunächst der heute tatsächliche Bedarf festgestellt wird. Es ist für Sie nicht hilfreich, wenn Sie uns bei Problemen fragen: "Warum geht x und y nicht, wo doch z auch funktioniert"​ und wir Ihnen nur antworten können: "Keine Ahnung, das haben Sie uns so konfigurieren lassen, das sollten Sie selbst wissen."​ **A**: Nein. Zum einen ist die Syntax der Konfiguration mit an Sicherheit grenzender Wahrscheinlichkeit nicht kompatibel, und zum anderen hat es sich als sinnvoll erwiesen, wenn zunächst der heute tatsächliche Bedarf festgestellt wird. Es ist für Sie nicht hilfreich, wenn Sie uns bei Problemen fragen: "Warum geht x und y nicht, wo doch z auch funktioniert"​ und wir Ihnen nur antworten können: "Keine Ahnung, das haben Sie uns so konfigurieren lassen, das sollten Sie selbst wissen."​
  
-In Sachen Konfiguration erleichtert die Firewall die Verwaltung im Ãœbrigen natürlich durch gängige Methoden wie die Möglichkeit zur Anlegung von Service Groups und Network-Object Groups, die für verschiedene Regeln wieder verwendet werden können, bzw. in den meisten Fällen mehrere Regeln zu einer oder einigen wenigen Regeln zusammenfassbar machen. Es macht Sinn, bei einer Neukonfiguration mit Syste- matik genau diese Hilfsmittel zu nutzen, um die Ãœbersichtlichkeit und damit auch die Wartbarkeit der zum Teil komplexen Regelwerke zu verbessern.+In Sachen Konfiguration erleichtert die Firewall die Verwaltung im Ãœbrigen natürlich durch gängige Methoden wie die Möglichkeit zur Anlegung von Service Groups und Network-Object Groups, die für verschiedene Regeln wieder verwendet werden können, bzw. in den meisten Fällen mehrere Regeln zu einer oder einigen wenigen Regeln zusammenfassbar machen. Es macht Sinn, bei einer Neukonfiguration mit Systematik ​genau diese Hilfsmittel zu nutzen, um die Ãœbersichtlichkeit und damit auch die Wartbarkeit der zum Teil komplexen Regelwerke zu verbessern.
 </​columns>​ </​columns>​
  
Zeile 118: Zeile 118:
 **F**: Warum braucht Ihr so viele IP-Adressen aus unserem Netzbereich?​ **F**: Warum braucht Ihr so viele IP-Adressen aus unserem Netzbereich?​
 <​newcolumn>​ <​newcolumn>​
-**A**: Dies lässt sich aus technischen Gründen leider nicht anders organisieren. Es ist stets hilfreich, wenn Sie als DV-Koordinator für Ihr(e) Institutsnetz(e) schon im Vorfeld einer möglichen Firewallnutzung dafür sorgen, dass die oberen 8 Adressen aus Ihrem Netzbereich für so genannte Netzdienste frei sind. Wir brauchen diese Adressen für unsere Router, die Firewalls und weitere Adressen für zukünftige Dienstangebote (z.B. WLAN-Terminierung im Institutsnetz). Als Service-Adressen sind diese gegenüber ​dem GB3 nicht kostenpflichtig.+**A**: Dies lässt sich aus technischen Gründen leider nicht anders organisieren. Es ist stets hilfreich, wenn Sie als DV-Koordinator für Ihr(e) Institutsnetz(e) schon im Vorfeld einer möglichen Firewallnutzung dafür sorgen, dass die oberen 8 Adressen aus Ihrem Netzbereich für so genannte Netzdienste frei sind. Wir brauchen diese Adressen für unsere Router, die Firewalls und weitere Adressen für zukünftige Dienstangebote (z.B. WLAN-Terminierung im Institutsnetz). Als Service-Adressen sind diese gegenüber ​Geschäftsbereich 3 der Verwaltung ​nicht kostenpflichtig.
 </​columns>​ </​columns>​
  
Zeile 124: Zeile 124:
 **F**: Wir betreiben einen eigenen DHCP-Server. Müssen wir dafür Regeln vorsehen? **F**: Wir betreiben einen eigenen DHCP-Server. Müssen wir dafür Regeln vorsehen?
 <​newcolumn>​ <​newcolumn>​
-**A**: In der Regeln nein. Es sei denn Sie nutzen unseren DHCP-Service. Dann sind entsprechende Regeln nötig. Unser DHCP-Service kann über den KDD in bestimmten Ausprägungen selbstständig konfiguriert werden.+**A**: In der Regeln nein. Es sei denn Sie nutzen unseren DHCP-Service. Dann sind entsprechende Regeln nötig, die wir aber bereits vor Auslieferung der Firewall für sie Eintragen. Unser DHCP-Service kann über den KDD in bestimmten Ausprägungen selbstständig konfiguriert werden.
 </​columns>​ </​columns>​
  
Zeile 130: Zeile 130:
 **F**: Sind die zentralen Firewalls auch VPN-Server? **F**: Sind die zentralen Firewalls auch VPN-Server?
 <​newcolumn>​ <​newcolumn>​
-**A**: Nein. Da diese Firewalls im sogenannten "Layer 2-" bzw. "​transparent mode" (und nicht im "Layer 3-" bzw. "​routetd mode") laufen, können wir den VPN-Service darüber nicht anbieten. Eine alternativen Dienst stellen wir jedoch unter dem Namen „Instituts-VPN“ über die zentrale VPN-Infrastruktur zur Verfügung.+**A**: Nein. Da diese Firewalls im sogenannten "Layer 2-" bzw. "​transparent mode" (und nicht im "Layer 3-" bzw. "​routetd mode") laufen, können wir den VPN-Service darüber nicht anbieten. Eine alternativen Dienst stellen wir jedoch unter dem Namen „Instituts-VPN“ über die zentrale VPN-Infrastruktur zur Verfügung. Näheres dazu finden sie [[netz:​vpn:​institutsvpn|hier]].
 </​columns>​ </​columns>​
  
Zeile 136: Zeile 136:
 **F**: Das klingt alles ganz toll, nur wo ist der Haken? **F**: Das klingt alles ganz toll, nur wo ist der Haken?
 <​newcolumn>​ <​newcolumn>​
-**A**: Sie erhalten eine redundante (praktisch vollständig ausfallsichere) Firewall, basierend auf ausbaufähiger Firewall-Infrastruktur,​ die derzeit bis zu 2 x 5,5 Gigabit/s Durchsatz hat, deren Soft- und Hardware von Ihnen nicht gepflegt werden muss und die Sie noch mindestens für 5 Jahre nichts kosten wird... Auch wir können keinen Haken feststellen.+**A**: Sie erhalten eine redundante (praktisch vollständig ausfallsichere) Firewall, basierend auf ausbaufähiger Firewall-Infrastruktur,​ die derzeit bis zu 2 x 16 Gigabit/s Durchsatz hat, deren Soft- und Hardware von Ihnen nicht gepflegt werden muss und die Sie noch mindestens für 5 Jahre nichts kosten wird... Auch wir können keinen Haken finden.
 </​columns>​ </​columns>​
  
Zeile 142: Zeile 142:
 **F**: Kann ich als DV-Koordinator die Firewall von zu Hause administrieren?​ **F**: Kann ich als DV-Koordinator die Firewall von zu Hause administrieren?​
 <​newcolumn>​ <​newcolumn>​
-**A**: Im Prinzip ja, aber... Nach Ihren Angaben schränken wir den Zugriff auf das Management Interface der Firewall auf bestimmte IP-Adressen ein. In der Regel wird von den Instituten gewünscht, dass die Firewall nur von bestimmten Adressen innerhalb des Instituts-Netzes erreichbar ist. Diese Einschränkung halten wir für sinnvoll. In so einem Fall wäre es dann notwendig, dass Sie entweder innerhalb ihres Netzes einen eigenen VPN-Server aufsetzen oder zu einem der genannten Rechner (in Ihrem eigenen Interesse wenigstens auf die VPN-Adressen der TU, besser noch auf die Instituts-VPN-Adressen beschränkt) Zugang per rdesktop o.ä. ermöglichen,​ um auch von "zu Hause" aus auf das Firewall Management zugreifen zu können. Selbstverständlich kann die Firewall aber auch so eingerichtet werden, dass beliebige Adressen auf das Management zugreifen können, aber wir raten von solchen Konfigurationen ab, auch wenn der Zugriff über HTTPS erfolgt.+**A**: Im Prinzip ja, aber... Nach Ihren Angaben schränken wir den Zugriff auf das Management Interface der Firewall auf bestimmte IP-Adressen ein. In der Regel wird von den Instituten gewünscht, dass die Firewall nur von bestimmten Adressen innerhalb des eigenen ​Instituts-Netzes erreichbar ist. Diese Einschränkung halten wir für sinnvoll. In so einem Fall wäre es dann notwendig, dass Sie entweder innerhalb ihres Netzes einen eigenen VPN-Server aufsetzen oder zu einem der genannten Rechner (in Ihrem eigenen Interesse wenigstens auf die VPN-Adressen der TU, besser noch auf die Instituts-VPN-Adressen beschränkt) Zugang per rdesktop o.ä. ermöglichen,​ um auch von "zu Hause" aus auf das Firewall Management zugreifen zu können. Selbstverständlich kann die Firewall aber auch so eingerichtet werden, dass beliebige Adressen auf das Management zugreifen können, aber wir raten von solchen Konfigurationen ab, auch wenn der Zugriff über HTTPS erfolgt.
 </​columns>​ </​columns>​
  
Zeile 177: Zeile 177:
 **Wider**: Mit der Firewall vom Gauß-IT-Zentrum sind wir abhängig vom GITZ. **Wider**: Mit der Firewall vom Gauß-IT-Zentrum sind wir abhängig vom GITZ.
 <​newcolumn>​ <​newcolumn>​
-**Für**: Ganz ehrlich? Nicht abhängiger als Sie es sowieso schon sind. Sollte eines schwarzen Tages das GITZ abbrennen und beide Hauptrouter,​ einschließlich beider FWSM-Module in Rauch aufgehen, dann hätten wir aktuell alle auch so ein riesiges Problem. Was Wartungsarbeiten an den Modulen (Software-Updates etc.) angeht, so werden wir diese zwar ankündigen,​ da dadurch ggf. auch das Konfigurations-Interface (ASDM) aktualisiert wird, aber die eigentlichen Updates werden sie nicht mehr bemerken, als Sie es aktuell spüren wenn wir die Software auf unseren Routern erneuern. Nicht zuletzt dafür haben wir ja in Redundanz investiert. Mit der Wahl des Betreuungs- modells ​entscheiden Sie ansonsten wie "​abhängig"​ Sie vom Gauß-IT-Zentrum sein wollen. Vergessen Sie dabei jedoch nicht, dass auch Instituts-eigene Administratoren gelegentlich nicht verfügbar/​erreichbar sind, bzw. ggf. – auf Grund mangelnder Erfahrung/​Routine – deutlich länger für die Umsetzung einer Änderung brauchen als Mitarbeiter am GITZ, die sich täglich mit der FW beschäftigen.+**Für**: Ganz ehrlich? Nicht abhängiger als Sie es sowieso schon sind. Sollte eines schwarzen Tages das GITZ abbrennen und beide Hauptrouter,​ einschließlich beider FWSM-Module in Rauch aufgehen, dann hätten wir aktuell alle auch so ein riesiges Problem. Was Wartungsarbeiten an den Modulen (Software-Updates etc.) angeht, so werden wir diese zwar ankündigen,​ da dadurch ggf. auch das Konfigurations-Interface (ASDM) aktualisiert wird, aber die eigentlichen Updates werden sie nicht mehr bemerken, als Sie es aktuell spüren wenn wir die Software auf unseren Routern erneuern. Nicht zuletzt dafür haben wir ja in Redundanz investiert. Mit der Wahl des Betreuungsmodells ​entscheiden Sie ansonsten wie "​abhängig"​ Sie vom Gauß-IT-Zentrum sein wollen. Vergessen Sie dabei jedoch nicht, dass auch Instituts-eigene Administratoren gelegentlich nicht verfügbar/​erreichbar sind, bzw. ggf. – auf Grund mangelnder Erfahrung/​Routine – deutlich länger für die Umsetzung einer Änderung brauchen als Mitarbeiter am GITZ, die sich täglich mit der Firewall ​beschäftigen.
 </​columns>​ </​columns>​
  
Zeile 191: Zeile 191:
 **Für**: Mit Verlaub, diese Art der Betrachtung ist extrem kurzsichtig. Tatsächlich sollte //keine// Firewall, solange sie läuft und die Regeln entsprechend der eigenen Wünsche implementiert sind, irgendwelche "​Probleme"​ oder großartige Arbeit machen. Dies gilt aber nur bis zu dem Tag, an dem sie ausfällt; entweder weil die Hardware (oder ein Stück Hardware) oder die Software den Dienst quittiert. Wenn Sie dafür nicht einen extrem guten und kurzfristig implementierbaren Ausfallplan haben, ist Ihr Institut für die Zeit, in der Sie daran noch arbeiten, komplett vom Netz abgeschnitten;​ ganz abgesehen von der Zeit, die es u. U. braucht, bis qualifiziertes Personal vor Ort ist. Unserer Erfahrung nach wird ein Ausfall des "​Internets"​ in den allermeisten Fällen von den Mitarbeitern am Institut als Zeit betrachtet, in der faktisch so gut wie nicht gearbeitet werden kann. **Für**: Mit Verlaub, diese Art der Betrachtung ist extrem kurzsichtig. Tatsächlich sollte //keine// Firewall, solange sie läuft und die Regeln entsprechend der eigenen Wünsche implementiert sind, irgendwelche "​Probleme"​ oder großartige Arbeit machen. Dies gilt aber nur bis zu dem Tag, an dem sie ausfällt; entweder weil die Hardware (oder ein Stück Hardware) oder die Software den Dienst quittiert. Wenn Sie dafür nicht einen extrem guten und kurzfristig implementierbaren Ausfallplan haben, ist Ihr Institut für die Zeit, in der Sie daran noch arbeiten, komplett vom Netz abgeschnitten;​ ganz abgesehen von der Zeit, die es u. U. braucht, bis qualifiziertes Personal vor Ort ist. Unserer Erfahrung nach wird ein Ausfall des "​Internets"​ in den allermeisten Fällen von den Mitarbeitern am Institut als Zeit betrachtet, in der faktisch so gut wie nicht gearbeitet werden kann.
  
-Bei uns ist alles redundant. Dies schließt nicht nur die FW selbst, sondern auch den Router und die Stromversorgung mit ein. Bei einem Ausfall einer Komponente eines Gerätes übernimmt das Andere die Arbeit ohne Verbindungsausfall. Noch dazu ist unsere Infrastruktur ​bei Hersteller "im Service",​ und wenn eine Komponente ausfällt, haben wir innerhalb von etwa 24 – 48 Stunden Ersatz. -> In unseren Augen erhöht das die Verfügbarkeit bzw. Ausfallsicherheit ganz erheblich.+Bei uns ist alles redundant. Dies schließt nicht nur die Firewall ​selbst, sondern auch den Router und die Stromversorgung mit ein. Bei einem Ausfall einer Komponente eines Gerätes übernimmt das Andere die Arbeit ohne Verbindungsausfall. Noch dazu ist unsere Infrastruktur ​beim Hersteller "im Service",​ und wenn eine Komponente ausfällt, haben wir innerhalb von etwa 24 – 48 Stunden Ersatz. -> In unseren Augen erhöht das die Verfügbarkeit bzw. Ausfallsicherheit ganz erheblich.
 </​columns>​ </​columns>​
  
Zeile 197: Zeile 197:
  
 <columns 100% 50% - -> <columns 100% 50% - ->
-  * Erhöhte Sicherheit ohne Kosten. So wie jetzt (Stand Q3 2010) implementiert können wir entsprechend Ciscos End-of-Sale/​End-of-Life Policies ([[http://​www.cisco.com/​en/​US/​products/​products_end-of-life_po-licy.html]]) den Service noch mindestens 5 1/2 Jahre anbieten. Tatsächlich werden wir uns, je nach Anforderung und Entwicklung in unserer Netz-Infrastruktur,​ natürlich auch bereits früher um Upgrades bemühen. +  * Erhöhte Sicherheit ohne Kosten. So wie jetzt (Stand Q3 2014) implementiert können wir entsprechend Ciscos End-of-Sale/​End-of-Life Policies ([[http://​www.cisco.com/​en/​US/​products/​products_end-of-life_po-licy.html]]) den Service noch mindestens 5 1/2 Jahre anbieten. Tatsächlich werden wir uns, je nach Anforderung und Entwicklung in unserer Netz-Infrastruktur,​ natürlich auch bereits früher um Upgrades bemühen. Das letzte Upgrade erfolgte Anfang 2013. 
-  * Redundanz. Jeweils zwei Firewall-Module laufen bei uns in einem sogenannten "​active-active"​ Failover-Mode. Neben  (selbstverständlich) redundanter Stromversorgung,​ sind sie damit auch vor Ausfällen geschützt, sollte eines der Module kaputt gehen. Nebenbei besteht für die HW ein Service-Vertrag. Im Falle eines Defekts erhalten wir binnen 48h Ersatz.+  * Redundanz. Jeweils zwei Firewall-Module laufen bei uns in einem sogenannten "​active-active"​ Failover-Mode. Neben  (selbstverständlich) redundanter Stromversorgung,​ sind sie damit auch vor Ausfällen geschützt, sollte eines der Module kaputt gehen. Nebenbei besteht für die Hardware ​ein Service-Vertrag. Im Falle eines Defekts erhalten wir binnen 48h Ersatz.
   * Falls sie schon eine Firewall betreiben, haben Sie mit unserer Lösung weniger Arbeit (weil Sie weniger zu pflegen haben); weniger Arbeit -> weniger Arbeitszeit --> weniger Kosten.   * Falls sie schon eine Firewall betreiben, haben Sie mit unserer Lösung weniger Arbeit (weil Sie weniger zu pflegen haben); weniger Arbeit -> weniger Arbeitszeit --> weniger Kosten.
-  * Selbst wenn Sie Sich die Gesamtleistung der Firewall-Hardware im Gauß-IT-Zentrum mit anderen Instituten teilen müssen, so zeigt die Erfahrung, dass tatsächliche Leistungs-Peaks sehr zeitversetzt abgefragt werden. Im allgemeinen dürfte sich die Firewall des Gauß-IT-Zentrums für Sie daher als deutlich ​performanter darstellen als übliche "​SoHo"​-Lösungen,​ wie sie ansonsten für ein Institut in Frage kämen. Das mag für Sie aktuell noch uninteressant sein, weil Sie ggf. eine bestehende eigene Firewall nicht als Bottleneck empfinden, aber in Zeiten, in denen die übertragenen Datenvolumen immer rapider wachsen, sollte man die Skalierbarkeit und Performanz nicht ganz aus den Augen verlieren.+  * Selbst wenn Sie Sich die Gesamtleistung der Firewall-Hardware im Gauß-IT-Zentrum mit anderen Instituten teilen müssen, so zeigt die Erfahrung, dass tatsächliche Leistungs-Peaks sehr zeitversetzt abgefragt werden. Im allgemeinen dürfte sich die Firewall des Gauß-IT-Zentrums für Sie daher als um ein vielfaches ​performanter darstellen als übliche "​SoHo"​-Lösungen,​ wie sie ansonsten für ein Institut in Frage kämen. Das mag für Sie aktuell noch uninteressant sein, weil Sie ggf. eine bestehende eigene Firewall nicht als Bottleneck empfinden, aber in Zeiten, in denen die übertragenen Datenvolumen immer rapider wachsen, sollte man die Skalierbarkeit und Performanz nicht ganz aus den Augen verlieren.
 <​newcolumn>​ <​newcolumn>​
   * Trotz Firewall: Transparenz im Netz. D.h. Fehler lassen sich (mindestens durch uns) ungehindert aufspüren, was im Falle von zwischengeschalteten Instituts-eigenen Firewalls nicht der Fall ist.   * Trotz Firewall: Transparenz im Netz. D.h. Fehler lassen sich (mindestens durch uns) ungehindert aufspüren, was im Falle von zwischengeschalteten Instituts-eigenen Firewalls nicht der Fall ist.
-  * Unabhängigkeit von "​eigenem Know-How":​ Wissenschaftliche Mitarbeiter und insbesondere studentische Hilfskräfte arbeiten in aller Regel nur wenige Jahre (teilweise nur Monate) an einem Institut. Bei der Ãœbergabe von Aufgaben an Nachfolger geht nicht selten ein Großteil des Wissens sowie der Erfahrungswerte verloren. Dies ist insbesondere dann der Fall, wenn die Aufgaben vom Vorgänger überhaupt nur "​sporadisch"​ wahrgenommen werden mussten (wie häufig bei Firewall-Arbeiten der Fall, wenn diese gut läuft). Selbst wenn sich Ihr Institut für die Firewall des Gauß-IT-Zentrums entscheiden sollte, aber zunächst den Modus "Self Managed Firewall"​ wählt, ist es später (nach Absprache) jederzeit möglich, dass diese Betreuung wieder an das Gauß-IT-Zentrum übergeht, falls ein Nachfolger mit den entsprechenden Qualifikationen/​Kenntnissen nicht zur Stelle ist. Bitte haben Sie aber Verständnis dafür, dass die Frequenz, mit der derartige ​Ãœbernah- men/Ãœbergaben der FW-Administration stattfinden,​ in der Regel deutlich über einem Jahr liegen sollte.+  * Unabhängigkeit von "​eigenem Know-How":​ Wissenschaftliche Mitarbeiter und insbesondere studentische Hilfskräfte arbeiten in aller Regel nur wenige Jahre (teilweise nur Monate) an einem Institut. Bei der Ãœbergabe von Aufgaben an Nachfolger geht nicht selten ein Großteil des Wissens sowie der Erfahrungswerte verloren. Dies ist insbesondere dann der Fall, wenn die Aufgaben vom Vorgänger überhaupt nur "​sporadisch"​ wahrgenommen werden mussten (wie häufig bei Firewall-Arbeiten der Fall, wenn diese gut läuft). Selbst wenn sich Ihr Institut für die Firewall des Gauß-IT-Zentrums entscheiden sollte, aber zunächst den Modus "Self Managed Firewall"​ wählt, ist es später (nach Absprache) jederzeit möglich, dass diese Betreuung wieder an das Gauß-IT-Zentrum übergeht, falls ein Nachfolger mit den entsprechenden Qualifikationen/​Kenntnissen nicht zur Stelle ist. Bitte haben Sie aber Verständnis dafür, dass die Frequenz, mit der derartige ​Ãœbernahmen/Ãœbergaben der Firewall-Administration stattfinden,​ in der Regel deutlich über einem Jahr liegen sollte.
   * Nachteile können wir ehrlich nicht entdecken. ;-)   * Nachteile können wir ehrlich nicht entdecken. ;-)
 </​columns>​ </​columns>​
netz/firewall.txt · Zuletzt geändert: 2022/05/05 14:02 von tstrauf
Gauß-IT-Zentrum