Blog

Was im August passiert ist: Ticket-Gespräche, QS über MCP und Kontosteuerung

Der August war ein Monat des Zusammenführens und des Begrenzens. Support-Gespräche wurden vollständig, denn die E-Mail-Antwort einer anfragenden Person erscheint jetzt im Ticket-Verlauf statt in einer verknüpften E-Mail an anderer Stelle, und Tickets, die auf Ihr Team warten, fallen auf dem Board auf. Die Kontosteuerung wurde greifbar, mit Administratoren, die Sie ernennen können, und einer Inhaberschaft, die Sie übertragen können. Ein angebundener KI-Assistent kann jetzt selbst einen vollständigen, verknüpften Satz von QS-Datensätzen anlegen. Und wir haben unsere bisher längste Sicherheitsliste ausgeliefert, samt Abonnementpflicht und einer Reihe von Plattformgrenzen. Hier ist der vollständige Überblick.

Ticket-Gespräche und Sichtbarkeit auf dem Board

E-Mail-Antworten von anfragenden Personen erscheinen jetzt direkt im Ticket-Gespräch. Eine neue Workflow-Aktion, E-Mail zum Gespräch hinzufügen, hängt eine eingehende Antwort an den Verlauf des Tickets an, zu dem sie gehört. So lesen Sie das Gesagte der Reihe nach neben Ihren eigenen Antworten, statt eine verknüpfte E-Mail zu öffnen, um es zu finden. Fügen Sie die Aktion einem E-Mail-Workflow nach Ticket-Referenzen extrahieren hinzu, eine eigene Konfiguration braucht sie nicht.

Jeder Eintrag wird der Person zugeordnet, die ihn gesendet hat, der Verlauf zeigt also deren Namen und nicht System, und beim ersten Schreiben einer unbekannten Adresse wird automatisch ein Kontakt angelegt. Dieselbe E-Mail zweimal zu verarbeiten erzeugt niemals einen doppelten Eintrag. Eine eingehende Antwort erfüllt das Ziel für die erste Reaktion in Ihrem SLA nicht, denn eine anfragende Person, die schreibt, ist keine Agentin oder kein Agent, der antwortet, und sie ändert den Status des Tickets nicht. Wie mit Antworten umgegangen wird, definieren weiterhin Sie über Workflows.

Tickets, die auf Ihr Team warten, fallen jetzt auf dem Kanban-Board auf. Antwortet die anfragende Person, wird die Karte mit einem Akzent und einem Hinweis auf die eingegangene Antwort markiert, samt Wartezeit, sodass zwei Stunden anders aussehen als zwei Tage. Diese Karten steigen an den Anfang ihrer Spalte, wodurch eine offene Rückmeldung beim Überfliegen des Boards schwer zu übersehen ist, und Ihre gewählte Sortierung gilt innerhalb jeder Gruppe weiter, das Aufsteigen überschreibt Ihre Reihenfolge also nie.

Ein neuer Filter Wartet auf Antwort schränkt das Board auf das ein, was auf Ihr Team oder auf die anfragende Person wartet, und eine Sortierung nach Letzter Antwort ordnet Tickets nach der neuesten Gesprächsaktivität. Beides steht auch in der Ticketliste und ihren Exporten bereit. Interne Notizen gelten nicht als Antwort, eine Notiz lässt ein Ticket also weiter als wartend markiert, während Antworten aus einer Automatisierung, etwa eine vorgefertigte Antwort aus einem Workflow, zählen. Bestehende Tickets wurden einbezogen, das Board zeigt den tatsächlichen Gesprächsstand also sofort.

Formatierung bleibt im Helpdesk erhalten

Ein Ticket aus einer E-Mail zu erstellen übernimmt jetzt die Formatierung der E-Mail. Überschriften, Listen, Fettdruck, Links und Bilder kamen bisher als reiner Text an. Ein Vorgang, der aus einem Ticket erstellt wird, behält die Formatierung der Ticketbeschreibung auf dieselbe Weise. Beide Beschreibungsfelder sind jetzt vollständige Rich-Text-Editoren, mit Werkzeugleiste, Tabellen, der Medienbibliothek, Bild-Upload per Ziehen und Ablegen oder Einfügen sowie KI-Unterstützung, und beide Dialoge sind breiter, damit die Werkzeugleiste bequem hineinpasst. An bestehenden Tickets und Vorgängen ändert sich nichts.

