IT-Sicherheit bei Time Cockpit: Was aktuelle KI-Modelle für SaaS-Dienste bedeuten

Apr 21, 2026 von Alexander Huber

Warum wir gerade jetzt über Sicherheit schreiben

Zeiterfassungsdaten sind keine Nebensache. Sie sind eine wichtige und schützenswerte Datengrundlage: Wer wann wie lange an welchem Projekt gearbeitet hat, welche Stundensätze gelten, wie Teams ausgelastet sind und welche Leistungen gegenüber Kunden oder Förderstellen nachgewiesen werden können. Entsprechend sorgfältig muss man mit diesen Daten umgehen.

Wir nehmen diese Verantwortung ernst und arbeiten konsequent daran, hohe Standards zu erfüllen. Der eigentliche Punkt ist für uns dabei nicht ein einzelnes Modell, sondern etwas Grundsätzlicheres: Wenn Schwachstellen schneller gefunden und ausgenutzt werden können, steigt der Wert sauberer Architektur, klarer Identitäten und belastbarer Betriebsprozesse. Claude Mythos Preview, das im April 2026 viel Aufmerksamkeit bekommen hat, ist für uns deshalb vor allem ein Anlass, transparent zu erklären, wie wir time cockpit betreiben, welche Sicherheitsvorkehrungen wir treffen und warum der Umstieg auf Microsoft Entra für viele Unternehmen sinnvoll ist.

Was aktuelle KI-Modelle für Cybersecurity verändern

Der konkrete Anlass für diesen Artikel ist Claude Mythos Preview. Entscheidend ist aus unserer Sicht aber weniger der Produktname als die Richtung: Aktuelle Frontier-Modelle werden bei Coding-, Reasoning- und Cybersecurity-Aufgaben deutlich stärker. Anthropic beschreibt Mythos Preview als so leistungsfähig, dass das Modell nicht allgemein veröffentlicht wurde, sondern nur einem begrenzten Kreis an Partnern im Rahmen von „Project Glasswing“ zugänglich ist. Ziel ist es, kritische Software schneller abzusichern, bevor solche Fähigkeiten breit missbraucht werden können. (Anthropic System Cards)

Besonders relevant ist dabei nicht nur, dass ein Modell einzelne Schwachstellen findet. Der kritische Punkt ist die Strecke von der Analyse bis zum praktisch nutzbaren Exploit. Moderne Modelle werden immer besser darin, mehrere Schritte eines Angriffs zu verketten: analysieren, Hypothesen bilden, testen, anpassen, Exploits ausarbeiten, weitergehen. Genau das macht die Entwicklung für Sicherheitsverantwortliche so relevant, weil damit die Hürden für sehr unterschiedliche Angreifergruppen sinken, von wenig erfahrenen Angreifern über kriminelle Gruppen bis hin zu staatlichen Akteuren.

Die AI Security Institute (AISI) in Großbritannien kommt in ihrer eigenen Evaluierung zu dem Ergebnis, dass Mythos Preview bei mehrstufigen Angriffssimulationen einen deutlichen Sprung gegenüber früheren Modellen zeigt. Die AISI formuliert zugleich nüchtern, dass solche Modelle in kontrollierten Tests bereits in der Lage zu sein scheinen, kleine und schlecht geschützte Unternehmensnetzwerke autonom anzugreifen. Das ist kein „magischer Hackerknopf“, aber ein klares Signal: Zeit, Kosten und Einstiegshürden für das Auffinden und Ausnutzen von Schwachstellen sinken weiter. Für SaaS-Anbieter heißt das nicht Panik, sondern mehr Disziplin bei Architektur, Identitäten und Betrieb.

Warum gerade Behörden und Sicherheitsverantwortliche aufhorchen

Die Aufregung rund um solche Modelle entsteht nicht nur wegen einzelner Demo-Szenarien, sondern wegen der möglichen Skalierung. Wenn Sicherheitsforschung beschleunigt wird, profitieren zunächst auch Verteidiger. Gleichzeitig steigt aber das Risiko, dass aus Forschung schneller praktisch nutzbare Exploits werden und schwach geschützte Systeme schneller und systematischer angegriffen werden können. Genau deshalb werden Sicherheitsgrundlagen, die früher „nur wichtig“ waren, in einer KI-unterstützten Bedrohungslage zu einem noch härteren Qualitätsmaßstab.

