Funktionen

Alle Funktionen, gegliedert nach Job-to-be-done

ip·Solis ist klar fokussiert. Hier ist die vollständige Funktionsbreite, geordnet nach dem Team, das sie am meisten nutzt.

Self-Service

  • MitarbeiterportalEine dedizierte „My IT"-Ansicht zeigt jedem Mitarbeitenden alle aktiven Assets mit Verlängern-, Ändern-, Zurückgeben- und Stornieren-Aktionen an einem Ort. Der Anfragekatalog ist berechtigungsbasiert gefiltert, sodass jeder Nutzer nur die für ihn freigegebenen Assets sieht. Kostenhochrechnung, Datenklassifizierungs-Badges und assetspezifische Hilfetexte werden bereits beim Ausfüllen der Anfrage angezeigt — kein Ticket, keine Admin-Beteiligung.
  • Berechtigungsbasierter KatalogDer Katalog filtert dynamisch auf Assets, für die der Anfragende berechtigt ist — basierend auf AD-Gruppenmitgliedschaft, Abteilung oder expliziten Freigaben in der Asset-Definition. Das Anfrageformular passt sich dem Attributschema des Assets an und zeigt PII-, PHI- und PCI-Warnungen inline, damit Anfragende die Datenklassifizierung kennen, bevor sie absenden.
  • One-Click-GenehmigungGenehmigungsanfragen werden per E-Mail mit einem signierten Token-Link verschickt, der Genehmigung oder Ablehnung ohne Portal-Login ermöglicht. Führungskräfte können auch direkt aus einem Microsoft-Teams-Kanal per Adaptive Card handeln. Vertretungsregeln erlauben die Vorkonfiguration von Stellvertretern für geplante Abwesenheiten, und bedingte Multi-Approver-Workflows mit N-von-M-Quorum stehen für regulierte Asset-Typen zur Verfügung.
  • AuftragszeitleisteJeder Auftrag durchläuft eine definierte Zustandsmaschine — Pending Approval, Scheduled, Processing, Provisioning, Provisioned — sichtbar in einer Live-Statusansicht, die der Mitarbeitende jederzeit einsehen kann. Pro-Schritt-Runbook-Output, Laufzeiten und Fehlermeldungen sind im Auftragsdetail abrufbar, sodass Operatoren Fehler ohne Datenbankzugriff diagnostizieren können.
  • Stornieren und entziehenMitarbeitende können eigene Aufträge stornieren, solange das Runbook noch nicht gestartet ist. Nach der Provisionierung löst die Zurückgeben-Aktion das konfigurierte Deprovision-Runbook aus, das den Zugriff entzieht und — je nach Richtlinie — das Asset in den Pool zurückführt oder zur Neuinstallation vormerkt. Jede Aktion wird mit vollständiger Zuordnung im Audit-Log festgehalten.

Lebenszyklus & Asset Pool

  • Asset-DefinitionenEine einzige Asset-Definition hält Zuweisungsmodell, Provisionierungs- und Deprovision-Runbooks, Berechtigungsregeln, Attribute, Kosten und Datenklassifizierung an einem Ort fest. Jeder Auftrag für diesen Typ erbt diese Einstellungen automatisch, sodass Änderungen sofort wirksam werden, ohne bestehende Datensätze anzufassen.
  • Pool-ZuweisungPool-Assets schöpfen aus einem gemeinsamen Kapazitäts-Bucket — bei Anfrage wird eine freie Instanz zugeteilt, bei Rückgabe geht sie in den Pool zurück und wird optional per Wipe-Runbook neu aufgesetzt. Echtzeit-Dashboard-Kacheln zeigen Frei-, Belegt-, Neuinstallation- und Fehler-Zählungen mit Warnungen ab ≥ 80 % und kritischer Hervorhebung ab ≥ 95 % Auslastung.
  • Personal-ZuweisungPersonal-Assets erstellen oder reservieren eine dedizierte Instanz pro Nutzer — geeignet für individuell zugewiesene Arbeitsplätze, namentliche SaaS-Lizenzen oder jede Ressource, bei der eine feste Identität-Asset-Bindung erforderlich ist. Kapazitätslimits und Ablaufdaten werden pro Typ erzwungen, und Verlängerungsanfragen durchlaufen dieselbe Genehmigungspipeline wie neue Anfragen.
  • Recycle-WorkflowsWenn ein Asset zurückgegeben wird oder abläuft, legt die Deprovision-Richtlinie den weiteren Weg fest: reiner Zugriffsentzug, saubere Rückführung in den Pool oder ein vollständiges Neuinstallations-Runbook, das die Maschine löscht und als Frei markiert. Jede Richtlinie wird unabhängig pro Asset-Typ konfiguriert, sodass ein gemeinsamer Lab-Desktop und eine namentliche SaaS-Lizenz unterschiedliche Wege ohne eigenes Skript gehen.
  • Leaver-DeprovisionierungEine SCIM-2.0-Deaktivierung oder ein direkter HR-Webhook widerruft automatisch alle aktiven Aufträge des ausscheidenden Nutzers und startet für jedes Asset das zugehörige Deprovision-Runbook. Ausstehende Genehmigungen, bei denen der Leaver als Genehmiger vorgesehen war, werden ersetzt, damit Warteschlangen nicht ins Stocken geraten. Der Ablauf ist idempotent — dasselbe Event mehrfach für denselben Nutzer zu senden ist stets ungefährlich.

