Vertrauen und Sicherheit
Grenzen kennen.
Kontrollen überprüfen.
Bewerten Sie easyIGA danach, wie Sie es konkret betreiben werden, welche Zugriffsrechte es benötigt und welche Nachweise für das jeweilige Release vorliegen. Die Sicherheit dieser Website und die Sicherheit der Identitätssysteme von Kunden sind getrennte Geltungsbereiche.
Ihre Sicherheitsanforderungen besprechen Bereitstellungsoptionen vergleichen Schwachstelle melden
Standardmäßig selbst gehostet
easyIGA ist eine Ebene über midPoint, mit der die Fachbereiche arbeiten. midPoint ist open source. Im Standardmodell läuft der gesamte Stack auf Infrastruktur, die Ihre Organisation kontrolliert. Netzwerkkontrollen, Verschlüsselung, Backups, die Verwaltung von Zugriffsrechten, Monitoring und Wiederherstellung muss Ihr Team selbst bewerten und betreiben.
Supportzugriffe sollten ausdrücklich autorisiert, im Umfang begrenzt, protokolliert und wieder entzogen werden, sobald sie nicht mehr benötigt werden. Lassen Sie sich die tatsächliche technische Regelung in der Implementierungsvereinbarung bestätigen. Die Bezeichnung „selbst gehostet“ allein belegt nicht, dass jede Integration, jeder Endpunkt eines KI-Modells und jeder Supportkanal Daten innerhalb einer bestimmten Grenze hält.
EU-Hosting als Option
Für Organisationen ohne geeignete Infrastruktur ist auf Anfrage eine in der EU gehostete Bereitstellung verfügbar, die unser Team betreibt. Holen Sie vor Vertragsabschluss die tatsächlichen Hosting-Standorte, die Unterauftragsverarbeiter, die Regelungen für Supportzugriffe sowie die Bedingungen für Aufbewahrung, Backup, Wiederherstellung und Löschung ein. Datenstandort, operativer Zugriff und internationale Datenübermittlungen hängen zusammen, sind aber unterschiedliche Fragen.
Vereinbaren Sie schriftlich, wer für die Behandlung von Sicherheitsvorfällen, das Patching, die Verfügbarkeit und den Ausstieg zuständig ist. Ein Standort- oder Architekturdiagramm ersetzt nicht die vertraglichen Zusagen und die getesteten Kontrollen des Dienstes.
Konkretes Nachweispaket zur Sicherheit anfordern
| Bereich | Anzufordernde Nachweise |
|---|---|
| Zugriff und Authentifizierung | IdP-Integration, Berechtigungen, Rechte der Servicekonten, Geltungsbereich der MFA, Notfallzugriff und Sitzungskontrollen. |
| Software-Lieferkette | Release-Kennung, Abhängigkeitsinventar, Schwachstellenbefunde, Build-Herkunft (Provenance) und Signaturprüfung, sofern bereitgestellt. |
| Durchsetzung von Richtlinien | Tests auf unbefugte Anfragen, Rechteausweitung, kollidierende Rollen und direkte administrative Änderungen. |
| Audit-Nachweise | Erfasste Ereignisse, Korrelation, Umgang mit fehlenden Daten, Aufbewahrung, Zugriffsbeschränkungen und Schutz vor Veränderung. |
| Betrieb | Wiederherstellung aus Backups, Wiederherstellungsziele, Patch-Prozess, Zuständigkeiten bei Sicherheitsvorfällen und getestete Fehlerbehandlung. |
| Ausstieg | Exportformat, Übertragbarkeit der Konfiguration, Abhängigkeiten, fortbestehende Lizenzen und Regelungen zur Löschung. |
Grenzen des Bedrohungsmodells
Das Least-Privilege-Prinzip, Genehmigungsrichtlinien und unabhängige Aufzeichnungen können das Risiko verringern, aber keines davon schützt ein System vollständig vor einer Kompromittierung. Testen Sie die Berechtigungen, die der Ebene und ihren Servicekonten zur Verfügung stehen. Eine kompromittierte Komponente kann die Befugnisse missbrauchen, über die sie rechtmäßig verfügt. Eine Protokollierung an zwei Stellen begründet für sich genommen weder Manipulationssicherheit noch eine unabhängige Vertrauensbasis.
Governance ersetzt weder Endpunktschutz noch Netzwerkabwehr, IdP-Härtung, PAM-Sitzungskontrollen oder Anwendungssicherheit. Eine vollständige Prüfung umfasst diese Systeme und die Verbindungen zwischen ihnen. Überprüfen Sie die Ergebnisse in den Zielsystemen, statt davon auszugehen, dass eine genehmigte Anfrage eine wirksame Änderung garantiert.
Welche Dienste diese Website nutzt
easyiga.com nutzt Cloudflare für die Auslieferung und den Schutz des Dienstes. Kontaktformulare verwenden Cloudflare Turnstile und einen Worker; Resend stellt die daraus entstehende Nachricht an ein Microsoft-365-Postfach zu, und die Anfrage wird in einem CRM erfasst, das unser Team selbst auf einem Firmenserver in der EU betreibt. Cloudflare, Resend und Microsoft 365 sind Dienste Dritter, das CRM nicht.
Die optionale Webanalyse nutzt Google Analytics 4, das erst nach der Einwilligung in die Webanalyse geladen wird. Die Produktionskonfiguration aktiviert weder Bing UET noch eine KI-gestützte Verarbeitung von Besucheraktivitäten. Schriften und Bilddateien der Marke werden von dieser Website ausgeliefert; einige Artikelfotos werden von Unsplash geladen. Zwecke und Einstellungen finden Sie in der Datenschutzerklärung und der Cookie-Richtlinie.
Das Repository der Website führt vor dem konfigurierten Deployment-Job einen Build und automatisierte Tests aus. Diese Website-Pipeline ist kein Nachweis für die Sicherheitskontrollen oder den Release-Prozess der davon getrennten Anwendung easyIGA.
Sicherheitsbedenken melden
Sicherheitsschwachstellen in easyIGA oder auf dieser Website melden Sie an security@easyiga.com gemäß der unten stehenden Richtlinie zur Meldung von Schwachstellen; derselbe Kontakt ist maschinenlesbar unter /.well-known/security.txt veröffentlicht. Für ein Sicherheitsgespräch, das keine Schwachstellenmeldung ist (Fragebögen, Nachweispakete, Fragen zur Implementierung), nutzen Sie das Kontaktformular.
Hosting-Angaben zuletzt am 24. September 2026 geprüft. Übersicht der Website-Dienste zuletzt am 14. September 2026 geprüft. Für Sicherheitshinweise zu midPoint selbst nutzen Sie die Sicherheitsdokumentation von Evolveum.
Richtlinie zur Meldung von Schwachstellen
Der Website-Betreiber („wir“) möchte von einer Sicherheitsschwachstelle in easyIGA oder auf dieser Website erfahren, bevor es jemand anderes tut. Diese Richtlinie beschreibt, wie Sie eine Schwachstelle melden, wozu wir uns im Gegenzug verpflichten und worum wir Sie bitten. Sie orientiert sich an ISO/IEC 29147 (Offenlegung von Schwachstellen) und ISO/IEC 30111 (Behandlung von Schwachstellen) und ist die Strategie für die koordinierte Offenlegung von Schwachstellen, die Artikel 13 Absatz 8 der Cyberresilienz-Verordnung (Verordnung (EU) 2024/2847) von einem Hersteller verlangt. Version 1.0, gültig ab dem 14. September 2026.
Meldeweg
Senden Sie eine E-Mail an security@easyiga.com. Das Postfach wird von mehr als einer Person gelesen, sodass eine Meldung nicht von der Verfügbarkeit einer einzelnen Person abhängt. Der Kontakt ist außerdem unter /.well-known/security.txt im Format nach RFC 9116 veröffentlicht. Wir lesen Englisch und Slowakisch.
Hilfreich in einer Meldung sind: die betroffene Komponente (easyIGA, midPoint, Keycloak oder die Website) und ihre Version (bei easyIGA die Release-Kennung oder der Image-Digest), die Schritte zur Reproduktion, die beobachteten Auswirkungen und die Angabe, ob Sie Belege dafür haben, dass die Schwachstelle bereits ausgenutzt wird. Wenn Sie möchten, senden Sie zunächst eine nicht sensible Zusammenfassung. Wir bestätigen dann die Adresse und richten auf Wunsch einen verschlüsselten Kanal ein, bevor Sie Details zum Exploit senden. Einen PGP-Schlüssel veröffentlichen wir noch nicht; sobald wir das tun, erscheint sein Fingerabdruck hier und in security.txt.
Wozu wir uns verpflichten
- Eingangsbestätigung innerhalb von 5 Werktagen nach Erhalt (es gelten slowakische Werktage).
- Eine Statusmeldung innerhalb von 15 Werktagen, danach weitere Statusmeldungen im Verlauf des Falls bis zu seinem Abschluss.
- Kein zugesagter Termin für die Behebung. Wir sagen Ihnen, was wir wissen, auch wenn die Antwort lautet, dass die Behebung von einer vorgelagerten Komponente (Upstream) abhängt oder nicht geplant ist.
- Namentliche Nennung, falls Sie das wünschen, im Eintrag zur Behebung und unter „Danksagungen“ auf dieser Seite.
- Für Schwachstellenmeldungen zahlen wir keine finanziellen Belohnungen.
Koordinierte Offenlegung
Wir bitten um 90 Tage ab dem Datum Ihrer Meldung, bevor Sie Details veröffentlichen. Die Frist ist in beide Richtungen verhandelbar. Sie wird kürzer, wenn eine Behebung früher veröffentlicht wird oder die Schwachstelle bereits öffentlich bekannt ist, und länger, wenn die Behebung von einer vorgelagerten Komponente, vom Bereitstellungszyklus eines Kunden oder von einer gesetzlichen Pflicht abhängt. In diesem Fall teilen wir Ihnen die Gründe schriftlich mit. Wenn wir uns nicht mehr melden, gelten die 90 Tage trotzdem; nach ihrem Ablauf brauchen Sie für eine Veröffentlichung nicht unsere Erlaubnis.
Was wir mit einer bestätigten Meldung tun: Wir reproduzieren sie, bewerten den Schweregrad, beheben oder entschärfen die Schwachstelle, dokumentieren die Behebung im Produkt-Changelog unter „Security“ und teilen sie den Kunden mit dem Release mit. Wird eine Schwachstelle aktiv ausgenutzt, melden wir sie zusätzlich innerhalb der Fristen von Artikel 14 der Cyberresilienz-Verordnung (CRA) an die ENISA und das als Koordinator benannte nationale CSIRT, mit einer Frühwarnung innerhalb von 24 Stunden, nachdem wir davon Kenntnis erlangt haben. Diese Meldung ist unsere gesetzliche Pflicht und erfordert nichts von Ihnen.
Geltungsbereich
Im Geltungsbereich: die Anwendung easyIGA und ihre Bereitstellungsartefakte, wie sie von dem auf der Seite Über uns genannten Anbieter geliefert werden (Backend, Frontend, Integrationsschicht, Container-Images und Deployment-Skripte), sowie diese Website, easyiga.com, einschließlich ihrer Kontakt-API.
Komponenten Dritter haben eigene Verfahren zur Offenlegung, und Korrekturen liefern deren Maintainer. Melden Sie eine Schwachstelle in midPoint an Evolveum (security@evolveum.com, siehe die Sicherheitsdokumentation von Evolveum) und eine Schwachstelle in Keycloak an das Keycloak-Projekt (keycloak-security@googlegroups.com). Wenn Sie nicht sicher sind, welche Komponente betroffen ist, senden Sie die Meldung an uns; wir leiten sie weiter und bleiben beteiligt. Schwachstellen in den Diensten, auf die sich diese Website stützt (Cloudflare, Resend, Microsoft 365, Google Analytics, Unsplash), liegen in der Verantwortung dieser Anbieter.
Worum wir Sie bitten
- Testen Sie nur, wozu Sie berechtigt sind. easyIGA ist standardmäßig selbst gehostet. Eine Installation, die Sie im Internet finden, gehört daher einem Kunden. Testen Sie sie nicht. Melden Sie uns, was Sie beobachten können, und wir kontaktieren den Kunden.
- Belassen Sie es beim Nachweis. Lesen, kopieren, ändern oder löschen Sie keine Daten über das hinaus, was die Schwachstelle belegt, und greifen Sie nicht auf Konten oder Daten anderer Personen zu.
- Keine Denial-of-Service- oder Lasttests, kein Social Engineering, kein Phishing, kein physisches Eindringen und kein automatisiertes Scannen in einer Frequenz, die einen Dienst beeinträchtigt.
- Melden Sie zeitnah, halten Sie die Details bis zum Ende der Frist für die koordinierte Offenlegung vertraulich und löschen Sie alle erlangten Daten, sobald die Meldung abgeschlossen ist.
Sicherheitsforschung, die in gutem Glauben und im Rahmen dieser Richtlinie erfolgt, ist vom Website-Betreiber autorisiert. Wir werden deswegen keine rechtlichen Schritte gegen Sie einleiten und weder einen Kunden noch einen Komponentenhersteller bitten, dies in unserem Namen zu tun. Diese Autorisierung deckt kein Verhalten außerhalb dieser Richtlinie ab und kann Dritte nicht binden. Meldungen und die darin enthaltenen personenbezogenen Daten werden gemäß der Datenschutzerklärung zur Klärung der Meldung verarbeitet und als Teil der Sicherheitsdokumentation des Produkts aufbewahrt.
Danksagungen
Hier stehen Sicherheitsforschende, die eine Schwachstelle nach dieser Richtlinie gemeldet und um Nennung gebeten haben. Bisher niemand. Diese Richtlinie ist neu.
Verantwortlich für die Richtlinie: die für das Produkt easyIGA verantwortliche Person. Überprüfung mindestens einmal jährlich und nach jeder bearbeiteten Meldung. Version 1.0, 14. September 2026.