Teilnahmewettbewerb zur Ausschreibung eines Firewallsystems (Soft- und Hardware) zur Absicherung der Fachbereichsnetze im Neubau GEP auf dem Campus Westend der Goethe-Universität Frankfurt am Main
Zur Absicherung der Fachbereichsnetze im Neubau GEP auf dem Campus Westend ist der Einsatz eines HA-Netzwerk-Firewallpaares erforderlich, welches mit mehrfach 10G in das universitäre Netz eingebunden werden kann.
Aufgrund der z.T. sehr unterschiedlichen „Systemphilosophien“ und der daraus resultierenden, bzw. auch innerhalb einer grundsätzlichen Systemausrichtung recht unterschiedlichen technischen Lösungen am Markt, kann der Auftraggeber die Leistung derzeit noch nicht abschließend und vollumfänglich beschreiben, so dass, im Rahmen eines „Offenen Verfahrens“ hinreichend bestimmte Wertungskriterien vorgegeben werden könnten.
Gleichwohl handelt es sich insgesamt um eine sehr spezifische Leistung, die regelmäßig nur von einem überschaubaren Bieterkreis am Markt angeboten wird.
Der Auftraggeber beabsichtig deshalb, nach Durchführung eines vorgelagerten Teilnahmewettbewerbs, ein Nichtoffenes Verfahren unter den zugelassenen Teilnehmern, bzw. sofern auch nach den Ergebnissen eines entsprechenden Teilnahmewettbewerbs, die Leistung nicht abschließend beschrieben werden kann, oder nur ein Teilnehmer sich für ein Nachfolgeverfahren qualifizieren konnte, ein Verhandlungsverfahren mit maximal 3 Teilnehmern durchzuführen.
Die aktuell bereits abschließend vom Auftraggeber zu formulierenden „Mindestanforderungen“ an die einzubringende Hard- und Software, sind nachfolgend aufgelistet und stellen den Rahmen entsprechender Teilnahmeanträge, zur Berücksichtigung von Bewerbern im anschließenden Nichtoffenen Verfahren, bzw. im Verhandlungsverfahren, dar:
Technische Mindestanforderungen und deren Überprüfung im Rahmen des Teilnahmewettbewerbs:
Die Netze der im neuen Gebäude ansässigen Fachbereiche und Arbeitsgruppen müssen gegen Angriffe aus dem Internet gesichert werden. Da es im Detail von den Forschungsgruppen abhängt, ob ein Zugriff von Außen ein gewünschtes Verhalten von externen Systemen darstellt oder ein Angriff ist, müssen die Firewall-Regeln von den Arbeitsgruppen selbst erstellt werden. Daher muß die Firewall eine mandantenfähige Konfigurationsmöglichkeit für vom Hochschulrechenzentrum festgelegte Funktionalitäten bieten.
Das System muß als High-Availability-Lösung ausgelegt werden, so dass der Ausfall eines Systems durch die Verlagerung der Funktionalität auf eine andere Firewall aufgefangen wird.
Das System muß mit allen Komponenten (Hardware, Management, Logging) im Stadium „General Availability“ verfügbar sein.
Folgende Mindestanforderungen müssen von dem neuen Geräten und dem Management zwingend erfüllt werden:
Hardware:
— redundantes HA-Cluster mit mindestens 2 Geräten,
— Softwareupgrade und Hardwarersatz am HA-Cluster ohne Serviceunterbrechung,
— Ein HA-Cluster muss mit verschiedenen Softwareständen im active-active Betrieb funktionieren,
— Firewall performance 120 Gbps,
— Deep Packet Inspection performance 30 Gbps,
— Firewall packets per second (64 bytes) 15 Mpps,
— Interfaces: mindestens 8 x 10G,
— die Verwendung von Fremdoptiken muß unterstützt werden,
— Wire Speed auf allen Interfaces gleichzeitig,
— Interface müssen im laufenden Betrieb getauscht werden können.
Funktionalität:
— Unterstützung von mindestens 50 virtuellen Firewalls,
— paralleler Betrieb von ipv4 und ipv6,
— ipv4 und ipv6 portbasierendes Regelwerk,
— ipv4 und ipv6 servicebasierendes Regelwerk (FTP, SMTP, HTTPS, POP, IMAP etc.),
— ipv4 und ipv6 application basiertes Regelwerk (Facebook, Youtube etc.),
— voip-Protokolle H.323, SIP, SCCP, MGCP, RTP oder SRTP, RTCP oder SRTCP,
— NAT-Unterstützung von H.323 und SIP,
— application- und port-basierende Services sollen individuell bandbreitenbeschränkbar sein,
— das System muß im Layer-2, im Layer-3, in der Firewall-Funktionalität und in der IDP-Funktionalität für IPv4 und IPv6 ausgelegt sein,
— Link Aggregation (LACP),
— jumbo frame Unterstützung (>9 000 bytes),
— Layer-3-Routingprotokolle: RIP, RIPnG, OSPFv3, BGP4,
— Multicast Support: PIM, IGMP, PIM RPF, Static RP, SAP, SDP,
— NAT Policies müssen getrennt von Firewall-Policies sein,
— Anforderungen an concurrent sessions 10 Million,
— Anforderungen an security policies 80 000,
— IDP Funktionalität muß ohne Zusatzhardware integrierbar sein.
Folgende Anforderung wird im Rahmen der Teststellung überprüft. Es handelt sich um eine Mindestanforderung, die erfüllt werden muss:
— (1) Zur Realisierung eines verteilten Management muss das Gerät sowohl mandantenfähig als auch in voneinander getrennte virtuelle Systeme aufteilbar sein.
Systemmanagement:
— ssh,
— snmpv3,
— ISSU,
— ist die Funktionalität (Firewalling, IDP, Management) auf unterschiedliche Teilsysteme verteilt, muss die Kommunikation verschlüsselt erfolgen können.
Zentrales Firewall-Management:
— Die Authentifizierung und Autorisierung der Administratoren muß gegen Radius und LDAPS möglich sein,
— Administratoren verschiedener virtueller System müssen parallel zeitgleich das Management System nutzen können, auch zeitgleich Änderungen speichern/ downloaden können,
— Konfigurationsfiles müssen human readable (ASCII) sein und es müssen Import- und Exportmöglichkeiten existieren,
— Es müssen mehrere Konfigurationsfiles im Management vorhaltbar und aktivierbar sein,
— Aktionen der Administratoren müssen nachweisbar sein (audit log),
— Das parallel Konfigurieren und Aktivieren von Konfigurationen durch mehrere Administratoren darf die Reaktionszeiten des Systems nicht verlängern,
— In-Service-Software-Update muss unterstützt werden,
— (2) es muß möglich sein, globale Objekte und Regeln für Gruppen von virtuellen Firewalls zur Verfügung zu stellen sowie globale Regeln vorgeben zu können,
— (3) Lokale Administratoren dürfen Zugriff nur auf zugewiesene virtuelle Firewalls, deren lokale Objekte, Policies und Logs sowie auf zentrale Objekte erhalten (RBAC, durch das HRZ vordefiniert). Diese Administratoren dürfen die Konfiguration, die Objekte und die Logs anderer Firewalls nicht sehen (und damit auch keinerlei Einflussmöglichkeiten auf die Konfiguration oder Objekte anderer virtueller Firewalls haben).
Folgend wird das Konzept grob umrissen:
nicht einsehbar für den lokalen Administrator (virtuelle Firewalls anderer Organistationseinheiten):
— jegliche Informationen anderer, nicht im Verantwortungsbereich des lokalen Administrators, liegender Konfigurationen nicht vom lokalen Administrator veränderliche aber in seinem Verantwortungsbereich einsehbare Konfigurationsobjekte (read only):
— Interfaces,
— Vlan-Id,
— NAT-Adressbereiche,
— statisches und dynamische Routing,
— pre- und post-Rules,
— Virtuelle Firewalls,
— Zonen,
— globale Adress-, Service- und Apllikationsobjekte
— QoS
vom lokalen Administrator in seinem Verantwortungsbereich veränderliche Konfigurationsobjekte (read/write):
— security policies und deren Versionierung,
— Adressobjekte,
— Serviceobjekte,
— Applikationsobjekte,
— Schedulerobjekte,
— Counter,
— Logging,
— (4) Es muss möglich sein, zentral zeitliche Vorgaben zum Vorhalten der Logfiles zu konfigurieren, lokale Administratoren dürfen eigene Einstellungen nur innerhalb dieses zeitlichen Rahmens vornehmen,
— (5) Zur Konfiguration durch lokale Administratoren muss ein graphisches User Interface zur Verfügung stehen und dieses muss Zugriff auf alle vom Administrator konfigurierbaren Funktionalitäten ermöglichen.
Für die Durchführung der Teststellung gilt folgendes:
— Der Test findet an der Goethe Universität in deren Räumlichkeiten statt,
— Der Anbieter liefert die für den Test erforderliche Hardware, wobei diese nicht den für das Gesamtsystem geforderten Leistungsparametern entsprechen muss (die in der Teststellung nachzuweisenden Systemfunktionalitäten - s.o., müssen gleichwohl demonstriert werden können), wenn ein kleineres System mit identischer Software arbeitet; zudem ist kein HA-Paar erforderlich,
— Die Tests werden von einem Mitarbeiter des Anbieters begleitet, der die zu testende Funktionalität demonstriert,
— Zeitrahmen für die Tests sind 1 - 2 Tage,
— Dem Anbieter wird mindestens 3 Werktage vor der Teststellung, der Termin zur Teststellung per Email bekannt gegeben,
— Der Anbieter muss in der Zeit vom 3.2.2014 bis 7.2.2014 in der Lage sein, die Teststellung durchzuführen.
Es ist für den Erstausbau folgendes anzubieten:
Hardware:
— 2 Firewallsysteme mit je 2x10G SR zum Core, durch Transceiver um weitere 2x10G erweiterbar,
— 50 virtuelle Firewalls.
Software:
— Zentrales Managementsystem mit Loggingfunktionalität mit allen Lizenzen für die Hardware.
Garantie/ Wartung:
— Mindestgewährleistung von 60 Monaten auf alle Hardware-Komponenten,
— Software-Upgrade und -Support auf 60 Monate für Firewall und Management.
Die schriftlichen Teilnahmeanträge müssen auf alle vorgenannten Mindestanforderungen detailliert eingehen und deren Erfüllung, durch entsprechende Angaben (sofern gefordert, sind entsprechende Leistungsparameter detailliert anzugeben) nachvollziehbar erkennen lassen.
Zudem sind in den Teilnahmeanträgen alle, zur Beurteilung der Eignung des Teilnehmers, im Sinne der in den Punkte III.2.1 bis III.2.3 dieser Bekanntmachung dargelegten Anfordrungen, erforderlichen Eigenerklärungen abzugeben und ggf. geforderte Nachweise mit dem Teilnahmeantrag vorzulegen.
Der Auftraggeber behält sich vor Eigenerklärungen, bzw. Nachweise von Teilnehmern nachzufordern, bzw. Nachweise zu Eigenerklärungen auch selbst einzuholen.
Angebote in dem, dem Teilnahmewettbewerb nachgelagerten Verfahren (Nichtoffenes verfahren bzw. Verhandlungsverfahren) müssen in Form eines EVB-IT-Pflegevertrags, eines EVB-IT-Instandhaltungsvertrags und eines EVB-IT-Kaufvertrags (Kurzfassung) vorgelegt werden.
Deadline
Die Frist für den Eingang der Angebote war 2014-02-18.
Die Ausschreibung wurde veröffentlicht am 2014-01-17.
Wer?
Wie?
Wo?
Geschichte der Beschaffung
| Datum |
Dokument |
| 2014-01-17
|
Auftragsbekanntmachung
|