Sicherheit & Governance

AWS IAM sauber aufsetzen: Ein Berechtigungskonzept, das im Audit standhält

Die meisten Zwischenfälle in AWS-Konten beginnen nicht mit einer Sicherheitslücke, sondern mit einem Zugriffsschlüssel, der zu viel darf und zu lange gilt. Wer konsequent auf Rollen mit kurzlebigen Anmeldedaten umstellt, nimmt der häufigsten Angriffskette die Grundlage. Der Rest ist Handwerk: messen, welche Rechte tatsächlich genutzt werden, den Rest wegnehmen und die Leitplanken so setzen, dass eine einzelne Fehlkonfiguration folgenlos bleibt.

5 Kapitel mit allen Befehlen

Passende Kurse ansehen Persönlich beraten lassen

Betriebsingenieur analysiert Kosten- und Monitoring-Dashboards an drei Bildschirmen

Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team

Worum es geht

Woran Berechtigungskonzepte in der Praxis scheitern

Der Anfang ist immer harmlos. Ein Konto wird für ein Projekt aufgesetzt, jemand legt einen Benutzer mit Zugriffsschlüssel an, damit ein Skript Daten kopieren kann, und weil die Zeit drängt, bekommt dieser Benutzer eine weit gefasste Richtlinie. Zwei Jahre später existiert der Schlüssel noch, das Skript nicht mehr, und niemand traut sich, ihn zu löschen. Genau solche Schlüssel tauchen in Repositories, Protokollen und Container-Abbildern auf, und sie sind der bequemste Einstiegspunkt, den ein Angreifer bekommen kann.

Das zweite Muster ist die Berechtigung nach Zuruf. Ein Dienst funktioniert nicht, jemand hängt eine breitere Richtlinie an, die Fehlermeldung verschwindet, und die Berechtigung bleibt für immer. Nach ein paar Dutzend solcher Vorgänge kann niemand mehr sagen, warum eine Rolle darf, was sie darf. Das Prinzip der geringsten Rechte scheitert dabei selten an der Absicht, sondern daran, dass niemand misst, welche Rechte tatsächlich benutzt werden. Ohne Messung bleibt jedes Zurückschneiden ein Ratespiel mit Ausfallrisiko, und deshalb passiert es nicht.

Im Audit wird daraus ein Nachweisproblem. Prüfstellen für ISO 27001 oder für ein Testat nach BSI C5 fragen nicht, ob ein Konzept existiert, sondern wie ihr die Umsetzung belegt: Wer hat welche Rechte, wer hat sie vergeben, wann wurden sie zuletzt überprüft, und wie werden sie wieder entzogen. Bildschirmfotos aus der Konsole sind dafür kein Beleg. Belegbar wird es erst, wenn Rechte aus Code entstehen, Änderungen versioniert und begründet sind und Berichte automatisch erzeugt werden.

Miniatur-Szene: Leitstand mit steigender Kostenanzeige, Münzstapel neben einer Cloud, Lupe über einem Leck

Fünf Ebenen der Zugriffssteuerung in AWS

01 Getrennte Konten je Umgebung als äußerste Grenze
02 Service Control Policies als Leitplanke je Konto
03 Permission Boundaries als Decke delegierter Rollen
04 Rollen mit kurzlebigen Anmeldedaten statt Schlüsseln
05 Bedingungen und Ressourcenrichtlinien für den Einzelfall
06 Access Analyzer und CloudTrail als laufender Nachweis

Was du mitnimmst

Fünf Ebenen, die zusammen ein Konzept ergeben

Ein tragfähiges Berechtigungskonzept besteht nicht aus einer großen Richtlinie, sondern aus mehreren Ebenen, die unterschiedliche Fragen beantworten. Sie greifen ineinander und lassen sich einzeln einführen, in dieser Reihenfolge.

Rollen statt Benutzer, kurzlebig statt dauerhaft

Menschen melden sich über IAM Identity Center an und übernehmen dort eine Rolle, Maschinen bekommen eine Rolle über das Instanzprofil, über EKS Pod Identity oder über einen OIDC-Verbund. In allen Fällen laufen die Anmeldedaten von selbst ab und werden automatisch erneuert. Langlebige Zugriffsschlüssel bleiben nur dort, wo es nachweislich keine Alternative gibt, und dann mit Rotation und Ablaufdatum.