Administratoren und Kontoinhaberschaft

Inhaber und Administratoren können die Rolle Admin jetzt im Rollendialog unter Kontobenutzer erteilen und entziehen, der bisher jede Systemrolle sperrte. Die Rolle Basic bleibt fest, weil jedes Mitglied sie automatisch hat. Ein Konto behält immer einen Administrator, das Entziehen der Rolle Admin beim letzten verbleibenden Administrator wird also abgelehnt. Sie dürfen Ihre eigene abgeben, solange ein weiterer Administrator bleibt, und werden vorher gewarnt, dass Sie sie nicht selbst wiederherstellen können.

Die Kontoinhaberin oder der Kontoinhaber kann die Inhaberschaft unter Kontobenutzer an ein anderes Mitglied übertragen und bestätigt dabei zuerst die eigene Identität. Die neue Inhaberin oder der neue Inhaber erhält auch die Rolle Admin, und nur diese Person kann sie zurückübertragen. Ein Konto kann auch nicht mehr ohne Inhaberschaft zurückbleiben: Wer ein Konto besitzt, kann nicht gelöscht oder davon getrennt werden, bis die Inhaberschaft an jemand anderen übertragen wurde. Löscht die Kontoinhaberin oder der Kontoinhaber das eigene Konto und bleibt kein weiteres Mitglied, wird das Konto jetzt deaktiviert und offene Einladungen werden zurückgezogen, statt aktiv und leer bestehen zu bleiben.

Wird jemandem eine Rolle entzogen, schränkt das jeden von dieser Person erstellten API- und MCP-Token sofort ein, denn die Berechtigungen eines Tokens werden daran geprüft, was die Inhaberin oder der Inhaber aktuell besitzt, und nicht daran, was zum Zeitpunkt der Erstellung galt.

Ein vollständiger Satz von QS-Datensätzen über MCP

Ein angebundener KI-Assistent kann jetzt selbst einen vollständigen Satz von QS-Datensätzen anlegen. Bisher konnte er einen Testfall anlegen, ihm aber keine Schritte geben, eine User Story anlegen, ihr aber keine Abnahmekriterien anhängen, und einen Testzyklus anlegen, aber nichts hineinlegen, sodass jeder so erzeugte Datensatz in der Konsole von Hand fertiggestellt werden musste.

Testschritte lassen sich jetzt auflisten, hinzufügen, bearbeiten, neu anordnen, duplizieren und löschen, und ein Testfall kann mit allen seinen Schritten in einer einzigen Anfrage angelegt werden. Abnahmekriterien können beim Anlegen oder Aktualisieren einer User Story mitgegeben werden, und jedes Kriterium kommt mit eigener Kennung und eigener Abdeckung zurück, sodass ein Assistent einen Test verknüpfen und die Verknüpfung anschließend bestätigen kann. Tests lassen sich mit einer User Story oder mit einem einzelnen Abnahmekriterium verknüpfen, in beide Richtungen. Die Verknüpfung am Kriterium statt an der Story macht teilweise Abdeckung in der Rückverfolgbarkeitsmatrix sichtbar, und das ist die Praxis, die wir empfehlen.

Zyklen lassen sich jetzt füllen. Das Hinzufügen von Testfällen erzeugt die Testläufe, ein Zyklus kann geklont und sein Fortschritt abgerufen werden. Jeder Lauf nimmt eine Umgebung und eine Priorität auf, Ergebnisse von Bestanden, Fehlgeschlagen und Blockiert für jeden Schritt, Kommentare und Verknüpfungen zu allen Fehlern, die er aufgedeckt hat. Beim Hinzufügen von Testfällen zu einem Zyklus kann optional eine Umgebung angegeben werden, die für jeden dabei erzeugten Testlauf gilt, und das funktioniert über die API genauso wie über MCP, ein Zyklus muss also nicht mehr Lauf für Lauf eingerichtet werden.

