ANOMAL Consulting

IAM- und PAM-Beratung: Identitätsarchitektur, die auch Detection trägt

ANOMAL-Consulting gestaltet Identitätsarchitektur (Verzeichnisse, Federation, externe und Gastidentitäten, Service- und Workload-Identitäten), Autorisierungsmodelle nach Least Privilege und Segregation of Duties, sowie Joiner-Mover-Leaver-Automatisierung. Bei privilegiertem Zugriff geht es um Tiering von Admin-Konten, Just-in-Time-Elevation, Session-Aufzeichnung, Break-Glass-Verfahren und Hygiene von Secrets und Service-Accounts. Sauber entworfene Identitätsarchitektur liefert zugleich das Telemetrie-Fundament für ITDR und das SOC. Jedes Mandat wird individuell abgegrenzt, es gibt eine eigene Offerte pro Kunde.

Security ServicesAlleIAM- und PAM-Beratung: Identitätsarchitektur, die auch Detection trägt

Identitätsarchitektur

Am Anfang steht die Struktur: Verzeichnis- und Tenant-Design (Single-Tenant, Multi-Tenant, getrennte Umgebungen für Test und Produktion) und Federation zu Partnern und Kunden. Dazu kommen der Umgang mit externen und Gast-Identitäten sowie Service Principals und Workload-Identitäten für Applikationen und Automatisierung. Für Microsoft-Umgebungen wird das konkret an Microsoft Entra ID durchgespielt, für andere Verzeichnisdienste bleibt die Beratung anbieterneutral.

Verzeichnis- und Tenant-Struktur mit klarer Trennung von Produktions- und Testumgebungen.
Federation-Design für Partner, Kunden und Lieferanten ohne unnötige Vertrauensausweitung.
Externe und Gast-Identitäten mit Ablaufdatum, ohne dauerhaft bestehende Konten.
Service Principals und Workload-Identitäten mit eindeutiger Zuordnung zu Applikationen. Geteilte Dienstkonten entfallen.

Autorisierungsmodell und Lifecycle

Rollen- und Berechtigungsdesign nach Least Privilege ist kein einmaliges Projekt, sondern ein Modell mit Wartung: Segregation of Duties verhindert kritische Kombinationen (z.B. Zahlungsauslösung und Zahlungsfreigabe in einer Hand), Access Reviews und Rezertifizierung entfernen ungenutzte Berechtigungen regelmässig. Der Joiner-Mover-Leaver-Prozess wird so automatisiert, dass Rollenwechsel und Austritte Berechtigungen konsistent nachziehen. So sammeln sich keine veralteten Rechte an.

Rollen- und Entitlement-Design entlang der tatsächlichen Aufgaben, nicht nach generischen Vorlagen.
Segregation of Duties für kritische Prozesse wie Finanzen, Beschaffung und Systemadministration.
Access Reviews und Rezertifizierung mit klaren Verantwortlichen und Fristen.
Automatisierte Joiner-Mover-Leaver-Prozesse, direkt ausgelöst durch HR-Ereignisse, ohne manuelle Tickets.

Privilegierter Zugriff

Tiering von Admin-Konten: Trennung zwischen Domain-Admin, Server-Admin und Workstation-Admin, damit ein kompromittiertes Konto nicht automatisch die gesamte Umgebung mitreisst.
Privilegierte Rechte nur bei Bedarf und zeitlich begrenzt (Just-in-Time).
Session-Aufzeichnung für privilegierte Sitzungen als Nachweis- und Untersuchungsgrundlage.
Break-Glass-Verfahren für Notfallzugriff mit nachträglicher Prüfung. Dauerhaft offene Hintertüren gibt es nicht.
Hygiene von Secrets und Service-Accounts: Rotation, Vault-Anbindung, Beendigung von hartcodierten Zugangsdaten.

Anbieterneutral

Die Beratung beschreibt Fähigkeiten, nicht Produktnamen. Für Microsoft-Umgebungen wird konkret auf Microsoft Entra ID eingegangen, andere PAM-Plattformen werden generisch behandelt (z.B. gängige PAM-Lösungen für Session-Broker und Vaulting).

Von Identität zu Detection: Grundlage für ITDR und SOC

Eine sauber entworfene Identitätsarchitektur ist gleichzeitig die Voraussetzung für Identity Threat Detection and Response. Anmeldeanomalien, Token-Missbrauch oder ungewöhnliche Elevation lassen sich nur erkennen, wenn Baselines aus konsistenten Rollen und Tiering stammen. Details zur Erkennungsseite stehen auf ITDR: Identity Threat Detection and Response, zu konkreten Angriffsmustern auf Token-Diebstahl und Session-Hijacking und Business Email Compromise bei M365.

Nachweise für ISO 27001 und FINMA

Dokumentierte Rollenmodelle, Access Reviews und Tiering-Nachweise sind direkt verwertbar für Audits. Details zur Nachweisführung im SOC-Kontext stehen auf ISO 27001 und SOC und FINMA-Anforderungen. Wo Governance-Themen über die technische Umsetzung hinausgehen, bleibt das eine begleitende, punktuelle Unterstützung innerhalb der Beratung, keine eigenständige Führungsrolle.

Abgrenzung zu Nachbarthemen

