Sicherheit, Benutzbarkeit, Interoperabilität, Kosten und Nachhaltigkeit als Qualitäten

Sicherheit als Qualitätsmerkmal

Sicherheit ist die Fähigkeit des Systems, Daten und Funktionen vor unbefugtem Zugriff und unbefugter Nutzung zu schützen und dabei weiterhin die Befugten zu bedienen. Architekten gehen oft von der CIA-Triade aus: Vertraulichkeit (nur Befugte können Daten lesen), Integrität (Daten und Code werden nicht ohne Befugnis verändert, und Veränderungen sind erkennbar) und Verfügbarkeit (befugte Nutzer können den Dienst nutzen, wenn sie ihn brauchen). Angriffe lassen sich den drei zuordnen: Wer Kundendaten stiehlt, verletzt die Vertraulichkeit; wer die Bankverbindung eines Zahlungsempfängers ändert, verletzt die Integrität; und ein Denial-of-Service-Angriff verletzt die Verfügbarkeit.

ISO/IEC 25010:2023 verfeinert das Bild. Sein Merkmal Sicherheit hat sechs Teilmerkmale: Vertraulichkeit, Integrität, Nichtabstreitbarkeit (Aktionen oder Ereignisse lassen sich als geschehen nachweisen, sodass eine Partei sie später nicht leugnen kann), Verantwortlichkeit (Aktionen lassen sich eindeutig der Entität zuordnen, die sie ausgeführt hat), Authentizität (die Identität eines Subjekts oder einer Ressource lässt sich als die behauptete nachweisen) und, neu in der Ausgabe 2023, Widerstandsfähigkeit (das Produkt arbeitet weiter wie vorgesehen, während es von einem böswilligen Akteur angegriffen wird). Verfügbarkeit steht in diesem Modell unter Zuverlässigkeit, weshalb sie in Abschnitt 2.5 behandelt wurde.

Sicherheitsszenarien schreiben

„Das System muss sicher sein“ lässt sich weder entwerfen noch testen. Ein Sicherheitsszenario benennt eine Quelle (wer angreift, mit welchem Zugang), einen Stimulus (was versucht wird), ein Artefakt (was angegriffen wird), eine Umgebung (online, während eines Vorfalls, mit dem Angreifer bereits im Netzwerk), eine Antwort und ein Maß. Maße für Sicherheit betreffen oft die Erkennungszeit, das Ausmaß des Schadens oder die Zeit bis zur Wiederherstellung, weil sich „kein Angriff ist je erfolgreich“ nicht überprüfen lässt.

Drei Beispiele für eine Onlinebank. Credential Stuffing: Ein externer Angreifer probiert geleakte Kombinationen aus Benutzername und Passwort mit 50 Versuchen pro Sekunde von vielen Adressen aus an der Login-API; das System erkennt das Muster innerhalb von 2 Minuten, fordert die Quelladressen heraus oder sperrt sie, und Konten mit Multi-Faktor-Authentifizierung werden nicht übernommen. Manipulation durch Insider: Ein Support-Mitarbeiter mit legitimem Zugang ändert die Empfängerdaten eines Kunden; die Änderung erfordert die Freigabe durch eine zweite Person, und das Audit-Log hält wer, was und wann in einer Form fest, die der Mitarbeiter nicht verändern kann. Gestohlenes Backup: Ein Angreifer gelangt an eine Kopie des Datenbank-Backups der letzten Woche; alle personenbezogenen Daten darin sind mit getrennt gespeicherten Schlüsseln verschlüsselt, sodass keine Kundendaten lesbar sind.

Beachten Sie, dass jedes Szenario eine andere Architektur nach sich zieht: Rate Limiting und Anomalieerkennung am Rand des Systems, einen Freigabe-Workflow nach dem Vier-Augen-Prinzip und manipulationssichere Logs sowie Verschlüsselung mit getrenntem Schlüsselmanagement. Solche Szenarien systematisch zu finden ist Aufgabe der Bedrohungsmodellierung, die in Kapitel 8 behandelt wird.

Sicherheitstaktiken: ein Überblick