Ordner für Testfälle und für Testzyklen lassen sich jetzt als Baum abrufen, anlegen, umbenennen, verschieben und löschen, sodass so erzeugte Datensätze abgelegt werden können, statt sich unsortiert anzuhäufen. Das Löschen eines Ordners, der noch Datensätze oder Unterordner enthält, wird abgelehnt, sofern Sie es nicht ausdrücklich verlangen, und wenn Sie es verlangen, wandern die Datensätze auf die oberste Ebene, statt mit dem Ordner gelöscht zu werden.

Neu formatieren mit KI

Eine neue Aktion Neu formatieren im Reiter Verfeinern des KI-Schreibassistenten bringt die Darstellung Ihres Inhalts in Ordnung, ohne ein einziges Wort daran zu ändern. Sie teilt eine Textwand in Absätze, verwandelt eine Folge von Punkten in eine echte Liste, macht Zeilen, die sich wie Abschnittstitel lesen, zu Überschriften und räumt versprengte Formatierung auf. Jede andere Verfeinerungsaktion ändert Ihre Worte, ob durch Kürzen, Ausweiten oder Anpassen des Tons, Neu formatieren ist also die Wahl, nachdem Sie Inhalt von anderswo eingefügt haben. Sie steht überall dort bereit, wo das KI-Unterstützungsfeld erscheint, auf Englisch, Spanisch und Deutsch.

Wer was erstellt hat

Notizen, Aufgaben und Kontakte halten jetzt fest, wer sie erstellt hat. Die Listen für Notizen und Kontakte zeigen eine Spalte Erstellt von, und der CSV-Export aller drei enthält sie. Ein neuer Filter Erstellt von in diesen drei Listen schränkt sie auf die Datensätze einer Person ein, mit einer Option System für alles, was von einem Workflow, dem Zeitplan oder aus einer eingehenden E-Mail stammt und nicht von einem Mitglied Ihres Teams. Notizen haben außerdem gesammeltes Löschen erhalten, mehrere auszuwählen und zu entfernen ist also eine einzige Aktion, wo vorher jede Notiz einzeln gelöscht wurde.

Datensätze, die vor dieser Version erstellt wurden, zeigen System als Ersteller, weil der Ersteller damals nicht festgehalten wurde. An diesen Datensätzen ändert sich nichts, und niemand muss etwas tun.

Die Abonnementpflicht

Das Arbeiten in einer Organisation setzt jetzt ein aktives Abonnement voraus. Läuft eine kostenlose Testphase aus, oder erreicht ein gekündigtes Abonnement das Ende seines bezahlten Zeitraums, werden Anfragen nach den Datensätzen dieser Organisation abgelehnt, bis sie wieder abonniert ist. Bisher behielt eine abgelaufene Testphase den vollen Zugriff auf unbestimmte Zeit.

Dabei wird nichts gelöscht. Ihre Vorgänge, Tests, Dokumente und Ihr Verlauf bleiben genau so, wie sie waren, und sind in dem Moment wieder da, in dem Sie abonnieren. Was Sie brauchen, um das zu lösen oder um zu gehen, bleibt offen: Anmelden, die Abrechnungsseiten und Ihr Rechnungsverlauf, der Wechsel zu einer anderen Organisation, der Sie angehören, das Ansehen und Annehmen von Einladungen, Ihr eigenes Profil und Ihre Sicherheitseinstellungen, ein vollständiger Datenexport und das Löschen des Kontos. So wird niemand von der einen Seite ausgeschlossen, die die Organisation zurückbringt, und keine Organisation festgehalten, um an ihre Daten zu kommen. Andere Organisationen, denen Sie angehören, bleiben unberührt, denn die Sperre gilt für eine Organisation und nie für Ihren Benutzer.