Geringste Rechte messen, nicht schätzen

AWS liefert die Daten mit: Der Anmeldedatenbericht zeigt ungenutzte Schlüssel und Passwörter, die Dienstzugriffshistorie zeigt je Rolle, welche Dienste in den letzten Monaten wirklich verwendet wurden, und IAM Access Analyzer erzeugt aus CloudTrail-Ereignissen einen Richtlinienvorschlag. Damit wird das Zurückschneiden zu einer belegbaren Maßnahme statt zu einem Experiment im Produktivbetrieb.

Leitplanken über Service Control Policies

In einer Organisation mit mehreren Konten legen SCPs fest, was in einem Konto überhaupt möglich ist, unabhängig davon, was eine einzelne Rolle erlaubt. Typische Leitplanken sind die Beschränkung auf erlaubte Regionen, das Verbot, Protokollierung abzuschalten, und der Schutz zentraler Rollen. SCPs erteilen keine Rechte, sie begrenzen nur, und genau deshalb sind sie im Audit ein starkes Argument.

Permission Boundaries für delegierte Vergabe

Wenn Teams eigene Rollen anlegen dürfen sollen, ohne sich selbst höhere Rechte verschaffen zu können, ist die Permission Boundary das Mittel der Wahl. Sie setzt eine Obergrenze, die auch für neu erzeugte Rollen gilt. So bleibt die Geschwindigkeit im Team erhalten, während die Sicherheitsabteilung nur die Decke definiert, statt jede einzelne Richtlinie freizugeben.

Nachweise laufend erzeugen

CloudTrail als Organisationspfad, AWS Config mit Regeln für IAM, Access Analyzer für externen Zugriff und für ungenutzte Rechte, dazu ein wiederkehrender Bericht mit Datum. Wer diese vier Quellen zusammenzieht, beantwortet die Standardfragen einer Prüfung aus dem System heraus, statt vor jedem Termin Belege zusammenzusuchen und Lücken zu erklären.

Tutorial

Vom Bestand über die Umstellung bis zum belegbaren Nachweis

Die meisten Zwischenfälle in AWS-Konten beginnen mit einem Zugriffsschlüssel, der zu viel darf und zu lange gilt, deshalb ist die Abschaffung langlebiger Schlüssel der wirksamste Einzelschritt. Alles Weitere ist Handwerk, und es beginnt bei der Bestandsaufnahme, weil ohne Zahlen niemand einer Umstellung zustimmt. Danach folgen der Ersatz der Schlüssel durch Rollen, das gemessene Zurückschneiden der Rechte, die Leitplanken über Organisation und Boundaries und zuletzt die Nachweise, die eine Prüfung sehen will.

Schritt 1: Aufnehmen, wer heute was darf

Vor jeder Umstellung steht eine ehrliche Bestandsaufnahme. Die beiden wichtigsten Berichte holst du in wenigen Befehlen, und sie zeigen fast immer mehr, als das Team erwartet hat.

Anmeldedatenbericht und langlebige Schlüssel

aws iam generate-credential-report
aws iam get-credential-report --query Content --output text \
  | base64 -d > kontenbericht.csv

# Wer hat langlebige Schluessel und wann wurden sie zuletzt benutzt?
for u in $(aws iam list-users --query 'Users[].UserName' --output text); do
  aws iam list-access-keys --user-name "$u" \
    --query 'AccessKeyMetadata[].[UserName,AccessKeyId,Status,CreateDate]' \
    --output text
done

aws iam get-account-summary

Der Bericht enthält je Benutzer, wann Passwort und Schlüssel zuletzt genutzt wurden und ob eine mehrstufige Anmeldung aktiv ist. Alles, was seit mehr als neunzig Tagen unbenutzt ist, ist zunächst ein Kandidat für die Deaktivierung, nicht sofort für die Löschung. Deaktivieren ist umkehrbar, löschen nicht.

Welche Rechte werden tatsächlich genutzt?

ROLLE=$(aws iam get-role --role-name build-runner --query 'Role.Arn' --output text)

JOB=$(aws iam generate-service-last-accessed-details --arn "$ROLLE" \
  --query JobId --output text)

