🚀 Neue Funktionen
Integrationen: Microsoft Teams-Connector
Workflow-Regeln tragen den Großteil Ihrer Erinnerungen: eine auslaufende Prüfung, ein Antrag auf Ausübung von Rechten, der in eine neue Phase wechselt, eine Aufgabe ohne zugewiesene verantwortliche Person. Bisher hatten diese Erinnerungen nur zwei Ausgabekanäle: das Dastra-Benachrichtigungscenter oder E-Mail-Benachrichtigungen. Für bestimmte Nutzerinnen und Nutzer in Ihrer Organisation gehen Erinnerungen jedoch in einem Posteingang unter, oder das Benachrichtigungscenter wird schlicht nicht geöffnet, um nachzusehen, ob sich etwas getan hat.
Der Microsoft Teams-Connector eröffnet einen dritten Kanal – dort, wo Ihr Team ohnehin bereits kommuniziert. Sie verknüpfen einen Teams-Kanal mit Ihrem Arbeitsbereich, und Ihre Workflow-Regeln erhalten eine neue Aktion: eine Benachrichtigung in diesem Kanal veröffentlichen.
Die Person, die die Regel erstellt, verfasst Titel und Nachricht selbst, fügt Daten des auslösenden Objekts ein und entscheidet, ob ein direkter Link zu diesem Objekt in Dastra beigefügt werden soll oder nicht. Die Verbindung kann über den Konfigurationsbildschirm getestet werden, und der Connector kann jederzeit pausiert oder deinstalliert werden.
Integrationen: Jira-Connector
Teams, die Anträge auf Ausübung von Rechten bearbeiten, arbeiten häufig in Jira, wo jeder Antrag als Ticket angelegt wird. Ohne automatische Verknüpfung muss derselbe Antrag in Dastra erneut erfasst und sein Fortschritt doppelt nachverfolgt werden – mit dem Risiko, dass beide Tools auseinanderlaufen. Der Jira-Connector bringt nun die Lösung in Dastra.
Der Jira-Connector verbindet ein Jira-Projekt mit dem Verzeichnis der Rechteausübungen. Ein in Jira erstelltes Ticket erzeugt automatisch einen Antrag in Dastra, einschließlich der Informationen der antragstellenden Person und des Gegenstands des Antrags. Anschließend bleibt der Status in beide Richtungen synchron: Der Status des Jira-Tickets bringt die Phase des Antrags in Dastra voran, und eine Phasenänderung in Dastra überträgt sich auf das Jira-Ticket.
Die Konfiguration erfolgt eigenständig über die Arbeitsbereichseinstellungen:
- Dastra gegenüber Jira authentifizieren und anschließend das betreffende Projekt sowie den Ticket-Typ auswählen.
- Festlegen, wie die Ticketfelder den Antrag befüllen.
- Jeden Jira-Status einer Phase des Dastra-Workflows zuordnen.
- Die standardmäßige organisatorische Einheit für erstellte Anträge definieren.
- Die eingehende Benachrichtigung aus Jira einrichten, geschützt durch ein von Dastra erzeugtes Geheimnis.
Sie steuern Ihre Anträge aus dem Tool Ihres Teams heraus und behalten in Dastra zugleich das Register, den Verlauf und die Automatisierungen, die Ihre Anforderungen erfüllen.
Was ist Jira?
Jira ist Atlassians Plattform für Projekt- und Ticketmanagement, die von Teams häufig zur Verfolgung von Aufgaben, Fehlern und Workflows verwendet wird.
Integrationen: SAP LeanIX-Connector
Für bestimmte Organisationen oder Arbeitsteams lebt die Applikationslandkarte in SAP LeanIX: Jede Anwendung verfügt dort über ihr Datenblatt, ihren gebräuchlichen Namen, ihre Beschreibung, ihre Lebenszyklusphase, ihre Verantwortlichen und die Nummer, unter der das Unternehmen sie führt. Das Asset-Register von Dastra hingegen enthält die Datenlandkarte und die Compliance: zugeordnete Verarbeitungstätigkeiten, Sicherheitsmaßnahmen, den Anbieter, Prüfungen. Ohne Verbindung zwischen beiden werden die Anwendungen einzeln erneut erfasst, und beide Inventare beginnen bereits bei der ersten Inbetriebnahme auseinanderzulaufen.
Der SAP LeanIX-Connector verbindet eine LeanIX-Instanz mit dem Asset-Register. Importieren Sie Ihre Application Fact Sheets aus SAP LeanIX automatisch als Assets in Dastra (tägliche Synchronisierung, Upsert). Da das LeanIX-Datenmodell je Instanz individuell ist, würde eine starre Zuordnung nicht passen: Sie wählen selbst aus den tatsächlich in Ihrem Modell vorhandenen Feldern diejenigen aus, die die einzelnen Asset-Felder befüllen – einschließlich der internen Nummer als Referenz des Assets und der Adresse der verantwortlichen Person als benutzerdefiniertes Feld.
Sie entscheiden außerdem, ob fehlende Assets erstellt werden sollen und wie ein LeanIX-Datensatz mit einem bereits in Dastra vorhandenen Asset abgeglichen werden soll. Jedes importierte Asset behält die Spur des Datensatzes, aus dem es stammt, und der tägliche Abgleich löscht niemals, was in Dastra erfasst wurde.
Was ist SAP LeanIX?
SAP LeanIX ist eine SaaS-Plattform für Enterprise-Architecture-Management. Sie führt ein Inventar von Anwendungen, IT-Komponenten und deren Lebenszyklus, um die IT-Landschaft zu steuern und zu rationalisieren.
Integrationen: ServiceNow-Connector
Ihre Anwendungen werden in ServiceNow inventarisiert, während die Compliance in Dastra dokumentiert wird? Ohne Verbindung zwischen den beiden Tools wird jede neue Anwendung doppelt erfasst, und die Lücke zwischen dem technischen Inventar und dem Compliance-Register wächst, ohne dass jemand weiß, welches der beiden maßgeblich ist.
Der Abgleich ist umso heikler, als beide Tools nicht dieselbe Sprache sprechen: Derselbe Begriff (der Zustand einer Anwendung, ihre Art, ihre Kritikalität) trägt auf beiden Seiten weder denselben Namen noch dieselben Werte, und jede ServiceNow-Instanz ist anders konfiguriert.
Der ServiceNow-Connector verbindet eine ServiceNow-Instanz mit dem Asset-Register. Sie beschreiben die Zuordnung zwischen den Spalten der Tabelle der Business-Applikationen und den Feldern des Dastra-Assets, einschließlich der Übersetzung der Werte von einer Liste in die andere, und wählen, ob fehlende Assets erstellt werden sollen und wie ein eingehender Datensatz mit einem vorhandenen Asset abgeglichen werden soll. Der Import wird anschließend täglich wiederholt, ohne jemals die Arbeit Ihrer Compliance-Teams zu überschreiben.
Was ist ServiceNow?
ServiceNow ist eine SaaS-Plattform für digitales Servicemanagement (ITSM, ITOM, ITAM, HR, SecOps usw.), die es ermöglicht, IT- und Geschäftsprozesse innerhalb einer Organisation zu zentralisieren und zu automatisieren. Sie wird breit eingesetzt für das Management von Incidents, Anfragen, Assets und Unternehmensdaten.
Compliance: Versionsverwaltung von Frameworks
Ab sofort können Sie darüber informiert werden, dass eine neuere Version des Quell-Referenzrahmens existiert, Änderungen an Kontrollen, Tests, Risikoszenarien und Bedrohungen vorab anzeigen und anschließend durch Bestätigung eine neue, aktuelle Version erstellen.
Die Versionierung von Frameworks folgt demselben bewährten Prinzip wie im Modul Fragebögen. Wenn Ihre Organisation benutzerdefinierte Frameworks verwalten kann, können Sie jetzt aus einer bestehenden Version eine neue Version erstellen, sie als Entwurf bearbeiten und veröffentlichen, während der Verlauf erhalten bleibt.
Sie können daher:
- Eine neue Version erstellen eines benutzerdefinierten oder importierten Frameworks, die seine Kapitel, Anforderungen und zugehörigen Kontrollen übernimmt, mit Änderungsvermerk und automatisch vergebener Nummer.
- Eine Version veröffentlichen oder unveröffentlicht lassen, einen aufgegebenen Entwurf löschen und mehrere veröffentlichte Versionen desselben Frameworks parallel bestehen lassen.
- Die Hauptversion festlegen, die beim Hinzufügen eines Frameworks aus der Bibliothek zu einem Projekt standardmäßig vorgeschlagen und installiert wird.
- Den vollständigen Versionsverlauf einsehen (Nummer, Änderungsvermerk, Status, Datum und Autor) und eine frühere Version schreibgeschützt öffnen.
Der größte Vorteil ist die Unabhängigkeit Ihrer Compliance-Projekte. Ein Projekt ist an eine bestimmte Version gebunden: Ein Projekt, das auf Version 1 eines Frameworks basiert, wird nicht durch die Weiterentwicklung dieses Frameworks zu Version 2 beeinflusst, und beide Versionen können gleichzeitig in zwei verschiedenen Projekten verwendet werden. Die Migration eines Projekts auf eine andere Version bleibt eine manuelle und ausdrückliche Handlung und ist gesperrt, solange ein Audit läuft, damit keine laufende Arbeit verfälscht wird.
Die Anforderungen einer veröffentlichten Version sind gesperrt, die Metadaten (Bezeichnung, Logo, Beschreibung) bleiben änderbar, und die Erstellung einer Version verbraucht kein zusätzliches Kontingent. Ihre bestehenden Frameworks werden automatisch zu ihrer Version 1, wobei ihr aktueller Status erhalten bleibt und Ihre Projekte dieser Version 1 zugeordnet werden: Es ist keine Aktion Ihrerseits erforderlich.
In der Detailansicht einer Kontrolle zeigt das Panel der zugehörigen Anforderungen die Versionsnummer des ursprünglichen Frameworks an: Zwei identische Anforderungen aus zwei verschiedenen Versionen werden so nicht mehr als Duplikat verstanden.
Cookies: Verwaltung nicht klassifizierter Cookies
Der Cookie-Scan vergleicht jeden erkannten Cookie mit dem Diensteregister von Dastra. Wird keine Übereinstimmung gefunden, bleibt der Cookie verwaist. Ihre Einwilligungsbanner richten sich jedoch nur pro Dienst an Besucher: Ein Cookie, der keinem Dienst zugeordnet ist, wird dem Besucher nie angezeigt, und die eingeholte Einwilligung deckt ihn nicht ab. Da das Register nicht alle proprietären oder implementationsspezifischen Cookies kennen kann, tritt diese Situation auf der Mehrheit der gescannten Websites auf.
Dank des Tools zur Verwaltung nicht klassifizierter Cookies erscheint ein Tab „Nicht klassifizierte Cookies“ sowohl im Ergebnisbildschirm des Scans als auch im Banner-Editor, vorangestellt von einem Warnhinweis-Badge, das die Anzahl anzeigt.
Aus dieser Liste können Sie:
- Mehrere Cookies in einem Schritt einem bestehenden Dienst zuordnen, ohne ein Duplikat zu erzeugen, wenn der Cookie dort bereits erfasst ist.
- Aus einer Auswahl einen neuen Dienst erstellen, wobei das Formular auf Basis der am häufigsten vorkommenden Domain unter den ausgewählten Cookies vorausgefüllt wird.
- Die Cookies, die Sie nicht deklarieren möchten, nach Bestätigung löschen.
- Einen Cookie aus einem Dienst entfernen, um ihn zurück in die Liste der nicht klassifizierten Cookies zu verschieben.
Zähler, Warn-Badge und Verteilungsdiagramm aktualisieren sich nach jeder Aktion sofort, ohne den Scan erneut zu starten. Vor allem gilt: Nichts geht verloren – was bei der Erstellung des Banners nicht behandelt wird, bleibt diesem zugeordnet und kann später im Editor übernommen werden. Ein erneuter Scan auf einem bestehenden Banner gleicht die erkannten Cookies zunächst mit dem Register und anschließend mit Ihrer aktuellen Konfiguration ab und markiert bereits vorhandene Dienste mit einem grünen Häkchen.
Nicht klassifizierte Cookies werden niemals im öffentlichen Banner angezeigt: Ihre Besucher sehen weiterhin nur die nach Zweck gruppierten Dienste.
Sicherheit: Anmeldung per Passkey
Dastra bietet nun die Möglichkeit, sich mit einem Passkey anzumelden – ohne Passwort und ohne einzugebenen Bestätigungscode.
Ein Passkey ersetzt das Passwort und den sechsstelligen Code durch eine einfache Bestätigung auf Ihrem Gerät: Fingerabdruck, Gesichtserkennung oder PIN. Sie müssen sich nichts mehr merken oder abtippen, und die Anmeldung erfolgt in wenigen Sekunden.
Vor allem bietet er einen Schutz, den ein Passwort gegen Phishing nicht leisten kann. Ein Passwort und ein Bestätigungscode können auf jeder Seite eingegeben werden, die der von Dastra täuschend ähnlich sieht, und anschließend sofort anderswo wiederverwendet werden. Ein Passkey hingegen funktioniert nur auf der echten Dastra-Website: Er bleibt auf Ihrem Gerät, wird niemals übertragen und kann daher weder kopiert, noch abgefangen, noch erneut verwendet werden.
Konkret:
- Sie erstellen einen Passkey im entsprechenden Bereich der Seite Kontosicherheit oder direkt nach dem Login, wenn Dastra Ihnen dies anbietet.
- Sie melden sich anschließend ohne Eingabe von Passwort oder Code an.
- Sie benennen Ihre Passkeys, um sie von Gerät zu Gerät zu unterscheiden, und löschen sie jederzeit.
- Die Verzahnung mit der bereits eingerichteten Zwei-Faktor-Authentifizierung bleibt stimmig: Der Passkey gilt als starker Nachweis und fügt keinen unnötigen Schritt hinzu.
Browser, die Passkeys nicht unterstützen, bieten weiterhin die gewohnte Anmeldung an. Organisationen, die eine Single-Sign-On-Authentifizierung eingesetzt haben, verfügen bereits über ihre eigene Lösung und sind von diesem Mechanismus nicht betroffen.
Lesen Sie die Dokumentation zu Passkeys
Erweiterte Konfiguration: Senden Sie Ihre Sicherheitsprotokolle an Ihr SIEM
Dastra protokolliert die Aktivitäten Ihres Kontos: Anmeldungen, Änderungen von Berechtigungen, API-Schlüssel, SSO-Konfigurationen, Löschungen von Benutzern oder Arbeitsbereichen. Bisher blieben diese Spuren in Dastra, obwohl die Sicherheitsüberwachung einer Organisation in ihrem SIEM erfolgt, wo die Protokolle aller Anwendungen zentral zusammengeführt werden. Eine Korrelation zwischen einer Berechtigungsänderung in Dastra und einem andernorts erkannten Vorfall war daher nicht möglich.
Die SIEM-Integration eröffnet zwei komplementäre Wege.
Die Echtzeit-Übertragung, einmal pro Konto konfiguriert und dem Eigentümer vorbehalten, sendet jedes protokollierte Ereignis an die Adresse Ihres Collectors. Vier Formate werden unterstützt, um die wichtigsten Tools am Markt abzudecken: Splunk HEC (JSON), CEF (Common Event Format), Syslog (RFC 5424) und Dynatrace (Log Monitoring v2). Die Authentifizierung passt sich Ihrem Collector an (Bearer-Token, API-Schlüssel, benutzerdefiniertes Autorisierungsschema, benutzerdefinierter Header oder keine), benutzerdefinierte