Security by Design: So sichern wir KI-Agenten, APIs und Cloud-Infrastruktur ab
By
Daniel Angileri
·
4 minute read

Security by Design heißt: Sicherheit wird beim Entwurf eines Systems mitgeplant und nicht erst nach dem Go-live nachgerüstet. Bei dynabase ist das keine Zusatzleistung, sondern Teil jedes Projekts, egal ob wir einen KI-Agenten bauen, eine Schnittstelle anbinden oder eine Cloud-Infrastruktur aufsetzen. Hier zeigen wir, welche Fragen wir dabei klären und wie die Umsetzung konkret aussieht.
Was bedeutet Security by Design?
Wer Sicherheitsfragen erst am Ende stellt, findet Lücken, die schon in der Architektur stecken. Ein Service, der am Anfang aus Bequemlichkeit Admin-Rechte bekommen hat, lässt sich später nur mit Aufwand wieder einschränken. Deshalb klären wir früh: Wer greift auf welche Daten zu? Welche Systeme sprechen miteinander? Wo liegen Passwörter und Schlüssel?
Drei Grundsätze helfen dabei:
- Least Privilege: Jede Person, jeder Service und jeder KI-Agent bekommt nur die Rechte, die für die Aufgabe nötig sind.
- Security by Default: Die sichere Einstellung ist der Standard. Mehr Zugriff wird bewusst freigegeben, nicht aus Versehen.
- Privacy by Design: Datenschutz wird genauso früh mitgedacht, zum Beispiel welche Daten ein System überhaupt speichern muss.
Security by Design ist kein Zertifikat und keine einmalige Checkliste. Es ist eine Arbeitsweise, die sich durch Konzeption, Entwicklung und Betrieb zieht.
KI-Agenten absichern: Was darf der Agent?
Ein KI-Agent beantwortet nicht nur Fragen. Er ruft Daten ab, nutzt Schnittstellen und löst Aktionen in anderen Systemen aus. Damit wird die wichtigste Sicherheitsfrage: Was darf der Agent tun, und was nicht?
Wir betreiben selbst mehrere KI-Agenten im Arbeitsalltag und haben viel Zeit investiert, sie sicher zu betreiben. Die größte Angriffsfläche ist dabei fast immer das Tooling, also alles, was ein Agent tatsächlich ausführen kann. Deshalb achten wir auf:
- Eigene Zugänge pro Agent statt geteilter Admin-Konten
- Klare Scopes: Der Agent sieht nur die Daten und Werkzeuge, die er für seine Aufgabe braucht
- Selbstgehosteten, abgeschotteten Betrieb, wenn sensible Daten im Spiel sind
- Monitoring, damit ungewöhnliches Verhalten auffällt
- Regelmäßige Tests, zum Beispiel auf Prompt Injection (so testen wir unsere Agenten)
Bei der KI-Sicherheit gilt dasselbe wie bei jeder anderen Software: Ein Agent ist nur so sicher wie die Rechte, die man ihm gibt. Mehr dazu, wie wir Agenten bauen: KI-Agenten Entwicklung.
APIs und Schnittstellen: Authentifizierung, Autorisierung und Berechtigungskonzept
Bei jeder Schnittstelle stellen wir zwei Fragen. Erstens: Wer bist du? Das ist die Authentifizierung, etwa über Tokens nach dem OAuth2-Standard. Zweitens: Was darfst du? Das ist die Autorisierung, und sie wird im Berechtigungskonzept festgelegt.

Ein Berechtigungskonzept legt fest, welche Rolle welche Daten lesen, ändern oder löschen darf. Ein Beispiel: Ein KI-Agent, der für den Vertrieb Lagerbestände abfragt, braucht Lesezugriff auf den Bestand. Bestellungen ändern oder Kundendaten einsehen muss er nicht, also bekommt er diese Rechte auch nicht.
In der Praxis heißt das für uns:
- Rollen und Rechte werden vor der Entwicklung festgelegt, nicht danach
- Jede Anfrage wird geprüft, auch zwischen internen Systemen
- Zugriffe werden protokolliert, damit sie nachvollziehbar sind
- Die Vorgaben deines Unternehmens fließen direkt ins Konzept ein
Mehr zu Schnittstellen und Systemintegration: Individuelle Softwareentwicklung.
Cloud-Sicherheit und Kubernetes: Wer darf mit wem sprechen?
In der Infrastruktur geht es um dieselbe Frage auf einer anderen Ebene: Welche Services dürfen miteinander kommunizieren, und wie kommen sie an ihre Zugangsdaten? Bei Cloud-Sicherheit denken viele zuerst an den Anbieter. Ein großer Teil hängt aber davon ab, wie das eigene Setup konfiguriert ist.

