Sicherheit & Datenschutz bei Aveldra

Der Scan ändert nichts in deinem Tenant. Der Admin-Consent erteilt Aveldra aber auch Schreibrechte (vier Berechtigungen, siehe Liste). Aveldra nutzt sie nur, wenn du eine Aktion selbst auslöst oder eine Auto-Regel aktivierst. Auto-Regeln sind standardmäßig aus.

• Alle 16 Microsoft-Graph-Berechtigungen stehen unten mit Zweck: 12 lesende für Scan und Erkennung, 4 schreibende für Gegenmaßnahmen.
• Keine E-Mail- oder Dateiinhalte: Aveldra speichert Metadaten und Kontoangaben, die vollständige Liste steht unten.
• Aveldra speichert keine Microsoft-Zugriffstokens deiner Nutzer. Der Zugriff auf deinen Tenant läuft app-only über die Aveldra-App.
• Anmelden können standardmäßig nur Microsoft-Administratoren mit einer von drei Rollen (Globaler Administrator, Administrator für privilegierte Rollen, Sicherheitsadministrator), per Einladung aufgenommene Teammitglieder mit Lesezugriff und vom Aveldra-Support freigeschaltete Konten mit Admin-Rechten. Schreibende Aktionen verlangen eine dieser Microsoft-Admin-Rollen oder eine solche Freischaltung (Details unten).
• Mandantentrennung in der Anwendung: Jede Datenbankabfrage ist auf deinen Mandanten gefiltert und durch Tests abgesichert.
• Anwendung und Datenbank laufen in Frankfurt (Fly.io, Region fra). Einzelne Dienstleister verarbeiten Daten auch außerhalb der EU, siehe Sub-Prozessoren.
• Bestehende Audit-Einträge sind per Datenbank-Trigger gegen Änderungen gesperrt. Gelöscht wird nur nach Aufbewahrungsfrist oder auf DSGVO-Löschung.
• Übertragung nur über TLS/HTTPS. Tägliche, verschlüsselte Datenbank-Backups (AES-256) mit Off-Site-Kopie in der EU.
• Bei jeder Code-Änderung laufen SAST (Bandit), Secret-Scan (Gitleaks), Dependency-Audit sowie über 1.200 automatisierte Backend-Tests mit Coverage-Gate (mindestens 80 %) plus 75 Datenbank-Integrationstests gegen PostgreSQL.
• Konto und Daten löschst du als Administrator jederzeit sofort selbst in der App (Einstellungen → Konto löschen).
• Ein Incident-Response-Runbook ist dokumentiert (seit Juli 2026), seit 21.10.2026 führen wir ein Vorfallregister. Ausfälle veröffentlichen wir auf /sla.

Diese Grenzen gelten heute. Erledigte Punkte tragen wir hier mit Datum nach.

• Alarmierung: Beim Datenbank-Ausfall im Oktober 2026 hat sie nicht ausgelöst (Details auf /sla). Heartbeat- und Fehler-Monitoring sind vorhanden; die Alarmkette bauen wir neu auf und testen sie.bis Ende 2026
• Restore-Test: Die Wiederherstellung aus dem Backup ist noch nicht durch einen dokumentierten Restore-Test verifiziert.bis Ende 2026
• Löschung nach Kündigung: Vorgesehen ist eine Frist von 30 Tagen. Der automatische Löschjob greift wegen eines bekannten Fehlers derzeit nicht zuverlässig; bis zur Behebung löschen wir nach Kündigung und auf Anforderung manuell.Behebung geplant
• Incident Response: Das Runbook ist noch nicht geübt und kein formal freigegebener Prozess.geplant
• Audit-Log: Die Sperre ist derzeit von der Anwendungsrolle technisch aufhebbar. Eine Trennung der Datenbankrollen ist vorgesehen.geplant
• Externe Prüfung: Es gab interne Reviews, keinen externen Penetrationstest und keine Zertifizierung (SOC 2, ISO 27001).Pentest, sobald ein Kunde ihn anfordert

