Sicherheit: Anwendungen zur Laufzeit schĂĽtzen
Runtime Application Self-Protection (RASP) ist ein neuer Ansatz zum Schutz von meist Java-Anwendungen. Die aktuelle iX stellt drei Ansätze vor.
Unter dem Namen Runtime Application Self-Protection (RASP) versprechen viele Anbieter von Sicherheitsdiensten ihren Kunden neue Schutzfunktionen, die Angriffe auf ihre Anwendungen zur Laufzeit abwehren können. Wie Maik Schäfer in einem Artikel der aktuellen iX 3/2018 erklärt, umfasst die RASP eigentlich drei unterschiedliche Ansätze, um meist Java-Anwendungen in Unternehmen zu bewachen.
Eine Option ist das direkte Integrieren der RASP-Funktionen in den Quellcode der Anwendung. Anbieter stellen hierfür ein SDK bereit, mit dem ihre Kunden kritische Stellen des Programms mit einem API-Aufruf überprüfen können. Zuvor sammelt der Entwickler die nötigen Anwendungsdaten, damit er zwischen dem Normalfall und dem Angriff unterscheiden kann.
Will oder kann der Kunde seinen Quellcode jedoch nicht mehr anpassen, gibt es ebenfalls Dienste, die sich als Agent nachträglich zur Laufzeit einklinken. Meist greifen die Entwickler auf die Java-Instrumentation-Schnittstelle zurück, dank der sie eigene Programmlogik ergänzen können. Zum einen greifen diese Dienste auf gängige Frameworks für Webanwendungen zu, der Kunde kann aber in manchen Fällen auch nutzerspezifische Anpassungen anfragen.
Als dritte Option kommen Container hinzu. Auch bei ihnen muss der Kunde seinen Quellcode nicht extra anpassen. Hierbei kann der Dienst zum Beispiel seine Angriffserkennung in die JVM einfĂĽgen. Letztere interagiert mit allen intern verarbeiteten Informationen. Zuerst kann der Entwickler mit absichtlich kompromittierte Daten Auswirkungen eines Angriffs im Programm ĂĽberprĂĽfen, anschlieĂźend kann der Dienst kritische Stellen erkennen.
Wie die RASP-Ansätze zum Beispiel mit einem SQL-Injection-Angriff umgehen und welche Vor- und Nachteile sie bieten, finden Interessierte im Artikel.
Siehe dazu auch:
- Anwendungssicherheit: Selbstverteidigung zur Laufzeit, iX 3/2018, S. 103.
(fo)