Wie Tresorsperre und Bildschirmsperre einen Agent-Test verändern

Ein gesperrter Bildschirm und ein gesperrter Tresor sind unterschiedliche Kontrollen. Wer beide gleich behandelt, erhält einen Test, der kaum etwas aussagt. Die macOS-Bildschirmsperre begrenzt den interaktiven Zugriff auf eine Benutzersitzung. Eine Tresorsperre muss geschützte Aktionen an der Stelle stoppen, an der Credentials verwendet würden. Das gilt auch für Aktionen, die von einem Prozess angefordert werden, dem Sie bereits vertraut haben, bevor Sie den Blick vom Bildschirm abgewendet haben.

Dieser Unterschied ist bei autonomen Programmier-Agents besonders wichtig. Ein Agent kann einen Prozess am Leben halten, Kontext behalten, Aufgaben planen und eine fehlgeschlagene Anfrage erneut versuchen. Ein Test, der lediglich bestätigt, dass niemand am Schreibtisch tippen kann, zeigt nicht, ob dieser Prozess weiterhin eine API aufrufen oder eine SSH-Verbindung öffnen kann. Testen Sie beide Zustände unabhängig voneinander und anschließend ihr Zusammenspiel.

Ich habe Teams erlebt, die das einen Test für einen „gesperrten Computer“ nannten, einen einzigen Screenshot des Sperrbildschirms machten und die Arbeit für abgeschlossen erklärten. Das ist ein Beleg für einen Sperrbildschirm. Es ist kein Beleg für eine absolute Verweigerungsgrenze rund um Credentials.

Ein gesperrtes Display entscheidet nicht, ob ein Prozess handeln kann

Eine macOS-Bildschirmsperre schützt die Konsolensitzung vor einer Person mit physischem Zugriff auf Tastatur und Display. Sie sagt für sich genommen nichts über jeden Prozess aus, der bereits unter dieser Sitzung läuft, über jede von ihm verwaltete Netzwerkverbindung oder über jeden Credential-Speicher, den eine App verwenden kann.

Apples Dokumentation zur Plattformsicherheit trennt die Benutzerauthentifizierung und den Sitzungsschutz vom Schutz von Geheimnissen wie Keychain-Einträgen. Diese Trennung ist hier hilfreich, selbst wenn Ihre konkrete Umgebung weniger Komponenten umfasst als in Apples Dokumentation. Die Fragen „War der Bildschirm gesperrt?“ und „Konnte der Agent eine Credential verwenden?“ sind verschieden und erfordern unterschiedliche Nachweise.

Ein Agent kann bei entsperrtem Bildschirm harmlos sein und trotzdem gefährlich werden, sobald er ein Bearer-Token in seiner eigenen Umgebung hat. Umgekehrt kann ein Agent während einer gesperrten Sitzung laufen und weiterhin keine geschützte Anfrage stellen, weil die Credential nie in seinen Speicher gelangt ist und das Aktions-Gateway sie ablehnt. Der Bildschirmstatus zeigt nicht, welches Design Sie haben.

Verwenden Sie bei der Prüfung diese praktische Definition:

• Eine Bildschirmsperre steuert die interaktive Nutzung des Macs.
• Eine Tresorsperre steuert, ob die geschützte Aktion ausgeführt werden darf.
• Die Sitzungsautorisierung steuert, ob dieser bestimmte Agent-Prozess während seiner Laufzeit geschützte Aktionen anfordern darf.
• Ein Schlüssel pro Aufruf steuert, ob eine Person diese konkrete Verwendung der Credential bestätigen muss.

Diese Kontrollen können in einer gelungenen Demo gut zusammenspielen. In der Produktion sollten sie nicht davon abhängen, dass sie immer zusammenspielen.

Das Tresortor braucht einen absoluten Ablehnungstest

Ein absolutes Tresortor bedeutet, dass ein gesperrter Tresor jede Aktion verweigert, bei der eine gespeicherte Credential verwendet würde. Die Ablehnung muss vor dem Einfügen der HTTP-Credential und vor der Authentifizierung durch den SSH-Helfer erfolgen. Sie muss für einen Prozess gelten, der zuvor erfolgreich war, nicht nur für einen neuen Prozess, dem noch nie vertraut wurde.