Die Anbindung erfolgt einmalig per Microsoft-Admin-Consent – ohne Agent oder lokale Installation. Mit diesem einen Consent erteilst du alle hier aufgeführten Berechtigungen, die lesenden und die schreibenden. Für Scan und Erkennung nutzt Aveldra die lesenden:

• Application.Read.AllApps und Service Principals mit ihren Berechtigungen auslesen und bewerten.
• Directory.Read.AllErteilte App-Zustimmungen und Mitglieder von Admin-Rollen lesen.
• AuditLog.Read.AllAnmelde- und Verzeichnisprotokolle auf verdächtige Aktivität prüfen (Anmeldeprotokolle nur mit Entra ID P1).
• User.Read.AllFunde dem betroffenen Konto zuordnen und Nutzer zählen.
• MailboxSettings.ReadPosteingangsregeln auf Weiterleitungen prüfen (nur Regel-Metadaten).
• Domain.Read.AllDomänen für den E-Mail-Sicherheits-Check (SPF, DMARC, DKIM) lesen.
• Policy.Read.AllConditional Access, Security Defaults und Autorisierungsrichtlinie für den Härtungsstatus lesen.
• RoleManagement.Read.DirectoryAdmin-Rollenzuweisungen lesen und neue privilegierte Rollen erkennen.
• Reports.Read.AllMFA-Registrierungsstatus der Nutzer lesen.
• SecurityAlert.Read.AllMicrosoft-Defender-Warnungen einbeziehen (mit passender Lizenz).
• IdentityRiskEvent.Read.AllRisiko-Erkennungen aus Entra ID Protection einbeziehen (Entra ID P2).
• IdentityRiskyUser.Read.AllAls riskant markierte Nutzer aus Entra ID Protection einbeziehen (Entra ID P2).

Neue Postfach-Weiterleitungsregeln erkennen wir über app-eigene Berechtigungen und lesen dabei ausschließlich Regel-Metadaten (Regelname, Zieladresse) – niemals Nachrichteninhalte.

Für Gegenmaßnahmen (z. B. App-Zugriff entziehen, Sitzungen widerrufen, Weiterleitungsregeln deaktivieren) und zum Aktivieren der Basis-Sicherheit (Microsoft Security Defaults) – auch über mehrere betreute Kunden hinweg – enthält derselbe Consent diese schreibenden Berechtigungen:

• Application.ReadWrite.AllEiner App den Zugriff entziehen und ihn wiederherstellen.
• User.ReadWrite.AllAnmeldesitzungen eines kompromittierten Kontos widerrufen.
• MailboxSettings.ReadWriteVerdächtige Weiterleitungsregeln deaktivieren und wieder aktivieren.
• Policy.ReadWrite.SecurityDefaultsMicrosoft Security Defaults (Basis-Sicherheit) aktivieren und zurücknehmen.

Diese Rechte sind hoch privilegiert. Prüfe sie so kritisch wie bei jeder anderen App, die du in einem Kundenmandanten zulässt.

Wer sich anmelden und Aktionen auslösen darf

Anmelden können standardmäßig nur Microsoft-365-Administratoren (Globaler Administrator, Administrator für privilegierte Rollen, Sicherheitsadministrator) und vom Aveldra-Support einzeln freigeschaltete Konten; die Einstellung „Nur Administratoren zulassen“ ist ab Werk an. Freigeschaltete Konten erhalten in Aveldra Admin-Rechte und können damit auch schreibende Aktionen auslösen. Per Einladung aufgenommene Mitglieder deines MSP-Teams können sich auch ohne Microsoft-Admin-Rolle anmelden, erhalten dann aber nur Lesezugriff (Readonly). Owner im MSP-Konto ist nur, wer sich mit einer Admin-Rolle anmeldet; schaltest du „Nur Administratoren zulassen“ ab, erhalten andere Konten deiner Organisation nur Lesezugriff.