aws iam get-service-last-accessed-details --job-id "$JOB" \
  --query 'ServicesLastAccessed[?TotalAuthenticatedEntities>`0`].[ServiceName,LastAuthenticated]' \
  --output table

Die Dienstzugriffshistorie reicht bis zu ein Jahr zurück. Dienste, die dort nie auftauchen, kannst du der Rolle mit vertretbarem Risiko entziehen. Achte auf saisonale Läufe wie Jahresabschlüsse, bevor du eine Berechtigung entfernst, die nur einmal jährlich gebraucht wird und trotzdem geschäftskritisch ist.

Schritt 2: Zugriffsschlüssel durch Rollen ersetzen

Der wirksamste Einzelschritt ist die Abschaffung langlebiger Schlüssel. Für Menschen übernimmt das IAM Identity Center, für Systeme außerhalb von AWS der Verbund über OIDC.

Anmeldung und Rollenübernahme ohne Schlüssel

# Menschen: Anmeldung ueber IAM Identity Center, Anmeldedaten laufen ab
aws configure sso --profile prod-admin
aws sts get-caller-identity --profile prod-admin

# Uebergangsweise: Rolle uebernehmen statt Schluessel verteilen
aws sts assume-role \
  --role-arn arn:aws:iam::111122223333:role/deploy \
  --role-session-name pipeline-$(date +%s) \
  --duration-seconds 3600

assume-role liefert Anmeldedaten mit Ablaufdatum. Wähle die Sitzungsdauer so kurz wie möglich, denn ein abgegriffenes Token verliert damit von selbst seine Wirkung. Für Zugriffe durch Dienstleister kommt zusätzlich die Bedingung sts:ExternalId dazu, sonst genügt die Kenntnis der Rollen-ARN.

Vertrauensrichtlinie für eine Pipeline ohne hinterlegte Schlüssel

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com"
    },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": {
        "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
      },
      "StringLike": {
        "token.actions.githubusercontent.com:sub": "repo:meine-org/mein-repo:ref:refs/heads/main"
      }
    }
  }]
}

Die Bedingung auf sub ist der entscheidende Teil. Sie begrenzt die Rollenübernahme auf Organisation, Repository und Verzweigung. Prüfe die Zeile nach jeder Umbenennung eines Repositories erneut, sonst schlägt entweder die Pipeline fehl oder die Bedingung passt auf mehr, als beabsichtigt war.

Schritt 3: Rechte messen und zurückschneiden

Access Analyzer beantwortet zwei Fragen: Welche Ressourcen sind von außerhalb erreichbar, und welche Rechte liegen ungenutzt herum. Beide Antworten braucht ihr regelmäßig, nicht einmalig vor dem Audit.

Externen Zugriff und ungenutzte Rechte finden

# Externen Zugriff organisationsweit pruefen (kostenfrei)
aws accessanalyzer create-analyzer \
  --analyzer-name extern-org --type ORGANIZATION

# Ungenutzte Rollen, Schluessel und Berechtigungen aufspueren
aws accessanalyzer create-analyzer \
  --analyzer-name ungenutzt --type ORGANIZATION_UNUSED_ACCESS \
  --configuration '{"unusedAccess":{"unusedAccessAge":90}}'

aws accessanalyzer list-findings-v2 \
  --analyzer-arn "$ANALYZER_ARN" \
  --filter '{"status":{"eq":["ACTIVE"]}}' --max-results 25

Die Prüfung auf externen Zugriff ist kostenfrei, der Analysator für ungenutzten Zugriff wird je überwachter Rolle oder Benutzer abgerechnet. Fang mit der kostenfreien Variante an und ergänze die zweite, sobald die offensichtlichen Funde abgearbeitet sind.

Richtlinien prüfen, bevor sie ausgerollt werden

aws accessanalyzer validate-policy \
  --policy-document file://richtlinie.json \
  --policy-type IDENTITY_POLICY \
  --query 'findings[].[findingType,issueCode,findingDetails]' --output table

