Wie Finanzteams sichere Benutzerabläufe testen, ohne Kompromisse bei der Sicherheit einzugehen

Bei Finanzanwendungen sind die wichtigsten Aspekte – Authentifizierung, Zugriffskontrolle und sichere Arbeitsabläufe – auch am schwierigsten zu testen.

Dies sind keine optionalen Ebenen. Sie definieren, wie Benutzer mit der Anwendung interagieren.

Und sie bringen Einschränkungen mit sich, mit denen herkömmliche Testverfahren nicht immer gut umgehen können.

Sicherheit ist Teil der Benutzererfahrung

Der Anmeldevorgang in einer Finanzanwendung besteht nicht nur aus Benutzername und Passwort.

Dies kann biometrische Authentifizierung, Multi-Faktor-Authentifizierung, Sitzungsvalidierung und Prüfungen auf Geräteebene umfassen.

Jeder dieser Schritte kann sich je nach Gerät, Betriebssystem und Umgebung unterschiedlich verhalten.

Gleichzeitig werden viele Anwendungen über Unternehmenssysteme verteilt und unterliegen Richtlinien, die Einfluss auf ihren Betrieb haben.

Beim Testen muss all dies berücksichtigt werden, nicht nur, ob die zugrundeliegende Funktionalität funktioniert.

Warum Teams das Testen vereinfachen

In der Praxis passen viele Teams ihren Testansatz an, um die Komplexität zu bewältigen.

• Die Authentifizierung kann umgangen werden, um die Ausführung zu beschleunigen.
• Um Instabilität zu vermeiden, können Sicherheitsfunktionen deaktiviert werden.
• Um Funktionen zu isolieren, können separate Builds verwendet werden.

Diese Entscheidungen werden oft aus praktischen Gründen getroffen. Sie ermöglichen es, die Tests durchzuführen, ohne zusätzlichen Aufwand zu verursachen.

Sie ändern aber auch die Bedingungen, unter denen der Antrag validiert wird.

Ein erheblicher Teil der Testarbeit wird für die Fehleranalyse aufgewendet, anstatt Tests durchzuführen. Wenn die Tests die realen Bedingungen nicht widerspiegeln, wird diese Fehleranalyse noch schwieriger.

Die Rolle von Managed Environments (MDM)

Ein Bereich, der oft übersehen wird, ist das Testen in verwalteten Umgebungen.

Viele Finanzanwendungen werden über Mobile-Device-Management-Systeme wie Microsoft Intune oder VMware Workspace ONE bereitgestellt. Diese Systeme setzen Richtlinien durch, konfigurieren Geräte und kontrollieren den Zugriff.

Dies beeinflusst das Verhalten der Anwendung.

Beispielsweise können Zertifikate zur Authentifizierung erforderlich sein, Funktionen können aufgrund von Richtlinien eingeschränkt sein und Netzwerkkonfigurationen können von Standardeinstellungen abweichen.

Bei Tests außerhalb dieses Kontextes können diese Variationen übersehen werden.

In vielen Fällen basieren Testplattformen auf nicht verwalteten Geräten, die diese Einschränkungen nicht berücksichtigen. Daher wird Verhalten, das nur in verwalteten Umgebungen auftritt, vor der Veröffentlichung nicht validiert.

Das Testen gehärteter Anwendungen ist zu einer echten Herausforderung geworden.

Eine weitere Herausforderung, die bei Finanzanwendungen immer häufiger auftritt, ist das Testen von Software, die Laufzeitschutzmechanismen oder Verschleierungsmechanismen beinhaltet.

Diese Schutzmechanismen sollen Manipulationen, Reverse Engineering und unbefugten Zugriff verhindern und sind in vielen Finanzorganisationen vorgeschrieben.

Das Problem besteht darin, dass sie häufig die Interaktion der Testwerkzeuge mit der Anwendung beeinträchtigen.

