Plattformreife-Scorecard: wo steht Ihre Infrastruktur?
Zehn Control-Bereiche. Ein Radar-Chart. Ihre drei grössten Lücken. Kein Account nötig.
Pro Bereich den Slider auf den Ist-Zustand über alle aktiven Cloud-Provider ziehen.
Identity-Konsistenz
Jeder Engineer kann nachweisen, was er wann deployed hat, über alle Provider.
12345
FehlendNetzwerkklarheit
Traffic-Pfade zwischen Providern und ins Internet sind dokumentiert und erzwungen.
12345
FehlendIaC-Abdeckung
Die gesamte Produktionsinfrastruktur ist versioniert und ohne manuelle Schritte reproduzierbar.
12345
FehlendObservability
Jeder Produktionsservice hat einen namentlichen Owner, ein Log-Ziel und einen Alert-Pfad.
12345
FehlendKostensichtbarkeit
Sie können Spend innerhalb von 24 Stunden einem Team oder Projekt zuordnen, auf jedem Provider.
12345
FehlendSecurity-Baseline
Jeder Host und Service erfüllt eine schriftliche, automatisierte Baseline, bevor er in Produktion geht.
12345
FehlendSecret Hygiene
Keine langlebigen Credentials in Code, Images oder Config-Files.
12345
FehlendIncident-Bereitschaft
Ihr Team kann auf einen Produktionsincident reagieren, ohne den Engineer zu brauchen, der ihn gebaut hat.
12345
FehlendCompliance-Haltung
Sie können innert 1 Werktag einen Audit-Trail für Access- und Change-Events liefern.
12345
FehlendDecommission-Disziplin
Stillgelegte Workloads und Access werden in einem definierten Fenster entfernt, nicht dem Drift überlassen.
12345
FehlendIhre Scorecard
Gesamt-Reifegrad
| Control-Bereich | Score | Reifegrad |
|---|---|---|
| Identity-Konsistenz | 1 | Fehlend |
| Netzwerkklarheit | 1 | Fehlend |
| IaC-Abdeckung | 1 | Fehlend |
| Observability | 1 | Fehlend |
| Kostensichtbarkeit | 1 | Fehlend |
| Security-Baseline | 1 | Fehlend |
| Secret Hygiene | 1 | Fehlend |
| Incident-Bereitschaft | 1 | Fehlend |
| Compliance-Haltung | 1 | Fehlend |
| Decommission-Disziplin | 1 | Fehlend |
Ihre Top-3-Prioritäten
So sieht gut aus
- Ein zentraler IdP, federiert zu allen aktiven Cloud-Providern.
- Jeder menschliche Access-Eintrag hat einen namentlichen Owner und ein Review-Datum.
- Service Accounts nutzen OIDC oder provider-native Workload Identity. Keine langlebigen Keys.
- Deprovisioning eines ausscheidenden Engineers dauert unter 10 Minuten.
- Access Reviews in festem Rhythmus (quartalsweise Minimum für Produktion).
- Ein Netzwerkdiagramm existiert, ist versioniert und entspricht dem Deployed-State.
- Egress aus Produktion geht über einen kontrollierten Pfad, nicht direkt vom Compute.
- Cross-Environment-Traffic braucht explizite Konfiguration, kein Shared Networking.
- Private Endpoints für Managed Services in Produktion.
- Security-Group- und Firewall-Rules haben namentliche Owner und werden bei Änderung reviewed.
- Keine Produktionsinfrastruktur wurde ausserhalb einer nachverfolgten Änderung provisioniert.
- Neue Environments lassen sich aus Code aufsetzen, ohne die Person zu fragen, die Produktion gebaut hat.
- State Files sind remote, gelockt und access-controlled.
- Modul-Interfaces sind über die Provider hinweg standardisiert.
- CI führt terraform plan aus und verlangt Approval vor apply.
- Jeder Service in Produktion hat einen namentlichen On-Call-Owner.
- Logs landen in einem abfragbaren, retained Store (nicht nur auf der Instance).
- Mindestens ein Alert pro Service würde jemanden bei einem Incident wecken.
- Sie können "ist dieser Service gerade healthy?" beantworten, ohne per SSH auf den Host zu gehen.
- Log-Retention erfüllt Ihre Compliance-Anforderung (mindestens 90 Tage).
- Jede Resource hat ein Team- und Environment-Tag, erzwungen beim Provisioning.
- Ein täglicher oder wöchentlicher Cost-Report nach Team, nicht nur nach Account.
- Budget-Alerts feuern bevor Overspend passiert, nicht nach der Rechnung.
- Idle und untagged Resources werden mit einem namentlichen Owner zum Nachfassen gemeldet.
- Commitment- und Reservierungs-Spend wird in festem Rhythmus gegen den tatsächlichen Verbrauch geprüft.
- Eine schriftliche Baseline existiert: kein Root-SSH, verschlüsselt at rest, keine öffentlichen Ports ohne Begründung.
- Die Baseline wird in CI automatisch getestet, nicht manuell vor einem Release geprüft.
- CIS-Benchmark auf allen aktiven Providern aktiv, Findings wöchentlich reviewed.
- Keine langlebigen Credentials in Code-Repositories, CI-Secrets oder Images.
- Vulnerability Scanning läuft nach Zeitplan, nicht nur beim Erst-Deployment.
- Secret Scanning läuft in CI und blockiert Merges bei erkannten Credentials.
- Alle Application Secrets werden zur Runtime aus einem Managed Secret Store geholt.
- Keine IAM Access Keys für menschliche User. Menschlicher Access läuft über federierte Identity.
- Service Accounts nutzen OIDC oder Workload Identity. Keine manuell rotierten Keys.
- Jedes Secret lässt sich rotieren, ohne eine Application neu zu deployen oder ein Image neu zu bauen.
- Jeder Produktionsservice hat ein Runbook, geschrieben von jemand anderem als dem Primary Engineer.
- Die On-Call-Rotation umfasst mindestens zwei Personen pro Service.
- Runbooks werden mindestens einmal pro Quartal getestet.
- Alerts laufen auf eine einzige On-Call-Plattform, nicht in individuelle Inboxes.
- Post-Incident-Reviews werden innert 48 Stunden geschrieben und an einem durchsuchbaren Ort gespeichert.
- Management-Audit-Logs sind auf allen Providern aktiv und mindestens 1 Jahr retained.
- Logs liegen in einem Account, den Produktionsworkloads nicht ändern können.
- Sie können in unter 30 Minuten sagen, wer diese Resource wann geändert hat.
- Für regulierte Umgebungen: Audit-Logs fliessen in ein SIEM und werden nach Zeitplan reviewed.
- Controls des Compliance-Frameworks sind auf implementierte Controls gemappt, nicht auf Annahmen.
- Jedes aufgesetzte Environment hat einen namentlichen Owner und ein erwartetes Enddatum.
- Offboardete Engineers verlieren allen Cloud-Access innert 24 Stunden.
- Ungenutzte Resources werden wöchentlich gemeldet.
- Alte Environments werden nicht auf Vorrat behalten. Daten werden gesichert, dann abgebaut.
- Decommission ist ein tracked Work Item, kein Nachgedanke.
Möchten Sie das durchsprechen?
Sagen Sie mir, woran Sie arbeiten.