Schreibende Aktionen lösen die Rollen Owner und Admin aus, und nur, wenn das auslösende Konto eine der genannten Microsoft-Admin-Rollen hat oder freigeschaltet ist. Aktionen über mehrere Kunden laufen geführt über Vorschau, Bestätigung, Audit-Log und Rückgängig-Funktion.

Was wir nicht tun

• Nachrichten- oder Dateiinhalte lesen, exportieren oder speichern
• Passwörter einsehen oder zurücksetzen
• Daten eines Kunden an andere Kunden weitergeben
• Änderungen an deinem Tenant vornehmen, die du nicht auslöst oder per Auto-Regel freigegeben hast

Wir speichern Metadaten und Kontoangaben, die für Erkennung, Bewertung und den Betrieb deines Kontos nötig sind:

• App-Name, App-ID und angeforderte Berechtigungen (Scopes)
• Risikobewertung und Status (akzeptiert / ignoriert)
• Anmelde-Metadaten: IP-Adresse, Land und Stadt der Anmeldung, Zeitpunkt, Risikostufe, Client-App
• Regel-Metadaten neuer Weiterleitungen (Regelname, Zieladresse)
• Kontonamen (UPN) der betroffenen Nutzer bei Funden und Namen privilegierter Konten im Härtungs-Check
• E-Mail-Adressen der Aveldra-Nutzer: Login- und Kontakt-E-Mail, Teammitglieder und handelnde Person im Audit-Log

Niemals gespeichert werden E-Mail- oder Dateiinhalte. Deine betreuten Mandanten sieht gebündelt nur dein eigenes MSP-Team.

Für klar abgegrenzte Zwecke setzen wir folgende Sub-Prozessoren ein, einige davon verarbeiten Daten auch in den USA:

• Fly.ioAnwendung & Datenbank (Compute, PostgreSQL)Frankfurt (EU)
• VercelFrontend-Hosting (App & Website)EU / USA
• BackblazeVerschlüsselte Off-Site-Datenbank-BackupsEU (Amsterdam)
• StripeZahlungsabwicklung & Abo-VerwaltungEU / USA
• ResendTransaktions- & Benachrichtigungs-E-MailsUSA
• SentryFehler-Monitoring (technische Diagnose)EU / USA
• GitHubQuellcode-Hosting und CI; täglicher Backup-Lauf, verschlüsselte Backup-Artefakte (90 Tage)USA

Übermittlungen in die USA werden durch geeignete Garantien abgesichert (EU-Standardvertragsklauseln bzw. EU-US Data Privacy Framework). Die jeweils aktuelle Sub-Prozessoren-Liste ist öffentlich einsehbar, ebenso das AVV-Muster unter /avv.

Den erteilten Zugriff entziehst du selbstständig im Microsoft-Admin-Center (Enterprise-Anwendungen) – sofort und ohne Rücksprache. Konto und Daten löschst du jederzeit sofort selbst in der App. Nach Kündigung ist die Löschung binnen 30 Tagen vorgesehen; solange der automatische Löschjob nicht zuverlässig greift, löschen wir manuell (siehe „Noch offen“). Auf Anforderung löschen wir auch vorher.

Ausgenommen sind Protokolle mandantenübergreifender Aktionen (3 Jahre), die Microsoft-Tenant-ID (damit die kostenlose Testphase einmalig bleibt) und gesetzliche Aufbewahrungspflichten. Kopien in den verschlüsselten Backups werden nicht einzeln gelöscht; sie laufen mit der Backup-Aufbewahrung aus: bei GitHub nach 90 Tagen; für die Off-Site-Kopie bei Backblaze wird die Aufbewahrungsregel eingerichtet.

Du hast eine Schwachstelle entdeckt oder eine Sicherheitsfrage? Schreib uns an kontakt@aveldra.de. Wir bearbeiten Meldungen vertraulich und schnellstmöglich.

Safe Harbor: Meldungen aus gutgläubiger Sicherheitsforschung (kein Datenabfluss, keine Störung des Betriebs, keine Zugriffe auf fremde Kundendaten) verfolgen wir nicht rechtlich. Maschinenlesbarer Kontakt: /.well-known/security.txt.