Best Practices für die Sicherheit von Cortex Code CLI¶
Zu den grundlegenden Sicherheitsverfahren für Cortex Code CLI gehören die Verwendung sicherer Authentifizierungsmethoden, der Schutz von Konfigurationsdateien, das angemessene Verwalten von Rollen und Zugriff, der sichere Umgang mit dem Konversationsverlauf und die Sicherstellung der MCP-Serverintegrität und das Befolgen von Produktionssicherheitsprotokollen.
Wichtig
In verwalteten Umgebungen kann Ihre Organisation eine auf Systemebene verwaltete Einstellungsdatei bereitstellen, die Richtlinien durchsetzt (z. B. den Zugriff auf Tools einschränkt, zulässige Konten einschränkt oder Umgehungsfunktionen deaktiviert). Weitere Details dazu finden Sie unter Verwaltete Einstellungen (Organisationsrichtlinie).
Anmeldeinformationen¶
- Verwenden Sie nach Möglichkeit eine browserbasierte Authentifizierung.
Die Standard-Authentifizierungsmethode für Cortex Code CLI ist eine browserbasierte Authentifizierung. Verwenden Sie
authenticator = "externalbrowser"in Ihrerconnections.toml-Datei, um diese Option manuell einzustellen.- Verwenden Sie programmgesteuerte Zugriffstoken (PATs), wenn Sie versuchen, den Zugriff auf eine bestimmte Rolle zu beschränken.
Generieren Sie dedizierte PATs in Snowsight (siehe Verwenden von programmatische Zugriffstoken für die Authentifizierung). Stellen Sie den Ablauf auf ≤ 90 Tage ein, verwenden Sie beschreibende Namen, und rotieren Sie regelmäßig.
- Schützen von Konfigurationsdateien
Verwenden Sie den Modus
600für Konfigurationsdateien und700für Verzeichnisse, um den Zugriff auf nur Ihren Benutzenden zu beschränken.chmod 600 ~/.snowflake/connections.toml chmod 700 ~/.snowflake/cortex
- Niemals Anmeldeinformationen committen
Fügen Sie sensible Konfigurationsdateien zu
.gitignorehinzu.echo "~/.snowflake/connections.toml" >> ~/.gitignore
Verwenden Sie Umgebungsvariablen, um Anmeldeinformationen und Token zu speichern, und binden Sie diese mit der
${VARIABLE_NAME}-Syntax in Ihre Konfigurationsdateien ein.
Rollen und Zugriff¶
- Verwenden Sie für die jeweilige Umgebung geeignete Rollen.
Verwenden Sie z. B. eine Nur-Lese-Rolle in der Produktion und eine umfangreichere Rolle in der Entwicklung.
[dev] role = "DEVELOPER" [prod_readonly] role = "ANALYST"
Verwenden Sie niemals
ACCOUNTADMINfür Routineoperationen. Gewähren Sie die geringsten Berechtigungen.
Konversationsverlauf¶
Konversationen werden in ~/.snowflake/cortex/conversations/ gespeichert. Verwenden Sie cortex --private beim Starten von Cortex Code, um das Speichern von Sitzungen für sensible Aufgaben zu deaktivieren. Verwenden Sie alternativ den /clear-Befehl, um die aktuelle Sitzung zu löschen, bevor Sie Cortex Code CLI beenden.
Verwenden Sie Modus 700, um den Zugriff auf den Konversationsverlauf auf nur Ihren Benutzenden zu beschränken.
chmod 700 ~/.snowflake/cortex/conversations
MCP-Sicherheit¶
- Installieren Sie nur vertrauenswürdige MCP-Server.
Überprüfen Sie die Quelle und Integrität der MCP-Server, bevor Sie sie hinzufügen. Verwenden Sie die folgenden Befehle, um eine Liste der Server zu erhalten und alle nicht vertrauenswürdigen Server zu entfernen:
cortex mcp list cortex mcp remove <server>
- Führen Sie niemals eine Hartcodierung von MCP-Anmeldeinformationen aus.
Verwenden Sie Umgebungsvariablen. Legen Sie zunächst Folgendes in Ihrer Shell fest:
export GITHUB_TOKEN="your_token"
Dann referenzieren Sie sie in Ihrer MCP-Konfiguration:
{ "mcpServers": { "github": { "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" } } } }
Produktionssicherheit¶
- Planungsmodus aktivieren
Verwenden Sie den
/plan-Befehl, um beabsichtigte Aktionen vor der Ausführung zu überprüfen./plan Drop and recreate the ANALYTICS schema
Wenn Ihr persönliches Zugriffstoken kompromittiert wird¶
Widerrufen Sie das PAT sofort in Snowsight! Generieren Sie dann ein neues Token, und verwenden Sie es stattdessen. Denken Sie daran, dass Sie das Token nicht in Konfigurationsdateien verwenden. Verwenden Sie stattdessen Umgebungsvariablen.
Überprüfen Sie den Abfrageverlauf, um verdächtige Aktivitäten zu erkennen.
SHOW QUERIES IN ACCOUNT
Verwaltete Einstellungen (Enterprise-Richtlinie)¶
In einigen Organisationen stellen Administratoren verwaltete Einstellungen bereit, die Richtlinien für Cortex Code-CLI durchsetzen. Verwaltete Einstellungen können die Konfiguration auf Benutzerebene einschränken oder überschreiben (einschließlich Berechtigungsabfragen und Umgehungsverhalten).
Weitere Informationen dazu finden Sie unter Verwaltete Einstellungen (Organisationsrichtlinie).
Berechtigungen¶
Cortex Code hat drei Betriebsmodi:
Modus |
Indikator |
Befehle mit vorangestelltem Schrägstrich |
Beschreibung |
|---|---|---|---|
Aktionen bestätigen |
Blau ⏵⏵ |
Standardmodus |
Fordert vor potenziell schädlichen Aktionen eine Erlaubnis an. |
Plan |
Orange ⏸ |
|
Präsentiert einen Plan, bevor eine Aktion ausgeführt wird. |
Umgehen |
Rot >> |
|
Alle Tool-Aufrufe sind genehmigt. |
Drücken Sie Shift-Tab in Cortex Code CLI, um zwischen diesen Modi zu wechseln.
Warnung
Der Umgehungsmodus deaktiviert alle Eingabeaufforderungen zur Bestätigung. Verwenden Sie diese Funktion nur in vertrauenswürdigen Umgebungen.
Berechtigungstypen¶
Die folgenden Berechtigungsstufen gelten für Aufrufe von Cortex Code-Tools:
Typ |
Beschreibung |
|---|---|
EXECUTE_COMMAND |
Ausführen von Bash-/Shell-Befehlen |
FILE_READ |
Lesen von Dateiinhalt |
FILE_WRITE |
Erstellen/Ändern von Dateien |
FILE_EDIT |
Bearbeiten von bestehenden Dateien |
WEB_ACCESS |
Operationen für Websuche/Abruf |
Vertrauensmodell¶
Cortex Code klassifiziert Befehle und Operationen nach Risiko, wie die folgende Tabelle zeigt:
Level |
Beispiele |
Verhalten |
|---|---|---|
SAFE |
|
Automatisch genehmigt |
LOW |
Erstellen von neuen Dateien (z. B. |
In der Regel automatisch genehmigt |
MEDIUM |
Bearbeiten von Dateien (z. B. |
Eingabeaufforderungen im Bestätigungsmodus |
HIGH |
|
Fordert immer an |
CRITICAL |
|
Zusätzliche Bestätigung |
Shell- und SQL-Befehle werden auf der Grundlage ihrer potenziellen Auswirkungen klassifiziert.
Shell-Befehle¶
Befehle werden auf gängige Risikofaktoren analysiert.
- Riskante Befehle
rm,sudo,curl,wget,sshsystemctl,chmod,chowngit push --force,git reset --hard
- Gefährliche Flags
-rf,--force,--recursive--no-preserve-root
- Gefährliche Muster
Pipe zu Shell:
curl | bashHerunterladen und Ausführen
Versteckter Dateizugriff (
.-Präfix)Zugriff auf Systempfad (
/etc,/var,/usr)
SQL-Abfragen¶
SQL ist nach Operationstyp kategorisiert:
Kategorie |
Operationen |
Verhalten |
|---|---|---|
READ_ONLY |
SELECT, SHOW, DESCRIBE |
Automatisch genehmigt |
WRITE |
INSERT, UPDATE, DELETE, CREATE |
Eingabeaufforderungen |
USE_ROLE |
USE ROLE, USE WAREHOUSE |
Eingabeaufforderungen |
Sandbox-Berechtigungen¶
Wenn Sandboxing aktiviert ist:
Sandbox-Modus |
Verhaltensweise von Berechtigungen |
|---|---|
Container + Auto |
Sandbox-Befehle werden automatisch genehmigt |
Container + Reguläres |
Alle Befehle fragen ab |
OS + Auto |
Sandbox-Befehle werden automatisch genehmigt |
OS + Regulär |
Alle Befehle fragen ab |
Hook-Integration¶
Sie können die Berechtigungsrichtlinie mit Hooks anpassen. Hier ist ein Beispiel für einen Prä-Ausführungs-Hook, der Bash-Befehle automatisch genehmigt:
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "bash .claude/hooks/auto-approve.sh"
}
]
}
]
}
}
Dieser Hook könnte eine JSON-Antwort wie die folgende zurückgeben, um Bash-Befehle automatisch zu genehmigen.
{
"hookSpecificOutput": {
"hookEventName": "PreToolUse",
"permissionDecision": "allow",
"permissionDecisionReason": "Approved by policy"
}
}
Berechtigungsaufforderungen und Caching¶
Wenn Cortex Code Ihre Erlaubnis benötigt, um mit einer Operation fortzufahren, werden Sie mit Details zu der Anfrage unterstützt. Sie können die Anfrage genehmigen oder ablehnen. Sie können sich Ihre Wahl auch bei künftigen ähnlichen Anfragen merken:
„(Diese Sitzung) immer zulassen“ bleibt erhalten, bis Sie Cortex Code CLI beenden.
„Immer zulassen (beibehalten)“ bleibt auf unbestimmte Zeit gespeichert.
Diese Antworten werden zwischengespeichert und je nach Bedarf auf das Projektverzeichnis, den Tooltyp oder das Befehlsmuster beschränkt.
Permanente Berechtigungen werden in ~/.snowflake/cortex/permissions.json gespeichert. Nachfolgend sehen Sie ein Beispiel für einen Cache:
{
"/path/to/project": {
"Bash": {
"npm test": "allow",
"make build": "allow"
},
"Write": {
"*": "allow"
}
}
}
Löschen Sie diese Datei, um alle permanenten Berechtigungen zurückzusetzen. Um Berechtigungen für ein bestimmtes Projekt zurückzusetzen, löschen Sie den entsprechenden Eintrag.
Um den Sitzungscache zurückzusetzen, verwenden Sie den Befehl /new, der eine neue Sitzung startet, oder beenden Sie Cortex Code CLI, und starten Sie es neu.
Konfiguration¶
Stellen Sie die unten beschriebenen Umgebungsvariablen ein, um das Berechtigungsverhalten zu steuern:
Variable |
Beschreibung |
|---|---|
|
Legt das Standard-Timeout für den Sitzungsberechtigungscache fest (in Sekunden). |
|
Wenn auf |
Sicherheitscheckliste¶
Verwenden Sie PATs mit einem Ablauf von höchstens 90 Tagen
Setzen Sie die Dateiberechtigungen auf 600/700
Übertragen Sie niemals Anmeldeinformationen an Git
Verwenden Sie Rollen mit den geringsten Berechtigungen
Verwenden Sie niemals ACCOUNTADMIN für Routinearbeiten
Aktivieren Sie den Planungsmodus für die Produktion und reservieren Sie den Umgehungsmodus für vertrauenswürdige Umgebungen
Installieren Sie nur vertrauenswürdige MCP-Server.
Speichern Sie Anmeldeinformationen in Umgebungsvariablen
Verwenden Sie Hooks, um Richtlinien durch die Automatisierung von kundenspezifischen Sicherheitsprüfungen durchzusetzen
Überprüfen Sie die Berechtigungen regelmäßig