Automatisierung & Runbooks

  • Nativer PowerShell-7-Workerip·Solis betreibt einen nativen pwsh-7-Worker auf Linux, sodass bestehende AD-, SCCM-, XenServer- und VMware-Skripte unverändert laufen — ohne Windows-Host oder Wrapper-Schicht. PSGallery-Module können zur Build-Zeit installiert oder manuell hochgeladen werden; jedes Modul wird mit einem Linux-Kompatibilitäts-Flag versehen, damit der Worker Windows-Only-Module automatisch überspringt.
  • Verkettete Runbook-SchritteRunbooks bestehen aus geordneten Schritten, die jeweils ein gespeichertes PowerShell-Modul mit konfigurierbaren statischen Parametern und Template-Variablen wie {{order.username}} oder {{asset.name}} aufrufen. Jeder Schritt protokolliert Eingabe, strukturierten JSON-Output, Laufzeit in Millisekunden und etwaige Fehlermeldungen im Auftragslog und liefert damit eine vollständige Ausführungsspur.
  • Critical-Step-SemantikJeder Schrittfehler hält das Runbook sofort an und versetzt den Auftrag in den Zustand Failed, wobei die Fehlermeldung in der Admin-UI sichtbar wird — ohne weitere Verarbeitung. Das verhindert Teilprovisionierungszustände, bei denen etwa eine AD-Gruppe hinzugefügt wurde, eine SCCM-Tasksequenz aber nie startete, und stellt sicher, dass kein Fehler unbemerkt bleibt.
  • Cron-PläneStandalone-Runbooks können mit Standard-Cron-Ausdrücken (Minute, Stunde, Tag, Monat, Wochentag) und konfigurierbarer Zeitzone geplant werden. Jeder geplante Lauf wird mit Pro-Schritt-Output in einer Laufhistorie gespeichert; der Scheduler prüft jede Minute auf fällige Jobs und sichert jeden Lauf mit Überlappungsschutz pro Asset ab.
  • ÜberlappungsschutzEin per-Asset-Ausführungslock stellt sicher, dass parallele Provisionierungs- und Deprovisionierungs-Jobs für dasselbe Asset nie gleichzeitig gestartet werden. Das verhindert Race Conditions in mehrstufigen Runbooks, die AD-Gruppenmitgliedschaft, VM-Power-State oder SCCM-Collections ändern — und macht aggressive Cron-Zeitpläne ohne defensives Scripting sicher.