Was das für SaaS-Anbieter wie uns bedeutet

Für SaaS-Anbieter ist die richtige Reaktion aus unserer Sicht nicht Alarmismus, sondern Disziplin. Entscheidend sind nicht einzelne Marketing-Schlagworte, sondern eine Betriebsweise, die typische Fehlerflächen klein hält. Dazu gehört aus unserer Sicht vor allem eine Kombination aus:

• möglichst kleiner Angriffsfläche
• klaren und restriktiven Zugriffsrechten
• automatisierten, nachvollziehbaren Deployments
• solider Trennung von Mandanten und Identitäten
• kontinuierlicher Überwachung und Verbesserung

Genau aus dieser Perspektive möchten wir zeigen, wie wir time cockpit betreiben, mit besonderem Blick auf Angriffsfläche, Mandantentrennung, Identitäten und nachvollziehbare Änderungen.

Wie wir time cockpit betreiben

Ausschließlich Microsoft Azure, ausschließlich PaaS

Alle Services, die wir für time cockpit betreiben, laufen in Microsoft Azure. Dabei setzen wir konsequent auf Platform-as-a-Service (PaaS). Wir betreiben keine virtuellen Maschinen, keine SQL Managed Instances und keine eigene On-Premises-Serverinfrastruktur.

Der Vorteil liegt auf der Hand: Microsoft patcht und betreibt die zugrunde liegenden Plattformkomponenten, kümmert sich um physische Sicherheit, Basis-Härtung und die Verfügbarkeit der Plattform. Für uns ist das nicht primär ein Komfortargument, sondern eine bewusste Reduktion selbst zu härtender Infrastruktur. Das reduziert unsere operative Last und die Angriffsfläche deutlich. Gleichzeitig gilt auch in der Cloud das Shared-Responsibility-Modell: Microsoft verantwortet die Plattform, wir verantworten unsere Anwendung, Konfiguration, Identitäten, Berechtigungen und Prozesse.

Microsoft Azure bringt eine breite Palette an Compliance-Angeboten und Zertifizierungen mit, darunter etablierte Standards wie ISO 27001 sowie verschiedene SOC-Nachweise. Diese Basis ist für uns ein wesentlicher Baustein.

Deployments nur über CI/CD, Infrastruktur als Code

Wir deployen time cockpit ausschließlich über CI/CD-Pipelines in Azure DevOps. Manuelle Deployments auf Produktionssysteme sind nicht unser Betriebsmodell. Zusätzlich verwalten wir unsere Infrastruktur durchgängig als Infrastructure as Code (IaC).

Warum ist das sicherheitsrelevant?

• Änderungen sind versioniert und nachvollziehbar.
• Infrastruktur wird reproduzierbar statt „per Klick“ erstellt.
• Reviews werden einfacher, weil Konfigurationen im Code sichtbar sind.
• Rollbacks und kontrollierte Änderungen werden planbarer.
• Manuelle Konfigurationsfehler werden reduziert.

Gerade in einer Zeit, in der Schwachstellen schneller gefunden werden, ist nicht nur Geschwindigkeit wichtig, sondern Konsistenz. IaC hilft uns dabei, Sicherheit nicht nur zu dokumentieren, sondern wiederholbar umzusetzen und Konfigurationsdrift klein zu halten.

Redundanz, Routing und kontrollierter Netzwerkverkehr

Unsere Infrastruktur ist redundant ausgelegt. Das betrifft sowohl Azure SQL Database als auch App Services. Je nach Last betreiben wir zwischen fünf und fünfzehn App-Service-Instanzen.

Vor unseren Services steht Azure Front Door. Das bringt uns mehrere Vorteile:

• zentrale Richtlinien für eingehenden Webverkehr
• flexibles Routing und kontrollierte Rollouts
• besseres Staging, weil wir einzelne Kunden oder Benutzer gezielt auf bestimmte Instanzen leiten können

