C5-Themengebiet AM: ein Assetregister mit Klassifizierung aufbauen

Diese Seite behandelt das Themengebiet AM (Asset Management) des C5:2026, Abschnitt 5.4 des Katalogs. Wie Kriterien und Unterkriterien grundsätzlich aufgebaut sind, erklärt die Seite C5-Kriterienkatalog.

Worum geht es im Themengebiet AM?

AM regelt, wie der Cloud-Anbieter seine Assets erfasst und schützt. Der Katalog nennt als Ziel, die Identifizierung der organisationseigenen Assets zu gewährleisten und ein angemessenes Schutzniveau über ihren gesamten Lebenszyklus sicherzustellen (Abschnitt 5.4). Assets sind nach den ergänzenden Informationen zu AM-01 die Objekte im Verantwortungsbereich des Anbieters, die für die Informationssicherheit des Dienstes benötigt werden, etwa Firewalls, Loadbalancer, Webserver, Anwendungs- und Datenbankserver. Sie bestehen aus Hardware-Objekten, zu denen ausdrücklich auch virtuelle Infrastruktur-Ressourcen gehören, und Software-Objekten wie Container, Betriebssysteme, Datenbanken, Microservices und Programmierschnittstellen.

Das Gebiet umfasst zwölf Kriterien, AM-01 bis AM-12, mit 26 Basis-Unterkriterien, 2 verschärfenden und 9 erweiternden Zusatz-Unterkriterien. Sechs Kriterien sind laut Änderungshistorie neu: AM-01, AM-03, AM-04, AM-10, AM-11 und AM-12. Das Asset-Inventar ist zudem Grundlage für andere Gebiete, etwa für die Risikobeurteilung (AM-02.03B verweist auf OIS-07), die Netztopologie (COS-07.03B) und das Container-Management (OPS-34.02B verweist auf AM-02, AM-03 und AM-09).

Ein Hinweis für zweisprachige Teams: In der englischen Fassung 1.0.1 steht das erweiternde Unterkriterium zur Aktualität des Inventars als AM-01.02AC, in der deutschen Fassung 1.1.0 als AM-02.01AC. Der Inhalt ist derselbe.

Ausgangssituation: Inventar in Konsole und Tabelle

Fiktives Beispiel, kein Kunde. Ein Anbieter betreibt eine Plattform, über die Bauämter und Architekturbüros Bauanträge, Pläne und Freigaben austauschen. Rund 45 Beschäftigte, der Dienst läuft als SaaS auf der Infrastruktur eines großen Cloud-Anbieters: ein verwalteter Kubernetes-Cluster mit Microservices, eine verwaltete Datenbank, ein Objektspeicher für Pläne und Dokumente. Administratoren melden sich mit FIDO2-Sicherheitsschlüsseln an.

So sieht es vor dem Projekt aus:

• Die Cloud-Ressourcen sieht man in der Konsole der Plattform, Laptops und Sicherheitsschlüssel stehen in einer Tabelle der IT. Ein gemeinsames Inventar gibt es nicht.
• Welche Ressource welche Daten enthält und wer für sie zuständig ist, steht nirgends; einige Testressourcen haben keinen erkennbaren Zweck.
• Die Liste der Software beschränkt sich auf die eigenen Microservices. Welche Bibliotheken, Images und Datenbankversion darunter laufen, weiß nur das Betriebsteam.
• Änderungen an der Tabelle werden überschrieben, ohne Historie.
• Ein Sicherheitsschlüssel eines ausgeschiedenen Administrators ist seit Wochen nicht zurückgegeben.

Wer ist wofür verantwortlich: Anbieter, Plattform, Kunde?

Bei einem SaaS-Dienst auf fremder Infrastruktur teilt sich AM entlang der Grenze zwischen virtuellen und physischen Ressourcen. Unsere Einordnung für das Beispiel:

Wie die Rechenzentren selbst gesichert sind, gehört in das Themengebiet PS. Ob einzelne Hardware-Kriterien für Ihren Dienst anwendbar sind und wie Sie Subdienstleister einbeziehen, legen Sie mit dem Scope fest und begründen es in der Systembeschreibung. Ein Kriterium dürfen Sie dort nicht ausschließen, weil Ihre Kontrollen fehlen.

Wie sieht ein Klassifizierungsschema nach AM-09 aus?

AM-09 verlangt, dass Assets nach dem Schutzbedarf der Daten klassifiziert werden, die sie verarbeiten, speichern oder übermitteln. Den Schutzbedarf ermitteln die für Assets zuständigen Personen nach einem einheitlichen, dokumentierten Schema (AM-09.03B). Das Schema sieht Sicherheitsniveaus für Vertraulichkeit, Integrität, Verfügbarkeit und Authentizität vor, abgestimmt auf die Wiederherstellungsziele der Notfallplanung (AM-09.04B). Unser Schema für das Beispiel:

Die Zielwerte in der Spalte Verfügbarkeit sind Beispielwerte, die aus der eigenen Notfallplanung des Anbieters kommen müssen; wie Sie diese festlegen, zeigt das Themengebiet BCM. Die Stufen überprüfen Sie mindestens jährlich und bei wesentlichen Änderungen am Dienst (AM-09.02B). Klassifiziert ein Anbieter seine Assets nicht im Einzelnen, können nach den ergänzenden Informationen zu AM-09 alle Assets so behandelt werden, als bräuchten sie das höchste Sicherheitsniveau. Für kleine Dienste ist das ein möglicher Weg, nach unserer Einschätzung aber ein aufwendiger, weil dann überall die strengsten Maßnahmen gelten.

