Sicherheit, secrets und sicherer Betrieb

Lokale Projekt-Secrets

Lino registriert automatisch die lokalen Secrets, die für die generierte Anwendung erforderlich sind. Passwörter für Datenbank, Redis und RabbitMQ, der JWT-Schlüssel, API keys und andere sensible Werte bleiben in den User Secrets der Anwendung, statt in versionierten Dateien angelegt zu werden.

lino secret list
lino secret set
lino secret remove
lino secret clear

Die Befehle bleiben für die Wartung nützlich: Verwenden Sie secret list, um konfigurierte Schlüssel zu prüfen, secret set, um lokale Werte zu ändern oder zu registrieren, secret remove, um einen Schlüssel zu löschen, und secret clear, um alle lokalen Secrets des Projekts zu entfernen.

Dieser Ablauf ist in das generierte Projekt integriert. Wenn Sie Ressourcen wie Redis, RabbitMQ, Authentifizierung, Autorisierung, SMTP, API keys oder Download-Tokens hinzufügen, hält Lino sensible Werte aus dem Quellcode heraus und bereitet die Anwendung darauf vor, sie als Umgebungskonfiguration zu erhalten.

Sie können lokale Secrets bei Bedarf auch mit Plattformwerkzeugen von .NET und Aspire prüfen, zum Beispiel mit dotnet user-secrets list oder entsprechenden Aspire-Ressourcen. Der Lino-Befehl macht diesen Ablauf im Kontext des generierten Projekts direkter.

Parameter in Aspire

Der Aspire AppHost koordiniert Ressourcen wie Datenbanken, Redis, RabbitMQ, APIs, Worker und Web-Apps. In generierten Projekten registriert Lino sensible Werte als Aspire-Parameter, damit die Anwendung diese Werte als externe Abhängigkeiten behandelt und nicht als feste Daten im Quellcode.

Dazu gehören Passwörter für Datenbank, Redis und RabbitMQ sowie andere Werte, die für die lokale Infrastruktur erforderlich sind. Der AppHost übergibt diese Parameter mit dem Secret-Modell von Aspire an die entsprechenden Ressourcen, zum Beispiel mit Parametern, die als sensibel markiert sind.

Der praktische Vorteil ist, dass das Secret kein verlorenes Detail in Konfigurationsdateien mehr ist, sondern Teil des Ausführungsmodells der Lösung wird. Wenn Sie die Anwendung über Aspire ausführen, erhalten die Dienste die benötigten Abhängigkeiten, ohne dass Sie Passwörter manuell in jedes Projekt kopieren müssen.

Dieses Design hilft auch beim Deployment. Wenn Aspire Artefakte veröffentlicht, bleibt der Bedarf an diesen Parametern bestehen: In Docker Compose können beispielsweise Platzhalter und Umgebungsdateien erscheinen, die in der richtigen Umgebung ausgefüllt werden müssen; bei anderen Targets leitet dasselbe Prinzip die Übergabe sensibler Konfiguration an die Plattform.

Rate limiting

Rate limiting reduziert Missbrauch, Brute Force und unangemessenen Ressourcenverbrauch. Lino konfiguriert bereits Standard-Policies und wendet Helfer auf generierte Endpunkte an, damit öffentliche, authentifizierte, interne und sensible APIs nicht ohne Nutzungsgrenzen entstehen.

Das ist wichtig, weil eine API korrekt authentifizieren und trotzdem unter Volumenmissbrauch leiden kann. Login, Refresh Token, Registrierung und Passwortwiederherstellung sind sensible Abläufe; standardmäßig trennt Lino sie von gewöhnlichen Endpunkten, damit sie konservativere Limits haben.

• Verwenden Sie die generierten Policies, wenn Sie neue Endpunkte erstellen.
• Behalten Sie unterschiedliche Limits für sensible und gewöhnliche Endpunkte bei.
• Kombinieren Sie Rate limiting bei Bedarf mit Authentifizierung, Validierung und Bot-Schutz.
• Behandeln Sie 429 Too Many Requests als erwartete Antwort, wenn das Limit überschritten wird.

JWT-Sicherheit

Wenn Authentifizierung hinzugefügt wird, generiert Lino die Grundlage für das Ausstellen, Lesen und Validieren von JWTs und hält den Signaturschlüssel aus dem Quellcode heraus. Das Token identifiziert den Benutzer und enthält wesentliche Claims, ohne das JWT in eine portable Datenbank zu verwandeln.