Um dieses Problem zu umgehen, deaktivieren Teams möglicherweise Schutzmechanismen, verwenden spezielle Builds oder greifen auf eine teilweise Validierung zurück. Sobald die Schutzmechanismen jedoch entfernt sind, verhält sich die Anwendung nicht mehr wie im Produktivbetrieb.

Dadurch entsteht ein anderes Risiko, nämlich dass Probleme im Zusammenhang mit Sicherheitsebenen vor der Veröffentlichung nie validiert werden.

Da immer mehr Unternehmen die Anwendungshärtung als Teil ihrer Sicherheitsstrategie einsetzen, wird dies zu einer Standard-Einschränkung, die bei Sicherheitstests berücksichtigt werden muss.

Um genauer zu erfahren, wie diese Herausforderung in der Praxis bewältigt werden kann, siehe: Digital.ai Ich habe es in Automatisierte Tests treffen auf Anwendungshärtung: Lösung eines Problems DevSecOps Dilemma.

Wie ein realistischerer Ansatz aussieht

Ein effektiverer Ansatz konzentriert sich auf die Angleichung der Testbedingungen an die Produktionsbedingungen.

• Die Authentifizierungsabläufe werden bei ihrer Verwendung ausgeführt, einschließlich Biometrie und MFA.
• Die Anwendungen werden mit aktivierten Schutzmechanismen getestet, anstatt auf modifizierte oder unsichere Builds zurückzugreifen, die das Verhalten in der Produktionsumgebung nicht widerspiegeln.
• Die Geräte werden mit denselben Richtlinien und Einschränkungen konfiguriert, denen auch die Benutzer unterliegen, einschließlich der MDM-Steuerung.
• Die Tests werden auf verschiedenen Geräten und in unterschiedlichen Umgebungen durchgeführt, um die Variabilität zu erfassen.

Dies erhöht nicht unbedingt die Anzahl der Tests. Es verändert vielmehr, was diese Tests tatsächlich aussagen.

Warum dies die Entscheidungsfindung verbessert

Wenn Tests reale Bedingungen widerspiegeln, werden die Ergebnisse aussagekräftiger und handlungsrelevanter.

• Fehler sind leichter zu interpretieren, weil sie unter realistischen Szenarien auftreten, einschließlich gesicherter Datenflüsse und verwalteter Umgebungen.
• Die Untersuchungszeit verkürzt sich, da der Kontext bereits vorhanden ist.
• Release Entscheidungen können auf der Grundlage von Erkenntnissen getroffen werden, die dem Verhalten der Anwendung im Produktionsbetrieb entsprechen.

Die Verbesserung der Qualität dieses Signals hat einen direkten Einfluss darauf, wie schnell Teams Fehler erkennen und Release-Entscheidungen treffen können.

Ausgewogenheit zwischen Sicherheit und Testbarkeit

Oftmals herrscht die Annahme vor, dass das Testen sicherer Anwendungen Kompromisse erfordert.

Entweder wird die Sicherheit aufrechterhalten und die Tests werden eingeschränkt, oder die Tests werden durch die Reduzierung der Sicherheitsbeschränkungen erweitert.

In der Praxis wird dieser Zielkonflikt oft eher durch Einschränkungen bei den Werkzeugen oder der Umgebungskonfiguration als durch eine fundamentale Beschränkung hervorgerufen.

Das Testen sicherer, verwalteter und geschützter Anwendungen ist möglich, ohne deren Integrität zu beeinträchtigen – dies erfordert jedoch einen Ansatz, der berücksichtigt, wie diese Anwendungen tatsächlich in der Produktion laufen.

👉 Stoßen Sie bereits auf diese Herausforderungen? Sprechen Sie mit einem Testexperten um Ihre Umgebung zu erkunden und die nächsten Schritte zu planen. 

👉 Sie sind sich nicht sicher, wie sich Ihr aktueller Ansatz bewährt? Nehmen Sie die Bereitschaftsquiz für mobile Tests.