Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Sie können die Funktionen von Security Copilot erweitern, indem Sie ihre eigenen benutzerdefinierten Plug-Ins erstellen. Die Plattform unterstützt ein flexibles Framework zum Erstellen von Plug-Ins, mit denen spezielle Aufgaben ausgeführt werden können, die Ihren Workflowanforderungen entsprechen.
Erstellen neuer Plug-Ins
Je nachdem, wie Ihre Administratoren Security Copilot konfigurieren, können Sie möglicherweise neue Plug-Ins erstellen, indem Sie die folgenden Schritte ausführen:
Erstellen Sie ein Plug-In aus der Liste der unterstützten Plug-Ins.
Erstellen Sie eine YAML- oder JSON-Plug-In-Manifestdatei, in der Metadaten zum Plug-In und deren Aufruf beschrieben werden.
Veröffentlichen Sie das Plug-In-Manifest in Security Copilot.
Plug-In-Anforderungen
Jedes Security Copilot-Plug-In erfordert eine YAML- oder JSON-formatierte Manifestdatei (z. B.: plugin.yaml oder plugin.json), die Metadaten zu den Fertigkeiten beschreibt und erklärt, wie die Fertigkeiten aufgerufen werden.
Ein Manifest besteht aus zwei erforderlichen Schlüsseln der obersten Ebene, Descriptor und SkillGroups, jeweils mit Unterschlüssel- oder Wertpaaren sowie erforderlichen/optionalen Feldern je nach Qualifikationsformat.
Weitere Informationen finden Sie unter Agentmanifest.
Unterschiede zwischen OpenAI- und Security Copilot-Manifesten
OpenAI-Plug-Ins, die anhand der ChatGPT-Plug-In-Dokumentation erstellt wurden, verwenden in der Regel ein anderes Manifestformat als das Security Copilot-Manifestformat. Security Copilot unterstützt beide Formate.
Das OpenAI-Plug-In-Manifest wird beim Hochladen in das Security Copilot-Manifest übersetzt.
Hinweis
Zuordnungsdetails, insbesondere in Bezug auf Einschränkungen in Notizen, können sich in Zukunft ändern. Derzeit unterstützt die Plattform nur Plug-Ins in den OpenAPI-Versionen 3.0 oder 3.0.1.
Plug-In-Feldzuordnung
| Plug-In-Feld | Typ | Deskriptorfeld | Erforderlich | Notizen |
|---|---|---|---|---|
schema_version |
string | Nein | Dabei handelt es sich um die OpenAI-Manifestschemaversion, z. B. „v1“. Derzeit nicht verwendet. | |
name_for_model |
string | Name | Ja | Beschränkt auf die Länge von 100 Zeichen. Interner Name der Fertigkeiten. Lässt / \ ? # nicht zu. |
name_for_human |
string | DisplayName | Ja | Für Menschen lesbarer Name des Plug-Ins. Beschränkt auf die Länge von 40 Zeichen. |
description_for_model |
string | Beschreibung | Ja | Beschränkt auf eine Länge von 16.000 Zeichen. Interne Beschreibung für die Verwendung mit LLM. |
description_for_human |
string | DescriptionDisplay | Ja | Für Menschen lesbare Beschreibung des Plug-Ins. Beschränkt auf die Länge von 200 Zeichen. |
logo_url |
string | Symbol | Empfohlen | URL, die zum Abrufen des Hauptsymbols für das Plug-In verwendet wird. |
contact_email |
string | Nein | Email Kontakt für das Plug-In. Derzeit nicht verwendet. | |
legal_info_url |
string | Nein | Link für Plug-In-Informationen. Derzeit nicht verwendet. | |
api |
Objekt | Informationen zur Objektstruktur finden Sie im Abschnitt Plug-In-API. | Ja | |
auth |
Objekt | Ja |
authorization_type ist auf bearerbeschränkt. Details zur Unterstützung für verschiedene Authentifizierungen type wie none, oauth, api_key, aad, aad_delegated. |
Plug-In (API-Feld)
Objektstruktur für api-Feld
| Feld | Typ | Beschreibung | Erforderlich |
|---|---|---|---|
type |
string | Der einzige unterstützte Typ ist derzeit openapi. |
Ja |
url |
string | Link zu Ihrer OpenAPI-Spezifikationsdatei | Ja |
Leitfaden zur Erstellung von Plug-Ins
Es gibt viele Überlegungen zur Erstellung von Plug-Ins. Dieses Dokument soll einige der Richtlinien und bewährten Methoden zum Schreiben von Plug-Ins für Security Copilot erfassen.
Hinweis
Ein "Skillkonflikt" tritt auf, wenn Security Copilot nicht genau zwischen zwei verschiedenen Skills unterscheidet.
Anstatt über mehrere Fähigkeiten zu verfügen, die denselben Antworttyp zurückgeben, sich aber nur basierend auf Eingaben unterscheiden; Fähigkeiten definieren, die mehrere Eingaben erfordern und dann intern herausfinden, wie die Daten abgerufen werden.
- Wenn Sie beispielsweise eine einzelne
GetDevices-Fähigkeit verwenden, die entweder die Geräte-ID, die Benutzer-ID oder den Benutzernamen anstelle von separatenGetDeviceById,GetDeviceByUserIdundGetDeviceByUserNamebenötigt
- Wenn Sie beispielsweise eine einzelne
Sicherheits-Copilot unterstützt die Felder
DescriptionundDescriptionForModel.Descriptionwird in der UX verwendet (und für die Fähigkeitsauswahl, wennDescriptionForModelnicht festgelegt ist) undDescriptionForModelwird nur für die Fähigkeitsauswahl verwendet.- Angenommen, wir verfügen über die Fähigkeit „GetSslCertsByHostname“ mit der Beschreibung „Gibt die einem Hostnamen zugeordneten SSL-Zertifikate zurück“. Eine detaillierte descriptionForModel könnte lauten: „Ruft SSL-Zertifikate (auch als TLS-Zertifikate bezeichnet) für einen DNS-Hostnamen oder Domänennamen ab. Gibt eine Liste von SSL-Zertifikaten zusammen mit Zertifikatdetails wie Aussteller, Antragsteller, Seriennummer, Sha1 und Datumsangaben zurück“.
Die Beschreibungen der Fähigkeiten sollten ausführlich sein und für jemanden formuliert werden, der über ein gewisses Maß an Wissen verfügt, aber möglicherweise kein Experte in Ihrem Problembereich ist. Sie sollte nicht nur beschreiben, was die Fähigkeit bewirkt, sondern auch, warum jemand sie verwenden möchte.
- Eine gute Beschreibung lautet z. B. „Ruft Reputationsinformationen für eine IP-Adresse ab. Ermöglicht es Benutzern, festzustellen, ob eine IP-Adresse riskant ist“.