Angebot	Fokus	Wo es aufhört
IAM- und PAM-Beratung	Identitätsarchitektur, Autorisierungsmodell, JML-Automatisierung, privilegierter Zugriff.	Betreibt keine laufende Detection; liefert die Grundlage dafür.
Cloud- und Identity-Hardening-Projekt	Konkrete technische Umsetzung von Konfigurationen und Kontrollen in Cloud und Verzeichnisdiensten.	Setzt oft ein bereits definiertes Ziel-Rollenmodell voraus, statt es zu entwerfen.
Managed ITDR-Detection	Laufende 24/7-Erkennung und Response auf Identitätstelemetrie im SOC.	Braucht saubere Rollen und Tiering als Eingabe, sonst entstehen viele False Positives.
Zero-Trust-Architekturberatung	Übergreifendes Architekturprinzip über Netzwerk, Endpoint und Identität hinweg.	Identität ist nur eine von mehreren Säulen, nicht der alleinige Fokus.

Einordnung im SOC-Betrieb

IAM- und PAM-Beratung liefert die Datenbasis, auf der ITDR und ein SOC überhaupt zuverlässig unterscheiden können, was normal ist und was nicht. Der laufende Betrieb dazu ist auf SOC as a Service Schweiz beschrieben. Wo das übergeordnete Betriebsmodell selbst noch offen ist, ergänzt SOC-Beratung das Bild; die Übersicht aller Beratungsleistungen steht auf Security Consulting Schweiz.

Häufige Fragen

Deckt die Beratung nur Microsoft-Umgebungen ab?

Nein. Microsoft Entra ID wird als konkretes Beispiel behandelt, weil es in vielen Schweizer Umgebungen im Einsatz ist. Andere Verzeichnisdienste und PAM-Plattformen werden anbieterneutral über ihre Fähigkeiten beschrieben.

Was ist der Unterschied zu einem Hardening-Projekt?

IAM- und PAM-Beratung entwirft Architektur und Modelle. Ein Hardening-Projekt setzt konkrete Konfigurationen und Kontrollen technisch um, oft auf Basis eines bereits definierten Rollenmodells.

Wie lange dauert die Einführung von Just-in-Time-Elevation?

Das hängt von Anzahl privilegierter Konten, bestehenden Prozessen und der gewählten Plattform ab. ANOMAL legt den Scope individuell fest und stellt eine eigene Offerte pro Kunde.

Ersetzt IAM- und PAM-Beratung eine ITDR-Lösung?

Nein. Sie liefert die Grundlage (saubere Rollen, Tiering, Baselines), auf der ITDR-Erkennung erst zuverlässig funktioniert. Details auf [ITDR](/de/soc/itdr-identity-threat-detection).

Hilft die Beratung auch bei Segregation of Duties für Finanzprozesse?

Ja, Segregation of Duties für kritische Prozesse wie Zahlungsfreigaben oder Beschaffung ist Teil des Autorisierungsmodells und wird gezielt geprüft.

Weiterlesen im Cluster

ITDR: Identity Threat Detection and Response für die Schweiz

ITDR (Identity Threat Detection and Response) erkennt Angriffe auf Identitäten selbst, nicht nur auf Endpoints oder Netzwerke. Ziel sind Konten, Tokens, Sessions, Berechtigungen und Identity-Provider wie Entra ID oder Okta. ITDR erweitert EDR und SIEM um Signale, die nur im Identity-Layer sichtbar sind: Impossible Travel, Consent-Phishing, Refresh-Token-Missbrauch, Rollen-Missbrauch, Angriffe auf Federation und Directory-Objekte. Für Schweizer Unternehmen mit M365, Entra ID und regulierten Prozessen ist ITDR heute so wichtig wie EDR vor fünf Jahren.

Token-Diebstahl und Session-Hijacking erkennen und stoppen

Token-Diebstahl bedeutet, dass Angreifer den Session- oder Refresh-Token eines bereits authentifizierten Nutzers stehlen und damit MFA umgehen. Der klassische Weg ist Reverse-Proxy-Phishing (Adversary-in-the-Middle), zunehmend auch Info-Stealer auf dem Endpoint. Ein SOC erkennt das über Token-Nutzung ausserhalb des Nutzerkontexts, nicht über den Login selbst. Verteidigung heisst: phishing-resistente MFA, Continuous Access Evaluation, Token-Bindung und Detection auf Refresh-Token-Wiederverwendung.

Business Email Compromise in Microsoft 365 erkennen und stoppen

Business Email Compromise (BEC) in Microsoft 365 ist selten ein Malware-Fall, sondern eine Kette aus Phishing, Session- oder Token-Diebstahl, Inbox-Regeln und OAuth-Consent-Missbrauch. Ein SOC erkennt BEC über korrelierte Signale aus Entra ID, Exchange Online und Defender for Cloud Apps, nicht über den E-Mail-Text allein. Reaktion heisst: Session widerrufen, Inbox-Regeln entfernen, OAuth-Consents zurückziehen, MFA neu erzwingen, dokumentiert nach ISG- und Versicherungslogik.

SOC-Beratung: Zielbild, Betriebsmodell und Entscheidung vor dem Aufbau

ANOMAL-Consulting bewertet die SOC-Reife eines Unternehmens (Sichtbarkeit, Detection-Abdeckung je MITRE-Taktik, Prozess- und Eskalationsbereitschaft, Nachweisfähigkeit) und entwirft daraus ein Zielbetriebsmodell. Im Zentrum steht die Entscheidung zwischen Eigenbetrieb, Managed SOC und Co-Managed sowie die Gestaltung eines tierless, hoch automatisierten SOC statt klassischer Tier-1-Warteschlangen. Ergebnis ist ein verlässliches Betriebsdesign mit Schicht- und Abdeckungsplanung, Eskalationsmatrix und Mandat, Metriken und einem klaren Übergabeplan in den Betrieb. Jedes Mandat wird individuell abgegrenzt, es gibt eine eigene Offerte pro Kunde.

SOC as a Service in der Schweiz: Kompletter Leitfaden