Compliance & Audit

  • Access-Certification-KampagnenKampagnen definieren einen Scope — nach Asset-Typ, Kostenstelle, Abteilung oder einzelnen Nutzern — und materialisieren eine Review-Zeile pro aktivem Auftrag je zuständige Führungskraft. Führungskräfte erhalten signierte Token-URLs per E-Mail und können Zugriff bestätigen oder entziehen ohne Portal-Login. Überfällige Reviews können per konfigurierbarer Frist automatisch widerrufen werden, und Beweisexporte stehen pro Kampagne für ISO 27001-, SOX- und PCI-DSS-Prüfungen zur Verfügung.
  • Append-only Audit-LogDas Audit-Log ist durch PostgreSQL-Before-Trigger geschützt, die alle DELETE-, UPDATE- und TRUNCATE-Operationen auf Datenbankebene blockieren — nicht nur auf Anwendungsebene. Jede Zeile enthält Entität, Aktion, einen vollständigen Vorher-Nachher-JSON-Diff und einen präzisen Zuordnungsstring, der Portal-Nutzer, Admin-Sitzungen, namentliche API-Tokens, One-Click-Genehmigungslinks und automatisierte Systemaufgaben unterscheidet. Secrets werden nie in Diffs aufgenommen.
  • SCIM-2.0-EndpunktDer /scim/v2/-Endpunkt nimmt Provisionierungs- und Deaktivierungsereignisse von Okta, SailPoint, Ping, Entra ID und jedem SCIM-konformen Identity Provider entgegen. Provisionierungsaufrufe werden als No-Op bestätigt (ip·Solis führt kein eigenes Nutzerverzeichnis); ein DELETE oder PATCH mit active=false löst sofort den vereinheitlichten Leaver-Flow über alle aktiven Aufträge aus.
  • HR-Leaver-WebhookEin dedizierter Webhook unter /hr/leaver nimmt Payloads von Workday, SAP SuccessFactors, Microsoft-Graph-Change-Notifications und eigenen Systemen über integrierte Payload-Adapter entgegen. Die Authentifizierung unterstützt wahlweise HMAC-SHA256-Body-Signierung oder einen scoped Bearer Token (hr:leaver-Scope), sodass jedes Quellsystem seinen eigenen widerrufbaren Credential trägt.
  • BeweisexportAudit-Log-Einträge können nach Entitätstyp, Akteur, Zeitfenster und Änderungstyp gefiltert und dann als CSV exportiert werden. Zertifizierungskampagnen-Ergebnisse umfassen Pro-Review-Entscheidungen, Zeitstempel und Reviewer-Zuordnung — den vollständigen Nachweis, den externe Auditoren zur Prüfung der Zugriffskontrolle benötigen.

FinOps & Kosten

  • Kostenreport pro ProviderDie Provider-Ansicht aggregiert den prognostizierten Monatsaufwand nach der Kostenstelle jedes Asset-Typs und gibt Plattform-Teams eine Echtzeitübersicht darüber, was jedes von ihnen betriebene System die Organisation kostet. Tägliche historische Snapshots ermöglichen retrospektive Analysen, ohne Live-Auftragsdaten zu verlieren.
  • Kostenstellen- und AbteilungssichtDie Verbraucher-Ansicht aggregiert nach den AD-Attributen, die zum Zeitpunkt der Auftragserfassung vom Anfragenden gespeichert wurden — Abteilung, Kostenstelle, Unternehmen und Mitarbeiter-ID. Da es sich um unveränderliche Snapshots auf dem Auftragsdatensatz handelt, bleibt der Report korrekt, selbst wenn der Anfragende später das Team wechselt oder die Organisation verlässt.
  • Schwellwert-AlarmePro Kostenstellen-Ausgabenobergrenzen lösen E-Mail-Benachrichtigungen und Microsoft-Teams-Adaptive-Cards aus, sobald der prognostizierte Monatsaufwand das Limit überschreitet. Ein Ruhe-Fenster (Standard 24 Stunden) verhindert Alarm-Spam bei Aufwand nahe am Schwellwert, und eine Schwellwert-Bearbeitung setzt den Alarm-Timer sofort zurück, sodass der nächste Schwellwertbruch immer benachrichtigt.
  • CSV-ExportDie vollständige Pro-Auftrag-Kostenaufschlüsselung — mit Anfragenden-HR-Identität, Asset-Typ, Monatskosten und Kostenstelle — kann jederzeit als CSV exportiert werden. Der Export deckt alle Auftragsursprünge ab (Portal, API, ServiceNow-Webhook), sodass Finance- und Chargeback-Workflows einen einzigen kohärenten Datensatz erhalten.

