Das TNSystem-Journal

IT neu denken: Eine Infrastruktur aufbauen, die im Alltag trägt

Neue Hardware allein macht noch keine gute IT. Entscheidend ist, wie Netzwerk, Daten, Sicherheit und Arbeitsabläufe zusammenpassen.

IT-Praxis13 Min. Lesedauer
Illustration einer modernen IT-Umgebung mit Server, Netzwerkplan und Arbeitsplätzen für eine sichere und skalierbare Infrastruktur.
Illustration zum Beitrag. TN, 06.10.2026.

Planung vor der Einkaufsliste

Ein neuer Server, schnelle Rechner und eine leistungsfähige Internetverbindung: Damit lässt sich eine Einkaufsliste füllen. Eine durchdachte IT-Infrastruktur entsteht daraus noch nicht.

Für mich beginnt die Planung mit anderen Fragen. Welche Aufgaben müssen zuverlässig funktionieren? Welche Daten dürfen keinesfalls verloren gehen? Wer kümmert sich um die Systeme, wenn etwas ausfällt? Und kann jemand anderes die Umgebung übernehmen, ohne sie erst mühsam entschlüsseln zu müssen?

Wer seine IT neu aufbaut, bekommt die Gelegenheit, solche Fragen grundsätzlich zu klären. Diese Gelegenheit sollte nicht damit vertan werden, alte Probleme auf neue Geräte zu übertragen.

IT neu zu denken bedeutet nicht, möglichst viel Technik einzusetzen. Es bedeutet, die passende Technik so einzusetzen, dass sie die Arbeit dauerhaft unterstützt.

Erst verstehen, was gebraucht wird

Bevor ein Gerät bestellt oder ein Cloudvertrag abgeschlossen wird, gehört der tatsächliche Bedarf auf den Tisch.

Welche Anwendungen werden verwendet? Wo liegen die dazugehörigen Daten? Wer arbeitet im Büro, wer unterwegs? Welche Geräte benötigen Netzwerkzugang? Welche Leistungen hängen von einem externen Dienstleister ab?

Das amerikanische National Institute of Standards and Technology empfiehlt in seinem am 26. Februar 2024 veröffentlichten Leitfaden für kleine Unternehmen, zunächst Hardware, Software, Systeme und Dienste zu erfassen. Ebenso wichtig ist die Bewertung, welche Folgen deren Ausfall für den Betrieb hätte. [1]

Für einen kleinen Handwerksbetrieb könnte das beispielsweise bedeuten: Auftragsverwaltung, E-Mail, Kundenunterlagen und mobile Endgeräte haben Vorrang. Ein Entwicklungsbüro könnte dagegen hohe Anforderungen an große Projektdateien, Rechenleistung und Versionsverwaltung stellen. Die gleiche Einkaufsliste würde beiden kaum gerecht.

Auch eine vorhandene Umgebung sollte dabei kritisch betrachtet werden. Eine Anwendung muss nicht allein deshalb übernommen werden, weil sie seit Jahren läuft. Vielleicht erfüllt inzwischen eine andere Lösung ihren Zweck besser. Vielleicht lässt sich ein unnötig komplizierter Ablauf vereinfachen.

Am Ende dieser Bestandsaufnahme sollte verständlich festgehalten sein, was die neue Infrastruktur leisten soll. Erst danach beginnt die Auswahl der Komponenten.

Verfügbarkeit braucht konkrete Ziele

„Die IT darf nicht ausfallen“ klingt verständlich, hilft bei der Planung aber wenig. Eine belastbare Entscheidung braucht genauer beschriebene Anforderungen.

Zwei Begriffe sind dafür nützlich: RTO bezeichnet das Ziel für die Wiederherstellungszeit. RPO beschreibt, bis zu welchem Datenstand eine Wiederherstellung möglich sein muss und damit, welcher zeitliche Datenverlust höchstens akzeptiert wird. Diese Unterscheidung erläutert NIST bereits in seinem Leitfaden zur Notfallplanung von 2010. [2]

