Was sollten Sie vor dem Launch prüfen?
Ihr Launch-Termin rückt näher. Das Produkt funktioniert, das Team hat die wichtigsten Abläufe getestet, und Ihre Kunden sind bereit, es zu nutzen. Eine Frage braucht aber noch eine klare Antwort: Welche Belege haben Sie dafür, dass deren Konten und Informationen geschützt sind?
Beginnen Sie mit Zugriffskontrollen, sensiblen Daten, Deployment-Einstellungen und einem Plan für den Fall, dass etwas schiefgeht. Testen Sie dann die Risiken, die für Ihr Produkt spezifisch sind, beheben Sie die relevanten Befunde und überprüfen Sie diese Korrekturen. Ein sinnvolles Security-Review liefert der Person, die die Freigabe erteilt, eine nachvollziehbare Entscheidungsgrundlage – einschließlich dessen, was noch offen ist.
Dies ist unsere praxisnahe Ausgangs-Checkliste für ein Produktteam. Passen Sie den Umfang an die Daten an, die Sie verarbeiten, an Ihre Architektur und an die Folgen eines Ausfalls.
1. Legen Sie fest, was das Review abdeckt
Listen Sie die Web-App, mobile Apps, APIs, Administrationswerkzeuge und externen Integrationen auf. Berücksichtigen Sie die verschiedenen Benutzerrollen und die Systeme, in denen Kundendaten liegen. Halten Sie fest, welches Release bewertet wird, damit sich die Befunde dem zuordnen lassen, was Sie tatsächlich ausliefern.
Vereinbaren Sie, wer Tests autorisiert, welche Umgebungen getestet werden dürfen und wann Tests abgebrochen werden müssen. Verwenden Sie wo immer möglich synthetische Kundendatensätze. Für Arbeiten in der Produktion vereinbaren Sie Schutzmaßnahmen mit den Verantwortlichen für den Dienst.
Nutzen Sie den OWASP ASVS, um überprüfbare Sicherheitsanforderungen für Anwendungen auszuwählen. Geben Sie Version und Umfang in der Bewertung an. So hat Ihr Team eine gemeinsame Referenz dafür, wofür Nachweise erforderlich sind.
2. Prüfen Sie, worauf jede Person zugreifen kann
Eine erfolgreiche Anmeldung ist erst der Anfang. Ein Kunde sollte nur seine eigenen Datensätze erreichen, und ein Support-Konto sollte nur die Berechtigungen haben, die seine Aufgaben erfordern. Setzen Sie diese Entscheidungen bei jeder relevanten Anfrage serverseitig durch – auch bei Anfragen, die direkt an eine API gehen.
OWASP empfiehlt das Prinzip der geringsten Rechte, standardmäßige Zugriffsverweigerung und die Prüfung von Berechtigungen bei jeder Anfrage. Bauen Sie die Prüfungen entlang der tatsächlichen Beziehungen in Ihrem Produkt auf. Siehe die Autorisierungsleitlinien von OWASP.
- Testen Sie den Zugriff zwischen zwei Kundenkonten und gegebenenfalls zwischen zwei Organisationen.
- Prüfen Sie, was passiert, nachdem sich eine Rolle ändert oder ein Konto deaktiviert wird.
- Prüfen Sie Administratorzugriffe und die Kontowiederherstellung mit derselben Sorgfalt wie die Anmeldung.
3. Verfolgen Sie sensible Daten durch das System
Verfolgen Sie eine typische Kundenanfrage vom Browser oder der App über die API und die Datenbank bis zum Drittanbieterdienst. Ermitteln Sie, wo personenbezogene Daten und Zugangsdaten gespeichert, kopiert oder protokolliert werden. Das macht das Review für Entwickler und Geschäftsverantwortliche oft leichter verständlich.
Halten Sie Service-Secrets aus Frontend-Bundles und der Versionsverwaltung heraus. Beschränken Sie die Berechtigungen jedes Zugangsdatums, trennen Sie Umgebungen und legen Sie fest, wie Zugangsdaten rotiert oder widerrufen werden. Wurde ein Zugangsdatum offengelegt, wird es nicht dadurch ungültig, dass Sie es aus der aktuellen Datei entfernen: Widerrufen oder rotieren Sie es und untersuchen Sie, wie es verwendet wurde. Die OWASP-Leitlinien zum Secrets Management behandeln den gesamten Lebenszyklus von Zugangsdaten.
4. Kombinieren Sie Scans mit einer gezielten Bewertung
Abhängigkeits- und Konfigurationsscans sind nützliche Informationsquellen. Prüfen Sie zusätzlich die Abläufe, in denen Ihr Produkt folgenreiche Entscheidungen trifft: eine Aktion genehmigen, ein Dokument teilen, die Kontoinhaberschaft ändern oder eine Zahlung annehmen. Ein Befund ist erst dann nützlich, wenn das Team seine Auswirkungen versteht und ihn sicher reproduzieren kann.
Der OWASP Web Security Testing Guide bietet strukturierte Testleitlinien. Vereinbaren Sie, welche Bereiche für Ihr Produkt gelten, und dokumentieren Sie Ausschlüsse. Nehmen Sie bei einem mobilen Produkt die mobilen Clients und ihre APIs in den Umfang auf, statt anzunehmen, dass ein Web-Review sie abdeckt.
Fordern Sie eine Management-Zusammenfassung, technische Nachweise, betroffene Komponenten, Empfehlungen zur Behebung und einen vereinbarten Nachtest an. Legen Sie Termine anhand des tatsächlichen Umfangs und des verfügbaren Testzugangs fest.
5. Stellen Sie sicher, dass jemand Vorfälle erkennt und reagiert
Legen Sie fest, welche Ereignisse Aufmerksamkeit erfordern, wer Alarme erhält und was diese Personen als Nächstes tun sollen. Nützliche Sicherheitsereignisse können verweigerte Zugriffe, Änderungen an Berechtigungen und administrative Aktionen sein. Schützen Sie die Protokolle selbst und vermeiden Sie es, Zugangsdaten oder unnötige personenbezogene Daten zu erfassen. Die Logging-Leitlinien von OWASP erläutern die Balance zwischen aussagekräftigen Nachweisen und sensiblen Daten.
Bestimmen Sie für Ihren Release-Plan die Person, die eine Integration deaktivieren, Zugriffe widerrufen oder ein Deployment zurückrollen kann. Üben Sie eine Wiederherstellung aus einem aktuellen Backup in einer geeigneten Testumgebung. Dokumentieren Sie das Ergebnis und wie lange die Wiederherstellung tatsächlich gedauert hat.
6. Überprüfen Sie Korrekturen und dokumentieren Sie die Release-Entscheidung
Weisen Sie jedem Befund einen Verantwortlichen und ein Zieldatum zu. Priorisieren Sie ihn anhand seines technischen Schweregrads sowie der Angriffsfläche, der betroffenen Daten und der Auswirkungen auf Kunden. Testen Sie die Änderung und das zugehörige Verhalten erneut, bevor Sie den Befund als behoben markieren.
Unser empfohlenes Release-Protokoll ist kurz: was bewertet wurde, welche Version getestet wurde, was behoben wurde, was offen bleibt und wer das verbleibende Risiko akzeptiert hat. Behalten Sie Monitoring und Review-Verantwortung auch nach dem Launch bei; ein Review ist ein Nachweis für einen bestimmten Umfang und Zeitpunkt.
Fragen, die Produktteams stellen
Garantiert ein Penetrationstest, dass ein Produkt sicher ist?
Nein. Er kann Schwachstellen innerhalb eines vereinbarten Umfangs und Testzeitraums aufdecken. Sichere Entwicklung, Wartung, Monitoring und Folgeprüfungen bleiben Teil des Produktbetriebs.
Macht ein VPN eine Anwendung sicher?
Ein VPN kann eine Netzwerkverbindung schützen und den Zugriff auf private Dienste beschränken. Ihre Anwendung braucht dennoch eigene Authentifizierung, Autorisierung, eine sichere Konfiguration und ein Review.
Wann sollten Sicherheitstests beginnen?
Beginnen Sie mit der Diskussion von Risiken, solange Architektur- und Produktentscheidungen noch getroffen werden. Planen Sie Tests mit klar definiertem Umfang früh genug, um Befunde vor dem Release beheben und nachtesten zu können, und überprüfen Sie den Umfang, wenn sich wichtige Funktionen oder Integrationen ändern.
Sie möchten einen klaren Überblick über die Risiken Ihres Produkts? Entdecken Sie die Sicherheits- und Testleistungen von CloudCoder. Wir verbinden technische Befunde mit praktischen Engineering-Lösungen und einem Plan, um sie zu überprüfen.