Eine fehlgeschlagene Zahlung, die Stripe noch erneut versucht, sperrt niemanden aus. Ihre Organisation arbeitet während der gesamten Nachfrist normal weiter, die das Zeitfenster für das Aktualisieren der Karte ist, und erst eine erschöpfte Folge von Versuchen beendet den Zugriff. API-Token und MCP-Clients folgen derselben Regel mit einer Feinheit: Sie können weiterhin die für sie verfügbaren Werkzeuge auflisten und Datensätze lesen, aber alles, was anlegen, aktualisieren oder löschen würde, wird mit einer Antwort abgelehnt, die eine Zahlung verlangt. Eine Integration nennt den Grund also klar, statt kaputt zu wirken, und schreibt wieder, sobald das Abonnement aktiv ist, ohne Änderung auf ihrer Seite.

Plattformgrenzen

Für mehrere Teile der Plattform gab es keine Obergrenze, wie viel davon ein einzelnes Konto anhäufen konnte. Das ist jetzt begrenzt, und die Grenzen liegen deutlich über allem, was ein echtes Team tut.

  • Kontobenutzer: es gibt jetzt eine Obergrenze dafür, wie viele Benutzer ein Konto haben kann, einschließlich gesendeter, aber noch nicht beantworteter Einladungen. Konten mit aktivem Abonnement gilt eine hohe Grenze, die kein echtes Team erreicht, weil jeder hinzugefügte Benutzer ohnehin abgerechnet wird. Konten ohne Abonnement gilt eine deutlich niedrigere Grenze, und ein Abonnement hebt sie sofort an, ohne dass etwas beantragt werden muss. Ein Konto, das bereits über seiner Grenze liegt, behält jedes Mitglied und alle seine Daten und kann nur keine weiteren hinzufügen.
  • Einladungen: Kontoeinladungen sind jetzt in ihrer Häufigkeit begrenzt, je Administrator und je Konto, sowohl beim Senden einer neuen als auch beim erneuten Senden einer bestehenden Einladung. Damit ist ein Weg geschlossen, über den das Einladungssystem für große Mengen unerwünschter E-Mail hätte genutzt werden können. Einladen in normalem Tempo ist nicht betroffen.
  • Organisationen: die Zahl der Organisationen, die eine Person anlegen kann, ist jetzt begrenzt, und das Anlegen ist zusätzlich in seiner Häufigkeit begrenzt. Ohne das hätte die Benutzerobergrenze umgangen werden können, indem eine weitere Organisation gestartet wird, statt die aktuelle zu füllen.
  • API-Token: die Zahl aktiver API-Token, die ein Konto halten kann, ist jetzt begrenzt, und die MCP-Anfragegrenzen gelten nun auch je Konto und nicht nur je Token. Bisher trug jeder Token seine eigene Menge, mehr Token hoben also die Gesamtzahl, die ein Konto senden konnte. Widerrufen Sie einen Token, den Sie nicht mehr nutzen, um Platz für einen neuen zu schaffen.
  • Anfragehäufigkeit: die gesamte API liegt jetzt hinter einer übergeordneten Grenze für Anfragen pro Minute, angewandt je angemeldeter Person und nicht je Standort, sodass niemandes Aktivität die einer Kollegin oder eines Kollegen verdrängen kann. Anfragen, die anlegen, ändern oder löschen, tragen darüber hinaus eigene Grenzen, je Person und je Konto, denn die übergeordnete Grenze war auf das Lesevolumen der Konsole ausgelegt. Lesen ist nicht betroffen, die Admin-Konsole und die mobile App kommen keiner der beiden Grenzen nahe, und eingehende Webhooks von Stripe, Google Kalender und Ihren eigenen Integrationen bleiben unberührt.
  • Kalender: es gibt jetzt eine Obergrenze für die Zahl persönlicher Kalender, die Sie in einer Organisation halten können, und eine Grenze dafür, wie schnell Kalender und Termine angelegt werden können. Ihr Kontokalender und alle Kalender, die Sie von Google verbinden, zählen nicht für diese Obergrenze. Bisher konnte ein einzelnes Konto genug Kalender anhäufen, um seine eigene Kalenderleiste langsam zu machen.

Richtlinie zur Datenaufbewahrung

In Compliance steht jetzt eine Richtlinie zur Aufbewahrung und Entsorgung von Daten bereit, die für Geschäftsunterlagen eine Grundlage von sieben Jahren festlegt, mit kürzeren Fristen dort, wo eine kürzere Frist begründet ist.