Ein vereinfachtes Beispiel: Ein Betrieb legt fest, dass seine Auftragsverwaltung innerhalb von vier Stunden wieder nutzbar sein muss. Gleichzeitig sollen höchstens die Änderungen der letzten Stunde verloren gehen dürfen.

Dann reicht es nicht, irgendwann am Abend eine Sicherung anzufertigen. Ebenso wenig genügt eine vollständige Datensicherung, wenn ihre Rückübertragung und die anschließende Inbetriebnahme einen ganzen Tag benötigen.

Die genannten Zeiten sind keine allgemeine Empfehlung. Sie zeigen lediglich, warum Ausfallzeit und Datenverlust getrennt geplant werden müssen.

Für mich gehört außerdem eine Reihenfolge dazu: Welche Funktion wird zuerst wiederhergestellt? Die zentrale Anmeldung? Die Auftragsverwaltung? Der Dateizugriff? Wer solche Entscheidungen erst während einer Störung trifft, hat einen wesentlichen Teil der Planung verschoben.

Eigene Server, Cloud oder eine Kombination?

Die Frage nach dem Betriebsmodell sollte nicht als Glaubensfrage geführt werden.

Für jede wichtige Anwendung würde ich prüfen, wo sie sich unter den eigenen Bedingungen sinnvoll betreiben lässt. Dazu gehören der technische Bedarf, die verfügbaren Fachkenntnisse, die Internetabhängigkeit, die Kosten und der Umgang mit den Daten.

Das BSI behandelt in seinem Baustein „OPS.2.2 Cloud-Nutzung“, Edition 2023, unter anderem die Abhängigkeit von Anbietern, die geordnete Beendigung einer Cloudnutzung und die Übertragbarkeit von Diensten. Ein möglicher späterer Wechsel gehört damit bereits zur Auswahlentscheidung. [3]

Vor einer Auslagerung würde ich deshalb wissen wollen: In welchem Format bekomme ich meine Daten zurück? Welche Unterstützung gibt es beim Wechsel? Was geschieht mit Benutzerkonten, Berechtigungen und Verknüpfungen? Welche Aufgaben bleiben ausdrücklich beim Kunden?

Beim Eigenbetrieb stellen sich andere Fragen. Wer installiert Sicherheitsupdates? Wer kontrolliert die Sicherungen? Wie wird Ersatz beschafft? Wer übernimmt im Urlaub oder bei Krankheit?

Eine Kombination kann passen: bestimmte Anwendungen als externer Dienst, andere auf eigener Infrastruktur. Sie sollte aber einen nachvollziehbaren Zweck haben. Ich würde keine zusätzliche Verbindung zwischen zwei Umgebungen schaffen, wenn sie lediglich ein Problem löst, das durch eine einfachere Planung gar nicht entstanden wäre.

Die beste Lösung ist nicht zwangsläufig vollständig lokal oder vollständig in der Cloud. Sie ist diejenige, deren Betrieb und Risiken beherrscht werden können.

Das Netzwerk braucht Grenzen

Ein Netzwerk sollte nicht nur Geräte verbinden. Es sollte auch festlegen, welche Verbindungen nicht erlaubt sind.

Die australische Cybersicherheitsbehörde beschreibt in ihrer am 9. Oktober 2026 geprüften Anleitung zur Netzsegmentierung, wie getrennte Bereiche und kontrollierte Übergänge die Ausbreitung eines Angriffs erschweren können. Entscheidend sind dabei nicht nur die Unterteilung, sondern auch wirksam durchgesetzte Zugriffsregeln. [4]

Für eine überschaubare Umgebung könnte eine mögliche Struktur so aussehen:

Arbeitsplätze: Zugriff auf die benötigten Anwendungen und freigegebenen Daten.

Server und zentrale Dienste: Nur die für den jeweiligen Dienst erforderlichen Verbindungen.

Verwaltung der Infrastruktur: Zugang ausschließlich für berechtigte Administratoren und vorgesehene Verwaltungsgeräte.