Wie sieht ein prüffähiges Assetregister aus?

AM-03.01B und AM-04.01B legen fest, was ein Eintrag leisten muss: das Asset identifizieren, Einblick in Lebenszyklus oder Abhängigkeiten geben und dem Anbieter Kontrolle und Risikobeurteilung ermöglichen. Die ergänzenden Informationen nennen dazu mögliche Felder, etwa Name, Funktion, Modell, Standort, Eigentümer und Sicherheitsanforderungen, bei Software Version und übergeordnete Ressource. Ein Asset Owner ist dabei die Person oder Rolle mit Verantwortung für Verwaltung und Schutz, kein rechtlicher Eigentümer. Der Katalog spricht vom Asset-Inventar; das Assetregister ist das Arbeitsprodukt, mit dem Sie es führen. Ein Auszug aus unserem Register für das Beispiel (Schutzbedarf als V/I/V/A in der Reihenfolge Vertraulichkeit, Integrität, Verfügbarkeit, Authentizität; das A steht hier für Authentizität, die Verfügbarkeit ist das zweite V):

Drei Punkte machen das Register prüffähig. Erstens die Erfassung: automatisch und durch die zuständigen Personen, sodass das Inventar vollständig, richtig und konsistent ist (AM-02.02B). Zweitens das Änderungsprotokoll: Änderungen an den erfassten Informationen werden protokolliert (AM-02.04B), eine überschreibbare Tabelle reicht dafür nicht. Drittens die Verbindung zu den Berechtigungen: AM-02.05B verlangt Listen der Benutzer mit Zugriff auf eine Ressource und ihrer Rechte; die dürfen aus dem Identitätsdienst kommen, wie auf der Seite IAM beschrieben. Container, die Sie selbst betreiben, inventarisieren Sie mit ihrem Lebenszyklus; die Einzelheiten dazu stehen im Gebiet OPS. Die Softwareliste für Fremdkomponenten (SBOM) gehört zu DEV.

Beispiel-Kontrollbeschreibung zu AM-02

Ein Register ist nur so gut wie sein Abgleich mit der Wirklichkeit. Unsere Beispiel-Kontrolle für den Anbieter oben (eigene Formulierung, kein Katalogtext):

Die automatische Überwachung des Inventarprozesses entspricht dem erweiternden Unterkriterium AM-02.01AC (in der englischen Fassung AM-01.02AC). Ob Sie es aufnehmen, entscheiden Sie selbst; als Arbeitsweise empfehlen wir den Abgleich auch ohne Aufnahme, weil er die Basis-Unterkriterien erst belegbar macht.

Welche Nachweise der Prüfer sehen will

Für AM sind das Register und seine Historie der zentrale Nachweis, dazu Verfahren und Protokolle für die Lebenszyklusschritte. Beispiele aus unserem Szenario:

Ein Nachweisregister ordnet jedem Unterkriterium seinen Nachweis zu; wie Sie es führen, zeigt die Seite Nachweise und Dokumentation.

Mögliche Lücken: Ursache, Wirkung, Abhilfe

Die folgenden Lücken ergeben sich aus dem Wortlaut der Kriterien und dem Szenario oben. Ist ein einziges Unterkriterium nicht erfüllt, gilt das Kriterium als nicht erfüllt, und der Prüfer berichtet die Abweichung (Abschnitte 3.4.12 und 3.4.13).

Alle Kriterien des Themengebiets AM

Titel nach der deutschen Fassung 1.1.0, Zählung der Unterkriterien nach Abschnitt 5 der deutschen Fassung (B = Basis, AS = verschärfend, AC = erweiternd). In der englischen Fassung 1.0.1 hat AM-01 zwei und AM-02 kein erweiterndes Unterkriterium. Die Spalte „Worum es geht“ ist unsere eigene Kurzbeschreibung, kein Katalogtext; verbindlich ist der Wortlaut der Kriterien im Katalog.

Unter den Zusatzkriterien sind AM-07.01AS (Außerbetriebnahme auch für Entwicklungs-, Test- und Staging-Umgebung), AM-04.01AC (Angabe, wie lange ein Software-Asset Sicherheitsupdates erhält) und AM-09.03AC und AM-09.04AC (Protokollierung und Überwachung richten sich nach dem Schutzbedarf der Assets) für SaaS-Anbieter besonders greifbar.

Bezug zu ISO/IEC 27001:2022 Anhang A

Die folgende Zuordnung ist unsere eigene, nicht amtliche Einordnung nach Thema. Das BSI hat für C5:2026 noch keine Kreuzreferenz veröffentlicht, und auch eine amtliche Tabelle zeigt nach dem Katalog nur thematische Nähe, keine Erfüllung (Abschnitt 3.3). Die Kurzbezeichnungen sind unsere, keine Titel aus der Norm. Was Sie aus einem zertifizierten ISMS insgesamt wiederverwenden können, steht auf der Seite C5 und ISO 27001.