IT-Infrastruktur-Audit: Was zu prüfen ist und wie man es durchführt

Ein Infrastrukturproblem spürt man meist, bevor man es benennen kann. Deployments werden langsamer, die Cloud-Rechnung steigt, ohne dass neue Nutzer es erklären, und ein Entwickler wird zur einzigen Person, die weiß, wie die Produktionsdatenbank wiederhergestellt wird. Die Frage darunter ist einfach: Ist dieses Setup sicher und bereit zu wachsen, oder nur eine schlechte Nacht von einem schweren Ausfall entfernt?

Ein Infrastruktur-Audit ist eine strukturierte Überprüfung jedes Systems, auf dem Ihre Software läuft: Hosting, Datenbanken, Deployment-Pipelines, Backups, Netzwerk, Sicherheit und Cloud-Ausgaben, gemessen daran, wie es funktionieren sollte, damit das, was ausfallen, zu viel kosten oder sich der Skalierung verweigern wird, ans Licht kommt, bevor daraus Ausfallzeit, ein Sicherheitsvorfall oder eine ungeplante Rechnung wird.

Dieser Leitfaden behandelt, was eine gründliche Überprüfung prüft, welche Ausfälle sie verhindert und den wiederholbaren Prozess dahinter, aus der Erfahrung, dies sowohl als eigenständiges Software-Audit als auch als erste Phase größerer Rettungsprojekte durchzuführen.

Was ein IT-Infrastruktur-Audit tatsächlich abdeckt

Der Umfang liegt eine Ebene unter einem Code-Review. Ein Code-Review fragt, ob die Anwendung gut geschrieben ist, während dieser fragt, ob der Boden, auf dem sie steht, solide ist: die Server, das Netzwerk, die Datenspeicher und das Geld, das durch all das fließt. Eine gute Überprüfung beruht auf Belegen statt auf Meinungen, sodass jeder Befund auf eine Konfigurationsdatei, eine Dashboard-Kennzahl oder eine fehlende Kontrolle verweist, und zwei Entwickler, die dasselbe System betrachten, zum selben Schluss kommen.

Sie liefert außerdem eine priorisierte Liste, denn zu wissen, dass neunzig Dinge besser sein könnten, zählt weniger als zu wissen, welche fünf Ihnen zuerst schaden werden.

Ausfälle, die ein IT-Infrastruktur-Audit verhindert

Die meisten schweren Vorfälle sind gewöhnliche Lücken, die monatelang sichtbar waren, bis sie die Produktion im schlechtesten Moment lahmlegten. Eine Überprüfung fängt sie ab, solange sie noch billiger Papierkram sind und keine Krise. Zu den wiederkehrenden Fehlermodi gehören:

• Single Points of Failure, bei denen ein einzelner Server oder das Laptop einer einzelnen Person das Einzige ist, was zwischen Ihnen und einem Ausfall steht.
• Stilles Verrotten von Backups, bei dem Backups jede Nacht grün durchlaufen, aber nie wiederhergestellt wurden, sodass niemand weiß, dass sie unbrauchbar sind, bis man sie braucht.
• Konfigurationsdrift, die der Annual Outage Analysis 2025 des Uptime Institute bei fast 40 % der Organisationen mit einem größeren Ausfall in den letzten drei Jahren auf menschliches Versagen zurückführt, meist auf Personal, das sich nicht an das Verfahren hält.
• Kapazitätsblindheit, bei der das System nie auf dem Verkehrsniveau getestet wurde, das der Wachstumsplan des nächsten Quartals voraussetzt.

Sie früh abzufangen ist der Unterschied zwischen einem Dienstags-Ticket und einem Krisenstab am Wochenende, und es kostet an einem ruhigen Tag weit weniger als mitten im Vorfall.

Was zu prüfen ist: der Umfang des Infrastruktur-Audits

Der schnellste Weg, eine Überprüfung ehrlich zu halten, ist, von einem festen Umfang auszugehen, damit nichts übersprungen wird, weil es langweilig ist. Die Tabelle unten ist die Übersichtskarte; die Unterabschnitte danach erklären, wie „gut“ in jeder Ebene aussieht.

Hosting und Server