Drucker, Kameras und andere Netzwerkgeräte: Keine pauschale Zugriffsmöglichkeit auf sämtliche Arbeitsplätze und Server.

Gastnetz: Internetzugang ohne Zugriff auf interne Systeme.

Diese Tabelle ist ein Planungsbeispiel, kein fertiges Regelwerk. Welche Trennung sinnvoll ist, hängt von der Umgebung ab.

Technisch können dafür unter anderem VLANs verwendet werden, also logisch getrennte Netzbereiche. Eine VLAN-Einteilung allein legt jedoch noch nicht fest, welche Kommunikation zwischen diesen Bereichen erlaubt ist. Dafür braucht es passende Filter- und Zugriffsregeln. [4]

Gerade bei einer Neuplanung lohnt es sich, die benötigten Verbindungen ausdrücklich zu dokumentieren. Ein Drucker muss drucken können. Daraus folgt nicht, dass er uneingeschränkt mit jedem anderen Gerät kommunizieren können sollte.

Zugriffsrechte sind genauso wichtig wie Netzgrenzen

Auch innerhalb des eigenen Netzes sollte ein Gerät oder Benutzer nicht allein wegen seines Standorts als vertrauenswürdig gelten. Diesen Grundgedanken beschreibt NIST in „Zero Trust Architecture“ vom August 2020: Zugriffe sollen anhand von Identität und Berechtigung geprüft werden, nicht allein aufgrund der Zugehörigkeit zum internen Netz. [5]

Praktisch gehören dazu persönliche Konten, aufgabenbezogene Berechtigungen und ein geregelter Entzug nicht mehr benötigter Zugriffe. NIST empfiehlt in seinem Leitfaden von 2024 außerdem Mehrfaktor-Authentifizierung für Konten, die diese Möglichkeit anbieten. [1]

Ein neues System wäre für mich nicht ordentlich eingerichtet, wenn zwar alle arbeiten können, aber niemand erklären kann, weshalb einzelne Personen weitreichende Rechte besitzen.

Rechenleistung ist nicht dasselbe wie Ausfallsicherheit

Ein leistungsfähiger Rechner kann mehrere virtuelle Server betreiben. Damit lässt sich beispielsweise eine Anwendung von einer anderen getrennt verwalten.

Diese Trennung beseitigt aber nicht jede gemeinsame Abhängigkeit. Wenn sämtliche virtuellen Systeme auf einem einzigen physischen Rechner laufen und dieser ausfällt, stehen ohne geeignete Ersatzlösung auch die darauf betriebenen Dienste nicht mehr zur Verfügung.

NIST beschreibt in seinem Virtualisierungsleitfaden vom Januar 2011 außerdem die besondere Bedeutung des Hypervisors, also der Software, die virtuelle Maschinen verwaltet. Wird diese Ebene kompromittiert, können mehrere darauf laufende Systeme gleichzeitig gefährdet sein. [6]

Bei der Planung würde ich deshalb nicht nur Arbeitsspeicher, Prozessorkerne und Speicherkapazität vergleichen. Ebenso wichtig wären die Fragen: Welche Dienste teilen sich denselben Ausfallpunkt? Welche Ersatzmöglichkeiten gibt es? Wie lange dauert die Wiederherstellung tatsächlich?

Zwei Server sind noch keine unabhängige Infrastruktur, wenn beide vom selben einzigen Speichersystem oder derselben ungesicherten Stromversorgung abhängen.

Stromversorgung und Standort gehören zum Konzept

Auch der Aufstellort verdient Aufmerksamkeit. Für die Planung würde ich den Zugang zum Gerät, die Wärmeabfuhr, den Schutz vor Wasser und die Stromversorgung berücksichtigen.