Sallyport macht diese Grenze ausdrücklich sichtbar: Solange sein Tresor gesperrt ist, wird jede Aktion abgelehnt. Auf unterstützter macOS-Hardware wird das Tresortor durch Secure Enclave und Touch ID hardwareseitig abgesichert. Das ist stärker und eindeutiger als eine Konvention wie „Der Agent sollte dieses Tool nicht aufrufen, während ich weg bin“.

Der aussagekräftigste Test beginnt mit Erfolg. Konfigurieren Sie einen kontrollierten Endpunkt mit geringen Folgen, zum Beispiel einen HTTP-Endpunkt, der nur die Request-Methode und eine undurchsichtige Anfrage-ID protokolliert, oder einen SSH-Host mit einem Befehl, der ein festgelegtes Wort ausgibt. Beginnen Sie nicht mit einem Produktionsendpunkt. Sie brauchen ein Ziel, dessen Logs Sie prüfen können, ohne ein aktives Geheimnis preiszugeben oder etwas Wichtiges zu verändern.

Lassen Sie den Agent-Prozess anschließend weiterlaufen, sperren Sie den Tresor über die App und fordern Sie dieselbe Aktion erneut an. Ein korrektes Ergebnis besteht aus drei Teilen:

1. Der Aufrufer erhält eine klare Ablehnung statt eines Timeouts oder eines allgemeinen Netzwerkfehlers.
2. Das Aktivitätsjournal protokolliert den Versuch als abgelehnt, mit genügend Kontext zur Identifizierung der Sitzung und des Credential-Pfads, ohne die Credential offenzulegen.
3. Ihr kontrollierter Endpunkt oder SSH-Host erhält keine neue Anfrage und keinen Befehl.

Der dritte Teil deckt einen Fehler auf, den ausgefeilte Benutzeroberflächen verbergen können. Ein Gateway kann eine Ablehnung anzeigen, nachdem es bereits eine authentifizierte Anfrage gesendet hat, weil die Prüfung in der falschen Schicht erfolgt. Das entfernte Log ist der entscheidende Zeuge.

Vermeiden Sie bei SSH einen Test wie ssh host true, wenn Ihr Testhost andere Identitäten aus Ihrer normalen Umgebung akzeptiert. Verwenden Sie den Kanal, den der Agent nutzen würde, sprechen Sie ein isoliertes Konto an und geben Sie ihm einen Befehl, dessen Auftauchen in den Server-Logs eindeutig erkennbar ist. Wenn Sie nicht nachweisen können, welche Identität die Verbindung hergestellt hat, testen Sie Ihre Shell-Konfiguration und nicht die Grenze des Tresors.

Eine frühere Freigabe darf das Tor nicht überdauern

Die Sitzungsautorisierung beantwortet eine engere Frage als das Tresortor: Darf dieser Agent-Prozess während dieses Laufs geschützte Aktionen verwenden? Sie ist keine dauerhafte Freigabe und kann einen gesperrten Tresor nicht außer Kraft setzen.

Hier verwechseln Teams häufig Bequemlichkeit mit Berechtigung. Sie geben einen Agenten frei, sehen mehrere erfolgreiche Aufrufe, sperren den Tresor und entsperren ihn später wieder. Wenn der Prozess seine Arbeit fortsetzt, nehmen sie an, dass die frühere Freigabe je nach gewünschtem Komfort entweder bestehen bleiben oder verschwinden sollte. Legen Sie dieses Verhalten anhand des tatsächlichen Kontrollmodells fest und testen Sie es anschließend. Die dokumentierte Entscheidungsreihenfolge der App setzt das Tresortor an die erste Stelle. Ein geschlossenes Tor hat Vorrang.

Führen Sie diese Abfolge aus, ohne den Agenten neu zu starten:

1. Starten Sie einen neuen Agent-Prozess und führen Sie einen geschützten Aufruf aus. Geben Sie seine Sitzung frei, sobald Sie dazu aufgefordert werden.
2. Führen Sie mit derselben gewöhnlichen Credential einen zweiten geschützten Aufruf aus. Bestätigen Sie, dass er ohne eine weitere Sitzungskarte erfolgreich ist.
3. Sperren Sie den Tresor, während der Prozess weiterläuft. Wiederholen Sie den Aufruf und bestätigen Sie die Ablehnung, bevor das entfernte Ziel ihn erhält.
4. Entsperren Sie den Tresor über die erforderliche lokale Interaktion. Wiederholen Sie den Aufruf und halten Sie fest, ob die bestehende Sitzung gemäß den dokumentierten Regeln fortgesetzt wird.
5. Beenden Sie den Agent-Prozess, starten Sie einen neuen Prozess und führen Sie denselben Aufruf aus. Bestätigen Sie, dass der neue Lauf seine eigene Autorisierungskarte erhält.