Beginnen Sie mit dem, worauf alles andere läuft: ob der Ausfall einer einzelnen Maschine das gesamte Produkt lahmlegt, ob Betriebssystem und Laufzeitumgebungen auf eine unterstützte Version gepatcht sind und ob genug Spielraum bei CPU, Arbeitsspeicher und Festplatte besteht, um eine Verkehrsspitze aufzufangen, statt bei einer umzukippen. Ein Server bei 90 % Arbeitsspeicher an einem ruhigen Nachmittag hat keinen Spielraum mehr für einen geschäftigen Morgen, und ein abgelaufenes SSL-Zertifikat bleibt einer der häufigsten und am leichtesten vermeidbaren selbstverschuldeten Ausfälle.

Datenbanken

Die Datenbank ist meist der Ort, an dem eine Wachstumsgeschichte still zu einer Zuverlässigkeitsgeschichte wird. Prüfen Sie die Indizierung der Abfragen, die tatsächlich in der Produktion laufen, ob Replikation und Failover vorhanden sind und wie schnell die Daten im Verhältnis zu der Festplatte wachsen, auf der sie liegen. Eine Abfrage, die bei 10.000 Zeilen in zwanzig Millisekunden antwortet, kann sich bei zehn Millionen auf zwei Sekunden verlangsamen, und diese Kurve bleibt unsichtbar, bis ein Nutzer auf sie stößt.

Langsame Abfragen und fehlende Indizes sind die beiden Befunde, die in fast jeder Datenbankprüfung auftauchen, und beide lassen sich günstig beheben, sobald jemand sie benennt.

Deployment-Pipelines und CI/CD

Ein Release-Prozess ist sicher, wenn ein neuer Entwickler in seiner ersten Woche ausliefern und in unter einer Minute zurückrollen kann, und riskant, wenn nur eine Person die Abfolge auswendig kennt. Die Überprüfung prüft, ob Builds und Deployments automatisiert sind, ob ein echter Rollback-Pfad existiert und ob Secrets sicher eingespeist statt in Skripte eingefügt werden. Diese Phase an etablierten SDLC-Best-Practices auszurichten, ist oft die wirkungsvollste Änderung, die ein Mittelstandsteam vornehmen kann.

Manuelle Deployments fügen zu verlorener Zeit auch Risiko hinzu: Ermüdung und Tippfehler während einer manuellen Abfolge sind es, die ein routinemäßiges Freitags-Deployment in einen ungeplanten Ausfall verwandeln.

Infrastructure as Code

Infrastructure as Code bedeutet, dass Server, Netzwerke und Richtlinien in versionierten Dateien definiert werden, statt von Hand in einer Konsole zusammengebaut zu werden. Das Audit prüft, wie viel der Umgebung auf diese Weise erfasst ist und ob die laufenden Systeme von dem abgewichen sind, was diese Dateien beschreiben. Von Hand gebaute Infrastruktur ist wie ein Haus ohne Baupläne: brauchbar, bis jemand geht und niemand es zweimal auf dieselbe Weise nachbauen kann. Der praktische Test: Wenn eine Region ausfiele, könnten Sie die Umgebung aus dem Repository neu erstellen, oder würden Sie sie unter Druck aus dem Gedächtnis rekonstruieren?

Backups und Notfallwiederherstellung

Backups sind erst real, sobald sie wiederhergestellt wurden. Dieser Teil der Überprüfung bestätigt, dass zwei Kennzahlen vereinbart sind: das Recovery Point Objective, wie viele Daten Sie sich zu verlieren leisten können, und das Recovery Time Objective, wie lange Sie sich einen Ausfall leisten können, und verifiziert dann beide mit einer tatsächlichen Testwiederherstellung. Ein Backup, das Sie nie wiederhergestellt haben, ist eine Hoffnung, kein Plan.

Behandeln Sie es wie eine Versicherung: Sie wollen nicht am Tag des Brandes entdecken, dass die Police ein Loch hat.

Kostenprofil

Geld ist ebenso ein Zuverlässigkeitssignal wie eine Finanzfrage, denn Verschwendung bedeutet meist, dass Ressourcen bereitgestellt werden, ohne dass jemand hinsieht. Die Überprüfung fahndet nach ungenutzten Instanzen, überdimensionierten Maschinen und nicht getaggten Ressourcen, die es unmöglich machen, zu erkennen, welches Team was ausgibt. Harness prognostizierte in seinem Bericht FinOps in Focus 2025, dass 2025 allein für ungenutzte Ressourcen rund 44,5 Milliarden US-Dollar an Ausgaben für Cloud-Infrastruktur verschwendet würden.

Das Warnzeichen, auf das man achten sollte: eine Rechnung, die schneller wächst als Ihre aktiven Nutzer, was fast immer bedeutet, dass Sie für Kapazität zahlen, die niemand nutzt.