Für ausgehende Verbindungen nutzen wir in unserer Architektur ein NAT Gateway. Das ist nicht „das eine große Security-Feature“, aber es ist ein sinnvoller Baustein für kontrollierten Netzwerkverkehr: Es liefert vorhersehbare ausgehende IP-Adressen, erleichtert Whitelisting und erlaubt keine unaufgeforderten eingehenden Internetverbindungen über diesen Weg.

Zwischen App Services und Datenbanken nutzen wir Service Endpoints. Damit bleibt der Verkehr auf dem Azure-Backbone, und wir können den Zugriff auf definierte Netzbereiche einschränken. Auch das reduziert die Angriffsfläche.

Mandantentrennung auf Datenbankebene

Ein besonders wichtiger Punkt ist für uns die Trennung von Kundendaten. Bei time cockpit hat jeder Kunde eine eigene Datenbank. Unsere Multi-Tenancy ist also nicht nur logisch über Schemata oder Tabellenfilter getrennt, sondern tatsächlich auf Datenbankebene umgesetzt. Das ist für uns keine technische Randnotiz, sondern eine der wichtigsten Sicherheitsentscheidungen im Produktdesign.

Darüber hinaus hat jeder Benutzer einen eigenen Connection String und einen eigenen Datenbankbenutzer. Wenn ein Benutzer deaktiviert wird, passiert das nicht nur in der Anwendung, sondern zusätzlich auf Datenbankebene. Diese Trennung ist aus unserer Sicht ein wesentlicher Sicherheitsvorteil.

Schutzmechanismen in Azure SQL Database und App Service

Unsere Datenbanken sind mit 35 Tagen Point-in-Time-Restore konfiguriert. Damit können wir im Fehlerfall auf einen früheren Zeitpunkt zurückgehen. Zusätzlich profitieren wir von Funktionen, die Azure SQL bereits mitbringt:

• automatische Backups
• Transparent Data Encryption (TDE)
• Microsoft Defender for SQL
• SQL Vulnerability Assessment

Die Datenbanken werden also nicht nur gesichert, sondern auch regelmäßig auf sicherheitsrelevante Auffälligkeiten und Konfigurationsprobleme geprüft.

Auf Ebene von Azure App Service nutzen wir die integrierten Plattformfunktionen für TLS, Skalierung und Monitoring. Daten werden sowohl in Transit als auch at Rest verschlüsselt. Zusätzlich führen wir nächtliche Datenbankwartungen durch, insbesondere bei Statistiken und Indizes, damit Performance und Stabilität auch im laufenden Betrieb sauber bleiben.

Ergänzend härten wir auch angrenzende Infrastruktur, die für Missbrauchsszenarien wie Phishing oder Spoofing relevant ist. Dazu gehören Verbesserungen bei SPF, DKIM und DMARC für unsere Mail-Domänen sowie CAA-Einträge im DNS, damit der Kreis zulässiger Zertifizierungsstellen bewusst eingegrenzt wird. Gerade bei Social-Engineering-Angriffen sind solche Bausteine nicht alles, aber sie sind ein sinnvoller Teil eines belastbaren Gesamtkonzepts. (Microsoft Learn zu DMARC und Anti-Spoofing, Microsoft Learn zu DNS Record Types in Azure)

Authentifizierung und Zugriff nach dem Prinzip „so wenig wie nötig“

Für Authentifizierung setzen wir ausschließlich auf Microsoft Entra. Das gilt sowohl für time cockpit selbst als auch für unsere Authentifizierung gegenüber der Azure-Umgebung, in der time cockpit betrieben wird.

Obwohl wir ein kleines Team sind, hat nur ein eng eingeschränkter Kreis Zugriff auf Azure-Ressourcen. Und selbst dort gilt: Kein Zugriff ohne konkreten Bedarf. Standardmäßig besteht kein Zugriff unserer Mitarbeitenden auf Kundendatenbanken.

