Security by Design in KI- und Softwareprojekten | dynabase

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.

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.

Termin buchen

Häufige Fragen zu Security by Design