Netzwerk- und Sicherheitsprüfungen im Audit

Zuverlässigkeit und Sicherheit überschneiden sich so stark, dass eine ernsthafte Überprüfung sie als einen einzigen Durchgang behandelt, und manche Teams beauftragen diesen Teil für sich als Audit der Netzwerkinfrastruktur und Sicherheit, wenn Compliance oder ein Kundenvertrag es verlangt. Es steht Konkretes auf dem Spiel: Der Cost of a Data Breach Report 2025 von IBM bezifferte die weltweiten Durchschnittskosten einer Datenpanne auf 4,4 Millionen US-Dollar, ein seltener Rückgang gegenüber dem Vorjahr, getrieben von schnellerer Erkennung und Eindämmung.

Firewall-Regeln

Firewall-Regeln sammeln sich an wie Kram in einer Schublade: während eines Vorfalls schnell hinzugefügt und selten wieder entfernt, sobald er vorbei ist. Die Überprüfung liest den tatsächlichen Regelsatz und markiert alles allzu Freizügige, besonders Regeln, die Verwaltungsports oder Datenbanken dem offenen Internet aussetzen. Eine Firewall, die alles erlaubt, ist ein Türsteher, der die ganze Straße hereinwinkt, was schlimmer ist als gar kein Türsteher, weil es ein falsches Sicherheitsgefühl schafft.

Segmentierung, VLANs und geringste Rechte

Flache Netzwerke sind bequem und gefährlich, denn sobald ein Angreifer in einem drin ist, kann er alles erreichen. Gute Segmentierung begrenzt den Wirkungsradius, sodass eine Kompromittierung in einer Zone nicht auf den Rest übergreifen kann. Dieser Teil der Überprüfung prüft typischerweise:

• Ob Produktion, Staging und interne Tools auf getrennten Segmenten oder VLANs liegen statt in einem einzigen flachen Raum.
• Ob Dienste nur die konkreten Systeme erreichen können, die sie brauchen, nach dem Prinzip der geringsten Rechte statt der Bequemlichkeit.
• Ob interner Datenverkehr verschlüsselt ist, nicht nur der zum öffentlichen Internet gerichtete Verkehr.

Zugriffskontrollen und MFA

Die letzte Prüfung betrifft, wer hineinkommt und wie schwer es wäre, sich als diese Person auszugeben. Prüfen Sie, ob Multi-Faktor-Authentifizierung für jedes Administratorkonto erzwungen wird, ob Zugriff nach Rolle vergeben statt dauerhaft ausgehändigt wird und ob ehemaligen Mitarbeitern und veralteten Dienstkonten die Berechtigungen tatsächlich entzogen wurden. Verwaiste Administratorkonten sind eines der leisesten Risiken in jeder Umgebung, denn sie tragen volle Rechte und niemand behält sie im Blick.

Cloud-Infrastruktur

Cloud-Umgebungen verdienen einen eigenen Durchgang, da ihre Fehlermodi sich von denen eines Racks physischer Server unterscheiden. Die Überprüfung untersucht Richtlinien für Identity and Access Management, Auto-Scaling, die Aufteilung zwischen reservierten und On-Demand-Preisen und ob Managed Services dort eingesetzt werden, wo sie die Betriebslast senken würden. Die Cloud macht Resilienz und Kosteneffizienz möglich, ohne beides zu garantieren, und das Audit misst, was Ihr Setup tatsächlich liefert.

Ein häufiger Befund ist ein Lift-and-Shift, das On-Premises-Gewohnheiten in die Cloud kopiert hat, sodass das Unternehmen Cloud-Preise für ein Design zahlt, das nie Cloud-Vorteile wie Elastizität oder Managed Databases übernommen hat. Das zu entwirren ist genau die Arbeit, die ein dediziertes DevOps-Consulting-Engagement angeht, da die Lösungen Kosten, Zuverlässigkeit und die Deployment-Pipeline gemeinsam umspannen.

Wie man ein IT-Infrastruktur-Audit durchführt, Schritt für Schritt

Zu wissen, wie man IT-Infrastruktur auditiert, läuft auf eine wiederholbare Abfolge hinaus.