Wenn in Ausnahmefällen, etwa im Support, ein erhöhter Zugriff erforderlich ist, nutzen wir Privileged Identity Management (PIM). PIM erlaubt eine temporäre, nachvollziehbare Rechtevergabe nach dem Just-in-Time-Prinzip. Rollenvergaben werden geloggt und können auditiert werden. Dauerhafte, breite Administratorrechte vermeiden wir bewusst.

Gerätesicherheit, DevSecOps und Abhängigkeiten

Unsere eigenen Geräte werden über Microsoft Intune verwaltet. BitLocker und Microsoft Defender sind Pflicht. Zusätzlich überwachen wir, ob veraltete Software auf den Geräten installiert ist. Multi-Faktor-Authentifizierung ist für uns selbstverständlich. Unsichere zweite Faktoren wie SMS oder Telefonanrufe sind deaktiviert. Als Fallback verwenden wir Hardware-Tokens.

Organisatorisch haben wir wöchentliche DevSecOps-Termine, in denen wir Komponenten, Konfigurationen und Auffälligkeiten prüfen. Wenn wir Anomalien erkennen, versuchen wir proaktiv zu reagieren, statt erst im Incident-Modus zu improvisieren.

Wir überwachen zudem aktiv Schwachstellen in verwendeten npm-Paketen. Parallel führen wir Renovate ein beziehungsweise bauen dessen Nutzung weiter aus. Renovate ist ein Werkzeug, das verfügbare Updates für Abhängigkeiten automatisch erkennt und als Pull Requests vorbereitet. Dadurch werden Sicherheitsupdates weniger leicht übersehen.

Wenn wir Schnittstellen bauen, bevorzugen wir moderne Authentifizierungsverfahren. Wo das technisch nicht möglich ist, nutzen wir zumindest klar eingeschränkte Personal Access Tokens (PATs) statt Basic Auth. Perspektivisch ist für uns dort, wo es technisch sinnvoll ist, Workload Identity Federation der nächste logische Schritt, also weg von langlebigen Secrets und hin zu vertrauensbasierten Maschinenidentitäten. (Microsoft Entra Workload Identity Federation)

Zusätzlich betreiben wir externe Health Checks von mehreren Standorten in Europa. Damit überwachen wir die Erreichbarkeit unserer Services vor den App Services und betrachten Verfügbarkeit und Auffälligkeiten nicht nur aus einem einzigen Blickwinkel.

Wir speichern keine Bezahldaten

Ein oft unterschätzter Sicherheitsaspekt ist auch die bewusste Nicht-Speicherung sensibler Daten. Wir speichern keine Kreditkarten- oder sonstigen Bezahldaten. Die Zahlungsabwicklung erfolgt über Stripe, also über einen spezialisierten Zahlungsdienstleister. Damit entfällt für uns ein ganzer Bereich sensibler Datenverarbeitung.

Was Kunden selbst tun können

Auch die beste SaaS-Architektur ersetzt keine sauberen Sicherheitsprozesse auf Kundenseite. Aus unserer Erfahrung haben sich vor allem diese Maßnahmen bewährt:

• Microsoft Entra nutzen, wenn vorhanden. Viele Unternehmen haben Entra bereits über Microsoft 365 im Haus. Damit lassen sich Single Sign-On, MFA, zentrale Benutzerverwaltung und sauberes Offboarding deutlich einfacher umsetzen. Für time cockpit ist das in der Praxis meist der wirksamste Hebel. Mehr dazu finden Sie auch bei unseren Enterprise-Funktionen.
• Falls kein Entra im Einsatz ist: keine geteilten Accounts, starke und einzigartige Passwörter, ein Passwortmanager und MFA überall dort, wo es möglich ist. Pauschale erzwungene Passwortwechsel in kurzen Intervallen halten wir dagegen nur bedingt für hilfreich; wichtiger sind gute Passwörter, gute zweite Faktoren und ein schneller Wechsel bei Verdacht oder Personaländerungen.
• Offboarding ernst nehmen. Prüfen Sie regelmäßig, ob ausgeschiedene Mitarbeitende, externe Dienstleister oder frühere Projektpartner wirklich keinen Zugriff mehr haben.
• Rollen und Berechtigungen regelmäßig überprüfen. Gerade mit der Zeit sammeln sich oft Rechte an, die niemand mehr aktiv hinterfragt.
• Eine verantwortliche Person benennen. Ein klarer Application Owner oder interner Ansprechpartner hilft enorm, wenn Benutzer angelegt, deaktiviert oder Berechtigungen überprüft werden müssen.