Eine unterbrechungsfreie Stromversorgung kann begrenzte Ausfälle überbrücken oder ein geordnetes Herunterfahren ermöglichen. Dafür müssen die angeschlossenen Komponenten, die erforderliche Laufzeit und das Verhalten beim Stromausfall zusammenpassen. Notstromversorgung und vorbeugende Maßnahmen gehören auch zu den Themen des NIST-Notfallleitfadens von 2010. [2]

Bei einer Neuinstallation würde ich außerdem Kabel und Anschlüsse eindeutig kennzeichnen. Wer bei einer Störung erst herausfinden muss, welcher Anschluss zu welchem Gerät gehört, verliert Zeit an einer Stelle, die sich vorher hätte klären lassen.

Eine Datensicherung ist erst nach dem Rücksicherungstest überzeugend

Ein grüner Haken in der Sicherungssoftware ist erfreulich. Er beantwortet aber noch nicht die Frage, ob sich die benötigte Anwendung aus dieser Sicherung wieder betreiben lässt.

Das BSI benennt in seinem Baustein „CON.3 Datensicherungskonzept“, fehlende Wiederherstellungstests ausdrücklich als Gefährdung. Die Sicherung und ihre praktische Verwendbarkeit müssen zusammen betrachtet werden. Die für diese Prüfung direkt belegbare offizielle Quelle ist die Edition 2022. [7]

Für die Abnahme einer neuen Umgebung würde ich deshalb mindestens eine reale Wiederherstellung in einer geeigneten Testumgebung verlangen. Dabei wären nicht nur einzelne Dateien zu öffnen. Auch Datenbanken, Berechtigungen, Konfigurationen und erforderliche Schlüssel müssten berücksichtigt werden.

Ein Snapshot, der ausschließlich auf demselben Speichersystem liegt wie das Produktivsystem, hilft beim vollständigen Verlust dieses Speichersystems nicht weiter. Ebenso wenig ist eine zweite Festplatte automatisch ein vollständiges Sicherungskonzept.

Die US-Sicherheitsbehörde CISA empfiehlt in ihrem am 9. Oktober 2026 recherchierten StopRansomware Guide, wichtige Daten zusätzlich offline und verschlüsselt zu sichern und die Verfügbarkeit sowie Integrität der Sicherungen regelmäßig zu testen. [8]

Für mich gehören zu einem brauchbaren Sicherungskonzept daher drei Ergebnisse: Die benötigten Daten sind vorhanden, sie sind gegen relevante Verlustszenarien geschützt, und ihre Wiederherstellung funktioniert innerhalb der festgelegten Ziele.

Das muss auch dann gelten, wenn der übliche Administrator gerade nicht erreichbar ist.

Den laufenden Betrieb von Anfang an mitplanen

Eine Infrastruktur ist nicht fertig, sobald die Installation abgeschlossen ist. Ab diesem Zeitpunkt muss sie betreut werden.

Im BSI-Baustein „OPS.1.1.1 Allgemeiner IT-Betrieb“, Edition 2023, werden unter anderem die Verwaltung und Dokumentation der Umgebung sowie das IT-Monitoring behandelt. Der sichere Betrieb ist damit eine eigene Aufgabe und kein gelegentlicher Zusatz zur ursprünglichen Einrichtung. [9]

Für die Übergabe würde ich festhalten, wer Aktualisierungen bewertet, wer Störungen bearbeitet und wer bei einem Sicherheitsvorfall entscheiden darf. Ebenso gehören Wartungszeiten und eine Vertretungsregelung dazu.

Bei der Überwachung würde ich nicht nur fragen, ob ein Server erreichbar ist. Interessant wären auch fehlgeschlagene Sicherungen, knapp werdender Speicherplatz, ablaufende Zertifikate und auffällige Anmeldungen.

Eine Warnung hat allerdings nur dann einen Zweck, wenn sie jemanden erreicht, der sie einordnen und bearbeiten kann. Eine überfüllte Meldungsliste ohne Zuständigkeit wäre für mich keine ausreichende Betriebsüberwachung.

