Network Services
Die Network Services in der ix.Cloud umfassen die folgenden Optionen, um Services innerhalb der ix.Cloud untereinander zu vernetzen und externe Services mit Services in der ix.Cloud zu verbinden:
| Service Name | Service Kurzbeschreibung |
|---|---|
| Firewall | Elementare Sicherheit zwischen verschiedenen Subnetzen |
| Server Proxy | Indirekte und restriktive Kommunikation für Server der ix.Cloud |
| Load Balancer | Verteilung eingehender Verbindungen auf Anwendungen oder Service-Endpunkte |
| Web Application Firewall | Bietet Sicherheit für online Dienste vor böswilligem Internetverkehr und filtert Bedrohungen wie OWASP TOP 10 welche Online-Anwendungen negativ beeinträchtigen |
| Private DNS | Auflösung von IP-Adressen zu DNS-Namen innerhalb der ix.Cloud |
| Secure Mail-Relay | Sichere E-Mail-Zustellung aus all Ihren Systemen innerhalb der ix.Cloud |
| Hosted Software-Appliance | Virtuelle Server für Software-Appliances, ohne Support für Microsoft Hyper-V |
Firewall
Der Firewall-Service ist ein von Inventx verwalteter, cloudbasierter Netzwerksicherheitsdienst, über den die virtuellen Netzwerk-Ressourcen innerhalb der ix.Cloud geschützt werden können. Dieser Service ist ausschliesslich im SLA Platin verfügbar.
Die Richtlinien zur Anwendungs- und Netzwerkkonnektivität werden übergreifend für sämtliche Abonnements der ix.Cloud und virtuellen Netzwerke zentral erstellt und protokolliert. Es können Netzwerke und IP-Adressen zwischen verschiedenen Quellen (Sources) und Zielen (Destinations) freigeschaltet werden. Die Verbindungen werden auf definierte Services (insb. TCP/UPD-Ports) eingeschränkt.
Service Architektur
Service Umfang
| Leistungsmerkmal | Platin |
|---|---|
| Initiales Setup | ◻ |
| IT Grundschutz | ◼ |
| FQDN-Anwendungsfilterregeln | ◼ |
| Filterregeln für Netzwerkdatenverkehr | ◼ |
| SNAT-Unterstützung | ◼ |
| Protokollierung (Logging) | ◼ |
| DNAT-Unterstützung | ◻ |
| UTM-Features | ◻ |
IT Grundschutz
Upgrade/Patching
Die Firewall-Infrastruktur wird halbjährlich aktualisiert, es sei denn, es treten kritische Sicherheitslücken auf, welche ein sofortiges Upgrade erfordern.
Logging
Das Logging erfolgt über eine zentrale Instanz, an die sämtliche Logs zur Analyse und Auswertung gesendet werden. Die Logs werden 14 Tage lang live aufbewahrt und anschliessend für 800 Tage archiviert.
Malware Schutz
Der Malware-Schutz basiert auf gehärteten Appliances die beim booten durch secure boot auf ihre Integrität geprüft werden. Secure Boot stellt sicher, dass nur vertrauenswürdige und signierte Firmware und Software auf der Hardware geladen wird. Der Boot-Prozess startet mit einem unveränderlichen, in die Hardware eingebetteten Code und verifiziert nachfolgende Komponenten. Die Geräte überprüfen regelmässig die Integrität der installierten Firmware durch kryptografische Signaturen. Firewall-ASICs sind speziell entwickelte Hardware-Sicherheitsprozessoren, die viele der Sicherheitsfunktionen wie Verschlüsselung und Deep Packet Inspection (DPI) hardwareseitig beschleunigen. Die Systempartitionen, die für die Ausführung der Betriebssystem- und Konfigurationsdaten verantwortlich sind, sind von den Benutzerdaten und Anwendungen isoliert.
Service Optionen
Beim Firewall Service kann der Kunde weitere Dienstleistungen nach Absprache beziehen:
Initiales Setup
Die Umsetzung der initialen Konfiguration des Firewall-Service wird im Rahmen eines Projekts verrechnet. Dabei wird das kundenindividuelle Ruleset in Zusammenarbeit mit dem Kunden spezifiziert und anschliessend implementiert. Sämtliche Änderungen sind mit einem "Generic Request" zu beauftragen.
FQDN-Anwendungsfilterregeln
Kunden können den ausgehenden HTTP/S-Datenverkehr auf eine angegebene Liste vollständig qualifizierter Domänennamen (FQDN) beschränken, wobei Wildcard-Einträge über die UTM-Feature Option abgebildet werden müssen. Das FQDN-Feature erfordert keine SSL-Terminierung.
Filterregeln für Netzwerkdatenverkehr
Die kundenspezifischen Netzwerkfilterregeln zum Zulassen oder Verweigern nach Quell- und Ziel-IP-Adresse, Port und Protokoll werden von Inventx zentral gepflegt. Die Firewall ist zustandsbehaftet (stateful), so dass zwischen legitimen Paketen für verschiedene Arten von Verbindungen unterschieden werden kann. Die Regeln werden übergreifend für sämtliche Abonnements der ix.Cloud und virtuellen Netzwerke forciert und protokolliert.
SNAT-Unterstützung
Alle IP-Adressen für ausgehenden Datenverkehr des virtuellen Netzwerks in der ix.Cloud werden in die öffentliche IP-Adresse der Firewall übersetzt (Source Network Address Translation). Sie können Datenverkehr aus Ihrem virtuellen Netzwerk an Remoteziele im Internet identifizieren und zulassen. Die SNAT-Funktionalität kann optional auch für den internen Datenverkehr in der ix.Cloud implementiert werden.
Protokollierung (Logging)
Alle auf der Inventx terminierende und von der Inventx verantwortende Verbindungen werden protokolliert. Dies bedeutet, dass alle eingehenden sowie ausgehenden Verbindungen externer wie auch interner Herkunft aufgezeichnet werden.
Die Aufbewahrungsdauer beträgt 2 Jahre. Ein Log-Reporting an den Kunden ist bei Bedarf via "Generic Request" zu beauftragen.
DNAT-Unterstützung
Der eingehende Netzwerkdatenverkehr zur öffentlichen IP-Adresse der Firewall in der ix.Cloud, wird in die privaten IP-Adressen in den virtuellen Netzwerken des Kunden übersetzt (Destination Network Address Translation) und gefiltert. Die DNAT-Funktionalität kann optional auch für den internen Datenverkehr in der ix.Cloud implementiert werden.
UTM-Features
Die optionalen UTM-Features (Unified Threat Management) werden zusammen mit dem Kunden spezifiziert und danach durch Inventx betrieben.
Server Proxy
Sollen die Server in der ix.Cloud zur Erhöhung der IT-Sicherheit nicht direkt mit dem Internet kommunizieren, so ermöglicht der Server Proxy den Server-Systemen der ix.Cloud über definierte Regeln nur gewisse Adressen im Internet aufzurufen. Auf diesem Explizit-Proxy wird der Zugriff über verschiedene Technologien wie Web-Filter, Viren-Filter, Kategorien und Anwendungssteuerung kontrolliert und eingeschränkt. Alle Zugriffe (Ausnahmen möglich) werden mittels Deep-Inspection (Aufbrechen des Traffics) überprüft, wobei sich Inventx an die gesetzlichen Vorgaben des Datenschutzes hält.
Der Server Proxy steht als Shared Service ausschliesslich im SLA Platin zur Verfügung und muss über den "Generic Request" bestellt und verwaltet werden. Der Server Proxy kann nur von serverbasierten Systemen genutzt werden und steht für Clients nicht zur Verfügung.
Service Architektur
Service Umfang
| Leistungsmerkmal | Platin |
|---|---|
| Initiales Setup | ◻ |
| IT Grundschutz | ◼ |
| Standard-Richtlinie für Protokolle und Ports | ◼ |
| Standard-Richtlinie für Web-Filter | ◼ |
| Standard-Richtlinie für Viren-Filter | ◼ |
| Standard-Richtlinie für Anwendungssteuerung | ◼ |
| Standard-Richtlinie für Deep-Inspection | ◼ |
IT Grundschutz
Siehe Beschreibung Kapitel Firewall IT Grundschutz.
Service Optionen
Beim Server Proxy Service kann der Kunde aktuell keine optionalen Dienstleistungen beziehen.
Initiales Setup
Der Server Proxy als Shared Service kann nicht individuell an Kundenbedürfnisse angepasst werden und es stehen ausschliesslich globale Filterkonfigurationen zur Verfügung.
Ist eine individuelle Konfiguration des Server Proxy Services gewünscht, so wird dies im Rahmen eines Projekts erarbeitet und verrechnet. Während dem Projekt wird das kunden-individuelle Ruleset in Zusammenarbeit mit dem Kunden auf Basis des Inventx Standard Rulesets spezifiziert und auf einem privaten Server Proxy implementiert.
Standard-Richtlinie für Protokolle und Ports
Inventx pflegt eine Standard-Richtlinie für alle serverbasierten Systeme der ix.Cloud. Im Inventx-Standard werden die folgenden Services und Ports zugelassen:
| Protokoll | Proxy-Port(s) | Socks-Port(s) |
|---|---|---|
| HTTP | 80 | ⁃ |
| HTTPS | 443 | ⁃ |
| SSH | ⁃ | 22 |
Standard-Richtlinie für Web-Filter
Der Web-Filter kategorisiert alle Internetseiten anhand vordefinierter Algorithmen (Hersteller Vorgabe), welche erlaubt oder blockiert werden. Die globale Konfiguration basiert auf Inventx Standards, wobei folgende Kategorien zugelassen sind:
| Web-Kategorie | Zugelassen |
|---|---|
| Business | ◼ |
| Finance and Banking | ◼ |
| Information Technology | ◼ |
| Information and Computer Security | ◼ |
Standard-Richtlinie für Viren-Filter
Die globale Standard-Policy von Inventx entscheidet, welche ein- und ausgehenden Inhalte auf Viren untersucht werden und vermeidet so das Eindringen von schädlicher Software, wobei sämtlicher HTTP- und FTP-Datenverkehr analysiert wird.
Standard-Richtlinie für Anwendungssteuerung
Mithilfe der Anwendungssteuerung (Application Control) werden unerwünschte Funktionen von Webseiten ausgeschaltet. So kann zum Beispiel das Streamen von Audio- und Video-Dateien, das Chatten und das Hoch- und Herunterladen von Dateien verhindert werden. Das globale Ruleset von Inventx ist wie folgt definiert:
| Web-Kategorie | Gesperrt |
|---|---|
| Webmail (z.B. Gmail oder GMX) | ◼ |
| Game | ◼ |
| Mobile | ◼ |
| P2P | ◼ |
| Remote Access | ◼ |
| Social Media | ◼ |
| Video/Audio | ◼ |
| VOIP | ◼ |
| Unknown Applications | ◼ |
Standard-Richtlinie für Deep-Inspection
Der Server Proxy überprüft die HTTPS-Pakete, wobei die Kategorien "Health and Wellness", "Finance and Banking" aus datenschutzrechtlichen Gründen nicht analysiert werden. Dabei wird der HTTPS-Verkehr entschlüsselt, überprüft, wieder verschlüsselt und an das Ziel weitergeleitet.
Load Balancer
Ein Load Balancer verteilt den Datenverkehr eines bestimmten Service-Endpunkts auf mehrere Ziele. Dabei werden fehlerhafte Ziele erkannt und der Datenverkehr nur an intakte Ziele weitergeleitet. Dadurch können die Verfügbarkeit und Performance einer Anwendung optimiert werden.
Für HTTP/HTTPS-Anwendungen empfiehlt sich ein Load Balancer auf Layer 7, während bei Anwendungen mit TCP/UDP-Protokoll ein Load Balancer auf Layer 4 empfohlen wird.
Dieser Service ist nur im SLA Platin verfügbar. Layer 4 Load Balancer können über das Portal im Self-Service bestellt und verwaltet werden. Die übrigen Load Balancer müssen über den Service Request "Load Balancer" bestellt und verwaltet werden.
Service Architektur
Service Umfang
| Leistungsmerkmal | Layer 4 | Layer 7 |
|---|---|---|
| Initiales Setup | ◻ | ◻ |
| IT Grundschutz | ◼ | ◼ |
| Service Management | ◼ | ◼ |
| Bandbreite (5 MBit/s) | ◼ | ◼ |
| Service IP-Adresse | ◼ | ◼ |
| Service FQDN | ⁃ | ◼ |
| Protokolle/Ports | ◼ | ◼ |
| Load Balancing | ◼ | ◼ |
| Persistence | ◼ | ◼ |
| X-Forwarded-For | ◼ | ◼ |
| Default DDoS Profile | ◼ | ◼ |
| Health Monitoring | ◼ | ◼ |
| Error Page | ⁃ | ◼ |
| Maintenance Page | ⁃ | ◼ |
| SSL Offloading/Bridging | ⁃ | ◼ |
| Host Header Forwarding/Rewriting/Redirecting | ⁃ | ◼ |
IT Grundschutz
Patch Management
Die Loadbalancer-Infrastruktur wird mindestens halbjährlich aktualisiert, es sei denn, es treten kritische Sicherheitslücken auf, welche ein sofortiges Upgrade erfordern.
Malware Schutz
Der Malware-Schutz basiert auf gehärteten Appliances die beim booten auf ihre Integrität geprüft werden. Die Infrastruktur der Load Balancer nutzt Secure Boot und Image Signing, um sicherzustellen, dass nur signierte und vertrauenswürdige Softwarekomponenten ausgeführt werden. Die Load Balancer unterstützten RASP-Funktionalitäten (Runtime Application Self-Protection), die Anwendungen während der Laufzeit überwachen und schützen.
Service Optionen
Durch die in diesem Kapitel aufgeführten Optionen, kann ein Load Balancer auf unterschiedliche Weise konfiguriert werden.
Initiales Setup
Der Aufwand für die Einrichtung eines Load Balancers ist stark abhängig von den gewünschten individuellen Anforderungen des Kunden. Daher wird das initiale Setup eines Load Balancers nach Aufwand verrechnet.
Service Management
Im Service Management ist die Aktualisierung der verwendeten Softwarekomponenten und Security Patterns, das Ressourcenmanagement und das Backup der Infrastruktur inbegriffen. Das Zertifikats-Lifecycle Management (Erstellung/Beantragung, Integration, Austausch/Erneuerung von Zertifikaten) wird separat nach Aufwand verrechnet.
Bandbreite
Die Bandbreite (Datendurchsatz) ist pro Service individuell konfigurierbar. Im Basispreis ist eine Bandbreite von 5 Megabit per Second (MBit/s) inkludiert. In Schritten von 5 MBit/s kann der Service auf maximal 40 MBit/s gemäss separater Preisliste skaliert und den Anforderungen gerecht bestellt werden (siehe Tabelle unten). Die Verrechnung erfolgt nach Anzahl bestellter 5 Mbit/s Einheiten.
Wenn mehr Daten über den Load Balancer transportiert werden als die bestellte Bandbreite es erlaubt, werden Paketverluste (Paket-Drops) generiert. Wenn Paketverluste festgestellt werden, kann eine Erhöhung der Bandbreite bestellt/beauftragt werden. Bei einem Layer 4 Load Balancer kann die Erhöhung der Bandbreite direkt im Portal vorgenommen werden. Bei einem Layer 7 Load Balancer muss die Erhöhung der Bandbreite via Load Balancer Service Request beauftragt werden.
| Bankdbreite | Layer 4 | Layer 7 |
|---|---|---|
| 5 MBit/s | ◼ | ◼ |
| 10 MBit/s | ◻ | ◻ |
| 15 MBit/s | ◻ | ◻ |
| 20 MBit/s | ◻ | ◻ |
| 25 MBit/s | ◻ | ◻ |
| 30 MBit/s | ◻ | ◻ |
| 35 MBit/s | ◻ | ◻ |
| 40 MBit/s | ◻ | ◻ |
Service IP-Adresse
Pro Service kann eine IP-Adresse hinterlegt werden. Handelt es sich um eine private IP-Adresse ist diese kostenlos. Bei einer öffentlichen IP-Adresse fallen zusätzliche Kosten gemäss Preisliste an. Private IP-Adressen werden im Internet nicht geroutet und sind somit nur innerhalb eines lokalen Netzwerks verwendbar. Öffentliche IP-Adressen werden im Internet geroutet.
Service FQDN
Auf eine Layer 7 Service IP-Adresse (VIP) kann eine oder mehrere URLs verwiesen (DNS-Eintrag) werden. Ein DNS-Eintrag für die jeweilige URL ist Voraussetzung für die End-to-End (Client-Server) Kommunikation.
Protokolle/Ports
Wenn bei der Bestellung nichts anders angegeben, werden bei Layer 4 die Standard Ports 80/443 und bei Layer 7 das Protokoll HTTPS für den Serviceaufbau verwendet.
Die folgende Tabelle zeigt die möglichen Protokolle und Ports pro Service und Layer an.
| Protokoll/Port | Layer 4 | Layer 7 |
|---|---|---|
| TCP (alle möglichen Ports) | ◼ | ◻ |
| HTTP | ⁃ | ◻ |
| HTTPS | ⁃ | ◼ |
Load Balancing
Standardmässig ist None (Round-Robin) aktiviert. Die Option Load Balancing dient der Lastverteilung mit dem Ziel die Endsysteme gleichermassen zu belasten.
| Load Balancing Option | Layer 4 | Layer 7 |
|---|---|---|
| None (Round Robin) Jede neue Anfrage wird an einen Server im Pool gesendet, anschliessen top-down von neuem. |
◼ | ◼ |
| Least Connection Verbindungen werden jeweils an den Server gesendet, welcher aktuell am wenigsten Verbindungen offen hat. |
◻ | ◻ |
| Least Load Verbindungen werden jeweils an den Server gesendet, welcher aktuell am wenigsten ausgelastet ist. |
◻ | ◻ |
| Fastest Response Verbindungen werden jeweils an den Server gesendet, welcher am schnellsten antwortet. |
◻ | ◻ |
| Fewest Servers Per Algorithmus wird berechnet welche Anzahl von Servern für die Bewältigung der Anfrage notwendig ist. Es werden somit nur dem ersten Server im Pool Anfragen gesendet, sobald dieser die Kapazitätsgrenze erreicht hat wird top down der Traffic an den jeweils Nächsten weitergereicht. |
◻ | ◻ |
Persistence
Standardmässig ist keine "Persistence" konfiguriert. Durch Verwendung der Option Persistence, wird die Sitzung an ein bestimmtes Endsystem gebunden. So wird sichergestellt, dass die Anfragen während einer Sitzung immer vom selben Endsystem verarbeitet werden.
| Persistence Option | Layer 4 | Layer 7 |
|---|---|---|
| Client IP Die Client-IP wird als Kennung verwendet und dem Server zugeordnet. |
◻ | ◻ |
| TLS Die Informationen sind in die SSL/TLS-Ticket-ID des Clients eingebettet. |
⁃ | ◻ |
| APP Cookie Liest vorhandene Server-Cookies oder eingebettete URI-Daten wie JSessionID. |
⁃ | ◻ |
| HTTP Cookie Fügt ein Cookie in die HTTP-Anwort(en) ein. |
⁃ | ◻ |
| Custom HTTP Header Der Kunde kann benutzerdefinierte Vorgaben zur Zuordnung von Header-Werten zu bestimmten Servern erstellen. |
⁃ | ◻ |
X-Forwarded-For
Mit dem X-Forwarded-For ist es möglich, Client IP-Adressen (original IP) mit dem Header an das Zielsystem zu übertragen. Das Zielsystem kann diese Information verwenden, um beispielsweise aufzuzeigen, woher die Anfrage stammt oder serverseitig Black-/White-Lists aufzuschalten. Diese Option ist nur bei Load Balancer Layer 7 einsetzbar.
Default DDOS Profile
Standardmässig ist ein DDoS Profil (Build-in) aktiviert, welches auf Layer 3, 4 und Layer 7 Netzwerkattacken erkennt und verhindert.
| Default DDOS Profil | Layer 4 | Layer 7 |
|---|---|---|
| Layer 3 SMURF, ICMP Flood, Unknown Protocol, Tear Drop, IP Fragementation |
◼ | ◼ |
| Layer 4 SYN Flood, LAND, Port Scan, X-mas Tree, Bad RST Flood, Fake Session, Bad Sequence Number, Malformed/Unexpected Flood, Zero/Small Window, Rate Limiting CPS per IP, SSL Errors, SSL Renegotiation |
◼ | ◼ |
| Layer 7 Request Idle Timeout (10'000ms), SlowPost (30'000ms), SlowLoris (30'000ms), Invalid Requests |
⁃ | ◼ |
Health Monitoring
Beim Health Monitoring sendet der Load Balancer innerhalb eines Intervalls Anfragen an das Zielsystem, für welche er jeweils eine Antwort innerhalb eines gesetzten Zeitfensters erwartet.
Werden die jeweiligen Anfragen an einem Zielsystem nicht beantwortet, so wird das Zielsystem als nicht erreichbar markiert. Folglich werden Client-Server Anfragen nicht mehr an das Zielsystem weitergereicht.
| Health Monitoring Option | Layer 4 | Layer 7 |
|---|---|---|
| TCP (custom-client-request/custom-server-response) Wartet auf eine vollständige TCP Verbindung, auf einem spezifisch angefragten Port. |
◻ | ◻ |
| ICMP Sendet einen Ping und erwartet eine Rückmeldung vom "angepingten" Server. |
⁃ | ◻ |
| DNS (request/response) Prüft den "Name Server" ob eine korrekte Namensauflösung auf einen spezifizierten Eintrag möglich ist. |
⁃ | ◻ |
| HTTP/S (custom-client-request-header/-body, custom-server-response) Prüft den spezifizierten "Respond Code" auf deren Korrektheit. |
⁃ | ◻ |
| External Per Script-Befehl können Kundenspezifizierte Health-Checks vorgenommen werden. (wget, netcat, curl, dig, mysql-client, snmpget) |
⁃ | ◻ |
Error Page
Standardmässig wird bei einem Layer 7 Service eine "Default Error Page" ausgegeben, welche den Client über den Verbindungsfehler in Kenntnis setzt. Entspricht das Layout oder der Inhalt der Page nicht den Bedürfnissen, kann eine "Custom Error Page" erstellt und der Inventx zur Einbindung zur Verfügung gestellt werden.
Maintenance Page
Soll eine Maintenance Page für den Wartungsmodus geschalten werden, kann dies Anhand eines Auftrages an die Inventx, oder durch den Kunden selbst veranlasst werden. Im Zweiten fall, muss ein Skriptbasierter Lösungsanasatz gefahren werden, hierfür bitten wir Sie Ihren konkreten UseCase bekanntzugeben.
SSL Offloading/Bridging
Wenn ein Layer 7 Service bestellt wird, wird standardmässig das SSL-Offloading aktiviert. Diese Option ermöglich, dass der Load Balancer der verschlüsselte Traffic aufbrechen kann um z.B. Netzwerkangriffe erkennen zu können und anhand WAF-Richtlinien zu verhindern.
Beim SSL Offloading wird der Traffic entschlüsselt:
- Client zum Load Balancer = verschlüsselt
- Load Balancer zum Ziel = unverschlüsselt
Beim SSL Bridging hingegen wird der Traffic entschlüsselt und wieder verschlüsselt:
- Client zum Load Balancer = verschlüsselt
- Load Balancer zum Ziel = verschlüsselt
Für die Zertifikatsausstellung/-einbindung wird eine bestehende PKI-Infrastruktur in der Kundenumgebung vorausgesetzt. Falls Diese nicht zur Verfügung steht, müssen seitens Kunden die benötigten Zertifikate der Inventx zur Verfügung gestellt werden.
Das Lifecycle Management der Zertifikate ist nicht Bestandteil dieses Services und muss durch den Kunde sichergestellt werden.
Host Header Forwarding/Rewriting/Redirecting
Sofern ein Layer 7 Service bestellt wird, besteht die Möglichkeit anhand Host-Header Informationen forwarder, rewrites, redirects vorzunehmen. Zudem kann auf Wunsch eine Umleitung von HTTP auf HTTPS erfolgen.
Web Application Firewall
Mit der von Inventx betriebenen Web Application Firewall (WAF) wird die Serviceanbindung über den Load Balancer dahingehend unterstützt, dass eingehender HTTP-Verkehr auf Sicherheitslücken bzw. unbefugte Datenübertragung überprüft wird, bevor dieser den Anwendungsserver erreicht. Somit dient der WAF-Service als Durchsetzungspunkt für Sicherheitsrichtlinien, welche zwischen Webanwendung und dem Client Anwendung stattfindet.
Die WAF fängt alle HTTP-Anforderungen ab und überprüft diese mithilfe des vorgängig definierten Regelsets (Sicherheitsmodells), um identifizieren zu können ob es sich hierbei um ungewollten Datenverkehr (cross-site scripting, SQL injection, ect.) handelt. Dieses Vorgehen verhindert L7-DDos/Angriffe, bei denen versucht wird die Sicherheitsanfälligkeiten in webbasierten Anwendungen auszunutzen bzw. den Service negativ zu beeinflussen.
Dieser Service ist nur im SLA Platin verfügbar und muss über den Standard Service Request "Web Application Firewall" bestellt und verwaltet werden.
Service Architektur
Service Umfang
| Leistungsmerkmal | Platin |
|---|---|
| Initiales Setup | ◻ |
| IT Grundschutz | ◼ |
| Load Balancer Layer 7 | ◼ |
| Service Management | ◼ |
| OWASP TOP 10 Rule-Set | ◼ |
| Kundenindividuelles Rule-Set | ◻ |
| Betriebsmodus Enforcement | ◼ |
IT Grundschutz
Siehe Beschreibung Kapitel Load Balancer IT Grundschutz.
Service Optionen
Beim WAF-Service kann der Kunde weitere Dienstleistungen nach Absprache beziehen.
Initiales Setup
Der Aufwand für die Einrichtung eines WAF Services ist stark abhängig von den gewünschten individuellen Anforderungen des Kunden, im speziellen bei den zu definierenden Rule-Sets. Daher wird das initiale Setup einer WAF nach Aufwand verrechnet.
Load Balancer Layer 7
Die Basis-Konfiguration für den WAF bildet ein Load Balancer Layer 7. Entsprechende Service Optionen werden beim Load Balancer in der Ausprägung Layer 7 beschrieben.
Service Management
Im Service Management ist unter anderem die Aktualisierung der verwendeten Softwarekomponenten und Security Patterns, das Ressourcenmanagement und das Backup der Infrastruktur inbegriffen.
Das WAF-Lifecycle Management (Analyse/Anpassung von Regelsätzen) wird separat nach Aufwand verrechnet.
OWASP TOP 10 Rule-Set
Als Standard Rule-Set dienen die OWASP Top 10 Schwachstellen. Das Open Web Application Security Projekt (OWASP) ist eine internationale non-profit Organisation, die sich der Sicherheit von Webanwendungen verschrieben hat. Das bekannteste Projekt nennt sich OWASP Top 10. Hierbei handelt es sich um einen Report, der die 10 kritischsten Risiken abdeckt.
Kundenindividuelles Rule-Set
Gewisse Anwendungen benötigen für den einwandfreien Betrieb eine individuelle Konfiguration des Rule-Sets. Hierfür werden beispielsweise Ausnahmen für das OWASP Rule-Set für unerwünschte Detektionen erstellt. Anpassungen am Regelwerk sind mit einem "Generic Request" zu beauftragen.
Betriebsmodus Enforcement
Der WAF-Service wird im Betriebsmodus Enforcement betrieben. Dabei wird das konfigurierte Rule-Set produktiv angewendet und die Web-Anwendungen entsprechend geschützt, gleichsam ob der WAF-Service für die Test- oder Produktionsstufe genutzt wird.
Private DNS
Der Private DNS (Domain Name System) Service ermöglicht es, Server und Client-Systemen eine autoritative/reverse Auflösung von IP-Adresse zu DNS-Namen und vice versa. Die Zugriffe eines Kunden werden in einer privaten View (Zone) des globalen DNS-Systems abgebildet, die von Inventx gepflegt und betrieben wird.
Der Private DNS Service steht ausschliesslich im SLA Platin zur Verfügung und muss via "Generic Request" bestellt werden.
Service Architektur
Service Umfang
| Leistungsmerkmal | Platin |
|---|---|
| Initiales Setup | ◻ |
| Authoritive Zone | ◼ |
| Weiterleitung | ◼ |
Service Optionen
Durch die in diesem Kapitel aufgeführten Leistungselemente, kann der DNS Service auf unterschiedliche Weise individualisiert betrieben werden.
Initiales Setup
Die Umsetzung der initialen Konfiguration des Private DNS Service wird im Rahmen eines Projekts verrechnet. Dabei wird die Konfiguration in Zusammenarbeit mit dem Kunden spezifiziert und anschliessend implementiert.
Authoritive Zone
Eine autoritative Zone ist eine Zone, für die der lokale (primäre oder sekundäre) DNS-Server auf seine eigenen Daten verweist, wenn er auf Abfragen antwortet. Der lokale DNS-Server ist für die Daten in dieser Zone verantwortlich und antwortet auf Abfragen, ohne auf einen anderen Server zu verweisen. Es gibt zwei Zonenarten:
- Forward-Mapping: Eine Forward-Mapping-Zone ist ein Bereich des Domain-Namensraums, für den ein oder mehrere Nameserver die Verantwortung haben, auf Anfragen von Name-zu-IP-Adresse zu antworten.
- Reverse-Mapping: Eine Reverse-Mapping-Zone ist ein Bereich des Netzwerkraums, für den ein oder mehrere Namensserver für die Beantwortung der Anfragen von IP-Adresse-zu-Name zuständig sind.
Folgende Record-Typen sind pro Zonenart möglich:
| Record Typ | forward-mapping | reverse-mapping |
|---|---|---|
| Host Record | ◼ | ⁃ |
| A Record | ◼ | ⁃ |
| CNAME Record | ◼ | ⁃ |
| Alias Record | ◼ | ◼ |
| MX Record | ◼ | ⁃ |
| NS Record | ◼ | ⁃ |
| PTR Record | ◼ | ◼ |
| SRV Record | ◼ | ⁃ |
| TXT Record | ◼ | ⁃ |
Weiterleitung
Bei einer hybriden Architektur kann durch die DNS-Weiterleitung die ix.Cloud mit einer OnPremise-Umgebung des Kunden logisch verbunden werden. Durch diese Option können Kunden bereits vorhandene, lokale DNS-Server als autoritativ weiterverwenden.
Secure Mail-Relay
Mit dem von Inventx betriebenen Secure Mail-Relay Service können Kunden E-Mail (SMTP Syntax) aus der ix.Cloud sicher ins Internet versenden, wobei als Absender der Nachricht eine Inventx-Adresse hinterlegt wird.
Service Architektur
N/A
Service Umfang
| Leistungsmerkmal | Platin |
|---|---|
| Initiales Setup | ◻ |
| Quelle und Bestimmungsort | ◼ |
| Malware-Schutz | ◼ |
| Content-Filtering | ◼ |
| Session Handling | ◼ |
| Adressierung | ◼ |
| Versand über Internet | ◼ |
Service Optionen
Der Secure Mail-Relay Service der ix.Cloud weist die folgenden Merkmale aus:
Initiales Setup
Die Inbetriebnahme des Mail-Relay Service wird im Rahmen eines Projekts vollzogen. Dabei wird der Service in Zusammenarbeit mit dem Kunden spezifiziert und anschliessend integriert. Bestellungen und sämtliche Änderungen sind mit einem "Generic Request" zu beauftragen.
Quelle und Bestimmungsort
Der Mail-Relay Service ist nur innerhalb der ix.Cloud erreichbar, denn sämtliche Nachrichten werden auf Basis des IP-Ranges und der Absender-Adresse entgegengenommen. Als Empfänger können alle E-Mail-Adressen angegeben werden.
Malware-Schutz
Nach Entgegennahme der Nachricht findet eine Malware-Prüfung statt. Bei einem positiven Befund, wird die Nachricht abgelehnt (rejected). Zudem ist ein Antivirus-Outbreak-Filter von 20 Minuten hinterlegt, damit Malware zeitnah identifiziert werden kann.
Content-Filtering
Aus Sicherheitsgründen werden sämtliche Nachrichten gefiltert. Dateien vom Typ Video, Audio, Archiv sowie Executables, Scipts und verschlüsselte Files werden gefiltert und mit einem Error-TXT-File ersetzt. Um unerlaubten Datenabfluss zu verhindern, gelten folgende Regeln:
- Anzahl Attachments pro Nachricht: Maximal 5
- Grösse der Nachricht: Maximal 10 MB
- Kompressionslevel der Beilage: Maximal 12
Session-Handling
Es sind maximal 1'200 Nachrichten pro 30 Minuten und pro SMTP-Verbindung maximal drei parallele ELHO-Aufträge möglich. Bei Überschreitung dieser Werte, wird automatisch eine Drosselung (Throttling) ausgeführt.
Adressierung
Vor dem Versand an die Destination wird der Absender mit einer generischen Inventx-Adresse umgeschrieben (noreply@ixcloud.ch).
Versand über Internet
Der Versand der Nachrichten findet stets über das Internet statt. Ein verschlüsselter Versand (TLS) wird dringend empfohlen (preferred), jedoch nicht erzwungen.
Hosted Software-Appliance
Für den Betrieb von Software-Appliances können Virtuelle Server auf Basis der ESX-Virtualisierung von VMware bezogen werden, für den Fall, dass der Software-Hersteller keinen Support für Microsoft Hyper-V anbietet. Solche VM werden ausschliesslich im SLA Rhodium bereitgestellt und können weder über das ix.Cloud Portal noch über die ix.Cloud API verwaltet werden.
Service Architektur
Siehe Virtual Machine Darstellung SLA Rhodium.
Service Umfang
Virtuelle Server auf Basis von VMware können in den Standard Hardware-Profilen gemäss Virtual Machine bestellt werden. Solche VM werden ohne Betriebssystem (OS) ausgeliefert. Der Kunde ist für Lizenzierung, Betrieb und Wartung des OS selber verantwortlich (vgl. "Customer Owned OS" unter Virtual Machine). Die Off-Funktionalität steht nicht zur Verfügung.
Solche VM müssen via "Standard Service Request" bestellt werden - Mutationen und Dekommissionierungen via "Generic Request". Der Image-Import erfolgt gemäss Beschreibung für "Customer Owned OS" unter Virtual Machine.
Service Optionen
Keine Optionen verfügbar.