Seite 2: Sicherheitskonzept

Inhaltsverzeichnis

1. Schutzbedarfsermittlung

Um die eigenen Schutzziele zu ermitteln, werden die BSI-Standards 100-2 zur Vorgehensweise im IT-Grundschutz herangezogen. Sie teilen den Schutzbedarf in drei Grundwerte ein: Verfügbarkeit, Vertraulichkeit und Integrität. Jeder dieser drei Grundwerte ist mit einer von drei sogenannten Schutzbedarfskategorien bewertet:

• normal: Das schwerwiegendste Schadenszenario wirkt sich nur auf einzelne Externe oder Mitarbeiter aus.
• hoch: Das schwerwiegendste Schadenszenario wirkt sich auf Teilbereiche der nationalen Öffentlichkeit aus oder hat im eigenen Bereich nur schwerwiegende Auswirkungen.
• sehr hoch: Das schwerwiegendste Schadensszenario wirkt sich auf eine breite deutsche Öffentlichkeit
• aus und/oder hat im eigenen Bereich existenzbedrohende Auswirkungen.

Die vermeintliche Schlichtheit des Schemas mag dazu verführen, alle drei Grundwerte mit der Bedarfskategorie "sehr hoch" zu bewerten. Mit Blick auf die daraus resultierenden Projektkosten ist jedoch eine sorgfältige Betrachtung ratsam, bedenkt man, dass hinter einer sehr hohen Verfügbarkeit weltweit verteilte Servercluster stehen können. In dem Zusammenhang sollte diese Bedarfskategorie eher Firmen wie Google oder Amazon vorbehalten bleiben. Zur sorgfältigen Bewertung sind für jede Schutzbedarfskategorie die möglichen Schadenszenarien zu betrachten – wie "Verstoß gegen Gesetze und Vorschriften" oder "negative Innen- und Außenwirkung" – und die relevanten Auswirkungen zu ermitteln.

2. Identifikation von Bedrohungen

Spätestens an diesem Punkt sollten sich die Verantwortlichen externe Unterstützung ins Projekt holen, sofern intern keine ausgewiesenen Experten zur Verfügung stehen. Auf Sicherheitsaspekte spezialisierte IT-Dienstleister ermitteln für das gegebene IT-Szenario mögliche Bedrohungen. Hier werden Begriffe wie Spoofing (Verwendung fremder Identitäten), Tampering (unbefugtes Verändern von Informationen) oder Information Disclosure (Zugriff auf vertrauliche Informationen) genannt. Die Bedrohungen werden nach Wahrscheinlichkeiten sortiert und dabei Bewertungskriterien wie notwendiger Skill-Level (Wissensstand), Motivation, Gelegenheit und Größe des Angriffs bewertet.

3. Konkrete technische Maßnahmen zum Schutz vor Bedrohungen

Aus den oben beschriebenen Vorüberlegungen ergeben sich je nach Szenario unterschiedliche Maßnahmen. Das Projekt durchläuft von der Anforderungsanalyse über den Systemaufbau bis hin zum Betrieb mehrere Phasen. Sicherheitsaspekte sind bei jedem Schritt zu berücksichtigen. Zwar stechen die Architektur und die Betriebsinfrastruktur aus der Liste der Maßnahmen heraus, da sie offen sichtbar sind und eigene Kostenpositionen ausweisen. Gleichwohl lassen sich Fehler in der Entwicklung oder mangelhafte Tests nicht durch die sicherste Architektur oder den sichersten Betrieb ausgleichen. Microsoft veröffentlichte 2004 den Trustworthy Computing Security Development Lifecycle (SDL), der als Quasistandard beim Umsetzen eines sicheren Softwareentwicklungsprozesses hilft.

Je nach Sicherheitsanforderungen ergeben sich unterschiedliche Architekturen. Bei sehr hohen Anforderungen an die Verfügbarkeit werden die Aufgaben so auf die Server verteilt, dass ein Ausfall nicht den kompletten Service unterbricht. Dafür werden Server x-fach redundant gehalten und mit Load-Balancern die Last zwischen den verfügbaren Servern aufgeteilt.