Verbesserungen und Korrekturen

  • Sammelaktionen: wo eine Aktion auf jeden Datensatz einzeln angewandt werden muss, hält sie nicht mehr beim ersten Problem an und meldet einen allgemeinen Fehler. Sie arbeitet die restliche Auswahl ab und nennt Ihnen, wie viele Datensätze verarbeitet wurden, und wenn sie wegen einer erreichten Grenze angehalten hat, sagt sie, wie viele übrig sind, damit Sie sie für den Rest erneut ausführen können. Gesammeltes Löschen bei Funktionen und User Stories ist jetzt eine einzige Anfrage statt einer pro Datensatz, was es bei einer großen Auswahl merklich schneller macht.
  • Unbestätigte E-Mail: ist die Bestätigungs-E-Mail nie angekommen oder ihr Link abgelaufen, führt die Anmeldung mit E-Mail und Passwort jetzt auf eine Seite, die anbietet, eine neue zu senden, mit bereits eingetragener Adresse, statt Sie ohne Handlungsmöglichkeit auf der Anmeldeseite zu lassen. Ein neuer Link kann einmal pro Minute und bis zu drei Mal pro Stunde angefordert werden. Beachten Sie, dass ein Zurücksetzen des Passworts die Sperre nicht aufhebt, nutzen Sie also das erneute Senden und nicht Passwort vergessen?
  • Kanban-Board: behoben, dass Tickets vom Board verschwanden. Es lud stets nur die zehn neuesten Tickets und verteilte sie über alle sechs Spalten, Karten schienen also zufällig zu verschwinden, sobald ein Ticket erstellt wurde oder die Sortierung wechselte. Das Board lädt nun seinen vollständigen Satz, und die Auswahl der Seitengröße in der Ticketliste wirkt, statt immer zehn Zeilen zurückzugeben. Tickets werden standardmäßig zu dreißig pro Seite angezeigt.
  • Notizsuche: behoben, dass Notizen nach einer Aktualisierung durch eine Automatisierung aus der Suche fielen. Ein Workflow, der den Inhalt einer Notiz änderte, aktualisierte den Text für die Suche und für CSV- und PDF-Exporte nicht, eine Notiz konnte also aufhören, auf eine Suche nach Wörtern zu passen, die sie offensichtlich enthielt. Betroffene Notizen werden beim Upgrade korrigiert.
  • Registrierungsformular: die Felder Vollständiger Name und Firmenname enden jetzt bei 255 Zeichen und weisen darauf hin, wenn die Grenze erreicht ist, statt einen langen Wert anzunehmen und beim Absenden mit einem allgemeinen Fehler zu scheitern. Dieselbe Grenze gilt bei der Registrierung aus der mobilen App.
  • Dialog Benutzer hinzufügen: er zeigt jetzt, wie viel der Benutzermenge Ihres Kontos genutzt wird, und wenn sie erreicht ist, sagt er das und erklärt, was zu tun ist, statt das Formular anzunehmen und beim Absenden abzulehnen.
  • Registrierung mit Google: behoben, dass Sie beim Festlegen Ihres ersten Passworts nach einer Registrierung mit Google abgemeldet wurden. Die Rückkehr von Google beendete die gerade erzeugte Sitzung und ließ Sie wieder auf der Anmeldeseite. Konten, die durch eine Registrierung mit Google entstehen, erhalten jetzt genau dieselbe Sitzung wie jede andere Anmeldung.
  • Google-Konto verknüpfen: behoben, dass das Verknüpfen in den Sicherheitseinstellungen Sie erneut anmeldete, statt etwas zu verknüpfen. Google-Konto verknüpfen führt jetzt zu Google, fragt, welches Konto Sie anhängen möchten, statt das bereits angemeldete anzunehmen, und meldet bei der Rückkehr das Ergebnis.
  • Testzyklen über MCP: behoben, dass das Werkzeug für Testzyklen drei Angaben annahm und sie dann stillschweigend verwarf. Eine Umgebung, ein geplanter Starttermin und ein geplanter Endtermin wurden angenommen, die Antwort meldete Erfolg, und keine der drei wurde gespeichert, ein Zyklus sah also richtig eingerichtet aus, ohne es zu sein. Eine falsch benannte Angabe wird jetzt mit der Liste der akzeptierten abgelehnt. Derselbe Fehler wurde im Werkzeug für Testumgebungen behoben, das einen Browser, ein Betriebssystem und ein Gerät anbot, die es alle nicht gibt.