• Bewahren Sie den Signaturschlüssel in der Entwicklung in User Secrets und in der Produktion bei einem sicheren Provider auf.
• Behalten Sie die im Projekt konfigurierte Validierung von issuer, audience, Ablaufzeit und Algorithmus bei.
• Nehmen Sie nur Claims auf, die für den authentifizierten Ablauf erforderlich sind.
• Verwenden Sie bei Multi-Tenancy den Benutzer- und Tenant-Kontext, den Lino bereits bereitstellt.

Der JWT-Signaturschlüssel ist ein kritisches Secret, und Lino behandelt diesen Wert bereits als sensible Konfiguration. Wenn Sie neue Umgebungen, Pipelines oder Deployments erstellen, behalten Sie dieselbe Regel bei: Der Schlüssel darf nicht in Commits, Docker-Images, Logs, öffentlichen Dateien oder realen Konfigurationsbeispielen erscheinen.

JWT ersetzt auch keine Autorisierung in der Domäne. Claims helfen bei Entscheidungen, aber kritische Operationen müssen weiterhin den aktuellen Zustand, den Benutzerstatus, aktive Berechtigungen und den Kontext der Anfrage berücksichtigen. Der generierte Teil liefert die Grundlage; Ihre Verantwortung bei der Weiterentwicklung des Systems ist es, keine Abkürzungen zu schaffen, die diesen Ablauf umgehen.

API keys und Download-Tokens

Lino behandelt API keys und temporäre Tokens als Credentials mit begrenztem Scope. Wenn ein Ablauf temporären Zugriff auf eine Datei, ein Paket oder eine Integration freigeben muss, bevorzugt die generierte Grundlage kurze, spezifische Tokens, statt breite Credentials wiederzuverwenden.

• Verwenden Sie kurze Ablaufzeiten für Links und temporäre Tokens.
• Verknüpfen Sie das Token mit Benutzer, Tenant und Ressource, wenn der Ablauf diesen Kontext hat.
• Protokollieren Sie die Nutzung für Audits, wenn der Zugriff sensible Artefakte betrifft.
• Widerrufen Sie Tokens, wenn sich Ressource oder Berechtigung ändern.

Durch Schlüssel geschützte APIs verwenden das von Lino generierte Autorisierungs- und Rate-Limiting-Modell. Ein Schlüssel, der für Integrationsautomatisierung erstellt wurde, darf nicht zum Freifahrtschein für administrative Aufrufe werden, und ein temporäres Download-Token darf die Berechtigungen des authentifizierten Benutzers nicht ersetzen.

Wenn Sie neue Download- oder Integrationsabläufe erstellen, behalten Sie dieselbe Idee bei: expliziter Scope, Ablaufzeit, nützliche Metadaten und eine passende Rate-Limiting-Policy. So bleibt temporärer Zugriff auditierbar und vorhersehbar, statt zu einem losen Credential zu werden, das im System zirkuliert.

Secret-Provider in Produktion

User Secrets lösen die lokale Entwicklung. In Produktion behalten Sie dieselbe Trennung bei, indem Sie den sicheren Provider der Plattform verwenden: Azure Key Vault, AWS Secrets Manager, Google Secret Manager, HashiCorp Vault, Kubernetes Secrets oder vom Orchestrator geschützte Umgebungsvariablen.

Lino bereitet die Anwendung darauf vor, sensible Konfiguration von außerhalb des Codes zu erhalten. Der Wechsel in die Produktion ist eine Umgebungsentscheidung: Namen und Parameter bleiben bestehen, aber die Werte kommen aus dem Tresor, der Pipeline oder dem Orchestrator Ihrer Infrastruktur.

In Produktion kommen außerdem operative Praktiken wie Rotation, Trennung nach Umgebung, Berechtigungen pro Anwendung und Zugriffsaudits hinzu. User Secrets ersetzen diese Kontrollen nicht; sie decken die lokale Erfahrung ab, ohne Secrets ins Repository zu legen.

• Nach Umgebung trennen: Entwicklung, Staging und Produktion dürfen keine Credentials gemeinsam nutzen.
• Nach Anwendung trennen: Jeder Dienst sollte nur die Secrets erhalten, die er benötigt.
• Rotation planen: JWT-Schlüssel, SMTP, API keys und Datenbankpasswörter benötigen ein Austauschverfahren.
• Zugriff auditieren: Erfassen Sie, wer Secrets auf der Plattform lesen oder ändern kann.