Schritt vier ist kein kosmetisches Detail. Er zeigt, ob das Produkt versehentlich „Der Tresor wurde geöffnet“ mit „Der gesamte laufende Code ist wieder vertrauenswürdig“ gleichsetzt. Schritt fünf zeigt, ob eine Prozess-ID, ein Terminal-Elternprozess oder eine ungenaue Client-Bezeichnung zu einer unbeabsichtigt langlebigen Freigabe geworden ist.

Die Freigabekarte sollte mit der Code-Signaturberechtigung des Prozesses beginnen. Ein Prozessname lässt sich leicht kopieren. Ein Pfad kann irreführend sein. Die Code-Signaturberechtigung gibt der zuständigen Person eine stabilere Grundlage, wenn der Agent-Prozess ein Geheimnis verwenden möchte. Halten Sie fest, was die Karte während Ihres Tests angezeigt hat, einschließlich dessen, was Sie gesehen hätten, wenn eine nicht vertrauenswürdige Kopie des Clients dieselbe Anfrage gestellt hätte.

Der Sperrbildschirm hat einen eigenen Zweck

Testen Sie die macOS-Bildschirmsperre, nachdem Sie das Verhalten des Tresors ermittelt haben. Ihre Aufgabe besteht darin, eine andere betriebliche Frage zu beantworten: Was kann weiterlaufen, wenn niemand an der Konsole sitzt, und wie erlangen Sie die Kontrolle zurück?

Lassen Sie den Tresor zunächst in dem vorgesehenen verfügbaren Zustand und starten Sie eine bereits autorisierte Sitzung. Lösen Sie eine harmlose geschützte Aktion aus, sperren Sie den macOS-Bildschirm, warten Sie lange genug für Ihr übliches Szenario unbeaufsichtigter Arbeit und prüfen Sie anschließend, ob die Aktion fortgesetzt werden konnte. Nehmen Sie die Antwort nicht an. Energieeinstellungen, Netzwerkstatus, Prozesslebensdauer und das eigene Tor der App wirken sich darauf aus.

Führen Sie dasselbe Experiment anschließend mit einem ausdrücklich gesperrten Tresor durch, bevor Sie den Bildschirm sperren. Das Ergebnis sollte einfacher sein: Versuche geschützter Aktionen werden abgelehnt. Wenn ein Agent weiterhin Text erzeugen oder lokale Dateien bearbeiten kann, liegt das außerhalb dieser engen Aussage. Die Aussage lautet, dass er einen gespeicherten API- oder SSH-Schlüssel nicht in eine externe Aktion umwandeln kann.

Dieses Testpaar trennt eine unangenehme, aber legitime Richtlinienentscheidung von einem Sicherheitsfehler. Manche Entwickler erlauben einem bereits freigegebenen Agenten bewusst, bei gesperrtem Display risikoarme Arbeit fortzusetzen. Andere verlangen, dass jede Abwesenheit den Tresor sperrt. Das sind betriebliche Entscheidungen. Wenn ein Agent nach dem Sperren des Tresors Credentials verwenden kann, ist die Grenze fehlgeschlagen.

Testen Sie das nicht, indem Sie aus einiger Entfernung einen Sperrbildschirm beobachten. Erfassen Sie Zeitstempel aus der Agent-Anfrage, vom kontrollierten Endpunkt und aus dem Aktivitätsjournal. Eine Anfrage, die vor dem Sperren des Bildschirms begonnen hat, kann danach abgeschlossen werden. Das beweist nicht, dass sie erst nach der Sperre begonnen hat. Die Reihenfolge ist entscheidend.

Freigaben pro Aufruf sind für Aktionen gedacht, deren pauschale Bestätigung Sie bereuen würden

