Eigene benutzerdefinierte Plug-Ins erstellen
Wichtig
Einige Informationen in diesem Artikel beziehen sich auf ein vorab veröffentlichtes Produkt, das vor der kommerziellen Veröffentlichung möglicherweise erheblich geändert wird. Microsoft übernimmt mit diesen Informationen keinerlei Gewährleistung, sei sie ausdrücklich oder konkludent.
Tipp
Wenn Sie Hilfe zu nicht von Microsoft stammenden Plug-Ins benötigen, lesen Sie deren Dokumentation und technischen Support.
Neuer Plug-Ins werden erstellt
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.
Informationen zu OpenAI-Plug-Ins finden Sie unter Erste Schritte.
Zusammenfassung des Deskriptorfelds
Feld | Typ | Beschreibung | Erforderlich |
---|---|---|---|
Name |
string | Interner Name des Plug-Ins. Lässt / \ ? # @ nicht zu. |
Ja |
DisplayName |
string | Für Menschen lesbarer Name des Plug-Ins. | Empfohlen |
Description |
string | Für Menschen lesbare Beschreibung des Plug-Ins. | Ja |
DescriptionDisplay |
string | Alternative, für Menschen lesbare Beschreibung des Plugins, wenn keine Beschreibung angegeben ist. | Nein |
Category |
string | Hinweis: Dieser Wert wird derzeit auf Plugin während des benutzerdefinierten Plugin-Upload-Prozesses erzwungen. |
Nein |
Prerequisites |
string | Nein | |
Icon |
string | URL zum Abrufen des Hauptsymbols für die Fertigkeiten. | Empfohlen |
SkillGroups-Feldzusammenfassung
Besteht aus einer Liste von Qualifikationsgruppen, einschließlich Format
, Settings
und Skills
.
Feld | Typ | Beschreibung | Erforderlich |
---|---|---|---|
Format |
string | Verfügbare Optionen finden Sie im Abschnitt Format. | Ja |
Settings |
Objekt | Informationen zur Objektstruktur finden Sie im Abschnitt Einstellungen. | Ja, für Formate: API , DOTNET , CONTAINER |
Skills |
Objekt | Informationen zur Objektstruktur finden Sie im Abschnitt Fertigkeiten. | Ja, für Formate: GPT , DOTNET , KQL , LogicApp |
Format (SkillGroups-Feld)
Optionen für Format
-Feld:
API
GPT
KQL
Einstellungen (SkillGroups-Feld)
Objektstruktur für Settings
-Feld.
Feld | Typ | Beschreibung | Erforderlich |
---|---|---|---|
OpenApiSpecUrl |
string | URL für öffentliche OpenAPI-Spezifikation. | Ja |
EndpointUrl |
string | URL für öffentlichen Endpunkt. | Nein |
Fertigkeiten (SkillGroups-Feld)
Objektstruktur für Skills
-Feld.
Feld | Typ | Beschreibung | Erforderlich |
---|---|---|---|
Description |
string | Für Menschen lesbare Beschreibung für diese Fähigkeit. | Empfohlen |
DescriptionForModel |
string | Detaillierte Beschreibung der Fähigkeit, die für die Fähigkeitsauswahl verwendet wird | Nein |
Inputs |
Objekt | Liste der Objekte Name , Description , Required und DefaultValue (optional) für Benutzereingaben für die Fähigkeit. |
|
Settings |
Objekt | Benutzerdefinierte Einstellungen basierend auf dem Fertigkeitsformat. |
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 bearer beschrä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 zum Dokument der OpenAPI-Spezifikation der API. | 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 "Fähigkeitskonflikt" tritt auf, wenn Security Copilot nicht genau zwischen zwei verschiedenen Fähigkeiten unterscheidet.
Anstatt über mehrere Fähigkeiten zu verfügen, die denselben Antworttyp zurückgeben, sich aber nur basierend auf Eingaben unterscheiden; definieren Fähigkeiten, die mehrere Eingaben annehmen 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
,GetDeviceByUserId
undGetDeviceByUserName
benötigt
- Wenn Sie beispielsweise eine einzelne
Sicherheits-Copilot unterstützt die Felder
Description
undDescriptionForModel
.Description
wird in der UX verwendet (und für die Fähigkeitsauswahl, wennDescriptionForModel
nicht festgelegt ist) undDescriptionForModel
wird 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“.