Sicherheit

Der August war unser bisher umfangreichster Sicherheitsmonat. Neben den routinemäßigen Aktualisierungen der Frameworks und Drittanbieterkomponenten hinter ISO Mate hat sich Folgendes geändert.

  • Kontotrennung in der Rollenverwaltung: eine Rechteausweitung wurde behoben. Berechtigungen bei Anfragen auf Kontoebene wurden gegen das Konto geprüft, das Sie als aktiv markiert hatten, und nicht gegen das Konto, an das sich die Anfrage tatsächlich richtete. Wer mehr als einer Organisation angehörte, konnte so über eine davon administrativen Zugriff auf eine andere erlangen, einschließlich der Vergabe ihrer Rolle Admin an sich selbst. Berechtigungen werden jetzt immer gegen das in der Anfrage genannte Konto bewertet, und Sie müssen Mitglied dieses Kontos sein. Uns extern mit einem klaren, reproduzierbaren Machbarkeitsnachweis gemeldet.
  • Benutzerdefinierte Objekttypen: ein Teil des Bereichs für benutzerdefinierte Objekte entnahm das zu verwendende Konto der Anfrage statt Ihrer Sitzung, eine angemeldete Person hätte also die Felddefinitionen der benutzerdefinierten Objekttypen eines anderen Kontos lesen oder einen neuen Objekttyp in einem anderen Konto anlegen können. Jeder Teil dieses Bereichs verwendet jetzt Ihr eigenes Konto aus Ihrer Sitzung und ignoriert alles, was in der Anfrage mitgesendet wird. Auf Eintragsdaten war auf diesem Weg kein Zugriff möglich. Uns extern mit einem klaren, reproduzierbaren Machbarkeitsnachweis gemeldet.
  • Niemand erweitert die eigene Befugnis: eine Rolle zuzuweisen, eine Rolle anzulegen oder Berechtigungen zu einer bestehenden Rolle hinzuzufügen wird abgelehnt, wenn dadurch eine Berechtigung erteilt würde, die Sie in diesem Konto nicht haben. Eine Rolle umzubenennen oder zu beschneiden, die weiter reicht als Ihr eigener Zugriff, funktioniert weiterhin. Anfragen an ein deaktiviertes Konto werden jetzt abgelehnt, auch wenn Ihr eigenes aktives Konto in Ordnung ist.
  • Zahlen auf dem Dashboard: behoben, dass Dashboard-Zahlen ohne die Berechtigung für das Modul lesbar waren, aus dem sie stammten. Welche Panels erschienen, wurde allein im Browser entschieden, die Zahlen hinter einem Panel konnten also von einem Mitglied ohne Zugriff auf diesen Produktteil gelesen werden. Jedes Panel wird jetzt auf dem Server gegen dieselbe Berechtigung geprüft, die auch das Modul selbst regelt. Ein Mitglied, das einige Module erreicht und andere nicht, erhält weiterhin ein funktionierendes Dashboard mit den Teilen, auf die es Anspruch hat. Uns extern mit einem klaren, reproduzierbaren Machbarkeitsnachweis gemeldet.
  • Hochgeladene Dateien: nur Bilder und PDFs werden jetzt direkt im Browser angezeigt. Jeder andere Dateityp wird als Download ausgeliefert, und Dateitypen, die ein Browser als Seite oder Skript ausführen kann, etwa HTML und JavaScript, werden nicht mehr als Anhang angenommen. Damit ist ein Risiko für gespeichertes Cross-Site-Scripting geschlossen, und es verhindert, dass von Angreifern kontrollierte Seiten unter einer ISO Mate Adresse für Phishing gehostet werden. Derselbe Schutz gilt überall, wo ISO Mate eine hochgeladene Datei ausliefert, auch für Dateien, die vor dieser Änderung hochgeladen wurden, denn die Einschränkung greift im Moment der Auslieferung. Wenn Sie eine Webseite oder ein Skript teilen müssen, legen Sie es in ein Zip-Archiv. Über unser Programm zur Offenlegung von Schwachstellen gemeldet.
  • Zugangsdaten in Dateilinks: Datei- und Bildlinks führen Ihren Zugriffstoken nicht mehr mit. Bisher legte das Öffnen einer Anhangsvorschau oder die Anzeige Ihres Kontologos ein Zugangsmerkmal in die Adresse, wo es im Browserverlauf und in Serverprotokollen erhalten bleiben konnte. Die Admin-Konsole und die mobile App fordern die Datei jetzt über eine authentifizierte Verbindung an, und die Möglichkeit, sich über einen Link anzumelden, wurde vollständig aus der API entfernt.
  • E-Mail-Bestätigung: eine Umgehung bei der Anmeldung mit Google wurde behoben, die vollen Zugriff auf ein Konto gewährte, dessen E-Mail-Adresse nie bestätigt worden war. Da Google die Adresse bestätigt, bevor sie an uns übergeben wird, gilt eine übereinstimmende Adresse jetzt als Nachweis, dass die Adresse Ihnen gehört. Ein Konto, das seine E-Mail-Adresse nicht bestätigt hat, erreicht außerdem keinen Teil der API mehr, die Bestätigung wird also bei jeder Anfrage geprüft und nicht mehr nur bei der Anmeldung. Abmelden und das Abfragen des eigenen Anmeldestatus funktionieren weiter, ein unbestätigtes Konto bleibt also nie ohne Ausweg. Über unser Programm zur Offenlegung von Schwachstellen gemeldet.
  • Bindung an die Google-Identität: die Anmeldung mit Google ist jetzt an das bestimmte Google-Konto gebunden, das mit Ihrem Profil verknüpft ist. Wird ein anderes Google-Konto verwendet, wird die Anmeldung abgelehnt, auch wenn dessen Adresse mit der Adresse Ihres ISO Mate Kontos übereinstimmt. Bisher konnten zwei getrennte Google-Identitäten dasselbe Konto erreichen, während nur eine davon als verknüpft geführt wurde. Das verknüpfte Konto zu ersetzen erfordert jetzt, das aktuelle zuerst zu trennen, was Ihr Passwort oder eine an Ihre E-Mail-Adresse gesendete Bestätigung verlangt, und das Anhängen eines Google-Kontos geschieht jetzt ausschließlich innerhalb Ihrer eigenen Sitzung. Über unser Programm zur Offenlegung von Schwachstellen gemeldet.
  • E-Mail-Änderungen und Google: das Ändern Ihrer E-Mail-Adresse trennt jetzt ein Google-Konto, das mit der verlassenen Adresse verknüpft war, und meldet Sie aus Ihren anderen Sitzungen ab. Diese Verknüpfung überdauerte die Änderung bisher. Am wichtigsten ist das, wenn eine Arbeitsadresse nach Ihrem Weggang aus einer Organisation an jemand anderen übergeht, denn wer diese Adresse dann hält, könnte sich andernfalls weiterhin in Ihr ISO Mate Konto anmelden. Sie behalten den Zugriff mit Ihrem Passwort und können Google jederzeit erneut verknüpfen.
  • Abmelden: das Abmelden widerruft Ihre Sitzung jetzt auch dann, wenn ein Client nur seinen kurzlebigen Zugriffstoken sendet. Aus der Admin-Konsole und der mobilen App funktionierte das Abmelden bereits korrekt, aber einem Client, der nur den Zugriffstoken sendete, wurde ein erfolgreiches Abmelden gemeldet, während die Sitzung für die restlichen fünfzehn Minuten Lebensdauer dieses Tokens tatsächlich aktiv blieb. Dieser Weg widerruft jetzt jeden Token der Sitzung und hält das Abmelden im Prüfprotokoll Ihres Kontos fest. Über unser Programm zur Offenlegung von Schwachstellen gemeldet.
  • Fensterisolierung: die Konsole prüft jetzt selbst, auf der Anmelde- und der Registrierungsseite, und verweigert den Start der Google-Anmeldung, wenn sie von einer Seite einer anderen Website geöffnet wurde. Die API sendet dieselbe Isolationsanweisung wie die Konsole, und unsere Website sendet sie nun ebenfalls, alle drei stimmen also überein. Der Schutz ruht damit nicht mehr auf einem einzelnen Infrastrukturbaustein. Zusätzlich wird jeder Link, den die Konsole zu einem externen Ziel öffnet, so geöffnet, dass der neue Tab keinen Rückbezug auf den ISO Mate Tab behält, der ihn geöffnet hat. Angestoßen durch Meldungen über unser Programm zur Offenlegung von Schwachstellen.
  • Browser-Zwischenspeicher: Antworten der API werden nicht mehr in den eigenen Zwischenspeicher des Browsers geschrieben. Aus geteilten und Proxy-Zwischenspeichern waren sie bereits ausgenommen, aber ein Browser konnte weiterhin eine Kopie auf der Festplatte behalten, Datensätze mit personenbezogenen Angaben konnten also nach Ende der Sitzung auf einem Gerät verbleiben. Jede API-Antwort weist nun an, sie nicht zu speichern, während das beabsichtigte Zwischenspeichern von Downloads, Exporten und des öffentlichen Anfrageportals unberührt bleibt. Die Konsole prüft außerdem erneut, ob Sie noch angemeldet sind, wenn der Browser eine Seite aus seinem Vor- und Zurück-Zwischenspeicher wiederherstellt.
  • Verschlüsselung eingehender E-Mail: eingehende E-Mail an isomate.io erklärt jetzt, dass Verschlüsselung erforderlich ist. Eine veröffentlichte MTA-STS-Richtlinie teilt einem sendenden Server mit, welche Mailhosts legitim sind und dass die Verbindung verschlüsselt sein muss, ein Absender kann also nicht dazu verleitet werden, eine Nachricht unverschlüsselt oder an einen ausgetauschten Host zu liefern. Daneben wird die TLS-Berichterstattung veröffentlicht. Die Richtlinie startet im Testmodus, der Probleme meldet, ohne die Zustellung zu beeinflussen, und geht in die Durchsetzung, sobald die Berichte ihre Richtigkeit bestätigen. Der Schutz für Mail, die wir senden, war bereits vorhanden, und dies ist das eingehende Gegenstück. Über unser Programm zur Offenlegung von Schwachstellen gemeldet.
  • Token-Berechtigungen: die Definitionen der Rollen Admin und Basic sind über die API jetzt nur lesbar, wie es in der Konsole bereits galt, während das Zuweisen dieser Rollen an einen Benutzer eine eigene Aktion ist und erlaubt bleibt. Die Abrechnungsverwaltung kann nicht mehr an einen API- oder MCP-Token gehängt werden. Sie war in der Auswahl bereits ausgeblendet und wird nun auch beim Erstellen eines Tokens abgelehnt.
  • Abhängigkeiten: Drittanbieterkomponenten in der API und der Admin-Konsole wurden auf ihre aktuellen gepatchten Versionen gebracht, womit jeder Hinweis aus unseren automatischen Abhängigkeitsprüfungen erledigt ist. Die Laufzeitpakete der Konsole waren auf exakte Versionen festgelegt, weshalb sie Sicherheitspatches nicht selbst aufnehmen konnten. Sie folgen nun den Patch-Versionen, und nicht genutzte Pakete für das serverseitige Rendern wurden entfernt, statt sie weiterzuschleppen und jeden Monat erneut zu prüfen.

Was als Nächstes kommt

Es ist mehr auf dem Weg, quer über die Plattform. Wenn Sie ISO Mate noch nicht ausprobiert haben, starten Sie eine kostenlose 14-tägige Testphase unter isomate.io. Ohne Kreditkarte, mit vollem Zugriff auf alles ab dem ersten Tag.

Rückmeldung? Schreiben Sie uns an support@isomate.io oder nutzen Sie das eingebaute Feedback-Portal in der Plattform. Ihre Hinweise prägen, was wir als Nächstes bauen.

Leave a Reply