Was macht awaBerry sicher?
Sicherheitsarchitektur — für IT-Administratoren, Sicherheitsbeauftragte & Entwickler.
Sicherheitsphilosophie
Zero Trust. Least Privilege. Lokale Ausführung.
awaBerry basiert auf drei nicht verhandelbaren Sicherheitsprinzipien, die für alle drei Produkte gelten. Sicherheit ist keine zusätzliche Schicht über der Funktionalität — sie ist das Fundament, auf dem die Plattform aufgebaut ist.
Zero Trust
Kein Gerät, kein Benutzer und kein Skript wird standardmäßig vertraut. Jede Zugriffsanfrage wird explizit authentifiziert und autorisiert, jedes Mal — unabhängig vom Netzwerkstandort oder der vorherigen Zugriffshistorie.
Least Privilege
Jede Zugriffsgewährung definiert den minimal erforderlichen Umfang. Breiterer Zugriff muss bewusst konfiguriert werden, nicht vererbt. Kein Zugriff existiert außerhalb eines aktiven Projekts — keine permanenten Anmeldeinformationen, keine Hintergrundsitzungen.
Lokale Ausführung
Automatisierungslogik und Datenverarbeitung laufen auf dem registrierten Gerät. Daten werden nicht über die awaBerry Cloud-Infrastruktur übertragen, es sei denn, sie werden vom Betreiber explizit dorthin geleitet. Sensible Daten bleiben dort, wo sie hingehören.
Für IT-Administratoren
Operative Sicherheitskontrollen
Kein VPN, keine offenen Ports — Jemals
Der awaBerry Agent auf jedem Gerät stellt einen ausgehenden HTTPS-Tunnel zur Cloud-Koordinationsschicht her. Dies ist die einzige beteiligte Netzwerkverbindung. Es müssen keine Firewall-Regeln erstellt oder geändert werden. Kein öffentlicher IP-Adresse wird einem registrierten Gerät zugewiesen oder von diesem exponiert. Geräte hinter NAT, mobilen Datenverbindungen oder strengen Unternehmensfirewalls werden vollständig unterstützt — Netzwerkadministratoren, die den Datenverkehr beobachten, sehen standardmäßiges ausgehendes HTTPS.
Anmeldeinformationsarchitektur — Keine geteilten Anmeldeinformationen
Gemeinsame Root-SSH-Schlüssel, permanente VPN-Anmeldeinformationen und gemeinsame Admin-Passwörter werden durch projektspezifische API-Schlüssel ersetzt. Jedes Projekt hat eindeutige, unabhängige Anmeldeinformationen. Die Sperrung ist vollständig und sofort — das Löschen eines Projekts beendet alle aktiven Sitzungen, macht die Anmeldeinformationen ungültig und hinterlässt keinen residualen Zugriff. Kein Benutzerkonto zum Bereinigen. Kein SSH-Schlüssel zum Rotieren. Keine Firewall-Regel zum Rückgängigmachen.
Flottenzugriffskontrolle
Die Agentic API ermöglicht es einem einzelnen Projekt, mehrere Geräte gleichzeitig anzusprechen, was eine flächendeckende Automatisierung ohne die Erstellung gerätespezifischer Anmeldeinformationen ermöglicht. Jedes Projekt erzwingt weiterhin dieselben Berechtigungsbeschränkungen für jedes von ihm angesprochene Gerät — eine Konfiguration, einheitlich angewendet.
Für Sicherheitsbeauftragte
Zugriffskontroll- & Compliance-Architektur
Jedes Agentic API-Projekt erzwingt die Zugriffskontrolle über vier unabhängige Dimensionen. Keine Dimension erbt von einer anderen. Jede muss explizit konfiguriert werden — breiterer Zugriff ist immer ein explizites Opt-in, niemals ein Standard.
Berechtigungsstufe
Restriktiv (Standard): Standard-awaberry-Benutzer — privilegierter, isolierter Account ohne Zugriff auf andere Accounts oder Kernsystemverzeichnisse.
Freizügig (explizites Opt-in): Administrator- / Root-Zugriff — muss pro Projekt bewusst konfiguriert werden.
Dateisystem- & Schreibzugriff
Restriktiv (Standard): Nur benannte absolute Pfade — das Projekt kann nur auf Verzeichnisse zugreifen, die bei der Erstellung explizit aufgeführt sind.
Freizügig (explizites Opt-in): Alle Ordner, mit Schreibzugriff und Unterordnererstellung pro Pfad aktiviert.
Befehlsausführung
Restriktiv (Standard): Strikte Whitelist zulässiger Befehle — der Agent führt nur Befehle aus, die exakt mit der Liste übereinstimmen.
Freizügig (explizites Opt-in): Alle Befehle zulässig — nur für vertrauenswürdige interne Automatisierung geeignet.
Schreibgeschützter Audit-Zugriff
Erstellen Sie ein Projekt, das auf /var/log/ und /etc/app/ beschränkt ist, ohne Schreibzugriff und mit einer Befehls-Whitelist von schreibgeschützten Tools (cat, grep, tail). Teilen Sie den Schlüssel. Löschen Sie das Projekt nach Abschluss des Audits — keine residualen Artefakte.
Incident Response — Forensischer Zugriff
Gewähren Sie einem SOC-Analysten Lesezugriff auf Protokolle, Prozessdaten und Netzwerkstatus (ps aux, netstat -tulnp, cat /var/log/auth.log). Destruktive Befehle sind strukturell von der Whitelist ausgeschlossen. Löschen nach Abschluss der Untersuchung.
Zertifikatsrotation ohne gemeinsame Root-Zugänge
Ein dediziertes Projekt mit einer engen Befehls-Whitelist (systemctl reload nginx, certbot renew) und dem Zertifikatsverzeichnis im Geltungsbereich ermöglicht die vollständige TLS-Rotation im gesamten Bestand — keine Root-Anmeldeinformationen verlassen jemals Ihre Kontrolle.
Zugriff für Auftragnehmer ohne VPN-Onboarding
Generieren Sie einen Projektschlüssel. Teilen Sie ihn über die integrierte E-Mail-Entwurfsfunktion. Löschen Sie das Projekt, wenn die Arbeit erledigt ist. Gesamte Bereitstellungszeit: unter zwei Minuten. Gesamte Bereinigungszeit: ein Klick.
Automatisierte Backup-Pipelines, die von der Smart Automation Platform generiert werden, umfassen drei Ebenen der Datensicherheit:
Integritätsprüfung
Zeilenanzählprüfungen verifizieren, dass das Backup vollständig ist, bevor fortgefahren wird. Ein beschädigter oder leerer Dump bricht die Pipeline ab und löst eine Benachrichtigung aus — er wird niemals stillschweigend hochgeladen.
GPG-Verschlüsselung
Backup-Dateien werden vor dem Hochladen in die Cloud mit vom Betreiber verwalteten GPG-Schlüsseln verschlüsselt. Die awaBerry-Plattform hält niemals Verschlüsselungsschlüssel.
Vom Betreiber kontrollierter Speicher
Verschlüsselte Archive werden in von Cloudflare R2 oder S3-kompatible Buckets hochgeladen, die vom Betreiber besessen und verwaltet werden. awaBerry speichert oder greift nicht auf Backup-Daten zu.
Für Entwickler
Sicherheit im Entwicklungsworkflow
Lokale Ausführung — Daten bleiben auf dem Gerät
Die gesamte Automatisierungslogik wird lokal auf dem registrierten Gerät ausgeführt. Die Gemini CLI läuft auf dem Gerät. Generierte Skripte laufen auf dem Gerät. Daten, die von Automatisierungspipelines verarbeitet werden, werden nicht über die awaBerry Cloud-Infrastruktur übertragen — sie gehen nur dorthin, wohin das Skript sie explizit sendet (eine lokale Datei, eine Datenbank, ein REST-Endpunkt, ein Cloud-Bucket). Sensible Daten — Rechnungen, Gesundheitsakten, Anmeldeinformationen, proprietäre Datensätze — werden lokal verarbeitet und niemals einer Drittanbieter-Automatisierungsplattform ausgesetzt.
Geltungsbereich für KI-Agenten-Zugriff
Wenn KI-Agenten über die Agentic API als MCP-Server auf Geräte zugreifen, gilt dasselbe Berechtigungsmodell wie für jedes andere Zugriffsprojekt. Agenten authentifizieren sich mit einem Projektschlüssel — sie erhalten keinen breiteren Zugriff als jedes andere Projekt. Der Dateisystemzugriff ist auf explizit definierte Verzeichnisse beschränkt. Die Befehlsausführung ist auf die Projekt-Whitelist beschränkt. Der Zugriff des Agenten ist unabhängig von jeder anderen Integration in Ihrem Stack widerrufbar.
Transparenz von Abhängigkeiten und Skripten
Die Setup-Phase generiert Skripte unter Verwendung standardmäßiger, bekannter Bibliotheken (playwright, pdfplumber, hl7apy, feedparser, rclone). Generierte Skripte werden lokal gespeichert, sind menschenlesbar und prüfbar. Entwickler können sie inspizieren, ändern und versionieren. Es gibt keine proprietäre Binärdatei oder verschleierte Ausführungsschicht zwischen dem generierten Skript und dem Betriebssystem.
Zusammenfassung
Sicherheitseigenschaften im Überblick
Keine eingehenden Ports
Geräte-Agent verwendet nur ausgehenden HTTPS-Tunnel — keine Firewall-Regeln werden jemals berührt.
Kein VPN erforderlich
Alle Zugriffe laufen über den awaBerry Access Broker über Standard-HTTPS.
Keine geteilten Anmeldeinformationen
Jedes Projekt hat eindeutige, unabhängig widerrufbare Schlüssel — kein gemeinsamer Root, kein gemeinsames VPN, keine gemeinsamen Passwörter.
Least Privilege erzwungen
Vierdimensionale Berechtigungsmodell — Berechtigung, Dateisystem, Schreibzugriff, Befehlsumfang — pro Projekt konfiguriert, bei jeder Ausführung erzwungen.
Sofortiger Widerruf
Projekt löschen = sofortige Beendigung aller Zugriffe. Keine residualen Artefakte. Keine Bereinigung erforderlich.
Gastisolation
Externe Benutzer landen im sandboxed awaberry-Account — kein Zugriff auf andere Accounts oder Kernsystemverzeichnisse.
Verschlüsselt während der Übertragung
Der gesamte Tunnelverkehr ist Ende-zu-Ende HTTPS. Alle Backup-Archive sind vor dem Hochladen mit vom Betreiber verwalteten Schlüsseln GPG-verschlüsselt.
Lokale Datenverarbeitung
Automatisierung wird auf dem Gerät ausgeführt — Daten werden nicht über awaBerry übertragen. Skripte sind menschenlesbar, lokal gespeichert und vollständig prüfbar.
Schlussfolgerung
Sicherheit durch Architektur, nicht durch Hinzufügung.
Das Sicherheitsmodell von awaBerry ist keine zusätzliche Schicht über der Funktionalität — es ist das Fundament, auf dem die Plattform aufgebaut ist. Der nur ausgehende Tunnel eliminiert die häufigste Angriffsfläche für Fernzugriffe. Das projektbasierte Berechtigungsmodell macht Least Privilege zum Standard, nicht zur Ausnahme. Sofortiger Widerruf macht zeitlich begrenzte Zugriffe betrieblich praktikabel. Und die lokale Ausführung stellt sicher, dass sensible Daten niemals die Maschine verlassen müssen, auf der sie hingehören.