Ein Schlüssel pro Aufruf verlangt für jede Verwendung dieser Credential eine menschliche Freigabe. Er sollte über einer freigegebenen Sitzung liegen, die Sitzungsprüfung nicht ersetzen und das Tresortor nicht schwächen.

Nehmen Sie eine solche Credential in den Testplan auf, auch wenn die meisten Schlüssel gewöhnliche Freigaben pro Sitzung verwenden. Wählen Sie eine Zielaktion mit sichtbarer, umkehrbarer Wirkung, etwa einen Test-Endpunkt, der einen Wegwerfzähler erhöht, oder einen SSH-Befehl, der eine Datei in einem temporären Verzeichnis anlegt. Sie wollen nachweisen, dass die App beim zweiten Einsatz erneut fragt und dass die Ablehnung der Aufforderung die externe Aktion verhindert.

Führen Sie den folgenden Test bei entsperrtem Bildschirm aus, damit Sie das Verhalten der Aufforderung vom Sitzungsstatus trennen können:

• Starten Sie einen neuen Agent-Prozess und geben Sie seine Sitzung frei.
• Verwenden Sie die Credential pro Aufruf und geben Sie diesen Aufruf frei. Prüfen Sie ein entferntes Ereignis.
• Verwenden Sie dieselbe Credential erneut und lehnen Sie die Freigabe ab. Prüfen Sie, dass kein zweites entferntes Ereignis eingetreten ist.
• Sperren Sie den Tresor und verwenden Sie sie noch einmal. Die Ablehnung durch den Tresor sollte erfolgen, ohne eine sinnvolle Möglichkeit zur Freigabe einer Aktion anzubieten, die das Tor nicht zulassen kann.

Die verbreitete Empfehlung, jede Credential pro Aufruf zu markieren, klingt vorsichtig, weil dadurch jede Aktion zu einer sichtbaren Entscheidung wird. In der Praxis gewöhnt sie Menschen daran, wiederholte Karten abzunicken, ohne sie zu lesen. Reservieren Sie diese Einstellung für Credentials, deren einzelne Verwendung Geld, Zugriff, den Veröffentlichungsstatus oder eine andere Konsequenz verändert, die Sie bewusst prüfen müssen. Für routinemäßige Aufrufe bietet eine sinnvolle Sitzungsfreigabe zusammen mit einem sperrbaren Tresor der zuständigen Person weniger, aber klarere Entscheidungen.

Ein entferntes Log erkennt die Ablehnung, die ein lokaler Test übersieht

Eine lokale Fehlermeldung beweist nur, dass der Aufrufer einen Fehler gesehen hat. Sie beweist nicht, dass keine authentifizierte Anfrage den Rechner verlassen hat, und sagt nichts über Wiederholungen aus, die später eingetroffen sind.

Bauen Sie ein Testziel, das eine kurze Anfrage-ID meldet, die Sie selbst wählen. Die Agent-Aktion kann einen harmlosen Header oder ein Anfragefeld im Body senden, etwa test_run=screen-vault-01, sofern der konfigurierte Credential-Pfad Ihres Gateways diese Form der Anfrage zulässt. Protokollieren Sie auf der Empfängerseite die Ankunftszeit, die Methode, die normalerweise verfügbaren Quellinformationen und diese ID. Halten Sie das Ziel von Produktionsdaten getrennt.

Ihr Testprotokoll sollte eine kleine Tabelle wie diese enthalten:

Das Wort „hängt ab“ in Zeile C ist bewusst gewählt. Verstecken Sie keine Richtlinienentscheidung in einer Bestanden/Nicht-bestanden-Spalte. Legen Sie fest, ob ein freigegebener Prozess in Ihrer Umgebung bei gesperrtem Bildschirm weiterarbeiten darf, und stimmen Sie das erwartete Ergebnis darauf ab.

Prüfen Sie bei HTTP die Anwendungs-Logs und nicht nur die Zugriffs-Logs, wenn ein Reverse-Proxy Anfragen ablehnen oder wiederholen kann, bevor die Anwendung sie sieht. Prüfen Sie bei SSH die Serveraufzeichnungen zur Authentifizierung und zu den Befehlen für das isolierte Konto. Verwenden Sie für jeden Testversuch eine neue ID. Wenn Sie ein Label wiederverwenden, entsteht eine Diskussion über verzögerte Zustellung, obwohl Sie ein eindeutiges Ergebnis brauchen.

