CapordiaVerantwortliche benennen, bevor Zugriffe verteilt werden
Unterscheiden Sie den Verantwortlichen für den Mietvorgang, die Person, die den Zugriff auf das Projekt genehmigt, und die Person, die technische Änderungen am Ziel vornehmen darf. Der Verantwortliche für die Ergebnisse muss nicht unbedingt Prozesse starten oder die Maschine administrieren. Schreiben Sie die erforderlichen Vorgänge auf, bevor Sie die Rechte wählen: einen Export lesen, Eingaben ablegen, eine Aufgabe ausführen oder eine Umgebung ändern.
Prüfen Sie anschließend den Umfang der tatsächlich übergebenen Zugriffe. Wenn Sie nicht berechtigt sind, Identitäten zu erstellen oder Berechtigungen festzulegen, lassen Sie das mögliche Verfahren bestätigen, bevor Sie weitere Beteiligte einladen. Umgehen Sie diese Grenze nicht, indem Sie das Passwort des Capordia-Kontos weitergeben. Die Aufteilung der Arbeit und die Verwaltung des kommerziellen Vorgangs sind zwei verschiedene Fragen.
Eine individuelle Identität verwenden und ihren Geltungsbereich kennen
Eine individuelle Identität ermöglicht es, den Zugang einer Person zu entziehen, ohne den der gesamten Gruppe zu ersetzen. In einer SSH-Organisation per Schlüssel unterscheidet OpenSSH zwischen dem dem Server bekannten öffentlichen Schlüssel und dem vom Nutzer gehaltenen privaten Schlüssel. Das Koordinationsdokument kann einen Verweis oder Fingerabdruck eines öffentlichen Schlüssels enthalten; es darf niemals den privaten Schlüssel oder dessen Passphrase enthalten.
Zwei verschiedene Schlüssel, die Zugang zum selben Systemkonto gewähren, schaffen nicht automatisch zwei verschiedene Dateibereiche. Die Berechtigungen hängen vom Konto und den auf der Maschine konfigurierten Mechanismen ab. Entscheiden Sie daher, ob die Anforderung nur die individuelle Authentifizierung betrifft oder auch die Trennung der Aktionen. Für Automatisierungen sehen Sie eine ausdrückliche Identität und einen ausdrücklichen Eigentümer vor, ohne die persönliche Identität eines Kollegen stillschweigend wiederzuverwenden.
Das Ziel prüfen, bevor ihm eine Identität präsentiert wird
Kontrollieren Sie beim ersten Zugang den Namen der Maschine, das erwartete Konto und den Fingerabdruck ihres Hostschlüssels anhand einer vertrauenswürdigen Referenz, die im Prozess der Zugangsübergabe erhalten wurde. Dieser Hostschlüssel identifiziert den Server; er unterscheidet sich von Ihrem Nutzerschlüssel. Eine unerwartete Meldung über eine Änderung der Serveridentität verdient eine Prüfung, nicht die automatische Löschung der bekannten Referenz.
OpenSSH speichert Hostschlüssel und meldet deren Änderungen. Nutzen Sie diese Information im Kontext: angekündigte Neuerstellung der Maschine, geänderte Adresse oder unerklärtes Ereignis. Lassen Sie die Änderung bestätigen, bevor Sie fortfahren, wenn sie nicht erwartet wird. Ziel ist nicht, bei jeder Verbindung ein Ritual hinzuzufügen, sondern zu vermeiden, eine Identitätswarnung als bloße Anzeigestörung zu behandeln.
Fiktives Beispiel: drei Beteiligte, drei Bedürfnisse
Das fiktive Team „Dossier der Werke" bereitet eine Arbeitswoche vor. Idriss führt die Verarbeitungen des Projekts A aus, Noémie liest die Exporte nach und Sacha greift vorübergehend ein, um die Umgebung zu konfigurieren. Das Team wünscht die Rechte aus der Tabelle, muss aber prüfen, ob sie mit dem tatsächlich übergebenen System anwendbar sind. Es handelt sich weder um bestehende Kundenkonten noch um von Capordia angekündigte Funktionen zur Teamverwaltung.
Der entscheidende Grundsatz ist, dass Noémie keinen Administrationszugang erhält, um ein Ergebnis zu öffnen, und dass Sachas Eingreifen ein Ende hat. Eine bloße menschliche Genehmigung konfiguriert keine Rechte: Die technisch verantwortliche Person wendet die verfügbaren Mechanismen an, dann führt jeder die vorgesehenen Kontrollen durch. Ist die gewünschte Trennung nicht umsetzbar, muss das Projekt seine Organisation anpassen, bevor Daten eingeführt werden, die diese Trennung erfordern.
| Beteiligte Person | Bedarf | Gewünschter Bereich | Überprüfung |
|---|---|---|---|
| Idriss, Betrieb | Einträge ablegen und Projekt A starten | Arbeitsbereich A, ohne allgemeine Administration | Ende der Kampagne oder Rollenwechsel |
| Noémie, Validierung | Die übergebenen Exporte lesen | Ausgewählte Ergebnisse, ohne Änderung der Einträge | Ende der Validierung |
| Sacha, Eingreifen | Die zulässige Umgebung vorbereiten | Definierte und genehmigte Änderung | Sobald das Eingreifen abgeschlossen ist |
Ein Zugangsblatt vorbereiten und die Grenzen testen
Das Blatt verbindet eine Person oder eine Automatisierung, eine technische Identität, eine genehmigende Person, einen Bereich, eine Begründung und eine Frist. Bewahren Sie die Referenz des öffentlichen Schlüssels und das Verfahren zum Entzug auf, ohne die Geheimnisse zu speichern. OpenSSH ssh-keygen ermöglicht die Anzeige des Fingerabdrucks eines öffentlichen Schlüssels: Diese Referenz hilft, den richtigen Schlüssel beim Hinzufügen oder Entfernen zu bezeichnen, ohne seinen privaten Teil zu kopieren.
Testen Sie eine zulässige Aktion an einer synthetischen Datei und dann eine absichtlich außerhalb des Bereichs liegende Aktion, die als verweigert vorgesehen ist. Für eine Leserolle muss das Öffnen funktionieren und ein kontrollierter Änderungsversuch muss verweigert werden. Verwenden Sie keine echten Daten, um ein Löschverbot zu testen. Prüfen Sie auch die gemeinsamen Pfade und das Ziel der Ausgaben, denn ein korrektes Recht auf einen Ordner garantiert nicht alle Pfade des Programms.
Widerruf einplanen und eine neue Verbindung überprüfen
Lösen Sie den Widerruf am Ende des Einsatzes aus, beim Ausscheiden einer Person oder nach einem Verdacht auf Kompromittierung. Die verantwortliche Person identifiziert alle betroffenen Berechtigungen, einschließlich der übrigen für dieselbe Identität autorisierten Zugangswege. Sie setzt den Widerruf gemäß der tatsächlichen Konfiguration um. Die RevokedKeys-Direktive von OpenSSH ist ein möglicher Mechanismus unter den dokumentierten; sie darf nicht als aktiv auf einer Maschine angenommen werden, ohne dass dies überprüft wurde.
Prüfen Sie anschließend, dass eine neue Authentifizierung mit der widerrufenen Identität abgelehnt wird, ohne den Wiederherstellungszugang der verantwortlichen Person zu entfernen. Betrachten Sie bereits geöffnete Sitzungen, laufende Aufgaben und Automatisierungsidentitäten getrennt: Eine Berechtigung zu entziehen und eine Aktivität zu beenden sind unterschiedliche Entscheidungen. Muss eine Arbeit fortgesetzt werden, übertragen Sie deren Verantwortung nach einem vereinbarten Verfahren, statt eine verwaiste Identität zu hinterlassen.
Abkürzungen vermeiden, die die Kontrolle verhindern
Ein gemeinsamer privater Schlüssel verhindert, dass bekannt ist, wer ihn ersetzen muss, und erzwingt oft eine kollektive Rotation. Ein breiter Zugang „vorerst“ bleibt tendenziell bestehen, wenn niemand sein Überprüfungsdatum festgelegt hat. Ein Validierungskonto, das auch zur Administration der Maschine verwendet wird, macht Trennungsprüfungen schwer interpretierbar. Beheben Sie diese Probleme im Zugangsblatt, bevor sie zu einer Abhängigkeit im Betrieb werden.
Vermeiden Sie ebenso, Agent-Weiterleitungen, Tunnel oder Zugangsausnahmen hinzuzufügen, nur um eine nicht diagnostizierte Schwierigkeit zu umgehen. Lassen Sie den Bedarf an Verbindungen und deren Einschränkungen von der autorisierten verantwortlichen Person beschreiben. Dieser Leitfaden bietet keine universelle Serverkonfiguration: Die Mechanismen hängen von den übertragenen Rechten, der Umgebung und den Anforderungen des Projekts ab. Eine allgemeine Dokumentation ersetzt nicht die Validierung des Zielsystems.
Eine Zugangsorganisation übergeben, die überprüfbar bleibt
Tragen Sie bei der Übergabe die genehmigte Matrix, die aktiven Identitäten, die zulässigen und abgelehnten Tests, die Fristen und die Person, die einen Zugang entziehen kann, zusammen. Vergewissern Sie sich, dass eine abwesende Person ersetzt werden kann, ohne ihr Geheimnis weiterzugeben. Die Kontinuität beruht auf einem Verfahren und einer autorisierten Ersatzverantwortung, nicht auf einem im Projektordner geteilten Passwort.
Überprüfen Sie bei der Übergabe die unnötig gewordenen Zugänge und die Automatisierungen, die von einer persönlichen Identität abhängen. Blockiert eine unerwartete Ablehnung die Arbeit, legen Sie einen gezielten Vorfallbericht mit technischer Identität, betroffenem Pfad und bereinigter Fehlermeldung an. Fügen Sie nicht einfach allgemeine Rechte hinzu, nur um das Symptom verschwinden zu lassen. Der richtige Abschluss ist ein notwendiger, getesteter Zugang mit einem bekannten Ende.
Fragen zur Entscheidung
Sollte das Capordia-Konto mit allen Beteiligten geteilt werden?
Nein. Die Verwaltung der Miete und die technischen Zugänge zur Arbeit sind getrennt zu organisieren. Definieren Sie die möglichen Maschinenidentitäten mit den tatsächlich übertragenen Rechten. Diese Methode setzt kein System für Einladungen oder Teamrollen im Capordia-Bereich voraus.
Vergibt ein öffentlicher Schlüssel automatisch die richtigen Rechte?
Nein. Er dient der Authentifizierung, wenn er autorisiert ist; die möglichen Aktionen hängen anschließend vom Konto und den Berechtigungen des Systems ab. Prüfen Sie eine erlaubte und eine abzulehnende Aktion anhand synthetischer Dateien.
Was ist nach dem Ausscheiden eines Beteiligten zu prüfen?
Entziehen Sie seine Berechtigungen, kontrollieren Sie die Ablehnung einer neuen Authentifizierung und prüfen Sie die weiterhin mit seiner Identität verbundenen Sitzungen, Arbeiten und Automatismen. Halten Sie eine autorisierte verantwortliche Person für Wiederherstellung und Nachverfolgung vor. Schließen Sie nicht allein aufgrund eines gesetzten Häkchens auf den Widerruf.