Bass, Clements und Kazman gruppieren Sicherheitstaktiken danach, wann sie wirken. Angriffen widerstehen: Akteure identifizieren, authentifizieren und autorisieren, Zugriff und Angriffsfläche begrenzen (weniger offene Ports, weniger öffentliche Endpoints, Least Privilege), Daten bei der Übertragung und im Ruhezustand verschlüsseln, Entitäten trennen (sensible Daten in einem eigenen Speicher oder Netzwerksegment), Standardeinstellungen ändern und Eingaben validieren. Angriffe erkennen: Angriffserkennung (Intrusion Detection), Denial of Service erkennen, die Integrität von Nachrichten prüfen und ungewöhnliche Verzögerungen oder Muster bemerken. Auf Angriffe reagieren: Zugriff entziehen, Konten nach fehlgeschlagenen Anmeldungen sperren, Betrieb und Nutzer informieren. Sich von Angriffen erholen: einen bekannten guten Zustand wiederherstellen (wieder die Taktiken der Verfügbarkeit) und einen Audit-Trail führen, um zu verstehen, was geschehen ist, und die Nichtabstreitbarkeit zu stützen.

Dieser Abschnitt stellt nur die Familien vor. Prinzipien wie Defense in Depth und Least Privilege, Identitätsprotokolle, Verschlüsselung, Zero Trust und die Sicherheit der Lieferkette sind Thema von Kapitel 8. Der architektonische Punkt hier ist, dass Sicherheit eine Eigenschaft der gesamten Struktur ist und keine Komponente, die man am Ende hinzufügt: Wo Vertrauensgrenzen verlaufen, welche Komponente welche Daten hält und wie Services einander authentifizieren, sind frühe und teuer zu ändernde Entscheidungen.

Benutzbarkeit, Interaktionsfähigkeit und Barrierefreiheit

ISO/IEC 25010:2023 hat Benutzbarkeit in Interaktionsfähigkeit umbenannt: das Maß, in dem festgelegte Nutzer über die Benutzeroberfläche mit einem Produkt interagieren können, um Informationen auszutauschen und bestimmte Aufgaben zu erledigen. Ihre Teilmerkmale sind Erkennbarkeit der Eignung, Erlernbarkeit, Bedienbarkeit, Schutz vor Benutzerfehlern, Nutzerbindung (die die Ästhetik der Benutzeroberfläche ersetzt hat), Inklusivität, Benutzerunterstützung und Selbstbeschreibungsfähigkeit. Vieles davon ist Interaktionsdesign statt Architektur, doch mehrere Anliegen der Benutzbarkeit reichen tief in die Struktur hinein.

Reaktionsfähigkeit ist das offensichtliche. Bewährte Richtwerte der Ergonomie, bekannt gemacht durch Jakob Nielsen, nennen drei Grenzen: Etwa 0,1 Sekunden wirken unmittelbar, etwa 1 Sekunde erhält den Gedankenfluss des Nutzers, und etwa 10 Sekunden sind die Grenze der Aufmerksamkeit. Um sie einzuhalten, braucht es unter Umständen Caching, asynchrone Verarbeitung mit Fortschrittsanzeige oder optimistische Aktualisierungen. Rückgängigmachen und Abbrechen sind architektonisch: die letzten fünf Aktionen rückgängig machen erfordert umkehrbare Befehle, und das Abbrechen eines langen Uploads erfordert eine Operation, die sich sauber unterbrechen lässt. Offline-Arbeit in einer mobilen App erfordert lokale Speicherung und Synchronisation mit Konfliktbehandlung. All das ist viel billiger von Anfang an einzuplanen als nachzurüsten.

Barrierefreiheit, also die Möglichkeit für Menschen mit Behinderungen, das Produkt zu nutzen, ist zunehmend eine rechtliche Randbedingung und keine bloße Vorliebe mehr. Die Web Content Accessibility Guidelines in Version 2.2 (WCAG 2.2), seit Oktober 2023 eine W3C-Empfehlung, definieren testbare Erfolgskriterien auf den Stufen A, AA und AAA; Stufe AA ist der übliche Maßstab im Recht und in der Beschaffung. WCAG 2.2 hat neun Kriterien ergänzt, darunter Mindestgrößen für Zielflächen bei Zeigereingabe und barrierefreie Authentifizierung (kein Schritt der Anmeldung darf von einem kognitiven Funktionstest abhängen, etwa dem Merken eines Passworts oder dem Abschreiben eines Codes, es sei denn, dem Nutzer wird eine alternative Methode oder Hilfe angeboten, etwa das Einfügen aus einem Passwortmanager; einige weitere enge Ausnahmen gelten). In der Europäischen Union gilt der European Accessibility Act (Richtlinie (EU) 2019/882) seit dem 28. Juni 2025 für viele Verbraucherprodukte und -dienstleistungen, darunter E-Commerce, Bankdienstleistungen, E-Books und Personenbeförderungsdienste. Für Architekten ist Barrierefreiheit daher eine früh zu erfassende Randbedingung: Sie beeinflusst die Wahl des Frontend-Frameworks, das Designsystem, den Authentifizierungsablauf und die Test-Pipeline (automatisierte Barrierefreiheitsprüfungen in der Continuous Integration sowie manuelle Tests mit assistiven Technologien).

