aXes Architektur

aXes wird normalerweise in Umgebungen bei Großunternehmen oder Service Providern (SP) installiert. Die Sicherheitsstandards in diese Umgebungen können stark variieren, von fehlenden Firewalls angefangen bis hin zu Firewalls die zwischen und um jede mögliche Schicht der Infrastruktur herum installiert sind.

Das Ziel von aXes ist es flexible genug zu sein, damit es in jedem Sicherheitsumfeld in dem es installiert wird, läuft, mit wenig oder gar keinen Änderungen an der vorhandenen Infrastruktur. In einigen Fällen befinden sich die Client-Geräte an entfernten Orten, die nicht durch die Organisationen, die aXes steuern, verwaltet werden. Datenverkehr von Client-Geräten kann durch Firewalls geleitet werden und/oder Proxy Servers, wenn sie Server über das Internet aufrufen. Sicherheitsrichtlinien beim Kunden vor Ort erlauben möglicherweise nur Verkehr zu und von einem bestimmen Port. Die Herausforderung für Anwender besteht darin auf die Geschäftsanwendungen über das Internet zuzugreifen, ohne dadurch die Unternehmenssicherheit zu gefährden. Jegliche Software oder Hardware, die in einer Unternehmens- oder SP-Umgebung mit Internetzugang läuft, muss sich dieser Herausforderung stellen. aXes bewältigt diese Herausforderung ohne dabei den Endbenutzer zu beeinträchtigen, die Sicherheitsrichtlinien zu gefährden, und ohne die vorhandene Infrastruktur zu beeinträchtigen oder teuere Alternativen zu benötigen, wie das Virtual Private Network (VPN).

aXes beinhaltet einen integrierten Anwendungsserver mit einem eigenen schnellen, sicheren HTTP Server für die IBM iSeries (AS/400), mit einer integrierten Technologie zur Beschleunigung der Webseiten. Durch die Verwendung des aXes Anwendungsservers kann die Last reduziert werden, die Antwortzeit kann verkürzt werden und die Servicequalität kann einfacher vorhergesagt und gesteuert werden.

Firewalls, Caching und Proxy Servers

Firewalls werden in einem Unternehmen oder einer SP-Umgebung als eine Sicherheitsvorkehrung eingesetzt, um den Zugriff auf Server in einem Netzwerk zu kontrollieren. Wenn Client und aXes Anwendungsserver sich hinter derselben Firewall befinden, kann sich der Client direkt mit dem aXes Anwendungsserver verbinden. Das wird der Fall sein, wenn sich der Client im selben Intranet wie der aXes Anwendungsserver befindet, ein Internetzugangsverfahren (wie VPN) verwendet oder sich zur Kommunikation einwählt – diese Verfahren sind sich wie eine lokale Verbindung. Alternativ dazu kann sich der Client außerhalb der Firewall befinden. In diesem Fall verbindet sich der Client direkt über das Internet durch die Firewall zum aXes Anwendungsserver oder wird durch die Firewall am eigenen Standort hindurch geleitet, bevor er sich über das Internet zum aXes Anwendungsserver verbinden kann.

Der aXes Anwendungsserver erzeugt explicit HTTP Header die einen HTTP 1.1 Proxy Server anweisen keine aXes Transaktionen zwischenzuspeichern. Proxy Server legen keine aXes Transaktionen im Cache ab, da jede Transaktion eine eigene URL besitzt. Andere HTTP Transaktionen des aXes Anwendungsservers werden normal durch einen Proxy Server im Cache gespeichert.

Für weitere Firewall und Proxy Server Informationen besuchen Sie bitte:

aXes ports

aXes Anwendungsserver verwenden HTTP oder HTTPS Protokolle. Jede dieser Verbindungsarten wird von einem Prozess bedient, der einen Port auf dem aXes Anwendungsserver „abhört”. Die standardmäßigen Ports sind:

  • Port 80 HTTP
  • Port 443 HTTPS

Protokolle können oder können auch nicht verschlüsselt werden, je nach den Sicherheitseinstellungen für den Anwender.

Benutzer greifen normalerweise auf Anwendungen über den aXes Anwendungsserver zu, indem Sie die URL für den Server im Browser eingeben, zum Beispiel https://www.axeslive.com/. Die erste Verbindung zum aXes Anwendungsserver geschieht entweder über HTTP oder HTTPS. Der aXes Anwendungsserver antwortet auf die HTTP oder HTTPS Anforderung und zeigt dem Benutzer einen Anmeldeschirm an. Der Datenverkehr wird erzeugt, sobald der Benutzer sich anmeldet, die Anwendungen startet und auf die Anwendungen reagiert.

Um in einer sicheren Umgebung zu laufen, ist es wünschenswert den Internetverkehr zu verschlüsseln. Es ist deshalb wahrscheinlich, dass HTTPS verwendet werden wird. Wenn der aXes Anwendungsserver (HTTPS) den Port 443 abhört, dann muss dieser Port für eingehenden Verkehr zugänglich sein. Das heißt, dass der Port durch die Firewall auf der Seite des aXes Application Servers zugänglich sein muss. Wenn sich auf der Client-Seite ebenfalls eine Firewall oder Proxy Server befindet, muss Datenverkehr über Port 443 erlaubt sein.