1. Legen Sie Umfang und Standard fest. Entscheiden Sie, welche Systeme im Umfang sind und was „gut“ für jedes bedeutet, gemessen an vereinbarten Zielen, nicht am persönlichen Geschmack.
2. Prüfen Sie alles. Erstellen Sie eine echte Karte von Servern und Abhängigkeiten, denn Sie können nicht auditieren, was Sie nicht aufgeschrieben haben.
3. Sammeln Sie Belege. Ziehen Sie Konfigurationsdateien, Zugriffsprotokolle und Kostenberichte heran, damit jede Schlussfolgerung auf einem Artefakt beruht.
4. Testen Sie die Behauptungen. Führen Sie eine Wiederherstellung durch, lösen Sie ein Rollback aus und lasttesten Sie einen kritischen Pfad, denn Annahmen über Resilienz sind wertlos, bis sie erprobt sind.
5. Ordnen Sie Befunde nach Risiko und Aufwand. Trennen Sie das, was am schnellsten schadet, von dem, was ein langsames Schwelen ist, die Disziplin, die man beim Auditieren des Softwareentwicklungsprozesses anwendet.
6. Liefern Sie einen Bericht mit Verantwortlichen und Terminen. Ein Befund ohne Verantwortlichen und Frist ist eine Notiz, keine Lösung.

Testen vor der Inventur bedeutet, die falschen Dinge zu testen, und Berichten vor dem Priorisieren lässt das Team ohne Ausgangspunkt zurück.

Wie oft sollten Sie das Audit durchführen?

Es gibt keine einzig richtige Taktung, da sie davon abhängt, wie schnell Sie sich verändern. Eine praktikable Regel: Stabile Systeme erhalten eine leichte vierteljährliche Kontrolle und eine vollständige jährliche Überprüfung, während jede größere Änderung ihren eigenen gezielten Durchgang verdient.

Der häufigste Fehler ist, das Audit als Aufräumaktion statt als Gewohnheit zu behandeln. Lassen Sie einen Zyklus aus, und die Umgebung driftet binnen eines Jahres dorthin zurück, wo sie begann.

Was der Auditbericht enthält

Das Ergebnis ist der Punkt, an dem die Arbeit nützlich wird, und ein schwacher Bericht ist der Grund, warum viele Audits nichts ändern. Ein starker ist konkret genug, dass ein Entwickler ohne Folgemeeting danach handeln kann. Er enthält mindestens:

• Eine Management-Zusammenfassung in klarer Sprache, damit ein nicht technischer Entscheider die wichtigsten Risiken und die empfohlenen Ausgaben auf einer Seite sieht.
• Eine priorisierte Befundliste, jeder Punkt nach Risiko und Behebungsaufwand bewertet.
• Belege für jeden Befund, ein Konfigurationsausschnitt, eine Kennzahl oder eine Kostenaufschlüsselung.
• Eine Behebungs-Roadmap mit Verantwortlichen und groben Zeitrahmen.
• Ein Retest-Plan, denn ein Befund gilt erst als geschlossen, wenn jemand die Behebung verifiziert.

Hundert gleich gewichtete Warnungen sagen dem Leser nichts darüber, wo er anfangen soll, und Teams, denen ein solcher Bericht ausgehändigt wird, handeln meist nach keiner davon.

Machen Sie das Audit zur Gewohnheit

Die Systeme, auf denen Ihr Produkt läuft, fallen anfangs selten lautstark aus. Sie driften, sammeln kleine Kompromisse an und konzentrieren das Wissen auf ein oder zwei Personen, bis ein gewöhnlicher Dienstag zu einem Ausfall, einer überzogenen Rechnung oder einem Sicherheitsvorfall wird, dessen Eindämmung Monate dauert. Eine disziplinierte Überprüfung verwandelt diese leisen Risiken in eine kurze, priorisierte Liste von Dingen, die Sie tatsächlich beheben können.

Teams, die dies als wiederkehrende Gewohnheit statt als einmalige Hauruckaktion behandeln, skalieren ohne Drama, weil sie die Schwachstelle vor ihren Nutzern finden. Wenn Sie ein erfahrenes Team wollen, das genau diese Übung an echten Produktionssystemen durchgeführt hat, um sie durchzuführen oder Ihres zu unterstützen, kontaktieren Sie uns, und wir stecken den Umfang gemeinsam mit Ihnen ab.

Erfahren Sie, wie wir die Adoorabelle-Codebasis geprüft, 80 versteckte Probleme aufgedeckt und 3.600 $/Jahr an Infrastrukturkosten eingespart haben

Bitte geben Sie Ihre Geschäfts-E-Mail-Adresse ein ist keine Geschäfts-E-Mail

Fallstudie erhalten

FAQ