- Network Policies: Wir legen fest, welche Services miteinander sprechen dürfen. Das Frontend erreicht zum Beispiel die API, aber nicht direkt die Datenbank.
- RBAC in Kubernetes: Rollenbasierte Rechte für Personen und Services im Cluster.
- Secrets-Management: Passwörter, Schlüssel und Tokens liegen in einem zentralen Speicher, nicht im Code. Die Anwendung bekommt sie zur Laufzeit, und sie lassen sich regelmäßig austauschen (Secret Rotation).
- Sichere Deployments: Infrastruktur als Code und nachvollziehbare Deployments, damit Änderungen geprüft und wiederholbar sind.
- Firewall-Regeln: Offen sind nur die Verbindungen, die wirklich gebraucht werden.
- Audit Logs und Monitoring: Zugriffe und Auffälligkeiten werden sichtbar.
Mehr dazu: Cloud-Infrastruktur und DevOps.
Hybride Setups: Cloud und eigene Server sicher verbinden
Nicht jede Lösung läuft komplett in der Cloud. Bei Hortiya verbinden wir eigene Server, Google Cloud und IoT-Geräte für die Gewächshaus-Steuerung. Beim QS-Monitor für Mainzer Netze läuft Kubernetes auf der eigenen Infrastruktur des Kunden. In solchen Setups kommt eine weitere Frage dazu: Wie werden die Standorte sicher verbunden? Wir lösen das zum Beispiel über VPN-Verbindungen, die nur die nötigen Systeme miteinander verbinden.

Hortiya – hybrid: On-Premises + Google Cloud + IoT
KI-gesteuerte Gewächshaus-Systeme mit Fleet Management über verteilte Standorte: lokale Steuerung vor Ort, zentrale Intelligenz in der Cloud.
AI | Infrastructure

QS-Monitor für Mainzer Netze – On-Premises Kubernetes
Datenqualitäts-Monitoring für kritische Betriebsdaten, vollständig On-Premises in der Infrastruktur des Kunden.
Dashboard | Infrastructure
Die Vorgaben deines Unternehmens einbeziehen
Viele Unternehmen haben eigene Sicherheitsrichtlinien, oft abgeleitet aus Standards wie ISO 27001 oder aus Anforderungen wie NIS2. Diese Vorgaben klären wir zu Projektbeginn und bauen sie in Architektur, Rechtekonzept und Betrieb ein, statt sie am Ende abzuhaken. So erfüllt die Software, die wir bauen, deine Vorgaben von Anfang an.
Fazit
Security by Design ist bei uns Teil jedes Projekts. Die Fragen sind immer ähnlich: Wer darf was, welche Systeme sprechen miteinander, und wo liegen die Zugangsdaten? Je früher sie beantwortet sind, desto weniger muss später nachgebessert werden.
Du planst ein Projekt,
bei dem Sicherheit eine große Rolle spielt?
Dann lass uns in einem kostenlosen Gespräch klären,
worauf es bei dir ankommt.
Häufige Fragen zu Security by Design
Was bedeutet Security by Design?
Security by Design bedeutet, dass Sicherheit beim Entwurf eines Systems mitgeplant wird. Zugriffsrechte, Schnittstellen und Infrastruktur werden von Anfang an sicher gebaut, statt später nachgerüstet zu werden.
Was ist der Unterschied zwischen Security by Design und Security by Default?
Security by Design beschreibt die Arbeitsweise: Sicherheit wird von Anfang an mitgeplant. Security by Default beschreibt das Ergebnis: Die sichere Einstellung ist der Standard, und mehr Zugriff muss bewusst freigegeben werden.
Was gehört in ein Berechtigungskonzept?
Ein Berechtigungskonzept legt fest, welche Rollen es gibt und welche Daten und Funktionen jede Rolle lesen, ändern oder löschen darf. Dazu gehören auch technische Zugänge, etwa von Services oder KI-Agenten, und die Protokollierung der Zugriffe.
Wie sichert man KI-Agenten ab?
Vor allem über die Rechte: Ein KI-Agent bekommt nur Zugriff auf die Daten und Werkzeuge, die er für seine Aufgabe braucht. Dazu kommen eigene Zugänge pro Agent, Monitoring und regelmäßige Tests, zum Beispiel auf Prompt Injection.
Was ist Secrets-Management?
Secrets-Management heißt, Passwörter, API-Schlüssel und Tokens zentral und geschützt zu verwalten statt im Code oder in Konfigurationsdateien. Die Anwendung bekommt sie zur Laufzeit, und sie lassen sich regelmäßig austauschen.
Ist Security bei dynabase eine eigene Leistung?
Security ist bei uns Teil jedes Projekts und kein separates Paket. Wir klären Sicherheitsfragen in KI-, Software- und Infrastrukturprojekten von Anfang an mit und setzen sie in der Entwicklung und im Betrieb um.