NIS2-Konformität & Informationssicherheitsrichtlinie
Sarama CRM-Plattform
Betreiberin: Angad Manik Beratung für Strategie und Projekte, Rebgasse 53, 4058 Basel, Schweiz
Verantwortliche Person: Angad Bank (ehemals Manik), impact@angad.swiss
Plattform: sarama.angad.swiss
Stand: 11. März 2026
1. Zweck und Geltungsbereich
Diese Informationssicherheitsrichtlinie dokumentiert die Sicherheitsmassnahmen und Verfahren zur Vorfallreaktion der Sarama CRM-Plattform in Übereinstimmung mit der Richtlinie (EU) 2022/2555 (NIS2-Richtlinie), die am 16. Januar 2023 in Kraft trat und von den EU-Mitgliedstaaten bis zum 17. Oktober 2024 umzusetzen war.
Obwohl die Angad Manik Beratung für Strategie und Projekte ein Schweizer Unternehmen ist und NIS2 nicht direkt unterliegt, wenden wir NIS2-konforme Sicherheitspraktiken an, weil:
- Wir Kunden in der EU bedienen, die NIS2 unterliegen können;
- NIS2 Art. 21 von Unternehmen verlangt, ihre Lieferketten abzusichern, einschliesslich Anbietern ausserhalb der EU;
- Die Anwendung von NIS2-Standards Sorgfalt demonstriert und die Compliance unserer Kunden unterstützt.
Diese Richtlinie deckt die Sarama CRM-Plattform und alle an ihrem Betrieb beteiligten Systeme, Daten und Prozesse ab.
2. Governance und Verantwortlichkeit
2.1 Managementverantwortung (NIS2 Art. 20)
- Verantwortliche Person: Angad Bank (ehemals Manik) (Einzelunternehmer) ist für die Informationssicherheit verantwortlich und genehmigt alle Sicherheitsrichtlinien.
- Sicherheitsüberprüfungen werden regelmässig und nach jedem bedeutenden Vorfall oder Architekturänderung durchgeführt.
- Diese Richtlinie wird mindestens jährlich überprüft und aktualisiert.
2.2 Risikomanagement-Ansatz (NIS2 Art. 21(1))
Wir verfolgen einen risikobasierten Ansatz für die Sicherheit, verhältnismässig zu unserer Grösse, der Art unserer Dienste und den potenziellen Auswirkungen von Vorfällen auf unsere Kunden.
3. Risikomanagement-Massnahmen (NIS2 Art. 21(2))
3.1 Risikobewertung und Richtlinien (Art. 21(2)(a))
Risikoregister (identifizierte Hauptrisiken):
| Risiko | Wahrscheinlichkeit | Auswirkung | Minderung |
|---|---|---|---|
| Unbefugter Datenbankzugriff | Mittel | Kritisch | RLS, verschlüsselte Zugangsdaten, Org-Isolation |
| API-Schlüssel-Kompromittierung (Kundenschlüssel) | Mittel | Hoch | AES-256-GCM-Verschlüsselung, Rotationserinnerungen |
| OAuth-Token-Diebstahl | Niedrig | Hoch | Supabase Vault-Verschlüsselung, Token-Widerruf |
| XSS / Injection-Angriffe | Mittel | Hoch | DOMPurify, parametrisierte Abfragen, CSP |
| Supabase-Infrastrukturbruch | Niedrig | Kritisch | Schweizer Hosting, Verschlüsselung im Ruhezustand, Backup |
| DDoS auf öffentliche Endpunkte | Mittel | Mittel | Ratenbegrenzung, Supabase Edge-Schutz |
| Lieferketten-Kompromittierung (npm) | Niedrig | Hoch | Abhängigkeitsprüfung, Lock-Dateien |
| Phishing gegen Plattformnutzer | Mittel | Mittel | OTP-basierte Auth (keine Passwörter zum Phishen) |
3.2 Vorfallbehandlung (Art. 21(2)(b))
Siehe Abschnitt 5 (Vorfallreaktionsplan).
3.3 Geschäftskontinuität (Art. 21(2)(c))
- Datenbank-Backups: Verwaltet von Supabase (tägliche automatische Backups, Point-in-Time-Recovery für Pro-Pläne).
- Infrastruktur: Supabase Zürich-Region mit AWS-Infrastruktur.
- Datenexport: Kunden können jederzeit einen vollständigen Datenexport anfordern.
- Wiederherstellungsziel: Dienst innerhalb von 24 Stunden nach einem schwerwiegenden Vorfall wiederherstellen.
3.4 Lieferkettensicherheit (Art. 21(2)(d))
Unterauftragsbearbeiter und deren Sicherheitsniveau:
| Lieferant | Dienst | Sicherheitsstandards | Datenstandort |
|---|---|---|---|
| Supabase | Datenbank, Auth, Speicher, Edge Functions | SOC 2 Type II, verschlüsselt im Ruhezustand (AES-256), TLS | Zürich, CH |
| Stripe | Zahlungsabwicklung | PCI DSS Level 1, SOC 2 | USA (EU-US DPF) |
| Anthropic | KI-Modelle | SOC 2, Daten nicht für Training verwendet | USA (SVK) |
| OpenAI | KI-Modelle | SOC 2, Enterprise-Datenverarbeitung | USA (SVK) |
| Google Cloud | KI-Modelle (Gemini) | ISO 27001, SOC 2 | USA/EU |
| Analytics (einwilligungsgestützt) | SOC 2, ISO 27001 | USA/EU | |
| Cloudflare | Turnstile CAPTCHA | SOC 2, ISO 27001 | USA/EU (Anycast) |
3.5 Sicherheit in Entwicklung und Wartung (Art. 21(2)(e))
- Schwachstellenmanagement: Abhängigkeiten vor Updates überprüft. Bekannte CVEs verfolgt.
- Sichere Programmierung: Parametrisierte Abfragen (via Supabase Client), Input-Bereinigung (DOMPurify), Output-Encoding.
- Code Review: Alle Änderungen vor der Bereitstellung geprüft.
- OWASP Top 10: In der Anwendung adressiert:
- A01 Broken Access Control → Row-Level Security (RLS) auf allen Tabellen
- A02 Kryptographische Fehler → AES-256-GCM, TLS 1.2+
- A03 Injection → Parametrisierte Abfragen, kein rohes SQL von Benutzereingaben
- A05 Sicherheits-Fehlkonfiguration → CSP-Header, keine CORS-Wildcard
- A07 XSS → DOMPurify für HTML-Rendering
- A09 Logging → Audit-Log für alle Datenoperationen
3.6 Wirksamkeitsbewertung (Art. 21(2)(f))
- Sicherheitsmassnahmen werden nach jeder wesentlichen Änderung oder jedem Vorfall bewertet.
- Penetrationstests und Red-Team-Übungen werden regelmässig durchgeführt.
- Ergebnisse werden dokumentiert und mit verfolgten Zeitplänen behoben.
3.7 Cybersicherheitsschulung (Art. 21(2)(g))
- Die verantwortliche Person hält ihr Wissen über Cybersicherheitsbedrohungen und Best Practices aktuell.
- Sicherheitsbewusstsein ist in die operativen Verfahren integriert.
3.8 Kryptographie (Art. 21(2)(h))
| Anlage | Verschlüsselung | Standard |
|---|---|---|
| API-Schlüssel (KI-Anbieter) | AES-256-GCM | NIST SP 800-38D |
| OAuth-Tokens (E-Mail/Kalender) | Supabase Vault | Envelope-Verschlüsselung |
| Daten bei Übertragung | TLS 1.2+ | IETF RFC 5246+ |
| Daten im Ruhezustand (Datenbank) | AES-256 (Supabase/AWS) | Infrastrukturverwaltet |
| Abmelde-Tokens | HMAC-SHA256 | RFC 2104 |
| Verschlüsselungsschlüssel | Supabase Secret (ENCRYPTION_KEY) | Rotation bei Kompromittierung |
3.9 Zugriffskontrolle und Asset-Management (Art. 21(2)(i))
Authentifizierung:
- OTP-basiert (E-Mail-Einmalpasswort) — keine gespeicherten Passwörter.
- Kein Passwort-Wiederverwendungs-, Phishing- oder Brute-Force-Risiko.
Autorisierung:
- Isolation auf Organisationsebene via Row-Level Security.
- Rollenbasierte Zugriffskontrolle innerhalb von Organisationen (Owner, Admin, Member).
- Kontoebenen-Rollen (Owner, SDR, AE, CSM, SE, Member) mit granularen Berechtigungen.
- Mitgliedschaftsänderungen nur über RPCs (
INSERT-Policy:WITH CHECK (false)).
3.10 Multi-Faktor-Authentifizierung (Art. 21(2)(j))
- Aktuell: OTP-basierte Authentifizierung bietet einen starken Faktor (Besitz des E-Mail-Kontos).
- MFA über TOTP oder Hardware-Schlüssel ist auf der Roadmap für erhöhte Sicherheit.
4. Sicherheit öffentlicher Endpunkte
Die Plattform stellt öffentliche (nicht authentifizierte) Endpunkte für Formulare und E-Mail-Tracking bereit:
| Endpunkt | Zweck | Sicherheitsmassnahmen |
|---|---|---|
form-loader | Formulardefinitionen laden | Kein JWT erforderlich; CORS auf erlaubte Domänen beschränkt |
form-submit | Formulareingaben annehmen | Ratenlimit: 5/Min/IP/Formular; CORS beschränkt |
form-connect | Externe Formularintegration | Ratenlimit: 10/Min/IP; Org-spezifische Domänenvalidierung |
track-open | E-Mail-Öffnungstracking | Tracking-Pixel; IP-Filterung für Apple MPP |
track-click | E-Mail-Klicktracking | 302-Weiterleitung; keine Datenexposition |
process-unsubscribe | E-Mail-Abmeldung | HMAC-SHA256-Tokenvalidierung; keine Klartext-IDs |
assessment-chat | Öffentlicher Assessment-Chat | Keine CORS-Wildcard; dynamische Domänenvalidierung |
5. Vorfallreaktionsplan (NIS2 Art. 21(2)(b), Art. 23)
5.1 Vorfallklassifizierung
| Schweregrad | Beschreibung | Beispiel | Reaktionszeit |
|---|---|---|---|
| Kritisch | Datenschutzverletzung, Systemkompromittierung, Totalausfall | Datenbankbruch, Verschlüsselungsschlüssel-Leak | Sofort (< 1 Stunde) |
| Hoch | Teilweise Datenexposition, erhebliche Beeinträchtigung | API-Schlüssel-Exposition, RLS-Umgehung | < 4 Stunden |
| Mittel | Begrenzte Auswirkung, einzelner Mandant betroffen | Datenproblem einer einzelnen Org, Edge-Function-Fehler | < 24 Stunden |
| Niedrig | Geringfügiges Problem, keine Datenexposition | UI-Bug, nicht-sensibler Log-Leak | < 72 Stunden |
5.2 Schritte der Vorfallreaktion
- Erkennung & Triage (0–1 Stunde) — Umfang, betroffene Daten und betroffene Kunden identifizieren. Schweregrad gemäss obiger Tabelle klassifizieren.
- Eindämmung (1–4 Stunden) — Betroffene Systeme oder Konten isolieren. Kompromittierte Zugangsdaten widerrufen. Betroffene Endpunkte bei Bedarf deaktivieren.
- Benachrichtigung (innerhalb von 24 Stunden bei bedeutenden Vorfällen) — Betroffene Kunden per E-Mail benachrichtigen. Bei Datenschutzverletzungen: Meldung innerhalb von 72 Stunden gemäss DSGVO Art. 33. Bei NIS2-relevanten Vorfällen: CSIRT innerhalb von 24 Stunden (Frühwarnung), vollständiger Bericht innerhalb von 72 Stunden.
- Beseitigung & Wiederherstellung (1–7 Tage) — Ursachenanalyse. Schwachstellen beheben. Bei Bedarf aus Backups wiederherstellen. API-Schlüsselrotation für betroffene Kunden anordnen.
- Post-Incident Review (innerhalb von 30 Tagen) — Lessons Learned dokumentieren. Risikoregister aktualisieren. Präventivmassnahmen umsetzen. Diese Richtlinie bei Bedarf aktualisieren.
5.3 NIS2-Meldefristen (Art. 23)
| Frist | Anforderung |
|---|---|
| 24 Stunden | Frühwarnung an das zuständige CSIRT |
| 72 Stunden | Vollständige Vorfallmeldung mit Erstbewertung |
| 1 Monat | Abschlussbericht mit Ursache, Auswirkung und Behebung |
6. Compliance-Mapping
| NIS2-Artikel | Anforderung | Sarama-Umsetzung |
|---|---|---|
| Art. 20 | Governance | Verantwortung des Einzelunternehmers; dokumentierte Richtlinie |
| Art. 21(2)(a) | Risikoanalyse | Risikoregister (Abschnitt 3.1) |
| Art. 21(2)(b) | Vorfallbehandlung | Vorfallreaktionsplan (Abschnitt 5) |
| Art. 21(2)(c) | Geschäftskontinuität | Supabase-Backups, Exportmöglichkeit |
| Art. 21(2)(d) | Lieferkette | Unterauftragsbearbeiter-Bewertung (Abschnitt 3.4) |
| Art. 21(2)(e) | Sichere Entwicklung | OWASP, RLS, Input-Bereinigung |
| Art. 21(2)(f) | Wirksamkeitsbewertung | Regelmässige Sicherheitsaudits |
| Art. 21(2)(g) | Schulung | Fortlaufende Weiterbildung |
| Art. 21(2)(h) | Kryptographie | AES-256-GCM, TLS, HMAC (Abschnitt 3.8) |
| Art. 21(2)(i) | Zugriffskontrolle | RLS, RBAC, OTP-Auth (Abschnitt 3.9) |
| Art. 21(2)(j) | MFA | OTP (geplant: TOTP/Hardware-Schlüssel) |
| Art. 23 | Vorfallmeldung | 24h/72h/1Mo-Zeitplan (Abschnitt 5.3) |
7. Überprüfung und Aktualisierung
Diese Richtlinie wird überprüft:
- Mindestens jährlich;
- Nach jedem bedeutenden Sicherheitsvorfall;
- Nach grösseren Architekturänderungen;
- Wenn nationale NIS2-Umsetzungsgesetze aktualisiert werden.
8. Kontakt
Für Sicherheitsanfragen oder zur Meldung einer Schwachstelle:
Angad Manik Beratung für Strategie und Projekte
Angad Bank (ehemals Manik)
Rebgasse 53, 4058 Basel, Schweiz
E-Mail: impact@angad.swiss
Für dringende Sicherheitsvorfälle, E-Mail mit Betreff: [SICHERHEITSVORFALL] — Sarama CRM
Letzte Aktualisierung: 28. März 2026