Der Audit-Eintrag sollte den Zustandswechsel erklären

Eine gute Audit-Spur ermöglicht es einer prüfenden Person, nachzuvollziehen, wer den Agenten ausgeführt hat, welche Aktionen er versucht hat und ob das Gateway sie abgelehnt oder ausgeführt hat. Die prüfende Person sollte nicht raten müssen, ob ein fehlendes entferntes Ereignis durch eine Tresorsperre, eine unterbrochene Netzwerkverbindung oder einen Agenten verursacht wurde, der die Anfrage nie gestellt hat.

Die App führt ein Sitzungsjournal für Agent-Läufe und ein Aktivitätsjournal für einzelne Aufrufe. Beide stammen aus einem schreibgeschützten, verschlüsselten und hash-verketteten Audit-Log. Sie sind daher zwei Ansichten desselben zugrunde liegenden Datensatzes und keine konkurrierenden Logs mit unterschiedlichen Geschichten. Wenn ein Test einen Widerspruch zwischen den Journalen aufdeckt, behandeln Sie ihn als Testfehler, bis Sie ihn erklären können.

Halten Sie nach jedem Testlauf die folgenden Beobachtungen in Ihren Testnotizen fest:

• Die bei der Autorisierung angezeigte Sitzungsidentität sowie der Zeitpunkt Ihrer Freigabe oder Ablehnung.
• Der genaue Zeitpunkt, zu dem Sie den Tresor- und den Bildschirmstatus geändert haben.
• Das Erfolgs- oder Ablehnungsergebnis des Aufrufers für jede versuchte Aktion.
• Die zugehörigen Einträge im Aktivitäts- und Sitzungsjournal.
• Der Nachweis des kontrollierten Ziels, dass es die Aktion erhalten hat oder nicht.

Prüfen Sie anschließend die Kette offline mit:

sp audit verify

Ein erfolgreicher Lauf sollte melden, dass die Prüfung bestanden wurde, auch wenn der genaue Wortlaut je nach Version abweichen kann. Entscheidend ist, dass die Prüfung über Chiffretext funktioniert und das Öffnen des Tresors nicht erfordert. Dadurch kann eine geschützte Audit-Datei an eine prüfende Person übergeben werden, die Manipulationen feststellen muss, ohne Credentials oder die Möglichkeit zu erhalten, Aktionen auszuführen.

Überhöhen Sie die Aussage dieses Befehls nicht. Eine gültige Hash-Kette zeigt, dass die aufgezeichnete Reihenfolge nach dem Modell des Prüfers integer ist. Sie beweist nicht, dass Sie das richtige entfernte Log ausgewählt haben, dass Ihre Uhr korrekt geht oder dass ein Testziel keinen anderen Zugangsweg hatte. Kombinieren Sie sie mit den entfernten Nachweisen.

Die Prozesslebensdauer ist die Grenze, die viele auslassen

Eine Sitzungsautorisierung sollte enden, wenn der Agent-Prozess beendet wird. Testen Sie das ausdrücklich, denn „Ich habe ein neues Terminal geöffnet“ bedeutet nicht dasselbe wie „Der vorherige Prozess wurde beendet“. Ein Hintergrund-Supervisor kann ein Kind weiterlaufen lassen, nachdem seine Benutzeroberfläche verschwunden ist.

Beginnen Sie mit einer sauberen Ausgangslage. Beenden Sie den Agent-Prozess, bestätigen Sie mit Ihrer üblichen Methode zur Prozessprüfung, dass er verschwunden ist, und starten Sie anschließend über denselben Client-Pfad einen anderen Prozess. Sein erster geschützter Aufruf sollte eine neue Sitzung erzeugen und eine Autorisierung anfordern. Wenn er die Freigabe stillschweigend übernimmt, klären Sie, welche Identität diese Berechtigung übertragen hat. Das kann eine beabsichtigte Funktion sein, ist aber eine deutlich umfassendere Berechtigung, als eine Autorisierung pro Sitzung vermuten lässt.