Zur Dokumentation gehören außerdem die wesentlichen Abhängigkeiten. Welche Anwendung benötigt welche Datenbank? Wo werden Konfigurationen gesichert? Wie wird ein Ersatzgerät eingebunden?

Die Umgebung sollte nicht nur für denjenigen verständlich sein, der sie eingerichtet hat.

Datenschutz ist eine Planungsaufgabe

Sobald personenbezogene Daten verarbeitet werden, müssen technische und organisatorische Schutzmaßnahmen zum jeweiligen Risiko passen. Darauf weist der Europäische Datenschutzausschuss in seinem am 9. Oktober 2026 geprüften Leitfaden für kleine Unternehmen ausdrücklich hin. [10]

Für den Infrastrukturaufbau bedeutet das: Es muss feststehen, welche Daten wo liegen, wer darauf zugreifen darf und wie sie gegen unbefugte Nutzung oder Verlust geschützt werden.

Wird ein Dienstleister als Auftragsverarbeiter eingesetzt, sind dessen Aufgaben und Pflichten entsprechend zu regeln. Die Europäische Kommission erläutert, dass dafür grundsätzlich ein Vertrag oder ein anderer verbindlicher Rechtsakt erforderlich ist. [11]

Ich würde diese Fragen nicht erst nach der technischen Inbetriebnahme klären. Ein bereits aufgebauter Datenfluss lässt sich nicht durch einen allgemeinen Satz in der Datenschutzerklärung nachträglich begründen.

Das gilt auch für neue KI-Anwendungen. Für einen ersten Funktionstest würde ich bereinigte Beispieldaten verwenden, statt einem System sofort Zugriff auf die vollständige Kundenablage zu geben. Die Freigabe weiterer Daten müsste sich aus einer konkreten Aufgabe ergeben.

Nicht nur den Kaufpreis rechnen

Für die Entscheidung würde ich eine mehrjährige Gesamtrechnung aufstellen. Darin stünden neben Geräten und Einrichtung auch Lizenzen, Wartung, Datensicherung, Energie, Schulung und der spätere Austausch.

Ein einfaches Rechenbeispiel zeigt, weshalb der laufende Verbrauch nicht untergehen sollte: 100 Watt zusätzliche Dauerleistung entsprechen bei ganzjährigem Betrieb bei einem Jahr mit 365 Tagen rechnerisch 876 Kilowattstunden. Das ist keine Messung einer bestimmten Anlage. Zusätzlicher Kühlbedarf oder weitere Verbraucher sind darin nicht enthalten.

Genauso würde ich die eigene Arbeitszeit berücksichtigen. Eine Lösung ist für mich nicht automatisch günstig, wenn sie wenig kostet, aber dauerhaft viel Handarbeit verlangt.

Bei der Hardwareauswahl wären außerdem die vorgesehene Nutzungsdauer und die Unterstützung durch Hersteller und Dienstleister zu klären. Ich möchte vor dem Kauf wissen, welche Perspektive für Sicherheitsupdates, Ersatzteile und kompatible Erweiterungen besteht.

Dabei muss nicht jede denkbare Erweiterung sofort bezahlt werden. Eine nachvollziehbare Möglichkeit zum Ausbau kann vernünftiger sein als ungenutzte Leistung auf Vorrat.

Die Umstellung braucht einen Rückweg

Beim Wechsel auf die neue Infrastruktur würde ich schrittweise vorgehen.

Zunächst wird eine überschaubare Gruppe von Geräten oder eine begrenzte Anwendung umgestellt. Die Beteiligten testen ihre tatsächlichen Aufgaben: anmelden, Unterlagen öffnen, Daten bearbeiten, drucken und erforderlichenfalls von außen zugreifen.

Danach folgt die technische Prüfung. Funktionieren Sicherung und Wiederherstellung? Sind Berechtigungen korrekt? Werden Störungen erkannt? Sind die vereinbarten Leistungsziele erreicht?

