Daten, Zugänge und Sicherungen im Griff

Danach können Sie

Sie wissen, welche Informationen ins Projekt gehören, wer Zugriff auf Anwendung und Konten braucht und warum ein gespeicherter Code-Stand keine Datenbanksicherung ersetzt. Für eine kleine Übung reichen erfundene Daten; bei einer echten Anwendung treffen Sie diese Entscheidungen ausdrücklich.

Drei verschiedene Arten von Informationen

Art	Beispiel	Umgang
Code und Projektwissen	Bildschirm, Tests, Beschreibung des Änderungsablaufs	Im passenden Repository nachvollziehbar verwalten
Geheimnisse	Passwort, Dienstschlüssel oder Zugangstoken	Im vorgesehenen Geheimnisspeicher oder lokal geschützter Konfiguration halten
Geschäftsdaten	Echte Aufträge, Kundendaten oder Mitarbeiterangaben	In den dafür bestimmten Systemen mit geeigneten Rechten und Aufbewahrungsregeln bearbeiten

Ein privates Repository ist weiterhin für berechtigte Personen und angebundene Dienste zugänglich. Prüfen Sie deshalb, wer Zugriff hat und wem das Repository gehört. GitHub: Repository-Eigentum und Sichtbarkeit.

Geheimnisse vor dem Teilen erkennen

Eine Datei wie .env kann Zugangsdaten enthalten. Eine .env.example soll dagegen erklären, welche Angaben gebraucht werden, und nur Platzhalter enthalten. Kontrollieren Sie den tatsächlichen Inhalt; der Dateiname allein macht eine Datei nicht unbedenklich. Die GitHub-Einrichtung erläutert passende Ignore-Regeln.

Ist ein echter Schlüssel versehentlich gespeichert oder geteilt worden, behandeln Sie den Zugang beim betroffenen Dienst: sperren beziehungsweise ersetzen Sie ihn. Nur die sichtbare Zeile später zu löschen reicht nicht zuverlässig, weil frühere Stände oder Kopien bestehen können. Eine Bereinigung der Git-Geschichte benötigt ein abgestimmtes Vorgehen. GitHub: sensible Daten entfernen.

Mit KI ohne echte Kundenbestände üben

Benutzen Sie für die erste Übung erfundene Auftragsnummern und Kunden. Für einen Fehler genügt oft eine reduzierte Beschreibung mit synthetischen Daten. Entfernen Sie aus Fehlermeldungen und Bildern Zugangstoken und unnötige persönliche Angaben, bevor Sie sie teilen.

Bei einer Firmenanwendung gehört zur Werkzeugauswahl, welche Daten das gewählte Produkt verarbeitet und welche Einstellungen und Verträge für Ihr Unternehmen gelten. Das wird am konkreten Dienst geprüft. Eine pauschale Zusage «KI sieht unsere Daten nie» lässt sich nicht aus einem allgemeinen Tutorial ableiten.

Anmeldung und Berechtigung unterscheiden

Die Anmeldung klärt, welches Konto handelt. Die Berechtigung klärt, welche Aufträge dieses Konto lesen oder ändern darf. In der Service-App könnte die Planung alle Aufträge sehen, ein Techniker nur seine zugewiesenen Aufträge.

Das muss bei den Datenabrufen und Änderungen durchgesetzt werden. Ein ausgeblendeter Knopf reicht nicht. Prüfen Sie auch eine verbotene Aktion mit einem zweiten Testkonto. Bei einer Datenbank mit Row Level Security werden zum Beispiel Zugriffsregeln für Datensätze festgelegt; zusätzliche Regeln können für einzelne erlaubte Änderungen nötig sein. Supabase: Row Level Security.

Code zurücknehmen und Daten wiederherstellen

Wenn Sie den Filter-Code zurücknehmen, verschwinden dadurch keine irrtümlich angelegten oder gelöschten Geschäftsdaten. Umgekehrt ersetzt eine Datenbanksicherung nicht die Dokumentation, welcher Code-Stand dazu passt.

Schreiben Sie für Ihre Anwendung auf: Was wird gesichert? Wie oft? Wo? Wer kann darauf zugreifen? Wie würde eine Wiederherstellung ablaufen, und wann wurde sie mit geeigneten Testdaten geübt? Denken Sie auch an hochgeladene Dateien und Konfiguration. Bei Supabase sind beispielsweise Datenbanksicherungen und Dateien im Storage getrennt zu betrachten; die verfügbaren Sicherungen hängen auch vom gewählten Angebot ab. Offizielle Backup-Dokumentation.

Erfolgskontrolle

Für ein Übungsprojekt können Sie bestätigen, dass nur eigene Beispieldaten und keine Zugangsdaten geteilt werden. Für eine echte App kennen Sie zusätzlich Kontoinhaber, Rollen, erlaubte KI-Nutzung, getrennte Testzugänge und den geprüften Sicherungs-/Wiederherstellungsweg. Offene Punkte werden benannt, statt aus einem grünen Test automatisch vollständige Sicherheit abzuleiten.