Testen Sie außerdem einen fehlgeschlagenen Start und einen kopierten Client. Wenn ein Client-Prozess startet, eine Freigabe anfordert, vor einem Aktionsaufruf beendet wird und ein Ersatzprozess diese Freigabe verwenden kann, haben Sie einen Fehler in der Lebensdauer gefunden. Wenn ein anders signierter Prozess denselben freundlichen Namen verwendet, muss die Freigabeoberfläche der zuständigen Person genügend Berechtigungsinformationen geben, um ihn zu unterscheiden.

Das ist keine hypothetische Verwaltungsfrage. Agent-Tools entwickeln sich schnell weiter, und Wrapper starten Hilfsprozesse, stellen Verbindungen wieder her und erholen sich von Abstürzen. Der Prozess, der den geschützten Aufruf ausführt, ist das Objekt, das Sie autorisieren müssen. Ein Projektname oder ein Chatprotokoll ist keine Ausführungsidentität.

Schlafmodus, Neustart und Netzwerkausfall sind getrennte Experimente

Die Bildschirmsperre wird häufig auf einem aktiven Laptop getestet. Danach nehmen Menschen an, dass das Ergebnis auch für den Schlafmodus, einen Neustart und einen Netzwerkausfall gilt. Das tut es nicht. Jedes Ereignis verändert andere Teile des Systems.

Halten Sie beim Schlafmodus fest, ob der Agent-Prozess weiterläuft, ob der Mac den von Ihnen verwendeten Netzwerkpfad zulässt und ob sich der Tresorstatus ändert. Behandeln Sie beim Neustart jeden Agent-Lauf als neu und verlangen Sie vor der geschützten Nutzung eine neue lokale Entsperrung. Prüfen Sie bei einem Netzwerkausfall, dass ein fehlgeschlagener Aufruf keine unsichere Wiederholung auslöst, nachdem der Tresor gesperrt wurde oder der ursprüngliche Prozess beendet ist.

Halten Sie diese Experimente klein. Ein nützlicher Wiederholungstest verwendet eine Anfrage-ID und einen Empfänger, der unterscheiden kann, ob null, ein oder mehrere Eingänge eingegangen sind. Starten Sie die Anfrage, unterbrechen Sie den Netzwerkpfad zu einem kontrollierten Zeitpunkt, sperren Sie den Tresor, stellen Sie den Netzwerkpfad wieder her und beobachten Sie verzögerte Zustellungen. Wenn die Anfrage Nebenwirkungen hat, verwenden Sie einen Wegwerfempfänger. Eine gewöhnliche Leseoperation erneut zu versuchen ist etwas anderes, als eine zustandsverändernde Operation erneut zu versuchen.

Machen Sie daraus im Testdokument keine allgemeine Richtlinien-Engine. Die engere Frage lautet: Erzeugt die feste Entscheidungsreihenfolge auch dann den erwarteten Ablehnungszustand, wenn normale Computerereignisse einen Agenten unterbrechen? Klare Nachweise sind wertvoller als eine riesige Matrix ausgedachter Regeln.

Der fertige Testplan sollte eine eindeutige Aussage ermöglichen

Ihr fertiger Plan sollte es Ihnen ermöglichen, mit Nachweisen zu sagen, dass ein gesperrter macOS-Bildschirm und ein gesperrter Tresor unabhängig voneinander getestet wurden. Er sollte außerdem zeigen, ob ein freigegebener Prozess im unbeaufsichtigten Zustand handeln konnte, ob eine Freigabe pro Aufruf die zweite Verwendung blockierte und ob ein abgelehnter Aufruf das entfernte System nicht erreicht hat.

Formulieren Sie die abschließende Aussage in einfacher Sprache: „Wenn der Tresor gesperrt war, konnte der Agent die konfigurierte HTTP- oder SSH-Credential nicht verwenden, unabhängig davon, ob der macOS-Bildschirm gesperrt oder entsperrt war.“ Fügen Sie den Datensatz des entfernten Ziels und das Ergebnis der Audit-Prüfung hinzu. Ergänzen Sie anschließend Ihre separate betriebliche Entscheidung darüber, was ein freigegebener Agent tun darf, wenn nur der Bildschirm gesperrt ist.

Dieser letzte Satz verhindert die übliche Verwechslung in einer Vorfallprüfung. Jemand kann mit Ihrer Richtlinie für unbeaufsichtigte Arbeit nicht einverstanden sein. Die Richtlinie darf jedoch nicht mit einem Nachweis verwechselt werden, dass das Tresortor funktioniert hat.