Vor dem eigentlichen Umschalttermin müssen zudem Abbruchkriterien und Rückkehrverfahren feststehen. Welche Probleme würden die Umstellung stoppen? Welche Daten haben sich bereits verändert? Wie werden diese Änderungen bei einer Rückkehr berücksichtigt?

Ein Rückweg ist nicht schon deshalb vorhanden, weil der alte Server noch im Raum steht.

Zur Abnahme gehört für mich schließlich die Übergabe an die Menschen, die mit der Umgebung arbeiten und sie betreuen sollen. Sie brauchen verständliche Anleitungen, Ansprechpartner und die Möglichkeit, Fehler oder Unklarheiten zu melden.

Erst wenn die wesentlichen Aufgaben nachweislich funktionieren, würde ich alte Systeme außer Betrieb nehmen.

Mein Fazit: Die bessere Infrastruktur muss nicht die größere sein

Unter „IT neu denken“ verstehe ich keinen Wettbewerb um die meisten Geräte, die modernsten Begriffe oder die aufwendigste Architektur.

Mich überzeugt eine Umgebung, deren Aufbau sich erklären lässt. Die notwendigen Anwendungen funktionieren. Zugriffe sind begrenzt. Daten lassen sich wiederherstellen. Kosten und Zuständigkeiten sind bekannt. Änderungen können vorgenommen werden, ohne dass jedes Mal der gesamte Betrieb zum Experiment wird.

Dafür braucht es zunächst Planung, nicht zwangsläufig mehr Hardware.

Eine gut begründete, überschaubare Lösung wäre mir lieber als ein technisch beeindruckendes System, das niemand zuverlässig betreuen kann.

Gute IT erkennt man nicht nur daran, dass sie heute läuft. Man erkennt sie daran, dass sie morgen noch verstanden, gepflegt und im Ernstfall wiederhergestellt werden kann.

Einordnung und Recherche

Redaktionelle Aktualisierung: 9. Oktober 2026. Die Beispiele sind allgemeine Planungshilfen und kein vollständiges Sicherheits-, Datenschutz- oder Betriebskonzept für eine konkrete Umgebung. Anforderungen und geeignete Maßnahmen hängen vom jeweiligen Einsatz ab. Der Beitrag ersetzt keine individuelle technische oder rechtliche Beratung.

Quellen und weiterführende Informationen

Quellenprüfung am 09.10.2026. Einige BSI- und CISA-Seiten waren direkt nicht abrufbar; ihre genannten Empfehlungen wurden über den Originalquellen-Suchindex geprüft. Für CON.3 wurde die belegbare Edition 2022 statt der im Entwurf genannten Edition 2023 verwendet. Ältere Leitfäden stützen hier Grundbegriffe, keine aktuelle produktspezifische Installationsanleitung.

[1] NIST: „Cybersecurity Framework 2.0: Small Business Quick-Start Guide“
Quelle lesen ↗

[2] NIST: „Contingency Planning Guide for Federal Information Systems“, SP 800-34 Revision 1
Quelle lesen ↗

[3] BSI: „OPS.2.2 Cloud-Nutzung“
Quelle lesen ↗

[4] Australian Signals Directorate / Australian Cyber Security Centre: „Implementing network segmentation and segregation“
Quelle lesen ↗

[5] NIST: „Zero Trust Architecture“, SP 800-207
Quelle lesen ↗

[6] NIST: „Guide to Security for Full Virtualization Technologies“, SP 800-125
Quelle lesen ↗

[7] BSI: CON.3 Datensicherungskonzept, Edition 2022 (direkt belegbare Quelle zur Wiederherstellungsprüfung).
Quelle lesen ↗

[8] CISA und Partnerbehörden: „#StopRansomware Guide“
Quelle lesen ↗

[9] BSI: „OPS.1.1.1 Allgemeiner IT-Betrieb“
Quelle lesen ↗

[10] Europäischer Datenschutzausschuss: „Secure personal data“
Quelle lesen ↗

[11] Europäische Kommission: „Application of the GDPR“
Quelle lesen ↗

Ein Beitrag von TNAlle Beiträge