Interoperabilität

Interoperabilität ist das Maß, in dem zwei oder mehr Systeme Informationen austauschen und die ausgetauschten Informationen nutzen können. ISO/IEC 25010 ordnet sie der Kompatibilität zu, neben der Koexistenz. Sie hat zwei Ebenen. Syntaktische Interoperabilität bedeutet, dass sich die Systeme über Format und Protokoll einig sind: Beide sprechen HTTP und JSON. Semantische Interoperabilität bedeutet, dass sie sich über die Bedeutung einig sind: "amount": 1050 sind Pence, nicht Pfund; status: "closed" bedeutet bezahlt, nicht storniert. Die meisten Integrationsfehler sind semantisch.

Branchen senken die Kosten semantischer Einigung mit gemeinsamen Standards: HL7 FHIR für den Austausch von Gesundheitsdaten, ISO 20022 für Finanznachrichten, GTFS für Fahrpläne im öffentlichen Verkehr. Zu den architektonischen Taktiken gehören, Services über eine Registry zu finden, Schnittstellen mit Adaptern und Übersetzern anzupassen und Versionen ausdrücklich zu verwalten, damit ältere Partner weiter funktionieren. Ein Interoperabilitätsszenario könnte lauten: Ein neues Krankenhaus tritt dem Netzwerk bei und tauscht innerhalb von 4 Wochen Patientenzusammenfassungen über FHIR-R4-Ressourcen aus, ohne Änderungen am zentralen Patientenaktenservice.

Kosten als Qualität

Kosten tauchen in Qualitätsmodellen selten auf, doch sie begrenzen jede Architekturentscheidung. Unterscheiden Sie Erstellungskosten (der Aufwand, das System zu bauen), Betriebskosten (Infrastruktur, Lizenzen, Dienste Dritter, Support) und Änderungskosten (der Aufwand für jede künftige Änderung, um den es bei der Änderbarkeit geht). In der Cloud sind die Betriebskosten variabel und unmittelbar von der Architektur geprägt: Gesprächige Services zahlen für Netzwerkübertragung, überdimensionierte Cluster zahlen für ungenutzte Kapazität, und ein unbedachtes Abfragemuster kann eine Datenbankrechnung vervielfachen.

Ein nützlicher Weg, Kosten zum Qualitätsmerkmal zu machen, sind Stückkosten: Kosten pro Transaktion, pro aktivem Nutzer oder pro Bestellung. Anders als eine monatliche Gesamtrechnung zeigen sie, ob die Architektur mit wachsendem Geschäft effizienter oder weniger effizient wird, und sie lassen sich als Szenario formulieren: Bei 3 Millionen Bestellungen im Monat bleiben die Infrastrukturkosten unter 1 Penny pro Bestellung. FinOps-Praktiken, um dies zu steuern, werden in Kapitel 10 behandelt.

Energieeffizienz und Nachhaltigkeit

Software stößt selbst kein CO2 aus, doch die Hardware, auf der sie läuft, verbraucht Strom und trägt die Emissionen ihrer Herstellung in sich. Die Spezifikation Software Carbon Intensity (SCI) der Green Software Foundation, von der ISO als ISO/IEC 21031:2024 veröffentlicht, definiert eine Rate: Betriebsemissionen (Energie E mal CO2-Intensität I des Stroms) plus graue Emissionen M, geteilt durch eine funktionale Einheit R wie einen Nutzer, einen API-Aufruf oder eine Bestellung. Sie nennt drei Hebel: Energieeffizienz (für dieselbe Arbeit weniger Strom verbrauchen), Hardwareeffizienz (weniger Geräte nutzen und diese stärker und länger auslasten) und CO2-Bewusstsein (flexible Arbeit dann und dort ausführen, wo der Strom sauberer ist).

Die Architektur beeinflusst alle drei. Passende Dimensionierung (Right-Sizing) und höhere Auslastung verbessern die Hardwareeffizienz; Caching, effiziente Datenformate und das Vermeiden unnötiger Arbeit verbessern die Energieeffizienz; Queues und Batch-Verarbeitung ermöglichen es, Arbeit zeitlich oder räumlich zu verlagern. Nachhaltigkeit geht oft mit den Kosten einher, aber nicht immer: Ein Warm-Standby in einer zweiten Region verbessert die Verfügbarkeit und verdoppelt die grauen Emissionen. Große KI-Modelle machen die Frage dringlicher, wie Kapitel 12 erörtert.

Betriebssicherheit (Safety)

Betriebssicherheit ist die Freiheit von unvertretbaren Risiken für Menschen, Sachwerte oder die Umwelt. Sie unterscheidet sich von Sicherheit: Sicherheit schützt das System vor Menschen mit schädlicher Absicht; Betriebssicherheit schützt Menschen vor dem System, auch wenn niemand böswillig handelt. ISO/IEC 25010:2023 hat Betriebssicherheit als neuntes Merkmal ergänzt, mit den Teilmerkmalen betriebliche Beschränkung, Risikoidentifikation, Ausfallsicherheit (Fail-safe), Gefahrenwarnung und sichere Integration.

Sicherheitskritische Bereiche haben eigene Normen, die Architektur und Prozess vorgeben: IEC 61508 für funktionale Sicherheit allgemein, ISO 26262 für Straßenfahrzeuge, IEC 62304 für Software von Medizinprodukten und DO-178C für Software in der Luftfahrt. Typische Taktiken sind ein ausfallsicherer Standardzustand (ein Zug hält an, wenn die Signale ausfallen), unabhängige Überwachungskanäle, die die Hauptsteuerung übersteuern können, Redundanz mit Mehrheitsentscheid und eine strikte Trennung sicherheitskritischer Komponenten von allem anderen, damit ein Fehler im Infotainmentsystem nicht die Bremsen erreichen kann. Beachten Sie, dass ausfallsicher und hochverfügbar im Konflikt stehen können: Ein ausfallsicheres System hält oft an, was sicher, aber nicht verfügbar ist.

Observability, eine aufkommende Qualität

Observability (Beobachtbarkeit) ist das Maß, in dem Sie den inneren Zustand eines Systems von außen anhand der Daten verstehen können, die es ausgibt, und zwar gut genug, um Fragen zu beantworten, die beim Bau nicht vorhergesehen wurden. Sie ist in ISO/IEC 25010 nicht aufgeführt, auch wenn Analysierbarkeit und Verantwortlichkeit sie berühren. In verteilten Systemen ist sie zu einer eigenständigen Qualität geworden, weil die Wiederherstellungszeit und damit die Verfügbarkeit davon abhängt, wie schnell Menschen herausfinden, was nicht stimmt. Architektonisch erfordert sie strukturierte Logs, Metriken und verteilte Traces mit Korrelations-IDs, die einer Anfrage über Services hinweg folgen, und zwar von Anfang an eingeplant. Ein Szenario könnte lauten: Bei jedem fehlgeschlagenen Bezahlvorgang kann ein Bereitschaftsingenieur innerhalb von 5 Minuten den fehlerhaften Service und den Weg der Anfrage ermitteln. Siehe Observability in Kapitel 9.

Rechtliche und regulatorische Qualitäten

Gesetze und Vorschriften erzeugen Qualitäten, die man bis zu einem Audit leicht übersieht. Datenresidenz verlangt, dass bestimmte Daten in einem bestimmten Land oder einer bestimmten Region gespeichert oder verarbeitet werden; sie kann aus Branchenregeln, Verträgen mit der öffentlichen Hand oder Kundenanforderungen stammen. Die DSGVO selbst verlangt nicht, dass Daten in der EU bleiben, aber Übermittlungen außerhalb der EU brauchen eine Rechtsgrundlage und Garantien, was in der Praxis bestimmt, wo Services und Backups laufen. Auditierbarkeit bedeutet, später zeigen zu können, wer was wann getan hat: manipulationssichere Logs, für einen festgelegten Zeitraum aufbewahrt, mit synchronisierten Uhren. Aufbewahrungs- und Löschregeln verlangen, Daten mindestens eine bestimmte Zeit aufzubewahren (Finanzunterlagen) und nach einer Höchstdauer oder auf Antrag zu löschen (personenbezogene Daten), was in Systemen mit vielen Kopien, Caches und Backups schwierig ist. Erklärbarkeit und menschliche Aufsicht sind für manche automatisierten Entscheidungen vorgeschrieben, wie das Kapitel zur KI-Verordnung der EU erläutert.

Behandeln Sie diese als Randbedingungen mit Akzeptanzkriterien: „Kundendaten deutscher Auftraggeber der öffentlichen Hand werden nur in EU-Regionen gespeichert und verarbeitet, einschließlich Backups und Logs“ ist testbar und schließt manche Managed Services sofort aus. Datenschutzanforderungen werden in Privacy by Design und die DSGVO behandelt.