Liegen die Anforderungen weniger auf Verfügbarkeit, sondern eher im Bereich Vertraulichkeit, sind häufig dreistufige Architekturen vorhanden, die es ermöglichen, das Bestandssystem im Backend von der Zugriffsschicht im Web zu entkoppeln. Dabei übernimmt der Internet Layer die Aufgabe, die Benutzeroberfläche bereitzustellen. Die Schicht hält keine eigenen Daten, sondern sendet ihre Datenanforderungen an den Application Layer. Die Entkopplung vom Backend übernimmt ein Mechanismus, der asynchron Daten zwischen Application Layer und Backend synchronisiert. Das Intervall lässt sich frei wählen – von täglichen bis hin zu minütlichen Synchronisierungen für den Near-Online-Betrieb. Ein Durchgreifen über zwei Schichten ist in dieser Architektur nicht erlaubt. Der Verbindungsaufbau erfolgt ausschließlich aus dem Backend. Das heißt, der Application Layer darf keine Verbindung zum Backend-Layer herstellen. (s. Abb. 2)

Wird diese Architektur in den Betrieb übernommen, helfen diverse Infrastrukturkomponenten den Schutz vor unerlaubten Zugriffen auf der Netzwerkebene zu erhöhen. Für einen sicheren Datenverkehr insbesondere zwischen Web- und Internet Layer sorgen zertifikatsbasierte Verschlüsselungen. Ein Reverse Proxy als Einfallstor erlaubt die Kontrolle der Aufrufe und leitet diese intern an die verarbeitenden Server weiter. Unverzichtbar ist ein Virenscanner, wenn die Möglichkeit besteht, Dokumente hochzuladen. Ein sogenanntes Intrusion-Detection-System untersucht den Netzwerkverkehr auf ungewöhnliche Muster, die sich aus Angriffen ergeben und sperrt temporär den Zugriff bestimmter Internetadressen.

Neben dem sicheren Aufbau der Infrastruktur sind kontinuierlich Überwachungen und Updates des Systems notwendig. In regelmäßigen Zyklen veröffentlichen die Hersteller von Betriebssystemsoftware sicherheitskritische Hinweise, auf deren Basis regelmäßig Patches einzuspielen sind. Spezielle Sicherheitstests sorgen nach Änderungen am System dafür, dass sich nicht versehentlich ein Bug als sicherheitskritisch erweist.

4. Ableitung von Checklisten und Prüfpunkten für die einzelnen Projektphasen

Die aus der Sicherheitsanalyse abgeleiteten Maßnahmen sind im Laufe des Projekts operativ umzusetzen. Da es meist unmöglich ist, alle Projektmitarbeiter ausreichend in Sicherheitsfragen zu schulen, helfen Check- und Prüflisten dabei, die notwendigen Maßnahmen mit der erforderlichen Qualität umzusetzen.

Fazit

Das Thema Sicherheit für interaktive Anwendungen im Internet ist von der ersten Idee bis hin zum
laufenden Betrieb ganzheitlich zu betrachten und in jeder Phase des Lebenszyklus der Software zu berücksichtigen. Ein absolutes Maß oder eine Skala für Sicherheit gibt es ebenso wenig wie die auf alle Anforderungen passende Lösung.

Der eigene Schutzbedarf ist gründlich zu ermitteln und entsprechende IT-Maßnahmen gegen mögliche Bedrohungen sind einzuleiten. Dabei dürfen Kostengründe für eine Entscheidung durchaus eine
Rolle spielen, sofern sich die Verantwortlichen der Auswirkungen und Risiken bewusst sind und ihre Entscheidungen schriftlich fixiert haben.

Björn Kibbel
ist Manager Development und Integration Services bei der innobis AG.

Literatur

1. Marc Schiffer; Von Dinosauriern und Spatzen; Wie BSI-Anforderungen zur sinnvollen Ressourcenzuteilung führen; Artikel auf heise Developer
2. Niklaus Schild; Königsweg à la Redmond; Sichere Softwareentwicklung nach dem "Security by Design"-Prinzip; Artikel auf heise Developer
   

(ane)