Plattform-Sicherheit

Authentifizierung:

E-Mail + Passwort mit Erzwingung starker Passwörter
Google- und GitHub-OAuth
optionale Zwei-Faktor-Authentifizierung (2FA)
Session-Management mit automatischem Ablauf

Datenschutz:

alle Projekte sind standardmäßig privat
nur du und die von dir eingeladenen Teammitglieder können ein Projekt öffnen — kein anderer Airbuild-Kunde hat Zugriff darauf
Airbuild-Mitarbeiter greifen auf Projektinhalte nur nach dem Need-to-know-Prinzip zu, für Support und Störungsbehebung, unter Vertraulichkeitsverpflichtung, mit minimalen Rechten und MFA-geschütztem administrativem Zugriff — eine Produktfunktion, über die Mitarbeitende Kundeninhalte durchsehen, gibt es nicht; siehe Auftragsverarbeitungsvertrag
veröffentlichte Seiten sind unter ihrer *.airbuild.space-URL öffentlich
Quellcode wird verschlüsselt gespeichert (at rest)

Infrastruktur:

HTTPS überall — TLS 1.2 oder höher, Zertifikate über den AWS Certificate Manager verwaltet
sämtliche produktiven Compute-Ressourcen, Datenbanken und Speicher laufen auf AWS in eu-central-1 (Frankfurt): ECS, RDS, Aurora, EFS und S3
CloudFront liefert statische Assets über sein globales Edge-Netzwerk; alle Origins bleiben in eu-central-1
AES-256-Verschlüsselung at rest über AWS KMS; Projekt-Secrets sind zusätzlich auf Anwendungsebene verschlüsselt
Projektcode läuft unter einem unprivilegierten Systembenutzer, getrennt vom Konto, unter dem die Plattform selbst läuft; jeder Workspace hat ein eigenes Projektverzeichnis
wo der Runner-Host es zulässt, sperren zusätzlich Egress-Firewall-Regeln die Cloud-Metadaten-Endpunkte, Redis, PostgreSQL und interne Service-Ports; wo nicht, begrenzen VPC-Security-Groups, was ein Workspace erreichen kann
regelmäßige Sicherheits-Updates

Secret-Erkennung

Airbuild erkennt sensible Daten in Chat-Nachrichten automatisch:

API-Keys (OpenAI, Stripe, AWS usw.)
Passwörter und Tokens
Connection-Strings
Private Keys

Wird etwas erkannt, erscheint ein Banner mit maskiertem Wert und einem Vorschlag für den Variablennamen. Es hält die Nachricht nicht zurück und maskiert nichts in der Nachricht selbst — die beiden Aktionen sind In .env speichern, womit der Wert als Umgebungsvariable gespeichert wird, die der generierte Code lesen kann, und Ignorieren, das den Banner schließt. Soll das Modell einen Wert nie sehen, entferne ihn vor dem Senden aus dem Text.

Umgebungsvariablen

Best Practices für den Umgang mit Secrets:

speichere API-Keys im Environment-Tab, nicht im Code
nutze getrennte Werte für Dev und Prod
die KI ist angewiesen, Umgebungsvariablen zu referenzieren statt Secrets hart zu codieren; landet doch ein Key im Code, stoppt der Secret-Scan vor dem Veröffentlichen die Freigabe
von Integrationen verwaltete Variablen (DATABASE_URL) sind schreibgeschützt

Team-Sicherheit

rollenbasierter Zugriff im Projekt: Owner, Admin, Editor, Viewer — siehe Team & Rollen
rollenbasierter Zugriff in der Organisation: Owner, Admin, Member und Viewer, dazu eigene Rollen, die eine Organisation selbst mit eigenem Rechte-Satz anlegt. Billing Admin und Security Admin lassen sich beim Einladen eines Mitglieds zusätzlich vergeben
Admins können Mitglieder einladen und entfernen
Eigentumsübertragung verfügbar
jedes Teammitglied hat einen isolierten Workspace

Sicherheit veröffentlichter Seiten

automatisches HTTPS über CloudFront
CORS-Header pro Projekt konfiguriert
Generierte Backends setzen Authentifizierung pro Endpunkt, und jede Veröffentlichung listet Endpunkte ohne Sicherheitsanforderung zur Bestätigung auf — siehe Prüfung vor dem Release
Datenbankverbindungen sind verschlüsselt