# Wirkung gegen eine bestehende Rolle simulieren, bevor umgestellt wird
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::111122223333:role/build-runner \
  --action-names s3:PutObject kms:Decrypt \
  --resource-arns arn:aws:s3:::artefakte-prod/*

Beide Aufrufe gehören in die Pipeline, nicht auf den Laptop. validate-policy meldet Sicherheitswarnungen und unnötig breite Aktionen, simulate-principal-policy beantwortet vorab, ob eine engere Richtlinie den Betrieb bricht. Das ist der Unterschied zwischen einer geplanten Umstellung und einer nächtlichen Rückabwicklung.

Bedingungen, die im Alltag am meisten bringen

Bedingungsschlüssel	Wirkung	Typischer Einsatz
aws:PrincipalOrgID	Nur Aufrufer aus der eigenen Organisation	Bucket- und Schlüsselrichtlinien gegen fremde Konten absichern
aws:RequestedRegion	Nur erlaubte Regionen	Datenhaltung auf EU-Regionen begrenzen und Wildwuchs verhindern
aws:MultiFactorAuthPresent	Nur mit zweitem Faktor	Rollen mit erhöhten Rechten und unwiderrufliche Löschaktionen
aws:SecureTransport	Nur über TLS	Zugriff auf Objektspeicher ohne Transportverschlüsselung ausschließen
sts:ExternalId	Nur mit vereinbartem Geheimnis	Rollenzugriff durch Dienstleister und Werkzeuge Dritter
aws:PrincipalTag	Rechte anhand von Merkmalen	Zugriff je Team oder Umgebung ohne eine eigene Rolle je Team

Schritt 4: Leitplanken über Organisation und Boundaries

Rollen regeln, was jemand darf. Leitplanken regeln, was in einem Konto überhaupt möglich ist. Erst beides zusammen ergibt ein Konzept, das eine einzelne Fehlkonfiguration übersteht.

scp-nur-europa.json: Regionen begrenzen, Protokollierung schützen

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "NurEuropa",
      "Effect": "Deny",
      "NotAction": [
        "iam:*", "sts:*", "organizations:*", "account:*",
        "support:*", "health:*", "budgets:*", "ce:*", "cur:*",
        "cloudfront:*", "route53:*", "waf:*", "shield:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["eu-central-1", "eu-west-1"]
        }
      }
    },
    {
      "Sid": "ProtokollierungSchuetzen",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail",
        "config:DeleteConfigurationRecorder"
      ],
      "Resource": "*"
    }
  ]
}

Globale Dienste wie IAM, STS, CloudFront und Route 53 melden sich mit einer festen Region und müssen deshalb ausgenommen werden. Wer das vergisst, legt beim ersten Rollout die eigene Kontoverwaltung lahm und braucht das Verwaltungskonto, um wieder hereinzukommen. Wichtig: Auch Abrechnung und Kostenanalyse melden sich in us-east-1 an. Wer budgets und ce in der Ausnahmeliste vergisst, verliert nach dem Ausrollen den Blick auf die eigene Rechnung.

Leitplanke anlegen und Obergrenze für delegierte Rollen setzen

aws organizations create-policy --name nur-europa \
  --type SERVICE_CONTROL_POLICY --content file://scp-nur-europa.json

# Erst an eine Test-Organisationseinheit haengen, nie direkt an die Wurzel
aws organizations attach-policy --policy-id p-beispiel --target-id ou-test

# Obergrenze fuer Rollen, die Teams selbst anlegen duerfen
aws iam put-role-permissions-boundary \
  --role-name team-deploy \
  --permissions-boundary arn:aws:iam::111122223333:policy/grenze-team

Hänge eine neue SCP zuerst an eine Organisationseinheit mit einem einzigen Testkonto. Der Rückweg ist zwar einfach, aber in der Zwischenzeit stehen im schlechten Fall alle Rollouts, und der Fehler fällt erst auf, wenn ein Dienst in einer nicht erlaubten Region aufgerufen wird.

Schritt 5: Nachweise erzeugen, die im Audit halten

Der letzte Schritt entscheidet, ob aus einem guten Aufbau auch ein bestandenes Audit wird. Nachweise entstehen laufend, nicht in der Woche vor dem Termin.

Organisationsweite Protokollierung und gezielte Abfrage

aws cloudtrail create-trail --name org-trail \
  --s3-bucket-name protokolle-org \
  --is-organization-trail --is-multi-region-trail
aws cloudtrail start-logging --name org-trail

# Wer hat zuletzt Rechte an Rollen veraendert?
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=AttachRolePolicy \
  --query 'Events[].[EventTime,Username,Resources[0].ResourceName]' --output table

Der Protokollspeicher gehört in ein eigenes Konto, auf das die Betriebsteams keinen Schreibzugriff haben, zusätzlich mit Objektsperre. Andernfalls kann derselbe Zugang, der einen Fehler verursacht hat, auch dessen Spuren entfernen, und der Nachweis ist im Audit wertlos.

Was eine Prüfung regelmäßig sehen will

Eine versionierte Rechtematrix, die Rollen auf Aufgaben abbildet.Ohne die Zuordnung von Rolle zu Aufgabe lässt sich Angemessenheit nicht beurteilen. Eine Liste aus der Konsole zeigt den Ist-Zustand, aber nicht die Absicht dahinter, und genau danach wird gefragt.
Beleg, dass Rechte mindestens jährlich überprüft und dokumentiert entzogen wurden.Die wiederkehrende Überprüfung ist in ISO 27001 und in BSI C5 ein eigener Prüfpunkt. Ein Bericht aus Access Analyzer mit Datum und nachgewiesener Nachbearbeitung erfüllt ihn, eine mündliche Zusicherung nicht.
Mehrstufige Anmeldung für alle Zugänge mit erhöhten Rechten, einschließlich des Kontostammbenutzers.Der Stammbenutzer wird übersehen, weil ihn niemand benutzt. Er kann alles, auch Leitplanken abschalten, und ist deshalb regelmäßig der erste Prüfpunkt im Gespräch.
Alle Änderungen an IAM laufen über Code mit Freigabe durch eine zweite Person.Nur so entsteht eine lückenlose Historie mit Begründung. Handänderungen in der Konsole erscheinen zwar in CloudTrail, aber ohne fachlichen Grund und ohne Freigabe, und damit fehlt der Prüfung die halbe Antwort.
Getrennte Konten je Umgebung, mindestens Produktion getrennt von Entwicklung.Die Kontogrenze ist die stärkste Trennung, die AWS anbietet. Innerhalb eines Kontos hängt jede Trennung an korrekten Richtlinien, und die kann eine einzelne Fehlkonfiguration aufheben.

Wenn diese Grundlagen stehen, ist der nächste sinnvolle Schritt die Verankerung im Aufbau neuer Konten, damit jedes neue Projekt automatisch mit Protokollierung, Leitplanken und Kennzeichnung startet, statt sie nachträglich zu bekommen. Wie dieser Rahmen aussieht, beschreibt die Seite zur Landing Zone. Auf der Microsoft-Seite stellt sich dieselbe Frage unter anderen Namen, dort geht es um Entra ID und rollenbasierte Zugriffssteuerung, nachzulesen unter Entra ID statt Active Directory.

Passende Kurse

Kurse zu AWS IAM und Berechtigungen bei cmt

Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein Team.

AWS Security Essentials 1 Tag Präsenz nächster Termin 14.10.2026 Zum Kurs AWS Security Best Practices 1 Tag Präsenz nächster Termin 30.09.2026 Zum Kurs Security Engineering on AWS 3 Tage Präsenz nächster Termin 31.08.2026 Zum Kurs AWS Security Governance at Scale 1 Tag Präsenz nächster Termin 25.09.2026 Zum Kurs

Unverbindlich beraten lassen Alle AWS-Kurse ansehen

Wissen prüfen

Teste dich und finde deinen Weg

Bevor du einen Kurs buchst, lohnt sich eine ehrliche Standortbestimmung. Die Tests sind kostenlos und ohne Anmeldung.

Wissenstest AWS Cloud Practitioner Quiz Bereite dich auf die AWS CLF-C02 Prüfung vor. Teste dein Wissen zu EC2, S3, IAM, VPC und Cloud-Konzepten. Quiz starten

Gut zu wissen

Häufige Fragen zu AWS IAM und Berechtigungen

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt

Wann sind IAM-Benutzer mit Zugriffsschlüssel noch vertretbar?

Nur dort, wo weder Rollenübernahme noch Verbund möglich sind, etwa bei älterer Software eines Drittanbieters, die ausschließlich statische Schlüssel unterstützt. Dann gehören drei Dinge dazu: ein eigener Benutzer je Zweck statt eines Sammelkontos, eine eng gefasste Richtlinie mit Bedingungen auf Quelladresse oder Organisation, und ein dokumentierter Rotationsplan mit Ablaufdatum. Für Menschen gibt es diese Ausnahme nicht mehr, weil IAM Identity Center jeden Anmeldefall abdeckt. Prüfe den Bestand mit dem Anmeldedatenbericht, meist bleiben von zwanzig Benutzern zwei übrig.

Wie schneide ich Rechte zurück, ohne den Betrieb zu stoppen?

In drei Stufen. Erst messen: Die Dienstzugriffshistorie zeigt je Rolle, welche Dienste im letzten Jahr genutzt wurden. Dann eine engere Richtlinie bauen und mit aws iam simulate-principal-policy gegen die tatsächlich benötigten Aktionen prüfen. Zuletzt umstellen und die abgelehnten Aufrufe in CloudTrail beobachten, statt die alte Richtlinie sofort zu löschen. Plane den Wechsel außerhalb von Abschlussterminen, denn Quartals- und Jahresläufe brauchen Rechte, die in einer Momentaufnahme fehlen. Der Rückweg ist immer das erneute Anhängen der alten Richtlinie.

Was ist der Unterschied zwischen SCP und Permission Boundary?

Beide begrenzen, aber auf unterschiedlichen Ebenen. Eine Service Control Policy gilt für ein ganzes Konto oder eine Organisationseinheit und legt fest, was dort maximal möglich ist, unabhängig von einzelnen Rollen. Eine Permission Boundary hängt an einer einzelnen Rolle oder einem Benutzer und deckelt genau diese Identität, auch wenn ihr später eine großzügige Richtlinie angehängt wird. In der Praxis kombiniert man beides: SCPs setzen die Hausregeln, Boundaries erlauben es Teams, innerhalb dieser Regeln eigene Rollen anzulegen, ohne sich selbst höherzustufen.

Reicht ein sauberes IAM für ein Testat nach BSI C5?

IAM ist ein Baustein, kein Testat. C5 fragt über die Zugriffssteuerung hinaus nach Betriebsprozessen, Protokollierung, Änderungsmanagement, Notfallvorsorge und Steuerung von Dienstleistern. Wichtig ist außerdem die Zuständigkeitsgrenze: Der Anbieter belegt seinen Teil über sein eigenes Testat, ihr belegt den Teil, der in eurem Konto liegt, und genau dort sitzt IAM. Praktisch heißt das, die Anforderungen auf konkrete Nachweise abzubilden, etwa Berichte zur wiederkehrenden Rechteprüfung, Protokolle mit Manipulationsschutz und dokumentierte Freigaben für Rechteänderungen.

Welche Zertifizierung passt zum Thema und wie lange gilt sie?

AWS Certified Security Specialty mit dem Prüfungscode SCS-C03, 65 Fragen in 170 Minuten. Sie geht deutlich über IAM hinaus und deckt Erkennung, Reaktion auf Vorfälle sowie Infrastruktur- und Datensicherheit ab. Ein anderes Zertifikat wird nicht vorausgesetzt, wohl aber solide Betriebserfahrung. AWS-Zertifikate gelten drei Jahre und lassen sich ausschließlich durch eine erneute Prüfung verlängern, eine kostenlose Onlineverlängerung wie bei Microsoft gibt es nicht. Plane die Neuprüfung deshalb rechtzeitig ein, sonst fällt der Nachweis ausgerechnet während eines Audits weg.

Quellen

Zuletzt geprüft am 26. Juli 2026.

Echte Stimmen aus unseren IT-Kursen

“

Der Trainer konnte die Inhalte sehr gut vermitteln. Ich habe dabei viel gelernt.

Rückmeldung aus dem Kurs „Monitoring mit Prometheus und Grafana - Grundkurs“

“

Der Kursinhalt entsprach voll meinen Erwartungen, die richtige Mischung aus Theorie und Praxis.

Rückmeldung aus dem Kurs „Kubernetes Grundkurs“

Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Cloud-Programm den passenden Kurs oder Lernpfad zu finden.

0800 71 20000 E-Mail

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.