Viele Sicherheitsprobleme entstehen nicht durch spektakuläre Zero-Days, sondern durch alltägliche Versäumnisse: verwaiste Accounts, zu breite Rechte, fehlende MFA oder unklare Zuständigkeiten.

Genauso wichtig ist ein Punkt, der in Technikdiskussionen oft unterschätzt wird: Social Engineering. Also Angriffe, bei denen nicht primär Systeme, sondern Menschen manipuliert werden, etwa durch Phishing-Mails, gefälschte Login-Seiten oder gut vorbereitete Support-Anrufe. Wir würden Social Engineering nicht pauschal als das eine größte Einfallstor bezeichnen, aber klar als eines der wichtigsten. Der Verizon 2025 Data Breach Investigations Report zeigt, dass der menschliche Faktor in einem großen Teil der untersuchten Breaches eine Rolle spielt. Gerade deshalb helfen technische Maßnahmen wie Microsoft Entra, MFA und sauberes Offboarding nur dann wirklich, wenn sie durch Aufmerksamkeit, klare Prozesse und regelmäßige Sensibilisierung der Mitarbeitenden ergänzt werden.

Warum Microsoft Entra für viele Kunden der sinnvollste nächste Schritt ist

Wenn Sie time cockpit heute noch ohne Microsoft Entra nutzen, ist jetzt ein guter Zeitpunkt, über den Umstieg nachzudenken. Aus unserer Sicht ist das für viele Unternehmen kein Zusatzthema, sondern der praktikabelste nächste Schritt, um Identitäten, MFA, Offboarding und Richtlinien sauber zusammenzuführen. Für viele Unternehmen ist das kein großes Transformationsprojekt, sondern vor allem ein sauber geplanter Identitätswechsel mit viel praktischem Nutzen:

• Single Sign-On mit dem bestehenden Unternehmensaccount
• zentrale Benutzerverwaltung
• MFA und Richtlinien über die eigene Organisation
• weniger manuelle Arbeit beim Onboarding und Offboarding
• weniger separate Passwörter für einzelne Dienste

Wir unterstützen unsere Kunden dabei aktiv und begleiten die Umstellung strukturiert.

Fazit

Claude Mythos Preview ist vor allem eines: ein Signal dafür, dass sich Cyberrisiken weiter beschleunigen. Schwachstellen verschwinden dadurch nicht schneller, aber sie werden schneller gefunden und in manchen Szenarien schneller ausnutzbar. Genau deshalb gewinnen Architekturdisziplin, Identitätsmanagement, Automatisierung, Monitoring und klare Prozesse weiter an Bedeutung.

Die relevante Frage für SaaS-Anbieter ist deshalb nicht, ob KI klassische Sicherheitsgrundlagen ersetzt. Sie tut das nicht. Die relevante Frage ist, wie diszipliniert Architektur, Mandantentrennung, Identitäten und Betriebsprozesse aufgestellt sind. Für uns bei time cockpit heißt das: so wenig eigene Infrastruktur wie möglich, so wenig dauerhafte Rechte wie nötig, so viel Automatisierung und Nachvollziehbarkeit wie sinnvoll. Sicherheit ist kein einzelnes Feature und auch kein Zertifikatslogo, sondern das Ergebnis vieler technischer und organisatorischer Entscheidungen.

Wenn Sie Fragen zu unseren Sicherheitsmaßnahmen haben oder den Umstieg auf Microsoft Entra besprechen möchten, nehmen Sie gerne Kontakt mit uns auf. Wir unterstützen Sie gerne dabei, Ihre time-cockpit-Umgebung sicherer und einfacher administrierbar zu machen.