Integrationen

  • Active DirectoryDer PowerShell-7-Worker spricht ADWS nativ mit NTLM-Signierung oder Kerberos-Authentifizierung. Runbook-Schritte können Nutzer zu Sicherheitsgruppen hinzufügen oder daraus entfernen, Attribute setzen und das Verzeichnis abfragen. Die Vorgesetztenbeziehung wird zum Zeitpunkt der Auftragserfassung live für das Genehmigungs-Routing aufgelöst — nicht gespeichert — sodass Änderungen in der Berichtslinie automatisch berücksichtigt werden.
  • SCCMDie SCCM-Integration umfasst Geräteimport, Task-Sequence-Auslösung via WinRM und AdminService-REST-API-Aufrufe mit Kerberos-Authentifizierung. Eine integrierte Status-Probe pollt den Task-Sequence-Abschluss asynchron und setzt den Auftragsstatus automatisch weiter, sodass das Runbook den Celery-Worker-Thread nicht blockiert, während SCCM ein OS-Image ausrollt.
  • XenServer / VMwareVM-Lebenszyklus-Operationen — Klonen, Ein-/Ausschalten, Snapshot, Löschen — sind als PowerShell-Module implementiert (PowerCLI für vSphere, XenAPI für XenServer/XCP-ng) und werden aus Runbook-Schritten aufgerufen. SSL-Bypass für selbstsignierte Zertifikate ist vorkonfiguriert, und Stdin-Injection übernimmt interaktive Prompt-Workarounds, damit Labor- und Air-Gapped-Umgebungen ohne Skriptanpassungen funktionieren.
  • SCIM-2.0-IdPsDer /scim/v2/-Endpunkt integriert Okta, SailPoint, Ping Identity, Entra ID und jeden RFC-7644-konformen Identity Provider. Nutzer-Erstell- und Aktualisierungsaufrufe werden als No-Op bestätigt; Deaktivierungsaufrufe — DELETE oder PATCH active=false — lösen den vereinheitlichten Leaver-Flow aus, der alle aktiven Aufträge widerruft und Deprovision-Runbooks startet.
  • Generischer WebhookDer ServiceNow-Inbound-Webhook nimmt HMAC-SHA256-signierte Payloads entgegen und erstellt Aufträge durch dieselbe Genehmigungs- und Runbook-Pipeline wie Portal-Anfragen. AD-Attribute des Anfragenden werden zum Erstellungszeitpunkt als Snapshot gespeichert, sodass ServiceNow-Aufträge korrekt in Kostenstellen- und Abteilungsaufschlüsselungen neben Portal- und API-Aufträgen erscheinen.

Sicherheit

  • Scoped API-TokensNamentliche Tokens (Format: xpat_…) werden nur einmalig bei der Erstellung angezeigt und als SHA-256-Hash gespeichert. Jeder Token trägt einen oder mehrere granulare Scopes — admin:read, orders:write, scim:write, hr:leaver u. a. — und kann an eine bestimmte Admin-Rolle gebunden werden. Ein Mint-Guard verhindert Privilege-Escalation: Ersteller können nur Tokens mit ihrer eigenen Rolle oder darunter ausstellen.
  • Admin-RBACFünf Rollen — superadmin, admin, approver, auditor, helpdesk — legen fest, was jedes Admin-Konto sehen und ändern kann. Per-Asset-Typ-ACL-Grants schränken einzelne Admins zusätzlich auf eine Teilmenge von Asset-Definitionen ein, sodass Operatoren nur sehen, was sie verwalten. Eine Separation-of-Duties-Prüfung verhindert, dass der Admin, der einen Asset-Typ konfiguriert hat, Zugriffsanfragen dafür genehmigt.
  • Secret-HandlingAlle Integrations-Credentials — AD-Bind-Passwort, SMTP, vSphere, XenServer, SCCM, Teams-Webhook — werden in der app_config-Tabelle gespeichert, nie in Umgebungsvariablen oder Container-Images. Jeder Secret-konfigurierte Schlüssel kann auf einen externen Store (HashiCorp Vault, CyberArk CCP, Azure Key Vault, AWS Secrets Manager oder Conjur) verweisen, der bei Lesezugriff mit einem 60-Sekunden-TTL-Cache aufgelöst wird.
  • TLS überallAlle externen Endpunkte erzwingen TLS am Reverse Proxy; Plain-HTTP-Verbindungen werden abgelehnt. SCIM, HR-Webhook, Portal und Admin-API verlangen TLS, und SMTP ist ausschließlich TLS-konfiguriert. Der interne Container-zu-Container-Datenverkehr läuft ausschließlich über das isolierte Docker-Netzwerk.
Alle Funktionen, gegliedert nach Job-to-be-done — ip·Solis