Trust Center
Eine Seite für die Fragen, die eine Sicherheitsprüfung stellt: Wer berührt die Daten, was schützt sie, und wo liegen sie.
Verzeichnis zuletzt aktualisiert: 2026-09-07
Alles hier ist aus Dateien des öffentlichen Repositorys geschrieben, und jede Aussage nennt das Dokument, das sie belegt. Wo etwas noch nicht zutrifft, sagt diese Seite es — ein Trust Center, das nur die beruhigende Hälfte veröffentlicht, ist weniger wert als gar keines.
Auf einen Blick
Ein Server
Die Anwendung, ihre MySQL-Datenbank und ihre Backups liegen alle auf einem einzigen Plesk-verwalteten Host. Kein Managed-Datenbankdienst, kein Objektspeicher und kein CDN hält eure Daten.
Kein Verkauf, keine Abrechnung
Die Plattform ist für Mentees und Mentoren kostenlos. Im Code gibt es keinen Zahlungsdienstleister, kein Werbenetzwerk und keinen Datenhändler.
Standardmäßig optional
KI, Kalender-Synchronisation, gehostetes Video, Push und sämtliche Analytics-Anbieter bleiben inaktiv, bis ein Betreiber ihre Umgebungsvariablen setzt — und die meisten brauchen zusätzlich die Zustimmung der einzelnen Person.
Keine Tracker im CRM
Analytics und Live-Chat werden ausschließlich aus der öffentlichen Hülle geladen, nie aus der Anwendung selbst. Ein Seitenaufruf im eingeloggten Bereich würde den Namen eines Mentees an einen Anbieter tragen — deshalb kann er dort nicht entstehen.
Kostenlos für Mentees und Mentoren. Nichts auf dieser Seite ist ein kostenpflichtiges Add-on.
Wer diese Instanz betreibt
Diese Instanz wird von Mehmet Erşahin betrieben. Die vollständigen Kontaktdaten stehen im Impressum.
Unterauftragsverarbeiter
Jeder Dritte, an den dieser Code Daten senden kann. Die Liste ist aus der Deployment-Konfigurationsdatei abgeleitet und kann dem Code daher nicht unbemerkt hinterherhinken.
| Unterauftragsverarbeiter | Zweck | Datenkategorien | Hosting-Standort | AVV / SCC-Grundlage | Pro Deployment optional |
|---|---|---|---|---|---|
| Plesk-managed server (operator)DATABASE_URL | Betreibt den Anwendungscontainer, die MySQL-Datenbank und die Backups. | Alle Anwendungsdaten: Konten, Profile, Lebensläufe, Interaktionsprotokolle, Nachrichten, hochgeladene Dokumente. | Der eine Server des Betreibers; das Land wird auf Anfrage genannt. | Direkter Vertrag zwischen Betreiber und Hosting-Anbieter. | Erforderlich |
| Primary SMTP relaySMTP_HOST, SMTP_USER, SMTP_FROM | Post, die einen Menschen erreichen muss: Adressbestätigung, Einladungen, Passwort-Reset, Nachrichtenbenachrichtigungen. | Name und E-Mail-Adresse der Empfängerin, Betreff und Text, Links mit signierten Tokens. | Vom Betreiber gewählt; die ausgelieferte Voreinstellung ist der eigene Mailserver des Deployments. | Direkter Vertrag mit dem gewählten Relay. | Erforderlich |
| Bulk SMTP relaySMTP_BULK_HOST, SMTP_BULK_FROM | Ein zweiter Ausgangskanal für Zusammenfassungen, Erinnerungen, Ankündigungen und Newsletter. | Dieselben Kategorien wie beim primären Relay, nur für nicht dringende Post. | Vom Betreiber gewählt; bewusst oft ein anderer Anbieter und eine andere Absenderdomain. | Direkter Vertrag mit diesem Relay. | Optional |
| AnthropicANTHROPIC_API_KEY | KI-gestütztes Lesen von Lebensläufen und die KI-Assistenzfunktionen. | Aus einem hochgeladenen Lebenslauf extrahierter Text und der darum gebaute Prompt. | Die API von Anthropic. | Kommerzielle Bedingungen von Anthropic, geschlossen vom Betreiber. | Optional + Einwilligung |
| Google CalendarGOOGLE_CLIENT_ID, GOOGLE_CALENDAR_ENABLED | Spiegeln von Terminen aus der App in den eigenen Google-Kalender einer Nutzerin. | Titel, Beschreibung, Beginn und Ende, Adressen der Teilnehmenden sowie die OAuth-Tokens dieser Nutzerin. | Google. | Google-API-Bedingungen, geschlossen vom Betreiber. | Optional + Einwilligung |
| 8x8 JaaSJAAS_APP_ID, JAAS_API_KEY_ID, JAAS_PRIVATE_KEY | Gehostete Videoräume für Eins-zu-eins-Termine. | Anzeigename, Raumkennung und der Live-Audio- und Videostream. | Die JaaS-Infrastruktur von 8x8. | 8x8-JaaS-Bedingungen, geschlossen vom Betreiber. | Optional |
| meet.jit.si (8x8) | Der Standard-Videoraum, wenn JaaS nicht konfiguriert ist, der Rückfallweg, wenn ein JaaS-Anruf nicht startet, und der Ort jedes Termins, sobald das monatliche JaaS-Teilnehmerkontingent aufgebraucht ist. | Anzeigename, Raumkennung und der Live-Audio- und Videostream. | Die öffentliche Instanz von 8x8. | Nur die Bedingungen eines öffentlichen Dienstes — kein Vertrag. | Erforderlich |
| Browser push servicesVAPID_PUBLIC_KEY, VAPID_PRIVATE_KEY | Hintergrundbenachrichtigungen für neue Nachrichten bei geschlossener App. Den konkreten Dienst wählt der Browser der abonnierenden Person, nicht wir. | Der vom Browser ausgestellte Push-Endpunkt, eine verschlüsselte Nutzlast und die Kontaktadresse, die den Absender ausweist. | Der Push-Dienst des Browserherstellers — Google, Mozilla oder Apple. | Keine: Das Protokoll bietet dem Absender keinen Vertragspartner. Nutzlasten sind auf die Schlüssel der abonnierenden Person verschlüsselt. | Optional + Einwilligung |
| Plausible AnalyticsNEXT_PUBLIC_PLAUSIBLE_DOMAIN | Messung von Seitenaufrufen ausschließlich auf öffentlichen Marketingseiten. Hinzu kommt ein anonymes Klickereignis, wenn ein Besucher die öffentliche Demo öffnet: die Position des Links auf der Seite und nichts über die Person. | Seiten-URL, Referrer, grobe Geräte- und Browserdaten. Ohne Cookies. | Vom Betreiber gewählt; Voreinstellung plausible.io, selbst hostbar. | AVV von Plausible, geschlossen vom Betreiber — beim Selbsthosten nicht nötig. | Optional + Einwilligung |
| PostHogNEXT_PUBLIC_POSTHOG_KEY | Messung von Seitenaufrufen ausschließlich auf öffentlichen Marketingseiten. Autocapture, Sitzungsaufzeichnung und lokale Speicherung sind im Code hart abgeschaltet. Hinzu kommt ein anonymes Klickereignis, wenn ein Besucher die öffentliche Demo öffnet: die Position des Links auf der Seite und nichts über die Person. | Seiten-URL, Referrer, grobe Geräte- und Browserdaten. | Vom Betreiber gewählt; die ausgelieferte Voreinstellung ist die EU-Region von PostHog. | AVV von PostHog, geschlossen vom Betreiber. | Optional + Einwilligung |
| Google Analytics 4NEXT_PUBLIC_GA4_MEASUREMENT_ID | Messung von Seitenaufrufen ausschließlich auf öffentlichen Marketingseiten, geladen mit IP-Anonymisierung. Hinzu kommt ein anonymes Klickereignis, wenn ein Besucher die öffentliche Demo öffnet: die Position des Links auf der Seite und nichts über die Person. | Seiten-URL, Referrer, gekürzte IP, grobe Geräte- und Browserdaten. | Google. | Google-Analytics-Bedingungen und Standardvertragsklauseln, geschlossen vom Betreiber. | Optional + Einwilligung |
| tawk.to | Das Live-Chat-Widget auf der öffentlichen Startseite. | Die IP-Adresse der Besucherin und alles, was sie in den Chat schreibt. | tawk.to. | Bedingungen von tawk.to, geschlossen vom Betreiber. | Optional + Einwilligung |
| GitHub Actions + ghcr.io | Continuous Integration, Container-Builds und die Registry, aus der der Server zieht. Lieferkette, nicht Anfrageverarbeitung. | Quellcode, Build-Protokolle und Container-Images. Keine personenbezogenen Daten von Endnutzenden. | Von GitHub gehostete Runner und Registry. | GitHub-Bedingungen, geschlossen vom Betreiber. | Erforderlich |
Maßnahmen
Die Kurzfassung der Sicherheitsübersicht. Jeder Punkt ist durch ein Dokument im Repository belegt.
Fail-closed-Autorisierung
Die Einschränkung läuft über eine einzige Funktion. Eine Rolle ohne eigene Regel bekommt 403 statt einer ungefilterten Abfrage — eine neue Rolle gewährt also nichts, bis jemand ihre Regeln schreibt. In CI durch Regressionstests abgesichert.
Sitzungen und Zwei-Faktor
bcrypt-Passwort-Hashing, JWT-Sitzungen, rollenbasierte Zwei-Faktor-Pflicht und „von allen Geräten abmelden“. Angemeldet bleiben ist keine längere Sitzung, sondern ein separates rotierendes, widerrufbares Gerätetoken.
Einwilligung vor allem Optionalen
Analytics und Live-Chat laden erst, wenn ein gespeicherter, versionierter Einwilligungsdatensatz es erlaubt. Ändert sich die Bedeutung einer Kategorie, steigt die Version — ein altes Ja deckt so nie stillschweigend einen neuen Anbieter ab.
Backups und ein geprobter Restore
Ein vollständiger Dump vor jedem Produktions-Deploy und täglich um 03:15 UTC, restriktive Dateirechte, eine automatische Lebendprüfung und eine Restore-Übung mit schriftlichem Protokoll.
Auf dem Server wird nichts kompiliert
Images entstehen auf gehosteten Runnern; der Server zieht sie nur, tauscht den Container und prüft dessen Gesundheit. Beitragende arbeiten mit synthetischen Daten, und jeder Pull Request bekommt eine eigene Datenbank, die beim Schließen gelöscht wird.
Geprüft — und die Lücken stehen da
Ein Sicherheitsaudit nach Rolle × Endpunkt und ein triagierter Bericht der statischen Analyse. Die sauber getesteten Bereiche sind festgehalten, sodass ein Bruch als Regression zählt — und die nie untersuchten Bereiche sind ebenso ausdrücklich aufgeführt.
Was noch nicht zutrifft
Nur die beruhigende Hälfte zu veröffentlichen, würde den Rest entwerten.
- Mandantentrennung wird in der Produktion nicht erzwungen. Organisationsmodell, mandantenbezogene Tarife, Branding und SSO sind live, und die Durchsetzungslogik ist geschrieben — aber der Schalter dafür ist aus und der Rollout je Route läuft noch: die laufende Anwendung ist faktisch einmandantig, und heute filtert nichts nach Organisation.
- Produktion, die gemeinsame Vorschau und jede Pull-Request-Umgebung laufen auf einem Host. Es sind getrennte Container mit getrennten Datenbanken, nicht getrennte Maschinen.
- Für dieses Deployment gibt es weder einen SOC-2-Bericht noch ein ISO-27001-Zertifikat. Stattdessen gibt es ein öffentliches Repository, dieses Verzeichnis und interne Auditdokumente, die ihr lesen könnt.
- Web Push hat keinen Vertragspartner — das Protokoll bietet dem Absender keinen. Nutzlasten sind auf die Schlüssel der abonnierenden Person verschlüsselt, und die Funktion bleibt aus, solange kein Schlüsselpaar konfiguriert ist und die Person sie nicht selbst einschaltet.
Hosting und Datenstandort
Anwendung, Datenbank und Backups laufen auf einem Plesk-verwalteten Server. Dieses Repository nennt kein Hosting-Land und wird es nicht tun: Das Projekt ist Open Source und andere betreiben eigene Instanzen — eine im Quellcode festgeschriebene Region wäre eine Behauptung über den Server anderer Leute. Der Betreiber dieses Deployments nennt den Standort auf Anfrage.
Was der Code festlegt und ihr deshalb ohne Nachfrage prüfen könnt: Die ausgelieferte PostHog-Voreinstellung ist die EU-Region, Plausible ist cookiefrei und selbst hostbar, und jeder andere Drittanbieterpfad bleibt inaktiv, bis ein Betreiber ihn einschaltet.
Die Standortantwort als letzte Instanz
InternshipCRM steht unter AGPL-3.0-or-later. Ihr dürft eine eigene Instanz betreiben, auf eurer eigenen Infrastruktur, in eurer eigenen Rechtsordnung, ohne jemanden zu fragen und ohne jemanden zu bezahlen. Das ist die stärkste Standortgarantie, die dieses Projekt geben kann, weil sie uns vollständig aus der Frage nimmt. Eine Dual-Lizenz ist beim Rechteinhaber Mehmet Erşahin erhältlich — eine natürliche Person, kein Unternehmen.
Die Quelle lesen
Die Langfassungen liegen im Repository, direkt neben dem Code, den sie beschreiben: