Glossar

A

Agent

Ein Programm, das ein Sprachmodell nutzt, um eine Aufgabe in mehreren Schritten selbst zu erledigen: Es entscheidet, welches Werkzeug es als Nächstes aufruft, statt nur zu antworten. Der Unterschied zu einem Chat ist die Handlung, denn ein Agent liest nicht nur, er legt auch Tickets an oder ändert Daten. Deshalb ist die Frage, was er darf, wichtiger als die Frage, wie gut er formuliert. Siehe auch: MCP.

API-Gateway

Die Komponente, die vor Ihren Schnittstellen sitzt und jeden Aufruf annimmt, prüft und weiterleitet. Sie setzt an einer Stelle durch, was sonst jeder Dienst einzeln regeln müsste: Anmeldung, Begrenzung der Aufrufmenge, Protokollierung. Siehe auch: API Management.

API Management

Die Plattform um das Gateway herum, mit Verwaltung der Schnittstellen, Versionen und Zugänge, einem Portal für Entwicklerinnen und Entwickler und der Auswertung der Nutzung. Das Gateway führt zur Laufzeit aus, was hier festgelegt wird. Wer eine Handvoll interner Schnittstellen betreibt, braucht das selten; wer sie an Dritte ausgibt, fast immer. Siehe: Was ist API Management?

Auftragsverarbeitung

Der Fall, dass ein Dienstleister personenbezogene Daten im Auftrag und nach Weisung seines Kunden verarbeitet, zum Beispiel ein Cloud-Anbieter. Die Datenschutz-Grundverordnung verlangt dafür einen Vertrag, der Zweck, Dauer und Schutzmaßnahmen festhält. Verantwortlich für die Daten bleibt der Auftraggeber. Siehe auch: Datenresidenz.

B

Blast Radius

Der Bereich, den ein Fehler oder ein Einbruch erreichen kann, bevor ihn etwas stoppt. Eine Umgebung, in der alles in einem Konto liegt, hat einen großen Radius; getrennte Konten je Umgebung haben kleine. Die Frage dahinter lautet: Was geht kaputt, wenn genau diese eine Stelle versagt? Siehe auch: Least Privilege.

C

CI/CD

Der automatische Weg vom Quellcode zur laufenden Anwendung. CI steht für fortlaufende Integration, also das ständige Zusammenführen und Prüfen von Änderungen, CD für die fortlaufende Auslieferung des Ergebnisses. Weil jede Änderung denselben Weg nimmt, ist das auch die Stelle, an der Prüfungen greifen, solange eine Korrektur billig ist. Siehe auch: Shift Left.

Container

Eine Anwendung samt allem, was sie zum Laufen braucht, in einem abgeschlossenen Paket. Sie verhält sich auf dem Laptop genauso wie auf dem Server, weil die Umgebung mit im Paket steckt. Der Vergleich, der trägt: der Seefrachtcontainer, dessen Inhalt den Kran nicht interessiert. Siehe auch: Kubernetes.

Container-Registry

Der Ablageort, aus dem Server sich Container-Images holen. Wer dort schreiben darf, bestimmt, was in Produktion läuft, deshalb ist die Registry eine der Stellen, an denen Zugriffsrechte wirklich zählen. Siehe auch: SBOM.

CSPM

Cloud Security Posture Management, also Werkzeuge, die eine Cloud-Umgebung laufend nach Fehlkonfigurationen absuchen: offener Speicher, zu weit gefasste Rechte, fehlende Verschlüsselung. Sie finden, was sich zwischen zwei Projekten eingeschlichen hat, und machen den Ist-Stand vergleichbar. Sie ersetzen keine Regel, die den Fehler von vornherein verhindert. Siehe auch: Policy as Code.

D

Datenresidenz

Die Frage, in welchem Land Daten tatsächlich liegen und verarbeitet werden. Ein Rechenzentrum in Deutschland beantwortet sie nur zur Hälfte, denn Betrieb, Support und Sicherungskopien können anderswo stattfinden. Vertraglich zugesagt gehört beides. Siehe auch: Souveränität.

DevSecOps

Die Arbeitsweise, Sicherheitsprüfungen in dieselbe Strecke zu legen, in der ohnehin gebaut und ausgeliefert wird, statt sie ans Ende zu hängen. Sicherheit wird damit zur Aufgabe des Teams und nicht zur Freigabe einer anderen Abteilung. Das trägt nur, wenn die Prüfungen schnell sind und wenige Fehlalarme erzeugen. Siehe auch: Shift Left.

Drift

Der Zustand, in dem die tatsächliche Umgebung von dem abweicht, was im Code steht. Er entsteht meist harmlos, weil jemand während einer Störung schnell etwas von Hand ändert und es nie nachträgt. Jede unbemerkte Abweichung macht die nächste automatische Änderung unberechenbar. Siehe auch: Infrastructure as Code.

F

FinOps

Die Praxis, Cloud-Kosten dort sichtbar zu machen, wo sie entstehen, damit die Teams sie selbst steuern können. Voraussetzung ist eine saubere Zuordnung: Jede Ressource trägt eine Kennzeichnung, aus der hervorgeht, wozu sie gehört. Ohne diese Zuordnung bleibt am Monatsende eine Summe, die niemand erklären kann. Siehe auch: Landing Zone.

G

GitOps

Ein Betriebsmodell, bei dem der gewünschte Zustand verwalteter Ressourcen versioniert vorliegt und Agenten ihn laufend mit dem Istzustand abgleichen. Automatische Korrekturen hängen vom verwalteten Umfang und der Konfiguration ab. Reviews und Zugriffsregeln müssen eingerichtet werden. Siehe auch: Drift.

Golden Path

Ein vorbereiteter, dokumentierter Weg für eine wiederkehrende Aufgabe, etwa einen neuen Dienst aufzusetzen. Er ist so gebaut, dass der Weg, der die Vorgaben des Hauses erfüllt, zugleich der bequemste ist. Freiwillige Nutzung ist ein gutes Signal; verbindliche Nutzung allein belegt den Nutzen noch nicht. Siehe: Was ist Platform Engineering?

H

Hyperscaler

Die großen, weltweit betriebenen Cloud-Anbieter, allen voran Amazon Web Services, Microsoft Azure und Google Cloud. Sie bieten sehr viele Dienste zu geringen Einstiegskosten, und sie prägen die Begriffe, mit denen anschließend alle reden. Siehe auch: Shared Responsibility.

I

Identity Provider

Der Dienst, der weiß, wer im Unternehmen arbeitet, und der anderen Anwendungen bestätigt, dass jemand ist, wer er behauptet. Statt in jeder Anwendung ein eigenes Passwort zu pflegen, fragt jede Anwendung dort nach. Zugänge lassen sich so zentral verwalten; bestehende Sitzungen und Tokens müssen beim Entzug berücksichtigt werden. Siehe auch: SSO.

Infrastructure as Code

Server, Netze und Berechtigungen werden als Textdatei beschrieben, statt in einer Oberfläche zusammengeklickt. Aus derselben Datei entsteht jedes Mal dieselbe Umgebung, und eine Änderung wird geprüft wie Anwendungscode. Der eigentliche Gewinn ist die Wiederholbarkeit, denn eine Umgebung, die es nur einmal gibt, lässt sich nicht zurückrollen. Siehe: Was ist Infrastructure as Code?

Internal Developer Platform

Das interne Angebot, mit dem Entwicklungsteams sich selbst bedienen: vorbereitete Wege in die Produktion, fertige Bausteine und ein Verzeichnis, in dem steht, was existiert und wem es gehört. Sie ersetzt die Anfrage an ein zentrales Team durch einen Knopf. Sinnvoll wird sie erst, wenn dieselbe Aufgabe oft genug anfällt. Siehe: Internal Developer Platform.

K

Kubernetes

Ein System, das Anwendungen in Containern über viele Maschinen verteilt, sie neu startet, wenn eine ausfällt, und bei Last vervielfacht. Es ist weit verbreitet, aber keine Voraussetzung für eine Plattform. Es nimmt Betriebsarbeit ab und bringt eigene mit. Siehe auch: Container.

L

Landing Zone

Die vorbereitete Grundstruktur einer Cloud-Umgebung, bevor die erste Anwendung einzieht: Kontenschnitt, Netz, Identität, Regeln und Protokollierung. Der Vergleich, der trägt: erschlossenes Bauland mit Straßen und Anschlüssen, nicht das fertige Haus. Wer sie überspringt, baut die Ordnung später unter laufendem Betrieb ein. Siehe: Was ist eine Landing Zone?

Least Privilege

Der Grundsatz, dass jeder Zugang genau so viele Rechte bekommt, wie er für seine Aufgabe braucht, und keines darüber hinaus. Er wirkt im Schadensfall, weil ein übernommenes Konto nur das anrichten kann, wofür es zuständig war. Der Aufwand steckt im Nachhalten, denn Rechte wachsen schneller, als sie zurückgenommen werden. Siehe auch: Blast Radius.

LLM (Sprachmodell)

Ein großes Sprachmodell ist ein Programm, das aus sehr viel Text gelernt hat, welches Wort typischerweise folgt, und daraus Antworten bildet. Es weiß nichts, es rechnet Wahrscheinlichkeiten, und deshalb kann es überzeugend klingen und trotzdem falsch liegen. Für den Einsatz im Unternehmen zählt weniger das Modell als das, worauf es zugreifen darf. Siehe auch: RAG.

M

MCP

Model Context Protocol, eine offene Beschreibung dafür, wie ein Sprachmodell Werkzeuge und Datenquellen anspricht. Statt für jede Anwendung eine eigene Anbindung zu bauen, sprechen alle Beteiligten dasselbe Format. Nutzen und Risiko liegen an derselben Stelle: Es wird sehr leicht, einem Modell Zugriff auf echte Systeme zu geben. Siehe: MCP absichern.

mTLS

Eine verschlüsselte Verbindung, bei der sich beide Seiten mit einem Zertifikat ausweisen, nicht nur der Server. Damit können Dienste die Identität ihres Gegenübers prüfen. Welche Dienste auf welche Funktionen zugreifen dürfen, legen zusätzliche Zugriffsregeln fest. Siehe auch: Zero Trust.

Multi-Tenancy

Mehrere Teams oder Kunden arbeiten auf derselben technischen Grundlage, ohne einander zu sehen oder zu stören. Die Arbeit steckt in der Trennung: eigene Bereiche, eigene Grenzwerte, eigene Berechtigungen. Das spart Betriebskosten und kostet Entwurfsaufwand. Siehe auch: Internal Developer Platform.

O

Observability

Die Fähigkeit, von außen zu erkennen, was ein System gerade tut, aus Messwerten, Protokollen und der Verfolgung einzelner Anfragen. Die praktische Prüfung ist einfach: Lässt sich eine Störung erklären, ohne sich auf die Maschine einzuloggen? Wo die Antwort Nein lautet, dauert jede Störung länger als nötig. Siehe auch: SLO.

P

Platform Engineering

Die Disziplin, eine interne Plattform zu bauen und wie ein Produkt zu pflegen, damit Entwicklungsteams ohne Rückfragen ausliefern können. Sie setzt auf dem Fundament auf, das Cloud Engineering legt. Ihr Maßstab ist nicht die eingesetzte Technik, sondern ob die Teams den vorbereiteten Weg freiwillig nehmen. Siehe: Was ist Platform Engineering?

Policy as Code

Regeln für eine Umgebung werden als Code hinterlegt, etwa "kein öffentlich erreichbarer Speicher" oder "jede Ressource braucht eine Kostenstelle". Die Regeln lassen sich automatisiert prüfen. Je nach Einbindung werden Verstöße gemeldet oder Änderungen blockiert. Siehe auch: CSPM.

Postmortem

Die schriftliche Aufarbeitung einer Störung nach ihrer Behebung: was passiert ist, warum es passieren konnte und was sich ändert. Sie ist nützlich, solange sie ohne Schuldzuweisung geschrieben wird, weil sonst niemand mehr die interessanten Details erzählt. Ohne Maßnahmen mit Namen und Termin bleibt sie eine Erzählung. Siehe auch: Runbook.

Prompt Injection

Der Fall, dass ein Sprachmodell Anweisungen befolgt, die in Inhalten stecken, die es eigentlich nur lesen sollte, etwa in einer E-Mail, einer Webseite oder einem Dokument. Das Modell unterscheidet nicht zuverlässig zwischen "das ist die Aufgabe" und "das steht im Text". Deshalb begrenzt man, worauf es zugreifen darf, statt ihm zu vertrauen. Siehe: MCP absichern.

R

RAG

Retrieval Augmented Generation, auf Deutsch etwa: Antwort mit vorheriger Suche. Statt sich auf das Gelernte zu verlassen, sucht das System zuerst passende Stellen in Ihren eigenen Dokumenten und formuliert die Antwort auf dieser Grundlage. Mitgelieferte Fundstellen erleichtern die Prüfung. Die Qualität hängt sowohl von den gefundenen Inhalten als auch davon ab, wie das Modell sie für die Antwort verwendet. Siehe: Interne KI-Assistenten.

Runbook

Eine knappe Anleitung für einen wiederkehrenden Betriebsfall: woran das Problem zu erkennen ist, was in welcher Reihenfolge zu prüfen ist und wer zu rufen ist. Sie ist für den Menschen geschrieben, der nachts geweckt wurde. Ein Runbook, das seit einem Jahr niemand gelesen hat, ist im Ernstfall meistens falsch. Siehe auch: Postmortem.

S

SAST, DAST, SCA

Drei Gattungen automatischer Sicherheitsprüfung. SAST liest den Quellcode, DAST prüft die laufende Anwendung von außen, SCA vergleicht die eingebundenen Fremdbestandteile mit bekannten Schwachstellen. Jede findet, was die anderen strukturell übersieht, deshalb ersetzt keine die andere. Siehe auch: DevSecOps.

SBOM

Software Bill of Materials, eine maschinenlesbare Stückliste aller Bestandteile einer Software, einschließlich der Bestandteile der Bestandteile. Sie beantwortet die Frage, die nach jeder größeren Schwachstellenmeldung gestellt wird: Sind wir betroffen? Nützlich wird sie erst, wenn sie in jedem Build automatisch entsteht. Siehe: SBOM erzeugen, prüfen, aufbewahren.

Secrets Management

Der geordnete Umgang mit Passwörtern, Zugriffsschlüsseln und Zertifikaten: zentral abgelegt, im Zugriff eingeschränkt, regelmäßig gewechselt und nie im Repository. Der häufigste Fund ist kein Angriff, sondern ein Schlüssel, den jemand vor Jahren zum Testen eingecheckt hat. Siehe auch: Least Privilege.

Shared Responsibility

Die Aufteilung, wer für welchen Teil der Sicherheit in der Cloud geradesteht. Der Anbieter sichert Rechenzentrum, Hardware und den Dienst selbst, Sie sichern Ihre Konfiguration, Ihre Zugänge und Ihre Daten. Vorfälle in der Cloud passieren überwiegend auf der Seite, die dem Kunden gehört. Siehe: Cloud-Security Grundlagen.

Shift Left

Prüfungen wandern früher in den Entstehungsprozess, also nach links auf dem Zeitstrahl. Der Grund ist wirtschaftlich: Ein Fehler, der beim Prüfen der Änderung auffällt, kostet einen Kommentar, derselbe Fehler in Produktion kostet ein Release. Siehe auch: CI/CD.

SLO

Service Level Objective, ein selbst gesetztes Ziel für die Qualität eines Dienstes, etwa für Erreichbarkeit oder Antwortzeit. Sein Zweck ist nicht die Zahl, sondern die Entscheidung dahinter: Solange das Ziel gehalten wird, wird gebaut, wird es gerissen, wird stabilisiert. Ein SLO ohne diese Folge ist eine Kennzahl auf einer Folie. Siehe auch: Observability.

Souveränität

Die Frage, wie abhängig ein Betrieb von einem einzelnen Anbieter oder einer einzelnen Rechtsordnung ist. Sie zerfällt in drei kleinere Fragen: Wo liegen die Daten, wer kann auf sie zugreifen, und wie aufwendig wäre ein Wechsel. Pauschale Antworten helfen selten, die drei Teilfragen dagegen schon. Siehe auch: Datenresidenz.

SSO

Single Sign-on, also einmal anmelden und danach ohne erneute Anmeldung in alle angeschlossenen Anwendungen. Für Mitarbeitende ist das bequemer, für das Unternehmen vor allem sicherer, weil es nur noch eine Stelle gibt, an der ein Zugang eingerichtet und entzogen wird. Ein verbreitetes Protokoll dafür ist OpenID Connect. Hintergrund: OpenID Connect Core 1.0 (öffnet in neuem Tab).

T

Terraform State

Die Datei, in der Terraform festhält, welche Ressourcen es angelegt hat und wie sie zum Code gehören. Ohne sie weiß das Werkzeug beim nächsten Lauf nicht, ob es etwas ändern oder neu anlegen soll. Sie gehört an einen geteilten, gesperrten Ort und nicht auf einen Laptop, sonst arbeiten zwei Leute gleichzeitig an derselben Umgebung. Siehe: Terraform im Team.

Threat Modeling

Ein strukturiertes Gespräch entlang eines Architekturbilds: Was wollen wir schützen, wer könnte es angreifen, an welcher Stelle, und was tun wir dagegen. Ergebnis ist eine geordnete Maßnahmenliste, kein Werkzeugbericht. Es lohnt sich früh, weil sich ein Entwurf billiger ändern lässt als ein laufendes System.

Toil

Wiederkehrende Handarbeit im Betrieb, die nichts dauerhaft verbessert: dasselbe Ticket, derselbe Handgriff, jede Woche. Sie ist der beste Kandidat für Automatisierung, weil der Aufwand bekannt ist und der Nutzen sich wiederholt. Wer Toil nicht erfasst, automatisiert stattdessen das, was gerade Spaß macht. Siehe auch: Runbook.

Z

Zero Trust

Der Grundsatz, dass kein Zugriff allein deshalb vertrauenswürdig ist, weil er aus dem eigenen Netz kommt. Jeder Zugriff weist sich aus und wird geprüft, unabhängig vom Standort. In der Umsetzung ist das weniger ein Produkt als eine Reihe von Entscheidungen über Identität, Geräte und Berechtigungen. Siehe auch: Identity Provider.

Quellen zu GitOps, Zugriffsschutz und KI

• OpenGitOps: PrinciplesCNCF OpenGitOps Working Group
• Istio: SecurityIstio-Dokumentation, Authentifizierung und Autorisierung
• Azure Policy: Audit effectMicrosoft Learn
• RAG evaluatorsMicrosoft Learn, Qualität von Suche und Antworten