Ein eigener Schlüssel für Automatisierung statt eines geteilten Passworts: Token und ihre Grenzen

Ein Sicherungsskript, ein Überwachungswerkzeug oder eine Bereitstellungsaufgabe muss sich mit dem System verbinden. Der erste Reflex ist, ein Passwort zu übergeben, und meist das des Kontos mit den meisten Rechten. Genau dort fangen die Probleme an.

Was ein übergebenes Passwort übergibt

Ein Passwort gehört einer Person. Gibst du einem Skript ein Passwort, hast du ihm alles gegeben, was diese Person hält, und das im Klartext in einer Datei. Ändert sich das Passwort, steht die Automatisierung, und wenn die Person geht, wird das Passwort geändert, aber dass die Automatisierung daran hing, fällt meist genau an diesem Tag auf.

Was ein Token leistet

Ein Token ist ein eigener, an ein Konto gebundener Schlüssel. Er trennt drei Dinge: er lässt sich einzeln widerrufen, er kann ein eigenes Ablaufdatum tragen, und weil er einen Namen hat, weiß man, welche Aufgabe ihn nutzt. Eine Automatisierung abschalten zu können, ohne ein Passwort zu ändern, wirkt wie ein Detail; je größer der Aufbau wird, desto nützlicher ist genau das.

Die eigentliche Frage: was der Token darf

Die wichtigste Einstellung an einem Token ist, ob er die Befugnis des Kontos unverändert mitträgt. Tut er das, ist der Token so mächtig wie sein Besitzer. Ist der Besitzer voll berechtigt, ist es der Token auch, und er liegt jetzt in einer Datei auf irgendeiner Maschine.

Mit eingeschalteter Trennung hält der Token nur die Befugnis, die dem Token selbst gegeben wurde. Einem Sicherungsskript gibst du gerade genug, um Sicherungen anzulegen, und selbst wenn dieses Skript kompromittiert wird, ist das alles, was abfällt. Wähle standardmäßig die enge Seite und öffne die weite nur bewusst.

Das Geheimnis wird einmal gezeigt

Beim Anlegen eines Tokens siehst du sein Geheimnis einmal. Das ist keine Marotte der Oberfläche: das System bewahrt diesen Wert nicht in lesbarer Form auf. Verlierst du ihn, legst du einen neuen an, und das ist das richtige Verhalten. Ließe er sich irgendwo zurücklesen, wäre genau das das eigentliche Problem.

Wo der Schlüssel am Ende lebt

Wo der Schlüssel liegt, zählt mehr als wie stark er ist. Ein in ein Repository eingechecktes Skript, eine Konfiguration, die in einer Sicherungsdatei gelandet ist, ein Fenster auf einem Bildschirmfoto: alle tragen den Schlüssel. Entscheide vor dem Anlegen, wohin er geschrieben wird.

Ablaufdatum und Erneuerung

Ein Schlüssel mit Ablaufdatum hört eines Tages auf, ein Risiko zu sein, auch wenn sich niemand kümmert. Einer ohne lebt jahrelang und überdauert meist den, der ihn angelegt hat. Setze zu jedem Schlüssel eine Notiz: welche Aufgabe ihn nutzt, wer zuständig ist.

Was Atlas tut

Atlas verwaltet Token je Konto. Beim Anlegen ist die Trennung der Token-Befugnis vom Konto standardmäßig eingeschaltet, die enge Seite ist also der Ausgangspunkt und das Aufweiten ein bewusster Schritt. Das Geheimnis wird im Moment des Anlegens einmal gezeigt und im Panel nicht aufbewahrt. Bestehende Token werden mit Notiz und Ablaufdatum aufgelistet, sodass die Frage "welche Automatisierung auf dieser Maschine verbindet sich mit welchem Schlüssel" durch Lesen beantwortet wird.