Anforderungsprofil: PAM-Pilot
Herstellerneutrales technisches Anforderungs- und Beschaffungspaket zum Entscheidungspaket „PAM-Pilot“.
Am Ende stehen ein privilegiertes Zugriffsmodell, eine priorisierte Account-/Secret-Liste, ein getesteter PAM-Pilot für ausgewählte Administrationspfade und eine Entscheidung über Vaulting, Rotation, Session-Kontrolle und weiteren Rollout.
Thema: credentials · Stand 2026-09-20Vor jeder Punktebewertung nachweisen
Diese Kriterien sind als technische Mindestnachweise formuliert. Nicht erfüllte Muss-Kriterien sollten nicht durch Komfort- oder Preisvorteile kompensiert werden.
| ID | Kriterium | Geforderter Nachweis |
|---|---|---|
| M01 | Zielbild klar trennen: Benutzer-Passwortmanager, privilegiertes PAM und Passkeys lösen unterschiedliche Probleme und dürfen nicht als austauschbar behandelt werden. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M02 | SSO, SCIM/Provisioning, Deprovisioning, Gruppen-/Rollenmodell und Break-Glass-Zugriff mit realen Identitätsprozessen testen. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M03 | Für PAM Discovery, Rotation, JIT/JEA, Session-Isolation/-Monitoring und Service-Account-Abhängigkeiten im Pilot nachweisen. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M04 | Für Passwortmanager Browser, Mobile, Sharing, Passkeys, Recovery und Export/Exit mit repräsentativen Benutzern validieren. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M05 | Master-Keys, Emergency Access, Audit-Logs, Datenexport, Self-hosting/Cloud-Betrieb und Wiederherstellung organisatorisch dokumentieren. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
Mehrwert nur mit realem Betriebsnutzen bewerten
| ID | Kriterium | Bewertungshinweis |
|---|---|---|
| K01 | Passkeys/passwordless Verfahren lassen sich für geeignete Nutzer- und Admin-Gruppen integrieren. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
| K02 | JIT/JEA oder vergleichbare zeitlich begrenzte privilegierte Berechtigungen werden unterstützt. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
| K03 | Session Recording/Command Auditing ist für definierte privilegierte Zugriffe verfügbar. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
| K04 | Datenexport, Self-hosting oder alternative Betriebsmodelle reduzieren den Exit-Aufwand. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
Fragen für Angebot, Workshop und technische Klärung
Reduziert das Zielmodell dauerhafte privilegierte Rechte und trennt Standard- von Administrationskonten?
Können privilegierte Kennwörter und technische Secrets kontrolliert gespeichert, ausgegeben und rotiert werden?
Sind privilegierte Aktivitäten, Freigaben und relevante Sitzungen ausreichend protokollierbar?
Existiert ein kontrollierter, getesteter Break-Glass-Pfad ohne dauerhaften Bypass?
Sind Verzeichnisdienste, MFA, Zielsysteme, Netzwerkzonen und Automatisierung realistisch integrierbar?
Kann das Team Onboarding, Rotation, Störungen, Recovery und Lifecycle dauerhaft betreiben?
Gates als objektive Abnahmekriterien verwenden
Für den Pilotscope ist bekannt, wer womit auf welche Systeme privilegiert zugreift und welche Secrets betroffen sind.
Der Pilot kann anhand technischer und organisatorischer Kriterien abgenommen werden.
Die Shortlist ist aus Muss-Kriterien abgeleitet und nicht aus einer pauschalen Herstellerpräferenz.
Normale Administration und Notfallzugriff funktionieren nachvollziehbar, ohne permanente Umgehung des PAM-Pfads.
Der nächste Scope ist priorisiert und berücksichtigt technische Integrationskosten sowie organisatorische Verantwortlichkeiten.
Vor Produktivsetzung klären
- Break-Glass und Emergency Access mit klarer Aufbewahrung und Review-Cadence betreiben.
- Rotation-/Discovery-Jobs sowie fehlgeschlagene Secret-Updates überwachen.
- Owner für Vaults, privilegierte Accounts und technische Identitäten benennen.
- Recovery und Wiederanlauf des Vault-/PAM-Dienstes regelmäßig testen.
Vor Vertragsbindung nachweisen
- Vault-/Credential-Daten, Policies und Auditinformationen in einem nutzbaren Format exportieren können.
- Nach Migration alle betroffenen Secrets/privilegierten Kennwörter kontrolliert rotieren.
- Break-Glass-Zugriff während Cutover und Rückfall unabhängig von der abzulösenden Plattform sicherstellen.
Gewichtete Bewertung erst nach den Muss-Kriterien
Die Gewichte ergeben zusammen 100 %. Die Skala bewertet nachgewiesene Eignung – nicht Herstellergröße oder Markenpräferenz.
| Kategorie | Gewicht | Skala | Dokumentation |
|---|---|---|---|
| Privileged/Credential Controls | 30 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Identity-Integration | 20 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Betrieb & Recovery | 20 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Nutzer-/Admin-Workflows | 15 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Commercial & Exit | 15 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
Für Pilot, Entscheidung und Vertrag dokumentieren
- Privileged-Account-Inventar
- Secret-/Owner-Matrix
- Rollen- und Freigabemodell
- Muss-/Kann-Kriterien
- Finder-Profil
- Vergleichsmatrix
- Pilotarchitektur
- Rotationstest
- Break-Glass-Protokoll
- Session-/Auditnachweis
- Betriebs-Runbook
- Rolloutentscheidung