Wenn sich der Client in einer sicheren Umgebung befindet, kann es sein, dass die Firewall und/oder der Proxy Server auf der Client-Seite nur ausgehenden Datenverkehr zum Port 443 des Zielservers zulässt. In solchen Situationen muss der Datenverkehr über Port 443 kommunizieren.

aXes und Telnet

aXes verwendet kein Telnet. Weder das Telnet Protokoll noch der IBM i Telnet Server müssen laufen, wenn aXes läuft.

Die meisten Telnet-basierten Lösungen (Rich oder Thin Client) öffnen zwei Ports (Port 23 und Port 992). Der aXes Anwendungsserver wartet jedoch standardmäßig am Port für HTTP Anwendungen (Port 80) oder an einem spezifizierten Port.

Eine Frage, die häufig gestellt wird, ist: “Öffnet die Verwendung von Telnet oder Telnet-basierten Gateway Lösungen, die IBM i Anwendungen im Web unterstützen, Sicherheitslücken zum Server?“ Besonders relevant ist dies, wenn einige Produkte eine Kombination von Ports öffnet, um Session-Zugriff, ODBC Konnektivität, Java Client Access und/oder direkten Zugriff auf Sockets für Serveranwendungen und Daten erlauben.

Die Antwort ist nein, denn selbst wenn sich ein Hacker oder Eindringling erfolgreich mit einer offenen Telnet Session verbinden könnte (und einen Anmeldeschirm erhält), müssen sie immer noch das Benutzer-Login und die Passwortkombination wissen, bevor sie Zugriff auf den Server erhalten können. Korrekte IBM i Sicherheitsverfahren sollten eingeführt sein, um die Anzahl der erfolglosen Anmeldeversuche zu beschränken und um den Einbruchsversuch nachverfolgen zu können.

Telnet-basierte Methoden für den Serverzugriff ermöglichen Hacker die Art des Systems zu ermitteln, wenn sie eine Session aufbauen können, weil ihnen die Server-Anmeldung angezeigt wird.

Um die Informationsmenge für einen potenziellen Hacker auf ein Minimum zu beschränken, gibt es Standardregeln. aXes verbessert die Telnet-basierte Methode indem:

  • Kein Telnet verwendet wird (in der Tat kann der Telnet Server deaktiviert werden ohne aXes zu beeinträchtigen)
  • Nie der Sign-on-Schirm des Servers angezeigt wird
  • Die User ID und das Passwort (auch wenn SSL nicht verwendet wird ) immer verschlüsselt werden
  • Die HTTP Ports statt der Telnet Ports verwendet werden

aXes Sicherheitsmaßregeln

Sicherheit ist ein integraler Bestandteil der aXes Suite und wurde entwickelt, um Ihre Daten und Anwendungen zu schützen, während diese Anwendungen für remote Anwender über das Internet mit einem Browser zur Verfügung stehen. aXes unterstützt eine Vielzahl von Implementationsarten, jede für unterschiedliche Skalierbarkeits- und Leistungsstufen gedacht, ohne Beeinträchtigung der Sicherheit. aXes berücksichtigt folgende Sicherheitsbedenken:

  • aXes unterstützt die IBM i Sicherheit-und Authentifizierungsmechanismen bis und einschließlich der höchsten Sicherheitsstufe (Level 50).
  • Anwenderidentifikation und Passworte werden vor der Übertragung verschlüsselt und können nicht im Cache des Browsers abgelegt werden.
  • aXes unterstützt die Anmeldung von spezifischen IP Adressen.
  • aXes unterstützt die Anmeldung von spezifischem Gerätenamen.
  • aXes bietet Shadowing von User Sessions auf dem Server – ein Service der von Administratoren verwendet wird, um die Aktivität von Personen zu untersuchen, die aXes in Echtzeit verwenden.
  • aXes Anwendungsserver unterstützen sowohl Secure Sockets Layer (SSL) und als auch Transport Layer Security (TLS) Protokolle, die eine sichere Authentifizierung, Verschlüsselung, Non-Repudiation und VPN Technologien ermöglichen. Sowohl SSL als auch VPNs halten Lauscher vom Verfolgen und Abfangen des Datenverkehrs zwischen Browser und dem Server ab.

Der Datenverkehr zwischen Browser und aXes Anwendungsserver wird komprimiert (GZIP), was zwei wichtigste Vorteile bietet:

  • Der Verkehr ist schwerer mit Sniffern zu überwachen, und
  • bei der Benutzung von SSL oder VPN Technologien wird die zwischen Server und Browser zu übertragende Datenmenge vor der Verschlüsselung komprimiert

Bei der Verwendung von SSL oder VPN Technologien führt die Komprimierung des Datenverkehrs zu erheblichen Einsparungen hinsichtlich Bandbreiten und CPU-Belastung.

aXes Anwendungsserver sichert Webseiten durch die Anforderung spezifischer Lese- (*R) und Ausführungsberechtigungen (*X) Autorität für die eigentlichen Serverfiles. Es sichert den Zugriff auf Serververzeichnisse mit Zugriffskontrolllisten.